Data Integrity in Pharmaceutical Manufacturing

Two CASRAI pages already cover pharmaceutical data integrity from adjacent angles: the FDA Data Integrity Guidance for cGMP guide works through the 2018 Q&A document clause by clause, and Chromatography Data System Audit Trails covers the lab-instrument side — injection sequences, manual integration, CDS review by exception. Neither one is written for the shop floor. This guide is: the data-integrity risks and controls specific to manufacturing execution — the electronic batch record (EBR) or MES system that walks an operator through a batch, the PLC/SCADA layer and historian that actually control and log the equipment, and the electronic batch review that has to reconcile both before a batch is released.

That distinction matters because manufacturing-execution data integrity has a failure mode neither of the other two pages addresses well: a chromatography audit trail question is “does the reported result reflect every injection,” and an FDA-guidance question is “what counts as an invalidated result.” The manufacturing-execution question is “does the record of what the equipment actually did, generated by a control system nobody thinks of as a GxP record, match the record of what the batch record says happened — and can a reviewer actually see it if it doesn’t.”

Where Manufacturing-Execution Data Actually Lives

A batch has at least three separate systems generating records that all have to line up, and each one carries a different data-integrity risk profile:

• The electronic batch record (EBR) or MES. The system of record for the Batch Production Record itself — operator entries, in-process test results keyed in manually, electronic signatures, and the sequence enforcement that stops a step being skipped.
• PLCs, SCADA, and the process historian. The layer that actually drives and monitors equipment — setpoints, alarms, process values (temperature, pressure, mixing speed, fill weight) logged continuously, often at a resolution and frequency no human operator ever directly transcribes. This data is frequently generated by systems that were specified and validated by automation/controls engineering, not quality, and that gap in ownership is where most manufacturing-execution data-integrity findings originate.
• Standalone in-process test instruments. A balance, pH meter, or in-line analyzer feeding a result into the batch record, sometimes by manual transcription, sometimes by direct interface — each transcription point is a place ALCOA+ “original” and “accurate” can silently fail. See CASRAI’s ALCOA+ entry for the attribute set this framework is built on.

None of these three exists in isolation from 21 CFR Part 11 just because it isn’t the record quality reviews first: if a PLC/SCADA system or historian is used to satisfy a cGMP record-keeping requirement under 21 CFR Part 211 (most commonly 211.68, which permits automated equipment to perform and document manufacturing steps, and 211.100/211.110 for in-process controls), it is in scope for Part 11’s audit-trail, access-control, and electronic-signature controls whether or not the people who commissioned it thought of it as a “data integrity system.”

Batch Record and Electronic Batch Review: Risks and Controls

An EBR/MES system is designed to prevent the classic paper-batch-record failures — skipped steps, backdated entries, illegible strike-throughs — but it introduces its own risk surface:

• Retrospective editing of in-process entries. Control: the system-generated audit trail has to independently capture who changed a value, when, and why, without allowing the original entry to be obscured — the same 21 CFR 11.10(e) requirement that applies to any electronic record, but tested here against a workflow with dozens of operator touchpoints per batch rather than one.
• Out-of-specification in-process results entered, then “corrected” before review. Control: configure the EBR so an out-of-range in-process result triggers a system deviation or hold state automatically, rather than relying on the operator to flag it — real-time error prevention, not after-the-fact review, is the actual advantage an EBR has over paper.
• Second-person review scoped to signatures, not data. 21 CFR 211.188(b)(11) requires a second qualified person to check that each significant step was performed correctly; when a validated automated system performs that check, a human still has to confirm the system itself is operating as validated for the review to satisfy the requirement.
• Electronic batch review that stops at the MES and never reconciles against PLC/SCADA data. This is the control most manufacturing-execution data-integrity findings actually turn on: a batch record can show every field completed and every signature applied while the underlying process data — a temperature excursion, an alarm that was acknowledged and cleared without investigation, a manual override at the HMI — sits in a historian nobody pulled into the review. A defensible electronic batch review procedure has to specify which historian/PLC data points are reconciled against the EBR for every batch, not just which EBR fields get checked.

PLC, SCADA, and Historian Data: Risks and Controls

Automation and controls systems were historically validated for functional performance — does the equipment do what it’s supposed to do — without the same data-integrity lens applied to LIMS, EBR, or CDS software, even though the data they generate is frequently the objective evidence a batch record relies on. The recurring gaps:

