Law Firm Security Checklist for AI Timekeeping

AI timekeeping can observe the texture of legal work: the document an attorney edited, the email they answered, the meeting they attended, and the matter that work may belong to. That makes security diligence more consequential than checking whether a vendor has a familiar badge.

The useful question is not simply, “Is this product secure?” It is: What does the product observe, where does each form of data go, who can act on it, what persists, and what evidence supports every answer?

Use this checklist with your firm’s security, privacy, legal, client-relations, and billing teams. It is an evaluation framework, not legal advice. Applicable law, professional rules, protective orders, and client instructions may require controls beyond any vendor’s standard configuration.

How to use the checklist

For every material answer, record four things:

1. Behavior: what the product does in production today.
2. Evidence: a demonstration, architecture document, audit report, or other artifact that supports the answer.
3. Contract: the promise that should survive a product or policy change.
4. Owner: the person at the vendor and the firm responsible for the control.

This prevents a common diligence error: treating a product setting, a marketing statement, an independent examination, and a contractual commitment as if they were interchangeable.

1. Define the permitted use before examining the technology

Name the approved business purpose. Is the system being considered only to prepare draft time entries, or also to analyze activity, enforce billing guidelines, or improve the vendor’s models? List prohibited uses as explicitly as the approved ones.

Then identify matters that need special treatment. Client AI policies, protective orders, confidentiality commitments, regulatory duties, and geographic restrictions may vary by matter. The ABA’s Model Rule 1.6 commentary describes safeguarding information as a reasonableness analysis that considers its sensitivity and special client requirements. The Model Rules are models, not the governing rules in every jurisdiction, but they illustrate why a firm-wide approval alone may be insufficient.

Record: approved purpose, excluded matters, required notices or approvals, firm risk owner, and review date.

2. Inventory exactly what the product observes

Ask for a source-by-source inventory covering desktop applications, browser activity, email, calendar, documents, meetings, phones, mobile devices, billing systems, and offline work. For each source, distinguish:

• content from metadata;
• page text from URLs and titles;
• application events from screenshots;
• timestamps from measured duration;
• source evidence from activity derived by a model.

Request a live demonstration of pause and exclusion controls. Test personal activity and at least one sensitive matter. Also document what the product misses, because a gap that is not visible to the reviewer can create a misleadingly complete-looking record.

For example, Hourglass can collect rich browser content and metadata through its authorized extension. A user can pause that browser collection. Supported exclusions can apply to clients, matters, people, applications, URLs, and content controls; time-window exclusions are not currently supported.

3. Draw the complete data path

Do not accept “encrypted in the cloud” as a data-flow explanation. Follow one work event from its collection and transmission through processing, any model provider, the derived activity record, the draft entry, human review, approval, delivery to the billing system, and eventual retention or deletion.

Draw side paths for operational logs, diagnostics, analytics, caches, and backups. Label the legal entity and processing region at each stage. Keep raw evidence, derived activity, draft entries, approved entries, configuration, and telemetry as separate data layers; they rarely have identical access or retention rules.

Hourglass publicly describes processing in a firm’s US-hosted environment, restricted third-party model processing, human review, and export of approved entries to the billing system. Its internal topology is appropriately reserved for diligence rather than published in full.

4. Separate the AI questions

“No training” and “zero data retention” answer different questions. Ask each vendor:

• Does the vendor use customer data, drafts, corrections, or approvals to evaluate, personalize, train, or improve its own features or models?
• Does a third-party model provider retain inputs or outputs?
• May that provider use data to train its own general-purpose models?
• Can provider personnel review content for support or abuse monitoring?
• Is processing pooled across customers or isolated by customer or purpose?

Hourglass may use customer data, generated entries, corrections, approvals, and feedback to evaluate, personalize, and improve Hourglass features and models. Its US-based third-party model endpoints operate under zero-data- retention terms, and those providers are restricted from using customer data to train their own general-purpose models. Those two statements belong together: a restriction on a subprocessor is not a categorical promise about the application vendor’s own improvement practices.

Request a current subprocessor list and change-notification process, and put material data-use restrictions in the agreement.

