For most of the history of electronic batch records, e-signature workflows came baked into the MES. You bought a legacy batch execution module, the vendor had already fought the Part 11 fight with FDA years earlier, and your job was mostly configuration inside guardrails someone else built. That’s changing. As newer, more configurable platforms — Opcenter X, Plex, Tulip, Critical Manufacturing, and others — push low-code batch execution into regulated plants, the e-signature logic is increasingly something the plant IT team or MES admin has to design from scratch, not just inherit. And the first-week mistake is almost always the same one: treating every operator action as a signature event, because that feels safest. It isn’t. It’s just annoying, and annoyed operators find workarounds.
This piece is about how to actually draw that line — grounded in what ISA-95 and ISA-88 say about batch data structure, and what 21 CFR Part 11 (and its EU cousin, Annex 11) actually require.
Two different standards worlds, one batch record
It helps to separate what ISA-88/ISA-95 give you from what Part 11 gives you, because people conflate them constantly.
ISA-88 is a batch process model — it defines how a recipe decomposes into unit procedures, operations, and phases, and how equipment modules execute them. It tells you what happened: which phase ran, what parameters were used, what the process values were. ISA-95 extends that into the broader manufacturing operations management model — how batch execution data relates to production scheduling, resource models, and the exchange of information between MES and ERP or historian systems. Neither standard says one word about signatures. They’re data and process models, not regulatory compliance frameworks.
Part 11 is the regulation that governs when an electronic record is legally equivalent to a paper record with a wet signature, and when an electronic signature is legally equivalent to a handwritten one. Annex 11 is the EU GMP equivalent, less prescriptive on signature mechanics but converging on the same principles — attributable, contemporaneous, legible, permanent, and tied to a documented meaning.
So the practical task in configuring an MES batch module is this: use ISA-88/95 to define the structure of the batch record — what data exists and where it lives in the hierarchy — and use Part 11/Annex 11 to decide which of those data points require a signature event versus which just require an audit trail entry.
Record events vs. signature events — the distinction that actually matters
Every write to a batch record is a record event. Part 11 requires that record events be captured in a secure, computer-generated, time-stamped audit trail: who changed what, when, and — for changed values — what the prior value was. That’s true whether an operator scans a lot number, enters a weight, or acknowledges an alarm. This is table stakes. Every credible MES platform does this natively, and it does not require a signature.
A signature event is different. It’s the subset of record events where the regulation, your quality system, or the criticality of the decision demands that a specific individual formally attest — with legal weight — that the action is correct, complete, or authorized. Part 11 requires that a signature event capture printed name, date and time, and the meaning of the signature (reviewed by, performed by, approved by), and that it be permanently linked to the record it signs, not just logged nearby.
The design error most teams make is assuming more signatures equal more compliance. It doesn’t. Part 11 doesn’t require you to sign everything — it requires you to sign the things your predicate rule or quality system says need signing, and to do it correctly when you do. Over-signing creates two real problems: it trains operators to click through signature prompts without reading them (which itself becomes a data integrity finding), and it buries the genuinely critical signatures in noise.
A working rule of thumb
A signature event should exist where one of these is true:
- A predicate rule (GMP, a validated procedure, a regulatory filing) explicitly requires sign-off — batch release, deviation approval, master recipe approval.
- An irreversible or high-consequence decision is being made — releasing a batch to the next unit operation, overriding an out-of-spec result, closing a deviation.
- Accountability for a judgment call is being fixed at a point in time — a quality reviewer attesting the record is complete and accurate before disposition.
Everything else — routine data entry, phase completions, parameter logging, operator acknowledgment of a prompt — should be a record event with strong audit trail attribution, not a signature. If you find yourself asking an operator to sign off on every phase transition in a unit procedure, you’ve mapped ISA-88 execution steps directly onto Part 11 signature requirements, and that’s the wrong mapping.
Meaning of signature: the part everyone underbuilds
Part 11 requires that each signature carry an explicit meaning — not just a name and timestamp, but a statement of what the person is attesting to. “John Smith, 14:32, Performed By” is different from “John Smith, 14:32, Reviewed By,” and the system has to enforce that distinction, not leave it to a free-text field.
In practice this means your MES configuration needs a signature meaning taxonomy tied to role, not just to a generic “sign here” button. A batch record might carry a Performed By signature from the operator executing a phase, a Verified By signature from a second operator on a critical addition (the electronic equivalent of second-person verification), and a Reviewed/Approved By signature from quality on final disposition. Each of those is a distinct signature type with its own re-authentication requirement, its own audit trail entry, and its own place in the record. Configuring one generic signature widget and reusing it everywhere is a common shortcut that auditors catch quickly, because it can’t distinguish “I did this” from “I checked this.”
Password re-authentication vs. biometrics
Part 11 requires that electronic signatures use at least two distinct identification components — typically a user ID and a password — unless biometrics are used, in which case the biometric itself can substitute for one component. The key operational requirement, regardless of method, is that the signature must require a deliberate re-authentication at the moment of signing. Being logged into the MES is not the same as signing a record.
Password re-auth is the default in most plants because it’s simple to validate and doesn’t require additional hardware, but it has real friction costs — operators wearing gloves, working at a scanner terminal, or moving between stations resent re-typing a password dozens of times a shift, and that resentment is exactly what produces workarounds like shared credentials or sticky notes. Biometric re-auth (fingerprint, in some environments facial or badge-plus-PIN) reduces that friction but adds its own validation burden: you need to demonstrate the biometric system reliably and uniquely identifies the individual, handle enrollment and re-enrollment, and have a fallback procedure for injury or equipment failure. Neither approach is inherently more compliant — Part 11 doesn’t prefer one over the other. The choice is an operational one, driven by your plant floor conditions and how much signature volume you’re actually generating, which loops back to why getting the record-vs-signature line right upstream matters so much. Fewer, better-placed signatures make either re-auth method more tolerable.
Where this goes wrong in low-code platforms specifically
The newer generation of configurable MES tools makes it genuinely easy to add a signature prompt to any workflow step — drag a widget, done. That ease is the risk. In legacy systems, adding a signature point was enough friction that someone had to justify it against a validated requirement. In low-code environments, it’s tempting to add signatures reflexively, as a way of “being safe,” without a documented rationale tying each signature to a specific predicate rule or risk justification.
The fix isn’t a technology fix — it’s a governance one. Before configuring a single signature widget, build a signature requirements matrix: list every batch record data point from your ISA-88 recipe structure, and for each one, document whether it’s a record event or signature event, cite the predicate rule or risk justification if it’s a signature, and specify the meaning and role required. Validate against that matrix, not against what the platform makes easy to click together. That document also becomes your best defense in an FDA or notified-body audit, because it shows deliberate design rather than default configuration.
Get that matrix right once, and the rest — audit trail configuration, re-authentication method, signature manifestation on the printed or displayed record — falls into place as implementation detail rather than open questions you’re still arguing about during validation testing.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
