Records, Signatures, and the Law: 21 CFR Part 11 and EU Annex 11

📍 Where we are: We have the principles that make data trustworthy; now we meet the laws that make a trustworthy electronic record count, legally, as much as ink on paper.

In the last chapter on data integrity and ALCOA+ we met the idea that a record must be trustworthy enough to stand in for the medicine itself, and the ALCOA+ principles that spell out what "trustworthy" means: a record should be Attributable, Legible, Contemporaneous, Original, and Accurate, plus Complete, Consistent, Enduring, and Available. Those are good principles. But principles do not, by themselves, make a digital signature legally binding or a database entry admissible to a regulator. For that you need law.

This chapter is about the law. Two documents dominate it: the United States' 21 CFR Part 11 and the European Union's GMP (Good Manufacturing Practice) Annex 11. GMP is the baseline body of rules for how a regulated medicine must be made; Annex 11 is the part of it that deals with computerized systems. Together they answer one question: when is a computer record as good as a piece of paper?

This is the chapter where the book's thesis becomes law. A batch is made twice — once as the molecule, once as its data shadow — and Part 11 is what makes the data shadow legally count. An undocumented batch did not happen; an unsigned, untraceable electronic record is, legally, an undocumented batch.

Part 11 and Annex 11 don't create records — they make the electronic versions trustworthy, on top of the predicate rules. Original diagram by the authors, created with AI assistance.

The simple version

For centuries, a signed, dated paper record was the gold standard of "this really happened, and a named person stands behind it." When pharma went digital, regulators faced a problem: a database row is trivially easy to silently change, and a typed name is not a signature. Part 11 and Annex 11 are the rulebooks that make an electronic record behave like good paper — unforgeable, time-stamped, attributable, and impossible to quietly erase. They are the legal bridge from the filing cabinet to the server.

What this chapter covers

