Capture writes one audit row per changed field, append-only and chained with SHA-256 hashes, and the trail is always exportable. This page shows what an inspector asks, what the export lets you answer, and how to rehearse it.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Weight changed 68.0 to 68.5 kg
Site coordinator · Reason: Transcription error
Query Q-0014 answered on Weight
Site coordinator · Reason: Source checked
Vital signs form locked
Data manager · Reason: Visit cleaned
What to know first
What inspectors ask
An inspector reading electronic data does not start with the software brochure. They pick a value, usually one that looks interesting, such as a late lab result, a changed severity or a dose entered after the visit, and ask who entered it, when, what it was before, and why it changed. Then they ask whether anyone could have altered that history, and how you know.
Regulators expect computerised systems used in trials to keep secure, computer-generated, time-stamped audit trails that record changes without obscuring the original entry, and to let the sponsor or site provide copies for inspection. The general anchors are 21 CFR Part 11 (audit trails and accurate, complete copies of records) and the EMA guideline on computerised systems and electronic data in clinical trials, with Annex 11 expectations in the EU. See Annex 11 vs 21 CFR Part 11 and the FDA inspection checklist for clinical trial data.
A good audit trail answers three different questions: what changed (old and new value), who and when (identity and time, plus IP address where recorded), and can it be trusted (tamper-evidence). Many systems answer the first two; the third is where the hash chain and the append-only rule matter, because they let you show that a row was not changed or removed after the fact.
What is recorded
The trail is not assembled by the application on a good day. It is written by database triggers, so a change made through any path in the application produces a row, and the application cannot skip it.
| Field | Old | New | Reason | |
|---|---|---|---|---|
| 12 Oct 09:14 · site.user.a | AESEV | Mild | Moderate | Corrected after source review |
| 12 Oct 09:16 · site.user.a | AEOUT | (blank) | Recovering | Follow-up call |
| 12 Oct 11:02 · site.user.b | SYSBP | 182 | 128 | Transcription error |
Tamper evidence
A plain way to compare systems. Capture is described in the last column.
| Question | Application-level log | Locked table | Append-only with hash chain (Capture) |
|---|---|---|---|
| Written even if the app path changes | Not guaranteed | Yes | Yes: written by database triggers |
| Rows can be edited or deleted | Possibly, by admins | Restricted | Blocked for UPDATE, DELETE and TRUNCATE |
| Can you show a row was not altered | Hard to | By trust in the database | Each row hashes the previous one per study (SHA-256) |
| Granularity | Varies | Varies | One row per changed field |
| Deletion of clinical data | Often hard delete | Varies | Soft-deleted only; hard deletes blocked |
The first three columns describe common designs in general, not any named product. Ask every vendor how their trail is written and protected.
In the free sandbox, edit a field with a reason, then look for it in the audit trail and export it. The whole rehearsal takes ten minutes and no credit card.
Rehearsal
Run this before a real inspection, and again after any major change to the study.
Choose a mix: a late entry, a corrected value, an adverse event, a lab line and a calculated field. Inspectors choose where they like, not where you do.
For each one, locate every change, the user, the time, the old and new values and the reason. Note anywhere the reason is vague.
Produce the export, open it in the tool a reviewer would use, and check it is readable without your explanation. Confirm the format in the sandbox first.
Prepare a one-page explanation: rows are written by triggers, are append-only, are hash-chained per study, and hard deletes are blocked. Link it to your validation record.
Show who held which role, and that identity is individual, not shared. See 21 CFR Part 11 compliant EDC.
Keep the notes with the study documents. A dated rehearsal is evidence of inspection readiness.
Scope
The general overview of what an audit trail is, and why it matters beyond inspections, is on audit trail software for clinical trials. This page is narrower: it is about producing, reading and defending the record when someone external asks for it. For preparation more broadly, see audit-ready clinical trial data.
Some things are deliberately not claimed. The page does not name an export file format, because that should be confirmed in the sandbox against your own reviewers' tools. It does not claim a dedicated inspector login; how you give an inspector access, remote or on site, is a decision for your sponsor procedures. And it does not claim an independent penetration test: Capture reviews against the OWASP Top 10, and the security page lists what is and is not stated.
Finally, an audit trail only shows what the system saw. Source documents, training records, delegation logs and monitoring reports sit outside it, and inspectors will ask for those too.
Items
6
Ready
4
Yes. The audit trail is always exportable. Confirm the export format in the free sandbox against the tools your reviewers use.
One row per changed field with timestamp, user identity, old value, new value and reason for change. The server also records the IP address.
No through the interface. The database blocks UPDATE, DELETE and TRUNCATE on audit rows, and clinical data is soft-deleted only.
Each audit row carries a SHA-256 hash chained to the previous row for the same study, set only by database triggers, which makes later alteration or removal detectable.
This page does not claim one. Decide how you will give an inspector access under your sponsor procedures and rehearse it in the sandbox.
No software can. Capture provides Part 11-aligned controls; compliance is a shared responsibility with your validation, procedures and training.
Yes. Repeating rows such as concomitant medications or lab lines each carry their own audit trail.
Open the free sandbox, change a value with a reason, read the trail and export it. Every feature is available, with no credit card and no time limit.
Keep exploring
Audit trail software for clinical trials
The general overview.
FDA inspection checklist for trial data
Preparing for an inspection.
Audit-ready clinical trial data
Keeping data inspection-ready all along.
21 CFR Part 11 compliant EDC
Part 11 controls explained.
Annex 11 compliant EDC
The EU computerised systems view.
Security
Sign-in, audit trail and data controls.
Free sandbox, every feature, no credit card. Change a value, read the trail, export it.