Audit trail testing requirements

Which rule asks for a trail, and what does it ask for?

Two rules ask, in different words, and a suite written against one of them answers the other only by accident.

section 11.10(e) of 21 CFR Part 11 is three sentences long: "Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying." Four obligations sit in those three sentences, and only the first of them is usually tested. Whether the part reaches your records at all is a separate question, answered under FDA 21 CFR Part 11 validation testing.

45 CFR 164.312(b) is one sentence: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." Nothing sits beneath it, Appendix A to Subpart C marks it Required, and it settles neither which events belong in the trail, nor how an entry is laid out, nor how long an entry lives. Those three are yours to define and then to prove, so this page is about attacking a definition you wrote. Testing the trail on a live system means somebody reads real records while doing it, and the terms that work runs under are set out at how we work with protected health information.

The review side has its own clause. 45 CFR 164.308(a)(1)(ii)(D) is Required and reads: "Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." What the absence of any named technique in the Security Rule means for a test plan is set out under HIPAA testing requirements for software.

A certified health IT module answers to a third set of names. 45 CFR 170.315(d)(2) is titled "Auditable events and tamper-resistance", 170.315(d)(3) is "Audit report(s)" and 170.315(d)(10) is "Auditing actions on health information", three of the thirteen consecutive privacy and security criteria in 170.315(d). The certification route those titles belong to is described under ONC certification testing requirements.

How do you make an audit trail fail on purpose?

By changing data through a path nobody wrote a trail for, and by asking the trail a question about the past. A suite that clicks a button and then asserts that a row appeared confirms the path the developer already had in mind.

Steps 2 and 8 are the two with no button behind them. Both describe the system on an ordinary Tuesday, when a record changes through a path no test case was written for and an entry is read months after the build that wrote it was replaced.

What does "shall not obscure" mean in a test?

The assertion goes on the previous value, not on the existence of an entry. Three implementations pass the second assertion and fail the first: an update in place with a "modified" flag, an entry that stores only the new value, and a soft delete that flips a boolean and writes one row. Each of them proves that something happened and cannot say what the field held before it happened.

The test is therefore ordinal. Write value A, then B, then C, then rebuild A and B from the trail alone with the record itself out of reach. A trail that recovers only the immediately preceding value fails at the second edit, so one edit is never enough to test with.

Signed records raise the same question in a stricter form. 11.50(a) requires a signed electronic record to carry the printed name of the signer, the date and time the signature was executed, and the meaning associated with it. A correction applied after signing has to leave all three readable for the version that was superseded. Those mechanics belong to electronic signature testing under Part 11.

Whose clock stamped the entry?

11.10(e) asks for trails that are "computer-generated, time-stamped" and that "independently record the date and time" of the operator's action. Two entries that disagree about order carry more information than any single entry, so the clock tests are comparative.

Clock and timestamp attacks on a 21 CFR Part 11 audit trail, each paired with what the recorded entry has to show afterwards.

Attack	What the trail has to show
Workstation clock moved forward one day	The entry keeps server time, and the operator's offset appears nowhere in it
Two operators in two zones edit within one minute	The two entries order correctly against each other, whatever each screen showed
The edit crosses a daylight saving boundary	The stored instant is unambiguous, and the rendered local time names its zone
A client supplies its own timestamp field	The supplied value is treated as data, and the entry keeps the value the system generated
Two edits inside the same second	Order is still recoverable, by sequence where the time cannot separate them

FDA published a draft guidance on time stamps and then withdrew it, in the Federal Register of 25 February 2003 at 68 FR 8775, stating that it did not intend to re-issue it. No replacement appears in the current regulation text. The behaviour of your clock is a design decision you justify and test, and no agency document specifies it for you.

What happens when the writer is not the application under test?

Entries go missing at the points where a record changes with nobody in front of it. The words of 11.10(e) cover actions that create, modify or delete electronic records, and they do not distinguish the screen from the job queue. 164.312(b) is broader again: the mechanisms record activity in information systems, and an information system is larger than its user interface.

Four writers routinely produce changes with no entry behind them:

• A scheduled job that recalculates or expires values overnight.
• An inbound interface that updates a chart from another system.
• A migration or backfill script, run by an engineer holding database access.
• A support tool that acts on behalf of a named user, so the entry, where there is one, blames the user.