We start with why these rules were written, then walk through the core requirements of Part 11 — validation, audit trails, copies, retention, access controls, and electronic signatures. We meet Annex 11, Europe's parallel framework, and the global data-integrity guidance that grew up around both. We untangle the crucial idea of predicate rules and risk-based scope. Then we slow down and read a single audit-trail row field by field — the one data structure that carries most of the legal weight — and follow it through the review quality actually runs before release. Finally, we translate all of it into what a real data system — a historian (the plant's database of every sensor reading), a LIMS (the lab's sample-and-result system), an MES (the electronic batch-record system), each defined in full at the end of this chapter — must actually do.

Why the law exists: making digital records as good as paper

In the 1990s, the pharmaceutical industry wanted to stop printing everything. Paper batch records ran to thousands of pages; paper signatures had to be physically chased across a plant. Going paperless promised speed and fewer transcription errors — but only if regulators would accept electronic records and electronic signatures as legitimate.

So in 1997 the US FDA (Food and Drug Administration) issued 21 CFR Part 11 — Title 21 of the Code of Federal Regulations, Part 11 — formally titled Electronic Records; Electronic Signatures[1]. Its core promise is equivalence: an electronic record and a properly executed electronic signature can be just as legally valid as a paper record and a handwritten signature — provided the system meets a list of trustworthiness controls[1]. Part 11 did not lower the bar; it set the conditions under which "the computer says so" is allowed to mean something.

The core requirements of Part 11

Part 11 distinguishes two settings. A closed system is one where access is controlled by the same people responsible for the records — your validated factory historian (the plant database that logs every sensor reading), for instance. An open system is one where the people in control of access are not responsible for the content — think records traveling across the public internet to an outside party. Open systems carry extra duties, such as encryption, precisely because you cannot trust the surrounding environment[1]. Open systems are rare in a manufacturing plant but common at its edges: a cloud-hosted LIMS (lab sample-and-result system) run by a software vendor, or stability and release-test data transmitted to a contract testing laboratory — scenarios where the manufacturer owns the record but does not control the infrastructure holding it.

For closed systems, the regulation lists a now-familiar set of controls[1]:

• Validation. The system must be validated — formally demonstrated to do what it is supposed to do, reliably, including the ability to detect invalid or altered records. (We devote the entire next chapter to how this is done.)

• Audit trails. The system must keep a secure, computer-generated, time-stamped audit trail that records who did what and when — every create, change, or delete — without overwriting the previous value. The old value must remain visible[1]. An audit trail is the digital equivalent of crossing out an error with a single line so the original is still readable.

• Accurate copies. The system must be able to generate accurate and complete copies of records, in both human-readable and electronic form, for inspection and review[1]. In practice this means two outputs of the same record: a human-readable rendering (a PDF printout of a batch record page showing the signature block) and a full electronic export — a CSV or XML file that carries the underlying values plus their metadata, so nothing is lost in translation. A historian export of a single tag, for instance, keeps the value, its units, and its full audit context:

  timestamp_utc,tag,value,unit,quality,operator,modified
  2026-06-13T08:00:01Z,BR101.Temp.PV,37.02,degC,Good,jdoe,false

  A copy that drops the timestamp, the quality flag, or the audit-trail link is not an "accurate and complete" copy, no matter how readable it looks.

• Retention and retrieval. Records must be protected and retrievable throughout their required retention period — set not by Part 11 but by the predicate rule (in the US, 21 CFR 211.180 — a separate part of the same Title 21, covering GMP record-keeping rather than electronic records: at least one year past the batch's expiry date, often far longer), which for many GMP records means years or decades[1].

• Access controls. The system must limit access to authorized individuals, with unique log-ins, so that actions can be traced to a real person[1].

Then come electronic signatures. Part 11 says a typed-and-clicked signature can be legally binding, but only with safeguards[1]:

• Each signature must be unique to one individual and never reused.
• A non-biometric signature must use at least two components — typically a user ID plus a private password. (Within a single continuous login session, only the first signing needs both components; each later signing needs at least one component unique to the user.)
• The signature must be permanently linked to its record, so it cannot be copied, cut, or transferred to a different record.
• The signed record must display, in human-readable form, the printed name of the signer, the date and time, and the meaning of the signature (such as reviewed, approved, or authored).

This last point — signature-to-record linking — is what stops a signature from being "lifted" and pasted onto a different document, the digital version of forging a signature.

Before any of this counts, §11.100 supplies the missing half. It requires the organization to verify each individual's identity before issuing them a signature, and to certify to the FDA — once, in writing — that its electronic signatures are intended to be the legally binding equivalent of handwritten ones. Without that certification on file, the agency need not treat any of the company's e-signatures as binding, no matter how technically perfect the multi-component login is.

A peer-reviewed example shows this is not abstract — though it comes from clinical-research documentation, not GMP manufacturing, the engineering is identical. Researchers built a clinical-documentation system with exactly these features — unique log-ins, a tamper-evident audit trail, digital-signature safeguards, formal validation, and protected backups — to make it Part 11 compliant[9]. The same control set is what a manufacturing historian or LIMS must provide.

Europe's parallel: GMP Annex 11

The European Union reaches the same destination by a slightly different road. Annex 11 of the EU GMP guide — Computerised Systems — sets out the EU's expectations for any computerized system used in regulated manufacturing[3]. It covers risk management, supplier and service-provider responsibilities, validation, data security and integrity, audit trails, electronic signatures, and business continuity[3].

The differences are mostly of emphasis and structure. Part 11 is a regulation focused tightly on the records and signatures themselves; Annex 11 is structured as a guideline within EudraLex Volume 4, the EU GMP guide, framing computerized systems within the broader GMP lifecycle and leaning heavily on risk management and on the idea that the depth of controls should match the system's impact on patient safety, product quality, and data integrity[3]. Do not mistake "guideline" for "optional," though: Annex 11 is enforced as part of the legally binding EU GMP requirements, so failing it means failing a GMP inspection and losing market access. In practice, a company selling on both sides of the Atlantic designs one system to satisfy both — the overlap is large.

Annex 11 is also being substantially revised. An EMA concept paper (EMA/INS/GMP/745438/2022) opened the process in 2022[10], and a full draft revised annex went to public consultation in 2025 alongside a revised Chapter 4, expanding coverage to audit-trail review, cloud and SaaS service providers, data integrity across networked multi-system environments, and AI/ML[11]. The 2011 text described here is the current-but-soon-superseded baseline — the direction of travel is toward exactly the data-integrity and review controls this chapter dissects.

note

Annex 11 is explicitly linked to Chapter 4 of EU GMP, which governs documentation. That linkage is the European echo of a key US concept we meet next: these computer rules sit on top of the underlying requirement to keep good records in the first place.

The data-integrity overlap

Part 11 and Annex 11 do not stand alone. After a wave of inspection findings revealed manipulated and missing data across the industry, regulators worldwide issued data-integrity guidance that fleshes out the same expectations in the ALCOA+ language of the previous chapter. The UK's MHRA published its GxP Data Integrity Guidance (GxP being the umbrella for Good Laboratory, Clinical, Manufacturing, and Distribution Practice), defining ALCOA(+) principles and the controls — audit trails, access controls, lifecycle management — that protect them[5]. The international inspectorate body PIC/S issued PI 041-1, harmonizing risk-based data-governance expectations across many regulators[6]. The WHO set out good data and record-management practices for both paper and electronic systems[8]. And the FDA's own Data Integrity and CGMP questions-and-answers guidance spelled out current expectations for audit-trail review, retention, and access controls[7].

The message across all of them is consistent: an electronic record is only trustworthy if you can prove who made it, that it was unaltered (or that every alteration is visible), and that it is complete and retrievable for as long as the law requires.

Inside the audit trail: where the law becomes a data record

Every clause above is abstract until you look at the single data structure that carries most of the legal weight. Of all the controls Part 11 and Annex 11 demand, one is the data embodiment of the rest: the audit trail. When the release tests run in QC produce a result, and a reviewer later corrects a transcription slip before batch disposition, it is the audit trail — not the result itself — that lets an inspector reconstruct what happened years later. This section dissects that record, field by field, then follows it through the review that quality actually performs before release.

Attributable vs Original: preserving both the human and the old value

Two ALCOA+ principles collide inside a single change, and the audit trail is where they are reconciled. Attributable demands that the change be tied to a real, named person — not a shared login, not a service account. Original demands that the value before the change is never lost. A naïve database does neither: an UPDATE overwrites the old number in place, and the only "user" recorded is whatever account the application connects with. The audit trail fixes both at once. It records the human who made the change as a field distinct from the database account, and it keeps a full snapshot of the row before and after — so the original value is struck through, never erased. This is the digital version of the GMP rule for paper: cross out an error with a single line so the original is still readable.

Anatomy of an audit-trail row

The most useful thing you can do with an audit trail is read one row of it slowly, because every column is a regulatory requirement wearing a database disguise. Below is a single audit.change_log row — the UPDATE that corrects a titer result for an off-line sample — dissected field by field, with each column mapped to the exact clause it satisfies.

One row of an audit trail: each column is a Part 11 or Annex 11 control expressed as data — who, what, when, why, the old value never erased, and a hash that welds the row to its neighbors. Original diagram by the authors, created with AI assistance.

Read the columns in three groups. The provenance group — seq, ts, db_user, app_user — answers who and when. seq fixes the append order; ts is the §11.10(e) "computer-generated, time-stamped" requirement made literal; and the split between db_user (the database account, such as a bioproc service login) and app_user (the human, such as analyst mlee) is the whole point of ALCOA+ "Attributable" and Annex 11 clause 12 — only a person, not a service account, can be questioned in a deviation. The change group — table_name, action, row_key, old_row, new_row, reason — answers what and why: action is the INSERT/UPDATE/DELETE; row_key lets a reviewer pull a record's whole history with one filter — the same role the book's batch_id join key plays at the campaign level, gathering every change to BATCH-2026-001 with one predicate; and old_row/new_row make §11.10(e)'s "do not obscure previously recorded information" physically true, because the original value still sits in old_row forever. The integrity group — prev_hash, row_hash — answers has anyone touched this since. This is exactly the record that, in the open-source companion volume, becomes a concrete PostgreSQL table with triggers and a chain verifier; the open-source Part 11 chapter builds it line for line.

What the corrected number actually is: a downstream release attribute

It is worth grounding this row in the physical step it describes, because "a titer result for an off-line sample" is abstract until you know where it comes from. The value the analyst corrected is a release attribute measured on purified drug substance — the bulk antibody that emerges only after the entire downstream purification train (the unit operations after the bioreactor that turn crude harvest into pure, safe drug substance). That train is where the audit trail earns its keep, because each step both removes impurities and generates the very results the row records. After harvest, the antibody is grabbed out of a soup of cell debris by Protein A capture — affinity chromatography in which a Protein A ligand clamps the antibody's Fc stem while host-cell protein, DNA, and debris flow to waste, then a mild-acid elution (around pH 3.5) releases a concentrated, far purer pool, clearing 2 to 3 log (a hundred- to thousand-fold) of host-cell protein in one step (walked in full in Book 1's Protein A capture chapter). The acidic eluate flows straight into low-pH viral inactivation — a held acid bath (commonly pH 3.3 to 3.6 for about 60 minutes) that denatures enveloped viruses, carrying a validated log-reduction value (LRV — the log10 factor by which a step reduces virus, so an LRV of 4 is a ten-thousand-fold cut), paired with a size-based viral filter downstream so the two orthogonal (independently-acting) steps together clear both acid-fragile and acid-resistant viruses (Book 1's low-pH inactivation chapter).

Every one of those steps writes results an inspector will later read back: the capture-step host-cell-protein clearance, the monomer purity and HMW aggregate percentages by size-exclusion chromatography on the final pool, the documented LRV of the inactivation hold. The titer figure the analyst corrected is one entry in that release panel, and the audit trail is what proves the corrected value still traces to the right sample on the right pool. This is also why a documented reason matters so much downstream: an out-of-spec aggregate or a missed LRV is not a clerical footnote — it can disposition a whole lot as out-of-specification and open a formal investigation, exactly the failure mode the companion ontology's release gate models, where a single HMW result above 2.0 % trips the gate and routes the lot to deviation review.

Documented reason for change: Annex 11 clause 9 and the chain of custody

Notice the reason field. American Part 11 is comparatively quiet about why a change was made; Annex 11 clause 9 is explicit: the audit trail for GMP-relevant changes must record a documented reason. That single field turns an audit trail from a passive log into a chain of custody. A bare "value changed from 4.81 to 4.92" invites suspicion; "value corrected — transcription error against the raw HPLC printout" is defensible. The reason is what lets a reviewer distinguish an honest correction from data manipulation, which is precisely the distinction the post-2010 wave of data-integrity findings was about. In practice the application sets the human identity and the reason just before the change, and the system captures them automatically — the operator cannot forget, because the database writes the audit row for them.

Hash-chained integrity: detecting tampering without preventing privileged bypass

The last two columns, prev_hash and row_hash, address a question the other fields cannot: has the trail itself been altered since it was written? Each row's hash is computed over its own content plus the previous row's hash, so the rows form a chain. Delete a row, reorder two, or insert a forged one, and the chain no longer recomputes — the break is detectable. This is an honest, modest control, and it is important to say what it is not: it is not a blockchain, and it does not make tampering impossible. A database superuser who disables the capture or rewrites the table can still bypass it. The hash chain makes tampering detectable, not prevented — which means the controls that actually prevent privileged misuse (separation of duties, restricted administrator accounts, off-box log shipping) live in your procedures and infrastructure, and an inspector will ask to see them. This is the same risk-based posture that runs through CSV and CSA: match the depth of the control to the risk, and document the rest.

The same row as a triple: provenance the machine can query

The audit row is not only a database record — it is a tiny piece of provenance (the documented history of who produced a value, how, and from what), and provenance has a standard shape. The W3C PROV-O ontology — the standard vocabulary for "entity, activity, agent" provenance — models exactly the three groups the row carries: the corrected result is a prov:Entity, the UPDATE is a prov:Activity, and the named analyst is a prov:Agent the activity prov:wasAssociatedWith. Written as RDF (the graph data model in which each fact is a subject-predicate-object triple, glossed in the companion ontology book), one audit row reads:

# the corrected titer result, its UPDATE activity, and the human who ran it — as PROV-O.
ex:DS-001-titer-v2  a prov:Entity ;
    prov:wasRevisionOf  ex:DS-001-titer-v1 ;          # the old_row, never erased
    prov:wasGeneratedBy ex:change-1042 .
ex:change-1042      a prov:Activity ;
    prov:wasAssociatedWith ex:analyst-mlee ;          # app_user, the accountable human
    ex:reason "corrected — transcription error vs raw HPLC printout" .

That mapping turns the audit trail into something a reasoner can check, not just store. The constraint that "every GMP-relevant change carries a documented reason" — Annex 11 clause 9 — is exactly the kind of completeness rule a closed-world SHACL shape (a graph-validation rule that fails when a required value is absent, the closed-world complement to open-world reasoning) gates at the seam between systems. The companion ontology book builds precisely this gate for the release record — its ReleaseShape requires an attributable approvedBy signature and refuses to certify a lot whose required field is missing — and the audit-trail row is the same idea applied to change rather than to release. The "list every change to this batch, with who and why" query the next section runs is, in graph terms, a competency question (a question the data model must be able to answer, used as its acceptance test): SELECT the agent, old value, new value, and reason for every activity that revised a result of this batch, the change-history analogue of the lineage and impact questions the genealogy spine answers by traversal. Standardizing the row this way is what lets attribution survive when the record leaves the historian and crosses into a knowledge graph — the difference between a log that one application can read and provenance any system can interrogate.

The review query: what quality actually runs before release

An audit trail nobody reads satisfies the letter of the rule and none of its purpose. The international guidance is blunt about this: PIC/S and the FDA's data-integrity Q&A both insist that audit trails be reviewed, not merely kept, and that the review happen before the record is relied upon — that is, before batch release[7]. So the deliverable is not "we have an audit trail," it is "we have an audit trail someone reviews." Concretely, that someone runs a query: list every change to this batch's records — who, the old value, the new value, the reason, and when — and confirm the integrity chain is intact. The figure below follows one corrected result all the way from the analyst's keystroke to the reviewer's sign-off.

The forward path is automatic and the return path is human. The trigger captures the change without anyone remembering to; the chain verifier confirms nothing was silently removed; but the judgement — is this correction honest, is this deviation explained — is the reviewer's, and the rules require it before the batch can be relied upon.

Unsolved challenge: audit-trail review at scale in continuous manufacturing

Here is where a control that works beautifully for one batch starts to buckle. In classical batch manufacturing, the review boundary is natural: a batch ends, its records close, and a reviewer reads the audit trail before disposition. The volume is finite and the moment is well defined. Continuous and perfusion processes break both assumptions. There is no clean "end of batch"; product flows for weeks, and manufacturers carve the stream into rolling batch windows defined by time or volume rather than by a vessel emptying. Each window inherits a slice of an audit trail that never stops growing — and the regulators' requirement does not bend: the trail must still be reviewed before the data is relied upon[7].

The arithmetic is unforgiving. A single perfusion run can generate audit volume that no human can read line by line within a release timeline, yet the FDA's data-integrity guidance still expects review with the same rigor as the underlying data[7]. The honest state of the art is risk-based, exception-based review: rather than reading every row, quality reviews the changes that matter — manual overrides, out-of-sequence edits, deletions, changes lacking a documented reason — flagged automatically, with the routine bulk reviewed by sampling or by automated checks. This is sound risk-based thinking, and it is also genuinely unsettled: what counts as a reviewable exception, how to validate the filter that decides, and how to prove to an inspector that nothing material slipped through are open questions that the move toward continuous biomanufacturing has made urgent rather than theoretical. It is the audit-trail-review chapter of the broader Pharma 4.0 story — the industry's digital-transformation push, in which automation creates data faster than the human review model the rules assume can keep up.

When the filter is a model: validating the thing that decides what a human reads

The moment "flag the changes that matter automatically" becomes a machine-learning classifier — a model trained on past audit rows to predict which ones a human should review — the validation problem sharpens, and it inherits every hazard the companion ML book catalogues. Three matter most here. First, data leakage and the right cross-validation split. A naive accuracy on randomly-split audit rows is a flattering lie if rows from the same batch land in both training and test, because batches are not independent — the honest evaluation is a grouped, leave-one-batch-out split (hold out whole campaigns, never single rows, so the score reflects performance on a batch the model never saw), the same discipline that separates a real validation number from self-deception. Second, the applicability domain (the input region the model was actually trained on): a continuous run can drift into operating conditions no past batch occupied, and a flagging model asked to judge rows outside its training envelope is extrapolating — so it must report when a change is unlike anything it learned from and escalate it to a human rather than silently clearing it. Third, drift in the model itself: the relationship between "manual override at 3 a.m." and "genuinely suspicious" shifts as the process, staff, and recipe change — model drift that must not be confused with the process drift the trail exists to surface — so the filter needs the residual and population-stability monitoring the MLOps chapter builds, not a one-time qualification.

This collides head-on with the rule the next chapter is about. A GMP model that decides what a reviewer never sees is itself a computerized system that must be validated — and under the locked-model posture regulators expect, it is frozen, version-pinned, and changed only under a pre-approved change-control plan, never quietly retrained in place. That is the validation paradox in miniature: the filter learns, but GMP demands you prove the exact filter you qualified is the one running today. The honest current answer mirrors the rest of this book — a risk-based CSA (Computer Software Assurance) assessment that sizes the validation effort to the consequence of a missed exception, an advisory model whose misses a human can still catch, and an audit trail of the filter's own decisions so an inspector can ask the model the same question it asks the analyst: what did you skip, and why? The filter does not retire the reviewer; it triages for one, and it must be validated to the standard of any system that touches a release decision.

Predicate rules and risk-based scope

One point trips up almost everyone new to the field: Part 11 does not create the requirement to keep a record. That requirement comes from the underlying GMP regulations — what the FDA calls the predicate rules[2]. A predicate rule is the real-world law that says "you must record the batch temperature" or "a qualified person must approve release." For US drug GMP these live in the CFR: 21 CFR 211.68 governs automatic, mechanical, and electronic equipment and demands that such systems be controlled and checked; 21 CFR 211.192 requires that every batch's production and control records be reviewed and approved by the quality control unit before the batch is released. Tellingly, 21 CFR 211.68(a) requires that automatic, mechanical, and electronic equipment be routinely calibrated, inspected, or checked and that written records of those checks be maintained, and 21 CFR 211.182 requires individual equipment logs of major cleaning, maintenance, and use — which is precisely why audit trails and equipment records carry legal weight, not just engineering convenience. Part 11 only governs how you may keep and sign those records electronically. No predicate-rule requirement, no Part 11 obligation.

This matters because of history. When Part 11 first landed, industry read it so broadly — every spreadsheet, every timestamp — that compliance became paralyzing and costly. In 2003 the FDA issued its Scope and Application guidance, narrowing interpretation and announcing enforcement discretion over four core requirement areas[2]:

• Validation of Part 11 systems;
• Audit trails (the Part 11 audit-trail clause specifically);
• Record retention; and
• Generation of copies of records.

(The guidance also set legacy systems predating the rule aside.) The agency adopted a risk-based approach: focus controls where an inaccurate or lost record could genuinely harm a patient or compromise product quality, rather than applying maximum rigor to everything equally[2]. Effort should follow risk.

caution

"Enforcement discretion" is not a loophole. The FDA chose not to enforce those four Part 11 provisions as Part 11 requirements while it reconsidered scope[2] — but the predicate rules and current data-integrity guidance still demand the same controls. Audit trails are the clearest example: even though Part 11's audit-trail clause falls under discretion, the predicate rules (such as 21 CFR 211.68 and 211.192) and modern data-integrity guidance still require them, so skipping audit trails is a fast route to a regulatory finding.

This risk-based philosophy is exactly what the industry framework GAMP 5 (Good Automated Manufacturing Practice, 5th edition) operationalizes — using critical thinking (sizing each control to the actual risk rather than testing everything maximally) to scale validation and integrity controls to a system's risk and complexity[4] — the same posture the FDA itself finalized in its 2025 Computer Software Assurance guidance, the bridge to our next chapter.

Why it matters

For anyone building or running a data system, Part 11 and Annex 11 turn vague good intentions into a concrete specification. A compliant system cannot merely store data; it must store it in a way that can be defended to an inspector years later. That single requirement cascades into every design decision: unique user accounts instead of shared log-ins, an audit trail that can never be switched off, time stamps from a trusted clock, backups that are themselves protected and tested, and signatures welded to the records they approve. Get these wrong and the data — however scientifically perfect — may be legally worthless, and a batch may never reach a patient.

The most common real finding here is not a missing audit trail but a disableable one — a chromatography data system (CDS) or historian where audit logging is configurable and was shipped, or left, switched off. Inspectors specifically check that the trail cannot be turned off by an ordinary or even an administrator account, and that any change to the audit-trail configuration is itself audited — which is precisely what §11.10(e) means by a trail that does not obscure and cannot be quietly suppressed.

In the real world

In a modern biomanufacturing plant, three system types carry the regulatory weight. A historian is a database that records every sensor reading — pH, temperature, dissolved oxygen — second by second; the AVEVA PI System (formerly OSIsoft PI) and AspenTech InfoPlus.21 are the common commercial historians, and features such as AVEVA PI's event frames and both systems' audit trails are what capture who acknowledged or changed a value, and when. A LIMS (Laboratory Information Management System) tracks samples and test results; products such as LabVantage LIMS and Thermo Scientific SampleManager are marketed with Part 11 features such as unique log-ins, audit-trail capability configured to be always-on in validated deployments, and electronic-signature workflows — rather than bolting them on afterward. An MES (Manufacturing Execution System) runs the electronic batch record and enforces the steps of the recipe; systems like Körber's Werum PAS-X (the pharma-specific MES/EBR most widely deployed in biologics), Siemens Opcenter Execution Pharma (formerly SIMATIC IT eBR), and Rockwell FactoryTalk PharmaSuite are positioned by their vendors as supporting Part 11 electronic signatures and an as-executed batch record that ties each step to the operator who performed it. Each must provide Part 11 and Annex 11 controls natively: locked-down access, an immutable audit trail, electronic signatures bound to each approval, and accurate copies on demand[1][3].

The same legal weight follows the product all the way to the end of the line: the quality, regulatory, and data backbone that ties a finished biologic to its complete manufacturing history rests on exactly these audit-trail and signature controls.

This is also why interoperability work like real-time lab-data integration efforts cannot ignore compliance. When data flows automatically from an instrument, across a standard interface — OPC UA (the open machine-to-machine standard for live process data), AnIML or Allotrope (open formats that carry analytical results with their full context) for lab data, SiLA 2 for controlling and reading out lab instruments, and ISA-95 (B2MML) messages between the plant floor and the business layer — into a historian and onward to analytics, every hop has to preserve attribution and the audit trail. A standards-based pipeline that loses track of who measured what, when, and whether it changed is not just poor engineering — it breaks the chain that Part 11 and Annex 11 exist to protect.

The same audit trail that satisfies an inspector is what makes the integrated data safe to reuse downstream. Attribution, a documented reason, and a preserved original are exactly the provenance that makes a record FAIR — Findable, Accessible, Interoperable, and Reusable — so the legal control and the analytics value are, satisfyingly, the same control viewed from two sides: an analyst (or a model) can only trust a number it can trace back to who measured it, when, and whether it changed.

Key terms

• 21 CFR Part 11 — US FDA regulation making electronic records and signatures legally equivalent to paper, under specified controls.
• EU GMP Annex 11 — the EU's computerized-systems guideline within EudraLex Volume 4; the EU parallel to Part 11, and enforced as part of binding GMP requirements.
• Closed / open system — a system controlled by those responsible for its records (closed) versus one where access is controlled by outsiders (open), which needs extra protection.
• Audit trail — a secure, time-stamped log of who created, changed, or deleted a record, keeping old values visible.
• Documented reason for change — Annex 11 clause 9's requirement that a change be accompanied by why, turning an audit log into a chain of custody.
• Hash-chained audit trail — an audit trail in which each row's hash includes the previous row's hash, so any deletion, reordering, or edit breaks the chain and becomes detectable (detectable, not prevented).
• Provenance / PROV-O — the documented history of who produced a value, how, and from what; PROV-O is the W3C standard vocabulary (entity / activity / agent) that lets one audit row be expressed as machine-queryable RDF triples and validated by a SHACL completeness shape.
• Downstream purification — the unit operations after the bioreactor (Protein A capture, low-pH viral inactivation, polishing, viral filtration, UF/DF) that turn crude harvest into pure drug substance; the steps that generate the release attributes an audit trail records.
• Log-reduction value (LRV) — the log10 factor by which a viral-clearance step reduces virus (LRV 4 is a ten-thousand-fold cut); a validated, audit-recorded result, with orthogonal steps summed for total clearance.
• Grouped / leave-one-batch-out validation — evaluating a model (such as an audit-trail exception filter) by holding out whole campaigns, never single rows, so a leakage-free score reflects performance on a batch never seen in training.
• Applicability domain — the input region a model was trained on; a flagging model asked to judge changes outside it is extrapolating and must escalate to a human rather than silently clear them.
• Audit-trail review — the act, required before release, of quality reading the audit trail; in continuous processes it shifts toward risk-based, exception-based review.
• Electronic signature — a computer-based signing method that is legally binding when unique, multi-component, and permanently linked to its record.
• Signature-to-record linking — the requirement that a signature cannot be copied onto a different record.
• Predicate rule — the underlying GMP requirement to keep a record; Part 11 governs only how it may be kept electronically.
• Enforcement discretion — the FDA's choice not to act on certain Part 11 specifics while applying a risk-based scope.
• Risk-based approach — scaling controls to the patient-safety and quality impact of the record or system.
• GxP — the family of Good-x-Practice regulations (Good Laboratory, Clinical, Manufacturing, and Distribution Practice, GLP/GCP/GMP/GDP); data-integrity rules cut across all of them.
• Data-integrity guidance — the post-2010 MHRA, PIC/S (PI 041-1), WHO, and FDA documents that restate ALCOA+ controls and that, unlike Part 11 alone, all demand audit-trail review.
• Historian / LIMS / MES — plant data systems that must implement these controls natively.

Where this leads

Notice how often one word has appeared above: validation. A regulated data system must be proven fit for purpose before anyone may trust its records or its signatures. How that proof is built — through Computerized System Validation, the GAMP 5 risk-based framework with its software categories and V-model, and the industry's shift toward the leaner, critical-thinking philosophy of Computer Software Assurance (CSA) — is the subject of the next chapter, Validating Computerized Systems: GAMP 5 and the Move to CSA.

And if you want to see the audit-trail row of this chapter stop being a diagram and become running code — the actual CREATE TABLE, the trigger that captures every change, the verify_chain() function, and the e-signature workflow — the open-source Part 11 and Annex 11 chapter builds the whole thing on PostgreSQL and eLabFTW, and is honest about exactly which clauses open source alone cannot satisfy.