• Generic or shared operator logins at the HMI. If multiple operators log into a PLC/SCADA workstation under one shared credential, no audit trail entry is independently attributable to an individual — a direct ALCOA+ “attributable” failure, and one of the most common findings in this category because HMI access control is often set up by controls engineers without quality input.
• Setpoint and recipe changes made without a change-control record. A PLC that allows an operator to override a validated setpoint mid-run, with no requirement to document why, breaks the link between the validated process and what actually happened in that batch. Control: restrict setpoint/recipe edit rights by role, and route any in-process override through a documented deviation rather than a silent HMI change.
• Historian data retention shorter than the batch record retention requirement. A historian configured with a rolling data-retention window (common when it was specified for process troubleshooting, not GxP record-keeping) can age out the exact process data a batch record review or an inspection later needs, even though the batch record itself is retained. Retention policy on any historian feeding a GxP decision needs to match the record-retention period that applies to the batch record it supports, not a default IT/OT setting.
• Time synchronization across MES, PLC, and instrument clocks. An audit trail is only useful for reconstructing what happened if timestamps across systems agree closely enough to establish sequence — unsynchronized clocks between the EBR, the PLC, and a standalone instrument can make an entirely legitimate sequence of events look like a gap or an out-of-order entry under review.

Where a PLC/SCADA system or historian is itself computerized and GxP-relevant, it needs a validation plan under the same GAMP 5 risk-based computer system validation framework used for LIMS/ELN software — a configured SCADA/historian platform is typically GAMP Category 4, and any custom control logic layered on top of it is Category 5, which raises the validation burden specifically for the customized parts rather than the whole system.

Building a Data-Integrity Control Framework Across the Manufacturing-Execution Stack

Because EBR/MES, PLC/SCADA, and standalone instruments are typically specified, purchased, and owned by different functions (quality, automation/controls engineering, and metrology/calibration respectively), the most common structural gap is simply that no single inventory lists all three layers together as GxP-relevant data-generating systems. A workable framework:

1. Inventory every system that generates or holds data feeding a batch disposition decision — not just the EBR, but every PLC, SCADA node, historian, and standalone instrument whose output is referenced, directly or indirectly, in the batch record.
2. Classify each system’s data-integrity criticality based on whether its data is used to release product, and whether it’s the sole record of an event (a historian that’s the only record of a temperature excursion is higher criticality than a display-only trend screen).
3. Map each system against 21 CFR Part 11 and EU GMP Annex 11 controls — audit trail, access control, e-signatures where applicable — and record which controls are present, partially present, or absent for each.
4. Write the electronic batch review procedure to name the specific historian/PLC data points it reconciles against the EBR for each product, rather than describing review only in terms of the MES’s own fields and exceptions.
5. Close gaps with a documented, risk-prioritized remediation plan rather than a single all-systems validation project — the shared-login and setpoint-change-control gaps above are typically configuration fixes, not full re-validations, and can usually be closed faster than a historian retention-policy change that may require additional storage.

For the facility- and equipment-qualification side of this same stack, see CASRAI’s cGMP Facility Requirements guide and the IQ/OQ/PQ entry; for the broader GLP/GCP/GMP/GDP landscape this sits within, see GxP Compliance.

Frequently Asked Questions

Is a PLC or SCADA system actually subject to 21 CFR Part 11?

Yes, if it’s used to satisfy a cGMP record-keeping or control requirement under 21 CFR Part 211 — the determinant is the regulatory function the system performs, not whether it was purchased or specified as an “automation” system rather than a “quality” system. A PLC that logs process parameters used to demonstrate a batch met its in-process controls is a Part 11 record generator regardless of which department owns it.

Does a validated EBR/MES system remove the need to review PLC or historian data separately?

No, unless the EBR/MES was specifically validated to pull and reconcile that data automatically as part of its workflow. An EBR that only tracks its own fields and signatures, with no interface to the PLC/SCADA/historian layer, leaves that reconciliation to be done manually and named explicitly in the batch review procedure — otherwise it doesn’t happen at all.

What GAMP 5 category applies to a SCADA or historian system?

Most commercial SCADA/historian platforms, configured (not custom-coded) for a specific process, fall under GAMP Category 4; custom control logic, scripts, or interfaces built on top of that platform are Category 5 and carry a correspondingly higher validation and change-control burden for those custom elements specifically. See CASRAI’s Computer System Validation guide for the full category framework.

How is this different from the general FDA data integrity guidance?

FDA’s 2018 cGMP data integrity guidance answers general questions — what counts as an invalidated result, who may review an audit trail — that apply across every GxP system. It doesn’t work through the specific architecture of a manufacturing-execution environment: which of three or more separate systems (EBR, PLC/SCADA, historian, standalone instruments) generates which record, or how electronic batch review has to reconcile across them. See CASRAI’s FDA Data Integrity Guidance for cGMP guide for that general framework.