The immutable audit trail: what it records

When an auditor, a regulator or an incident investigator asks what happened to a record, the answer has to come from the system, not from memory. In inspection software the records are thickness readings, findings, remaining-life results and the approvals that closed out an interval. The audit trail is what makes those records evidence rather than assertions. This paper describes what an audit trail in inspection software should record, what "immutable" has to mean before you accept the word, how 21 CFR Part 11 and SOC 2 reviewers will read it, and where offline field capture complicates the picture.

What should an inspection software audit trail record?

The minimum event set is broader than most products ship. Anything that changes a record is obvious. The rest is where trails fall short:

• Create, update and delete of every record type, from a CML reading to a form template.
• Read. Who opened which record, and when. Investigations and data-subject requests both turn on this.
• Login and logout, including failed attempts and the identity provider used.
• Permission denied. Every blocked action, with the actor and the target. Denials expose both misconfiguration and probing.
• Tenant switch. In a multi-tenant system, a user with access to more than one tenant moving between them.
• Data export and import. Bulk export is the largest single data-loss vector a platform has. Workbook import is how bad data enters at scale.
• System change. Role edits, permission grants, configuration and form-definition changes, integration key issuance.

Each event needs the same context fields: the actor, the tenant, a request identifier that ties the event to a specific API call, the source IP address, the user agent, and a timestamp from the server clock. Without the request id you cannot join the audit event to the application log when something goes wrong. Without the user agent you cannot tell a field tablet from a desktop browser from an integration.

Why must the audit trail include reads, not just writes?

Most audit trails record writes because writes are what change data. Reads are left out for volume reasons. That trade is the wrong one for integrity data, for three reasons.

First, least privilege is only demonstrable through reads. You can show that a contractor role cannot edit another unit's vessels by pointing at the permission model. You can only show that the contractor never viewed those vessels by pointing at read events.

Second, investigations start with who knew what. When an inspection report is disputed, the question is often who saw the earlier finding and when, not who edited it.

Third, data-subject requests and privacy reviews ask which people accessed a named individual's data. Inspector names, signatures and qualifications are personal data. A trail without reads cannot answer the request.

The volume objection is real but solvable. Read events are small, storage is cheap, and the events can be tiered to colder storage without being deleted. What cannot be recovered is an event that was never written.

What does immutable mean, and how do you verify it?

"Immutable" appears in every audit-trail brochure. It has a specific meaning worth insisting on: no event can be altered or removed after the fact without detection. Two mechanisms make that claim testable.

A hash chain. Each audit event is hashed (SHA-256 is the common choice), and each new event includes the hash of the previous event alongside its own. The result is a chain per tenant in which changing or deleting any event breaks every hash after it. The chain does not prevent tampering by a database administrator with raw access; it makes tampering visible.

A verify routine. A chain no one recomputes is decoration. The platform should expose a routine, available to the tenant's own auditor, that walks the chain from the first event to the last, recomputes every hash, and reports the first break if one exists. Run it before and after a contentious period. Run it before a regulatory inspection.

Call this a hash-chained audit trail. It is not a blockchain, and vendors who call it one are selling a word.

Two further tests:

• Deletion policy. Ask whether any audit event is ever deleted, by retention job or by administrator. The right answer is never; storage can be tiered, never purged.
• Administrator exemption. Ask whether administrator actions are logged in the same chain as user actions. A separate, editable admin log is a hole.

What does 21 CFR Part 11 require of an audit trail?

For pharmaceutical and other FDA-regulated operators, 21 CFR Part 11 governs electronic records and electronic signatures. Its audit-trail requirement, in the controls for closed systems, is compact and demanding:

• The trail must be secure, computer-generated and time-stamped.
• It must independently record the date and time of operator entries and actions that create, modify or delete electronic records.
• Record changes must not obscure previously recorded information.
• The trail must be retained at least as long as the underlying record and be available for agency review and copying.

The phrase "must not obscure previously recorded information" rules out overwrite-in-place. When a thickness reading is corrected, the prior value, the new value, who changed it, when and why must all remain visible. The signature clauses add that a signature must be linked to its record so that it cannot be excised or copied to another record, and that each signing carries the signer's printed name, the date and time, and the meaning of the signature (review, approval, authorship).

SOC 2 approaches the same ground from the control side, under the criteria for logical access and for system operations: the entity logs activity, monitors the logs, and restricts who can alter them. A hash-chained trail with a verify routine gives a SOC 2 auditor a control that can be tested rather than described.

Regulated operators should also notice the electronic-signature detail on shared devices. If two inspectors sign on the same tablet, each signature must carry its own identity, not the identity of whoever logged the device in.

How does offline sync interact with the audit trail?

Field inspection happens where there is no signal. A reading captured inside a drum at 10:14 may reach the server at 16:40 when the tablet finds wifi. The audit trail has to hold both facts. If it records only the sync time, every reading in the unit appears to have been taken in the same ten minutes, which is both wrong and suspicious to an auditor.

Sync also creates conflicts. Two technicians can touch the same record offline, or the office can edit a work pack while a tablet holds an older copy. A trail that hides the resolution behind "last write wins" has lost data silently. What you want is a field-level conflict record: the local value, the remote value, who resolved the conflict, and when. Those conflict records belong in the same trail as everything else, because a conflict resolution is a change to the record.

Finally, offline data sitting on a device is part of the record's chain of custody. It should be encrypted at rest on the device so that a lost tablet does not become an unlogged export.

Does the record render the same in ten years?

An audit trail proves what happened to the data. It does not, by itself, prove what the inspector saw. Inspection forms change. A field is added, a dropdown gains an option, a unit label is corrected, a locale changes date format. If a completed inspection from 2019 is rendered against the 2026 form definition, the audit trail is intact and the record is still misleading.

The fix is to pin configuration to the record. A completed record should store the field configuration, locale and reference options it was executed with, so that it renders forever as executed. Ask a vendor to open a record completed under a form version they have since changed, and compare it to a PDF generated at the time. If they differ, the trail is complete and the evidence is not.

A record you cannot reproduce as it was signed is a record you cannot defend.

How intelliSPEC handles it

intelliSPEC writes an audit event for every create, read, update, delete, login, permission denied, tenant switch, data export, data import and system change. Each event carries the actor, the tenant, the request id, the IP address and the user agent. Events are chained per tenant with SHA-256: each event stores the previous event's hash alongside its own, and a verify routine recomputes the chain end to end for auditors. Audit events are never auto-deleted.

Completed records pin the field configuration, locale and reference options they were executed with, so a finished inspection renders as it did on the day it was signed regardless of later changes to the form. The signature widget records per-signer identity on a shared device, which matters for the Part 11 requirement that each signature belong unambiguously to one person.

The offline field app captures forms, images and workflows fully offline with no time limit on the local store, encrypts offline data at rest on the device, and writes field-level conflict records (local value, remote value, who resolved, when) at sync.

The controls are designed against the SOC 2 Trust Services Criteria and are described, with their current evidence, in the Trust Center. Regulated sites will find the pharma-specific context on the pharma solutions page; the execution side of the record, including signatures and the 13 workflow transitions, is covered on intelliINSPECT.