Audit trail and evidence

What this page is#

Almost every regulatory claim in this system rests on the audit trail, so this page says exactly what it records, how tampering is found, who can check it and where it stops. How to read and filter it on screen is on Review the audit trail; the list of every event type is the generated Audit events.

What is recorded#

Every event carries:

Entering a value and modifying one are separate event types, so a first entry and a later correction are told apart at a glance.

What causes an event. A change to anything governed writes a domain event with its before and after. Every mutating request also writes a request event, and every refusal writes an access decision (authz.decision): a person asking "did anyone try to reach data they should not have?" gets an answer. Sign-ins, signatures, locks and the platform's own acts are events of their own.

What does not. A successful read (opening a participant, a report or the trail) is not recorded. Document downloads and previews are the exception. The API's access log in the hosting's logs is the only record of a read (Not built yet).

How the record is made#

An event is queued in the same database transaction as the change it describes, so a change and its event commit together or not at all. The worker's relay then appends it to the ledger, in order, within a fraction of a second at the loads that were measured (the slowest event in any of the load tests took 0.82 s to appear; Testing and quality). An event that cannot be appended is retried and then set aside, visibly, with its error; the operator is alerted if events are waiting.

How tampering is detected#

Four layers, each catching what the one before cannot.

1. The table refuses. The application's database role can read and insert on the ledger and nothing else, and triggers refuse UPDATE, DELETE and TRUNCATE in every session, including a session that has switched triggers off. In production the server refuses to start if the role it is running as could change the ledger (The database).
2. The chain. The ledger is not one list but one chain for each organization, study and workspace, each with its own gapless position, its own genesis and its own head. Each event stores a SHA-256 hash of itself and of the event before it, over a canonical form of the event (properties in a fixed order, timestamps normalized), so inserting, removing or editing one breaks the chain at that point and the verification says where.
3. Verification on a schedule. The worker walks each chain every hour from its last checkpoint and in full once a week, records any break, and raises a critical alert (audit.chain_integrity) that clears when the chain verifies again.
4. Anchors outside the database. A hash chain cannot by itself reveal events cut off its end, together with the head that remembered them, by someone who can write the database. So the end of each chain is written once a day to storage that cannot be rewritten (S3 Object Lock in compliance mode), and a chain that no longer holds what was anchored fails verification whatever else is attested. In production the server refuses to start without anchoring, unless that is waived explicitly.

Who can check it#

Held by: Organization Admin, Project Manager, Clinical Research Associate, Data Manager, Medical Officer, Sponsor Manager, Auditor, Principal Investigator, Clinical Research Coordinator, Site Monitor, Clinical Data Coordinator, Regulatory Manager (audit.read).

Held by: Organization Admin, Auditor (audit.verify).

Reading the trail needs audit.read (a person at a site reads their own site). Verifying the chain is a separate permission held by the Auditor and the Organization Admin; that the Auditor holds it independently is the point, because an administrator is a subject of the audit and not only its custodian. The same walk runs in the background without anyone asking.

What cannot be changed#

• Audit events: append-only, as above.
• Query threads: comments and status changes cannot be edited or removed, an administrator included, by a trigger in the database.
• Signatures: never modified. A change under a signature withdraws it as a record of its own, and the original still proves what was signed.
• Captured values: a change is a new row that supersedes the old, so every value ever saved is still there.
• Design snapshots: a form version and the whole design are frozen with a content hash when submitted; the exact form used for any captured value can be reproduced.
• Retired and withdrawn things: sites, rules, documents, assignments, participants and on-demand records are retired, never deleted.

Where to look#

A study has two trails so that test activity is never read beside production's. Whoever holds the right to read both reads them one after the other, never merged.

What depends on your hosting#

Retention, backup and restoration of the ledger are properties of how the database is run, and so is the retention period. The application checks that the last backup is recent and raises an alert when it is not, and it verifies the restored copy's hash chain in the weekly restore check, but taking, keeping and testing backups is the operator's (Running it). A person with administrative access to the database host is outside what the application can protect; the daily anchor is what makes cutting events off the end of a chain findable.

Compliance Q&A#

Related#

Review the audit trail · Audit events · 21 CFR Part 11 · ALCOA+ · Security and hosting · Auditor