Electronic records and signatures guide
21 CFR Part 11 does not certify a blister packaging machine. It sets criteria for electronic records and electronic signatures within FDA-regulated activities. Whether it applies to a particular blister-line record depends on the applicable predicate rule, the record’s intended use and whether the regulated organization relies on the electronic record or signature.
A useful machine checklist therefore begins with records and responsibilities, not a feature badge. This guide shows how to define the system boundary, map required controls, write the URS and test the configured line without claiming that hardware or software alone establishes compliance.
Scope note: the regulated manufacturer must determine the applicable predicate rules, official records, signatures, retention periods and validation approach for its intended use. Equipment suppliers can provide functions and evidence; they do not approve the user’s quality system or regulatory interpretation.
Direct answer
What does 21 CFR Part 11 mean for a blister packaging machine?
The machine HMI may display temperatures, pressures, speeds, alarms, user actions, recipes, inspection decisions and production totals. That does not automatically make every displayed value a Part 11 record. The user must decide which data support a required regulated record or regulated decision. The same value can have a different status in another implementation because the official record and business process differ.
FDA’s 2003 Scope and Application guidance recommends determining in advance whether the organization will rely on an electronic or paper record for each predicate-rule record and documenting that decision. Printing a report does not automatically make the process paper-based if personnel continue to rely on the electronic data to perform regulated activities.
A responsible quotation should say which requested controls the proposed configuration supports, which components are included, which interfaces are outside scope, and which user procedures and validation activities remain. Avoid unqualified claims that the machine alone establishes regulatory acceptance or inspection readiness.
Applicability
Decide whether Part 11 applies before specifying features
Start with the applicable FDA record requirement, often called the predicate rule. Identify the record or signature that the organization must maintain or submit. Then document its format and use. Part 11 generally applies when the required record is maintained electronically in place of paper, when an electronic record is submitted under applicable requirements, or when an electronic signature is intended to replace a required handwritten signature.
FDA’s guidance describes a narrow interpretation of Part 11’s scope and enforcement discretion for certain Part 11 requirements. It also states that predicate-rule obligations continue and that required records must remain secure and reliable. Do not interpret the guidance as permission to ignore record integrity, validation or retention where the regulated process requires them.
Record inventory
List each electronic record and its source of truth
A blister line may include a PLC, HMI, vision system, printer or coder, serialization equipment, checkweigher, SCADA or historian, recipe database, directory service, backup server and connections to MES or an electronic batch-record system. Each component may create data, but the system inventory should distinguish transient control values from records retained for regulated use.
| Possible record | Questions to resolve | Boundary to document |
|---|---|---|
| Recipe and parameter set | Which version was approved, who may change it, and which values are recorded for a batch? | PLC/HMI storage, recipe server, approval workflow and transfer to the line. |
| Alarm and event history | Which events support investigations or batch review, and can entries be altered or overwritten? | Source clock, event generation, acknowledgement, storage, export and retention. |
| Audit trail | Which actions create, modify or delete regulated records, and how will reviewers inspect them? | Every application that changes the record, including administrator and service activity. |
| Inspection and reject data | Are results used for acceptance, reconciliation or deviation decisions? | Camera or sensor, position tracking, reject confirmation, summary and retained detail. |
| Batch or production report | What source data create the report, can it be regenerated, and is the electronic version official? | Calculation logic, report template, source data, approval and archive. |
| User and security records | Who created, changed, disabled or used accounts and roles? | Local accounts, central directory, application roles and administrative tools. |
| Electronic signature | What action is signed, what does the signature mean, and how is it linked to the record? | Application, identity source, signature components and signed-record export. |
| Configuration and software | Which versions and changes can affect the regulated result? | PLC, HMI, vision, databases, reports, interfaces and controlled documentation. |
For every in-scope record, assign an owner, authoritative location, format, retention rule, review process, backup method and retrieval test. If the line transfers data to another system, identify the point at which responsibility changes and how completeness is reconciled.
System boundary
Map the complete path from sensor or entry to retained record
The HMI is only one surface. A temperature value may begin at a sensor, pass through an input module and PLC, be displayed on the HMI, summarized in a batch report and archived on a server. A vision result may be generated on a separate industrial computer, sent to the PLC for reject tracking and exported to a production database. Validation must address the configured path that supports the intended record.
Draw the boundary as installed. Include hardware, firmware, application software, databases, operating systems, network components, time source, user directory, printers, removable media, backup destination, remote-access path and every interface that transfers or transforms regulated data. Identify whether the environment is treated as a closed system controlled by the people responsible for the records or whether open-system controls are relevant.
Interfaces need defined ownership and error handling. State which system sends and receives each field, how records are identified, how duplicates or missing transfers are detected, what happens during network loss, and how recovery is reconciled. A successful connection test does not prove that a complete regulated record survives failures, reprocessing and version changes.
Closed-system controls
Translate 21 CFR 11.10 into testable project requirements
Section 11.10 requires procedures and controls for closed systems that support the authenticity, integrity and, where appropriate, confidentiality of electronic records, and non-repudiation of signed records. The checklist below is a project translation, not a substitute for the regulation or the user’s risk assessment.
| Part 11 control area | Blister-line requirement to define | Evidence to plan |
|---|---|---|
| Validation | Intended use, requirements, configuration and tests show accurate, reliable and consistent operation and detection of invalid or altered records. | Traceability, specifications, test records, deviations and approval. |
| Record copies | Generate accurate and complete human-readable and electronic copies suitable for review and copying. | Export tests with data, metadata, audit trail and signature context as applicable. |
| Protection and retrieval | Protect records and retrieve them accurately throughout the required retention period. | Access, backup, restore, archive, migration and periodic retrieval evidence. |
| Access control | Limit system access to authorized individuals with controlled account lifecycle and roles. | User/role matrix, provisioning, removal, failed-access and privileged-access tests. |
| Audit trail | Secure, computer-generated, time-stamped recording of relevant creation, modification or deletion without obscuring prior information. | Challenge tests, review view/export, retention and administrator activity. |
| Operational checks | Enforce the permitted sequence of steps or events where sequence matters. | Recipe approval, batch-state and workflow challenge tests. |
| Authority checks | Only authorized roles can operate, sign, access input/output, alter records or perform controlled actions. | Positive and negative permission tests for each critical role. |
| Device checks | Verify the validity of the source of data input or operating instruction where appropriate. | Interface, device identity and wrong-source challenge tests. |
| Training and accountability | Qualified people use and maintain the system under written policies. | User procedures, training and electronic-signature accountability. |
| Documentation control | Control distribution, access, use, revision and change history of system documentation. | Document list, revisions, approvals and change records. |
Validation
Validate the configured system for its intended use
Validation is not a certificate attached to a standard software option. The regulated organization defines intended use, evaluates risk, approves requirements and provides evidence that the installed and configured system performs consistently for that use. Supplier development and factory tests can support this work, but they do not replace the user’s approval of the system in its process and quality environment.
Start with a traceable URS. Link each in-scope record and control to functional and configuration specifications, risk controls and tests. Include normal operation, boundary conditions, unauthorized actions, invalid inputs, communication loss, storage limits, full or unavailable destinations, power interruption, restart, restore and other credible failure states.
Define what “discern invalid or altered records” means for the architecture. Possibilities include prevented edits, controlled corrections that preserve prior information, audit-trail entries, database constraints, checksums or other technical and procedural controls. Do not assume that a PDF report proves the integrity of its source data or that a database backup proves the application can retrieve a complete record.
Supplier tests should identify software and configuration versions. Site tests should confirm the actual network, directory, time service, backup, interfaces, security settings, users, reports and procedures. Deviations need documented assessment and closure before the system is released for its intended regulated use.
Audit trails
Test audit-trail content, security, review and retention
Section 11.10(e) calls for secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify or delete electronic records. Record changes must not obscure earlier information. Audit-trail documentation must be retained at least as long as the related electronic record and be available for agency review and copying.
The URS should name the actions that require traceability. On a blister line these may include recipe creation or change, parameter change, inspection-limit change, user and role administration, clock change, alarm acknowledgement, manual data entry, deletion or archiving, report-template change and electronic approval. The exact list follows the record inventory and risk assessment.
Challenge the audit trail as a reviewer would use it
- create, modify and where permitted delete or deactivate a record, then verify the original information remains available;
- confirm user, date, time, action, old value, new value and reason where the approved requirement calls for them;
- test operator, supervisor, administrator, maintenance and service actions, including failed attempts where relevant;
- verify users cannot disable, overwrite or selectively remove the audit trail through ordinary access;
- filter, review and export the audit trail with enough context to understand the associated record;
- retain and restore the audit trail together with the record and confirm links remain intact; and
- define who reviews which audit trails, when, how exceptions are investigated and how completion is recorded.
A chronological event list is not automatically an adequate audit trail. It must cover the relevant record actions, be secured, remain connected to the affected record and support practical review.
Access and authority
Control individual accounts, roles and privileged access
Shared operator accounts weaken attribution and should not be used to execute regulated actions that must be associated with an individual. Define unique user identity, authentication, role assignment, account approval, activation, periodic review, modification, lockout, emergency access and timely deactivation. If a central directory manages identity, include its interface and failure behaviour in the boundary.
Role-based access must follow actual responsibilities. An operator may run an approved recipe but not change protected limits. A supervisor may review a batch without administering user accounts. Engineering or maintenance may access technical functions without approving a regulated record. Administrators need controlled, attributable use and independent oversight appropriate to the risk.
Build positive and negative tests from the approved user-role matrix. Verify each role can perform required work and cannot perform unauthorized work. Test local, remote and service access. Review default accounts, embedded passwords, inactive accounts, session timeout, screen locking and behaviour after repeated failed access.
Part 11 also contains controls for identification codes and passwords used in electronic signatures, including uniqueness, periodic checks or revision, loss management and safeguards against unauthorized use. The user’s security policy must define the implemented controls; a touchscreen login alone does not demonstrate the complete requirement.
Electronic signatures
Separate login, acknowledgement and legally binding signature
A login identifies a user session. An alarm acknowledgement records a response to an event. An electronic signature is a computer data compilation executed or adopted as the legally binding equivalent of an individual’s handwritten signature. Do not label every password entry or button press as an electronic signature.
For an in-scope electronic signature, define the signed record, the point of signing and the meaning of the signature, such as review, approval, responsibility or authorship. Section 11.50 requires the signed electronic record to show the printed name of the signer, date and time, and signature meaning. Section 11.70 requires the signature to remain linked to its record so it cannot be excised, copied or transferred to falsify another record by ordinary means.
Electronic signatures must be unique to one individual, and the organization verifies identity before assigning them. For non-biometric signatures, Part 11 specifies at least two distinct identification components and describes their use during continuous and non-continuous signing sessions. Organizational certification to FDA that electronic signatures are intended as legally binding equivalents is a user responsibility, not a machine-supplier certificate.
Test the signature in normal display, printed or human-readable copy, electronic export, archive, restore and migration. Verify the signature remains attached to the correct record and that later changes follow the approved process and remain traceable.
Copies and retention
Prove that records can be exported, read and retrieved
Section 11.10(b) requires accurate and complete copies in human-readable and electronic form suitable for FDA inspection, review and copying. A screenshot or summary PDF may be readable but incomplete if the regulated record also depends on metadata, audit trails, signatures, calculations or detailed inspection results. A proprietary database export may be complete but unusable without the application and documentation.
Define both outputs. The human-readable copy should present record identity, context, values, units, date/time, user, status, approvals and relevant audit history. The electronic copy should preserve the agreed data and relationships in a form that can be provided and evaluated. Test representative large records, special characters, time ranges, filters and all included subsystems.
Section 11.10(c) requires protection and ready retrieval throughout the record-retention period. The applicable predicate rule and record type determine that period; do not take a universal number from a machine specification. Confirm storage capacity, rollover behaviour, archival trigger, backup, restore, index/search, media lifecycle, software obsolescence and migration.
Record retention is an ability, not only a storage setting. Periodically retrieve an archived record and verify that it is complete, readable and linked to its audit trail and signatures. Document how the organization will maintain access if hardware, operating systems, databases or applications change.
Data integrity
Control data from creation through archive and disposal
FDA’s data-integrity guidance describes data integrity as completeness, consistency and accuracy, and explains that data should be attributable, legible, contemporaneously recorded, original or a true copy, and accurate. Apply those principles across the complete data lifecycle, including creation, processing, review, reporting, retention, retrieval, migration and permitted disposal.
For automatically generated data, identify the original record and the metadata needed to reconstruct activity. If the PLC stores only a current value while a historian stores the time series, state which is authoritative. If the system calculates accepted output from counters, document the inputs, reset permissions, calculation and treatment of rejects or manual changes.
Backup protects against loss; archive supports controlled long-term retention; disaster recovery restores service. They are related but not interchangeable. Define frequency, scope, encryption or other protection as appropriate, access, off-system location, monitoring, restore testing and reconciliation after recovery. Confirm that audit trails, configuration and signatures are included where needed.
Time is part of the record. Define the authoritative time source, synchronization, time-zone reference, daylight-saving treatment where relevant, permitted adjustment and audit of clock changes. When systems exchange data, confirm that event sequences remain understandable across their time references.
Interfaces and vendors
Close the gaps between PLC, vision, printing and site systems
Blister lines commonly combine subsystems from several suppliers. The base machine may control motion and process parameters, while a vision system records inspections, a printer manages variable data, serialization equipment handles identifiers, and a site system stores the batch record. Part 11 and data-integrity risk sits across the connected process, not inside one supplier’s cabinet.
Create an interface register. For each connection, name the sender, receiver, data, direction, trigger, identifier, acknowledgement, retry, duplicate handling, timeout, error alarm, local buffer, recovery and reconciliation. Define what happens if a downstream system is unavailable: whether the line stops, continues temporarily, stores data locally or requires a controlled manual process.
Agree who controls user accounts, clocks, backups, software versions, antivirus or application allow-listing, remote service, patches and configuration. Remote access needs authorization, secure enablement, session control, logging and review appropriate to the site policy. A vendor’s ability to connect should not create an uncontrolled privileged path.
Require the integrator to provide a single system architecture and responsibility matrix. Separate supplier tests can confirm components, but an end-to-end test must show that the final configured record remains complete through normal operation and credible failures.
Responsibility
Separate supplier deliverables from the user’s quality-system work
| Equipment supplier can provide | Regulated manufacturer must own |
|---|---|
| Documented standard functions, options, architecture and technical constraints. | Applicable regulations, predicate-rule assessment and official-record decisions. |
| Hardware/software identification, configuration records and controlled supplier documents. | Approved URS, risk assessment, intended use and site configuration. |
| Development or quality evidence available under the contracted scope. | Supplier assessment and determination that evidence is adequate for use. |
| Factory tests of configured access, audit trail, reporting, signatures and interfaces. | Site qualification, procedures, training, data governance and release for use. |
| Backup, export, diagnostic and maintenance functions described in manuals. | Retention periods, backup operation, archive, restore, review and periodic verification. |
| Change notices, support and authorized service within the agreement. | Change control, impact assessment, approval, regression testing and continued validated state. |
Ask the supplier to state limitations as clearly as features. If audit trails are stored only in one subsystem, if an export omits metadata, if local users cannot integrate with a central directory, or if records are overwritten at a storage limit, those facts belong in design review before purchase.
URS
Write requirements around records, users and lifecycle
- intended use, applicable predicate-rule records, official record format and electronic-signature decisions;
- complete system boundary, subsystems, software, database, network, directory, time, backup and interfaces;
- record identity, source data, metadata, calculations, status, review, approval, retention and retrieval;
- unique users, authentication, role matrix, account lifecycle, privileged access, session and remote-access controls;
- audit-trail events, content, security, display, filtering, review, export, retention and restore;
- electronic-signature components, manifestation, meaning, record linking and use rules;
- human-readable and electronic copies, formats, completeness, inspection access and migration;
- operational, authority and device checks for permitted sequence, action and input source;
- backup, archive, restore, disaster recovery, storage monitoring, time synchronization and failure response;
- documentation, software/configuration versioning, change control, service, patching and support; and
- FAT, SAT, IQ, OQ, PQ or other lifecycle evidence, responsibilities, deviations and acceptance criteria.
Make each requirement observable and testable. “System shall be Part 11 compliant” is not testable. “The batch-approval signature shall display the signer’s printed name, execution date/time and approval meaning in the record and its human-readable copy” can be traced to configuration and a test.
The tablet blister machine URS guide covers the wider mechanical and process scope. Add this electronic-record section only after the record inventory and system boundary are understood.
FAT and qualification
Test configured controls, failures and recoveries
FAT should use the identified software and configuration revisions and the agreed system boundary available at the supplier site. It can test accounts, permissions, audit trails, reports, signature workflows, exports, sequence checks, interfaces and selected failures. Site-specific services may need simulation, with the remaining tests explicitly reserved for SAT or qualification.
| Test area | Representative challenge | Evidence to retain |
|---|---|---|
| Identity and role | Authorized and unauthorized actions for every critical role, including administrator and service access. | User/role matrix, steps, results, screenshots or records and deviations. |
| Record creation/change | Create, modify and correct an in-scope record using the approved workflow. | Original and changed values, status, users and associated audit trail. |
| Audit trail | Challenge each required event and attempt ordinary alteration or disabling. | On-screen view, electronic copy, review result and security response. |
| Electronic signature | Sign with the required components and meaning; challenge wrong identity and invalid sequence. | Signed record, human-readable copy, electronic export and audit trail. |
| Copy and retrieval | Export a complete record, archive it, restore it and retrieve it with context. | Compared outputs, metadata, signature/audit links and retrieval approval. |
| Interface failure | Disconnect or interrupt an agreed connection, then recover and reconcile. | Alarm, local behaviour, queued data, transfer result and reconciliation. |
| Storage and restart | Challenge storage warning or unavailable destination as safely planned; restart after interruption. | System response, data completeness, sequence and approved recovery. |
| Time control | Verify synchronization, displayed reference and restricted clock change. | System times, event order, permission and audit record. |
Use the DQ, IQ, OQ and PQ blister-machine validation guide to connect supplier and site stages. FAT does not establish the complete site system, user procedures, long-term retention or continued validated state.
Operation
Maintain the validated state after release
Part 11 readiness continues after qualification. Operate account reviews, audit-trail reviews, backup and restore tests, storage monitoring, incident handling, change control, periodic assessment and training according to approved procedures. Track software, firmware, database, report, recipe and configuration versions that can affect regulated records.
Assess changes before implementation. Consider the intended use, record content, calculations, audit trail, signature, access, interface, backup, export and retained data. Define regression testing from impact and risk. Emergency fixes still need controlled documentation, review and follow-up.
Plan for obsolescence. A retention requirement can outlast the original computer or software. Maintain the ability to retrieve accurate and complete records, or execute a controlled migration that preserves data, metadata, audit trail and signatures as applicable. Test retrieval after migration rather than assuming that files copied successfully remain usable.
Security and Part 11 overlap but are not identical. Cybersecurity controls can protect availability, confidentiality and integrity, while Part 11 also addresses regulated record and signature meaning, lifecycle and equivalence. Manage both within the actual architecture and risk profile.
Primary references
Use the regulation and FDA guidance within their stated scope
Questions from project teams
21 CFR Part 11 blister machine FAQ
Can a blister packaging machine be certified as 21 CFR Part 11 compliant?
No single machine certificate establishes the user’s compliance. The regulated organization must determine scope, official records, intended use and procedures, then validate the configured system and operate it under its quality system. A supplier can provide functions, documents and test evidence for the contracted scope.
Does Part 11 apply to every value shown on the blister machine HMI?
No. Applicability depends on whether the value is part of a record required by an FDA predicate rule and whether the organization relies on the electronic record for regulated activity. Document the decision for each required record and map its complete electronic lifecycle.
Is a printed batch report enough to avoid Part 11?
Not automatically. FDA’s scope guidance says it may consider business practice and which record the organization actually relies on. If people rely on the electronic data to perform regulated activities, producing a printout does not by itself make the electronic record irrelevant.
What should a blister machine audit trail record?
Define events from the in-scope record inventory. Relevant examples may include recipe or parameter changes, record corrections or deletion, user and role administration, signature actions and configuration changes. The audit trail must preserve prior information, remain secured and support review and retention.
Are user login and electronic signature the same?
No. Login identifies a user session. An electronic signature is intended as the legally binding equivalent of a handwritten signature and has additional requirements for manifestation, components, identity, meaning and linkage to the signed record.
What records should the machine export?
Export needs follow the approved record inventory. For each in-scope record, define an accurate and complete human-readable copy and electronic copy, including the data, metadata, audit trail and signature context needed for inspection, review, copying and retrieval.
Can FAT complete Part 11 validation?
No. FAT can test the contracted functions and configured supplier-site boundary. The user must complete site-specific assessment and qualification for networks, directories, time, backup, interfaces, procedures, users, intended use and lifecycle controls before release.
What should I send with a Part 11 blister machine inquiry?
Provide the applicable market and predicate-rule assessment, official electronic records, signature workflows, system architecture, user roles, audit-trail and export requirements, interfaces, retention and backup strategy, validation deliverables and FAT acceptance criteria.
Define the electronic-record boundary before requesting the control package
Share the intended records, signatures, user roles, audit-trail needs, interfaces, retention approach and validation scope. HIJ can map those requirements to the proposed blister-line controls and identify which user and site responsibilities remain.
About this guide: prepared for engineering, automation, quality, validation, IT and procurement teams defining electronic-record controls for blister packaging equipment. It is an equipment-project guide, not legal advice or a compliance certification.
