← All posts

Audit-ready: how to prove who saw what, when

James Liu · 2025-09-10

When a regulator asks who accessed a document and when, "we'll get back to you" is not an answer. By the time you have an answer, the inquiry has become an investigation.

What 'audit-ready' actually means

An audit trail is "ready" when it satisfies four properties:

The four log questions

Every regulator inquiry boils down to some combination of:

  1. Who accessed it?
  2. When?
  3. From where (IP, geography, device)?
  4. What did they do with it (read, download, forward, modify)?

If your current system can't answer all four for any document in your possession, you have an audit-readiness gap. The gap is the project.

Tamper-evidence vs encryption

These solve different problems. Encryption keeps unauthorized eyes off the data. Tamper-evidence keeps the audit log itself honest — including against insider modification. A well-designed system uses both: encrypted storage of the documents, hash-chained logs of the access events.

The naive mistake is to put audit logs in the same database as the rest of your application data. A privileged user can rewrite them. Defense-in-depth requires logs to either (a) live in a system the application can append to but not modify, or (b) be cryptographically chained so modifications are detectable.

Storage and retention

Common retention floors for audit logs:

For most professional services firms, 7 years is a defensible default. Use WORM-style storage (write-once-read-many) for the long-tail retention so even admins can't quietly truncate the log.

An audit trail you can't query is an audit trail you can't use. Build the answer-in-minutes capability before you need it.


Written by James Liu. Have feedback? Reach out at hello@verifypg.com.