5. Build a role-by-data-layer access matrix

Test what a timekeeper, delegate, supervisor, billing administrator, firm administrator, vendor support worker, vendor engineer, and subprocessor can see or change. Repeat the test for raw activity, source content, drafts, approved entries, compliance flags, settings, and audit history.

Ask how privileged access is approved, limited, reviewed, and logged. Hourglass limits production-data access to approved personnel with an explicit reason and requires PII training for personnel with that access. Buyers should still inspect the detailed access procedure during diligence rather than infer every control from that summary.

Verify identity controls individually. Hourglass supports SSO and directory provisioning, including provisioning and deprovisioning, through WorkOS. Do not assume that naming an identity platform means every feature of that platform is implemented.

6. Verify customer separation and encryption

Ask the vendor to describe separation across the application, database, object storage, logs, backups, keys, and administrative access. Then ask how the boundary is tested and what evidence would reveal a failure.

Hourglass gives each firm its own application deployment and database; customer application data is not pooled into a shared firm database. Its security overview describes encryption in transit and at rest. During diligence, verify the report scope and technical coverage rather than turning those statements into a broader claim that every component is unique to one customer.

7. Write a retention schedule by data layer

A single “30 days” answer is usually incomplete. Record the period, deletion trigger, exceptions, and verification method for:

• raw evidence and derived activity;
• model inputs and outputs;
• drafts and approved entries;
• diagnostics, logs, and caches;
• backups and exported data.

For Hourglass, core customer records follow the firm’s configured retention and enterprise agreement. Processing data (including model inputs and outputs, diagnostics, and operational logs) generally follows a rolling period of no more than 30 days, subject to contractual, investigation, or legal exceptions. These rules should not be compressed into “all customer data is deleted within 30 days.”

Test offboarding too: export, access termination, integration disconnection, deletion timing, exceptions, and confirmation.

8. Inspect the assurance evidence, not the logo

SOC 2 is an examination and reporting framework, not a guarantee that an incident cannot occur. The AICPA’s SOC resources explain the reporting family. Request the current report under NDA and review the system description, examination period, Trust Services Criteria, exceptions, subservice organizations, and complementary user-entity controls.

Hourglass has completed a SOC 2 Type II examination, and the report is available through its customer diligence process. That statement should not be expanded into claims about ISO 27001 or other certifications without separate evidence.

9. Test logging, response, and recovery

Identify which authentication, administrative, data-access, configuration, approval, override, and export events are logged. Ask who monitors alerts, how suspicious activity is investigated, whether the firm can obtain relevant records, and how log integrity is protected.

Review the incident-response plan and the contract. Define the event that starts the notification clock, who receives notice, what it contains, and how updates follow. Hourglass’s customer contract provides notice to affected firms within 72 hours; that is a contractual commitment, not a claim that one deadline applies under every law.

Also review backup protection, recovery objectives, restoration testing, and continuity plans. The NIST Cybersecurity Framework 2.0 organizes risk management across Govern, Identify, Protect, Detect, Respond, and Recover. Use that lifecycle as a questioning aid, not as proof that a vendor conforms to NIST.

10. Preserve human control and billing integrity

Security includes preventing unsupported data from becoming an authoritative billing record. Confirm that the user can inspect uncertainty, correct attribution, edit or reject a draft, and see what changed.

Hourglass retains an audit record connecting original evidence, model suggestions, user edits, approvals, overrides, and export history. No draft is exported to the billing system without explicit human approval. A serious pilot should test weak evidence, excluded content, incorrect matter attribution, delegate workflows, and a failed integration, not only the best-looking demo path.

The final procurement test

Before approval, choose one representative work event and prove the full chain. Show what was collected, where it was processed, which model provider received it, who could view it, how the draft was reviewed, what reached the billing system, what was logged, and when each remaining copy is deleted.

Then attach the answers that matter to the DPA, security schedule, subprocessor terms, retention schedule, support-access rules, and incident provisions. Revisit the review when the vendor adds a material data source, model use, or subprocessor.

That is the durable standard for AI timekeeping security: not a universal “safe” label, but an evidence chain the firm can inspect, assign, test, and enforce.