Audit trails for ISO 9001 and 21 CFR Part 11

Regulators don’t evaluate document-management systems against a feature checklist. They evaluate them by asking questions and watching how the answers materialize. The questions are specific. They’re about individual documents, individual approvers, individual dates. The auditor wants to see evidence surface, not be assembled.

Most document-management programs that fail audits have audit trails. The trails exist. Events are captured. The failure is almost always at one of three layers: the events don’t attribute to specific people, the log is editable in ways that compromise integrity, or retrieval requires preparation that the auditor didn’t give you. None of these failures are dramatic individually — but they’re exactly what experienced auditors test for.

An auditor with twenty years of experience can tell the difference between a system that produces evidence and a system that reconstructs it within the first two questions.

The rest of this guide walks through the specific properties that separate the two kinds of systems — and what ISO 9001 and FDA Part 11 each demand in writing.

An audit trail isn’t a single feature — it’s a set of structural properties that together make the evidence defensible. The audit log in an active document lifecycle is built to satisfy all eight. Most alternative systems satisfy some but not all, which is exactly where regulators find their findings.

These eight properties are what the following sections unpack, mapped to specific regulatory expectations.

ISO 9001 clause 8.5 (“Control of documented information”) requires that documented information the QMS relies on is:

During a surveillance audit, the Quality Manager doesn’t produce an “ISO 9001 report” as such. They open a specific document — the one the auditor asked about — and show its audit log. The log answers the clause 8.5 question in context: who, what, when, with what evidence. The audit moves on. The standard is met because the evidence is available.

ISO 9001 doesn't ask for the audit log by name. It asks for the evidence that clause 8.5 has been followed. In modern document-management programs, the audit log is the evidence.

FDA 21 CFR Part 11 is different from ISO 9001 in kind, not just in degree. ISO is a management-system standard; Part 11 is a regulation. Compliance with Part 11 is binary — either your electronic records are Part 11-compliant or they aren’t. Failing Part 11 has direct consequences: FDA inspection findings, Form 483 observations, Warning Letters, in extreme cases consent decrees.

The most-cited Part 11 clause for document-management systems is §11.10(e):

A critical nuance. The product provides the capability customers use in their Part 11 compliance program. It doesn’t provide a “Part 11 validated system” — that’s a different assertion that requires validation scope (IQ/OQ/PQ) documented and maintained by the customer’s QA team. The customer’s validation posture remains their responsibility. What we provide is the audit-trail capability §11.10(e) explicitly requires.

Every event in the audit log resolves to a specific Microsoft Entra (Azure AD) identity — a person with a name, a role, and an authenticated session that produced the event. This is structural. It can’t be bypassed by the user, by admins, or by the product itself.

The contrast with how a lot of older document-management systems work is sharp. In legacy systems, shared service accounts were common — “qualityapproval@company.com” as a shared mailbox that multiple quality-team members used. In those systems, audit entries attribute to the shared account, not to the person who actually acted. Under Part 11’s named-person requirement, every such entry is an attribution failure waiting to be flagged.

The MFA question. Part 11 §11.10(g) also requires that access to electronic records uses “authority checks to ensure that only authorized individuals can use the system.” Most customers implement this via multi-factor authentication at the tenant level — MFA on the Entra identity that underlies every audit event. The active-lifecycle product inherits the tenant’s MFA posture; if MFA is required for SharePoint access, every audit event comes from an MFA-authenticated session.

“The audit log is append-only” is a common claim. The honest question is: at what level? Some systems make the log append-only at the user interface — users can’t edit entries through the app — but admins have backend access that allows modifications. Others enforce it at the permission layer but administrators can override. A few enforce it at the architectural level, where no interface exists to modify the log at all.

The last category is the only one that passes serious scrutiny. If an administrator could edit the log even if they never do, a regulator will ask what compensating controls prevent modification. Those controls exist on trust and process — not on architecture.

The integrity of the audit evidence should depend on architecture, not on administrators behaving. Any system where admins could modify the log has a structural weakness, regardless of organizational discipline.

The audit log in the active lifecycle is architecturally append-only. The underlying SharePoint audit storage does not expose modification APIs. There is no administrative override. Even the product owner — including us — has no mechanism to modify entries. The integrity holds whether the organization operates with perfect process discipline or imperfect.

What admins can do. They can’t modify entries, but they can:

• Read the full log (with appropriate permissions)
• Export the log for audit-report inclusion
• Configure who can access which documents (and therefore which logs)
• Set retention policies that determine how long entries persist

None of these compromise the append-only property. They govern access and lifecycle of the log, not its contents.

The practical test of an audit trail isn’t whether events are captured in principle. It’s whether the Quality Manager can retrieve a specific piece of evidence, under audit conditions, in under a minute — without having prepared for the specific question the auditor asked.

This is the pattern to rehearse before every audit: can any Quality team member, on any day, retrieve any document’s complete audit history in under a minute? If the answer is yes, the program is operationally ready. If it requires preparation, the program has gaps that will surface under pressure.

Each of these failures reflects a specific design choice that a system either has or doesn’t have. They can’t be remediated through policy or training — they require architectural change. That’s why evaluating an audit trail as part of system selection matters more than evaluating it after adoption.

Modern auditors don’t just sample individual documents. They also evaluate program-level metrics: are approvals happening on cadence? is review cadence adhered to across departments? are the roles that should sign off actually signing off? For these questions, per-document retrieval isn’t sufficient — the aggregate view is what satisfies.

Power BI reporting on top of the audit log provides exactly this view:

The dashboard is what a mature Quality program surfaces in monthly management review. It’s also what compliance shows to auditors before they start sampling documents — “here’s our program-level posture” as the context for the detail retrievals.

The audit trail that passes a real audit isn't the one with the most features. It's the one where the Quality Manager, on any random Tuesday, can produce any specific document's complete history in 30 seconds without preparation.

---

If your current audit trail depends on IT support to retrieve, shared-account attribution, user-entered timestamps, or “we’ll prepare that for Monday” answers under audit conditions, the gap is not cosmetic — it’s structural. A 30-minute conversation with our team is usually enough to map your current practice against the eight properties this guide describes, and to identify where the failure modes are most likely to surface.