The support tool is the worst of the four, because its trail is not empty. It is populated and wrong, and somebody will later read it as evidence of what a clinician did. Act through the tool, then assert that the entry carries both identities.

Does the trail survive an upgrade?

Retention is not a configuration value that one test reads once. FDA's 2024 guidance on electronic systems in clinical investigations states that changes, including software upgrades, security and performance patches, equipment or component replacements and new instrumentation, should not adversely affect the traceability, authenticity or integrity of new or existing data, and that all changes should be documented. Its inspection list for sponsors names the processes that keep records required to reconstruct the investigation from being altered in value or meaning, including during transfer to durable electronic data repositories.

Four things break across a version boundary, and none of them appears in a smoke test:

• An entry written under the old schema renders with a field missing, so the reconstruction of previous values now fails for everything older than the release.
• A status code was renamed, and old entries display the new label, which changes the meaning of the record without changing the record.
• The account that made an entry was deleted afterwards, and the entry now shows an empty actor.
• The retention window resets to a platform default during migration, and the 11.10(e) tie to the retention period of the subject records is quietly gone.

The suite that catches these runs against a database already holding entries written by earlier builds. Keeping it in the release train, and deciding what a schema migration obliges you to rerun, is covered in regression testing for regulated software.

What about the months before the trail existed?

Nothing tests them and nothing fills them. An entry is written while the action happens or it is never written, so a period that predates the mechanism stays empty for as long as the records last. Where that ordering decides what a company builds first, the argument is set out under QA requirements for a digital health startup.

The testable part is the boundary. Assert that the date the trail began is itself recorded and reportable, and that a report covering an earlier range states the mechanism was not running instead of returning an empty result. A report that renders "no activity" for a period nobody was recording turns a gap into a false statement to an auditor.

What does audit trail testing produce?

Artefacts an audit trail test produces under 21 CFR Part 11 and the HIPAA Security Rule, with the question each one settles.

Artefact	What it settles
Event catalogue	Which actions the product treats as recordable, with the field list per entry, agreed before the tests are written
Write path matrix	Which of the interface, API, import, support tool, job and script paths has a test for each catalogued event
Reconstruction protocol	That earlier values of a named field were rebuilt from the trail alone, on a named build, with the record removed
Clock comparison record	Which time source each entry carries, and the result of the skew, zone and same-second cases
Tamper attempt register	Which privilege attempted which change to which entry, and what the system did about it
Cross-version retention evidence	That entries written by an earlier build still reconstruct after the upgrade, with both build identifiers named
Export sample	One trail extract in human readable form and one in electronic form, for the copies obligation at 11.10(b)
Review procedure evidence	That the queries the 164.308(a)(1)(ii)(D) review depends on return results on the production estate

The catalogue decides whether the rest of the list is worth anything, because 164.312(b) and 11.10(e) both leave the event list to you. Turning the catalogue and these results into a package an auditor reads without a guided tour is validation documentation.

Where does audit trail testing go wrong?

• The suite asserts that an entry exists and never asserts the previous value, so every no-obscuring defect ships.
• Only the interface path is tested, while three other write paths reach the same table.
• The expected timestamp is computed from the same clock the system used, so a skew defect cannot fail the test.
• Retention is verified against a database seeded that morning, which cannot fail.
• The tamper attempts run as an ordinary user, and the administrator role that can edit the trail is never tried.
• The trail is tested at release and not after schema migrations, which are the changes that break entries written months earlier.

Sources for this page. The quoted text of 21 CFR 11.10(b), 11.10(e), 11.10(k)(2) and 11.50(a), and the section titles at 45 CFR 164.312(b), 164.308(a)(1)(ii)(D), 164.316(b)(2)(i) and 170.315(d)(2), (d)(3) and (d)(10), come from the collected records for Part 11, for HIPAA and for ONC certification, taken from the eCFR compilation as it stood on 31 August 2026. The enforcement discretion passages come from the recorded text of FDA's 2003 scope and application guidance, and the upgrade and inspection passages from the October 2024 guidance on electronic systems, electronic records and electronic signatures in clinical investigations.