21 CFR Part 11 Applicability, Assessment, and Compliance

Title 21 CFR Part 11 establishes requirements for electronic records and electronic signatures used to meet applicable US Food and Drug Administration record and signature requirements. It does not make every electronic file, database, or computerized system a Part 11 system.

Part 11 applicability begins with the underlying record requirement. The organization should identify which records and signatures are required by an applicable FDA regulation, commonly called a predicate rule, and determine whether electronic records or electronic signatures are used to satisfy that requirement.

A Part 11 assessment should therefore evaluate records, signatures, intended use, system boundaries, and reliance. It should not begin with a generic checklist applied to every software feature.

Relationship Between Part 11 and Predicate Rules

Predicate rules are the FDA requirements that establish:

• which records must be created;
• what information they must contain;
• who must review or approve them;
• whether a signature is required;
• how long records must be retained; and
• when records must be available for inspection.

Examples may include requirements for:

• batch production records;
• laboratory records;
• equipment-use records;
• production and process-control records;
• component and material records;
• stability records;
• complaint records;
• training records;
• investigation records; and
• regulatory submissions.

Part 11 does not replace these requirements. It provides additional controls when required records or signatures are maintained electronically.

The assessment should identify the applicable predicate-rule citation or justified quality-system requirement for each record type. A conclusion such as “the application is subject to Part 11” is too broad unless the organization identifies which records and functions create that applicability.

Electronic Records Within Part 11 Scope

An electronic record may be within Part 11 scope when it is:

• required by a predicate rule;
• created, modified, maintained, archived, retrieved, or transmitted electronically;
• relied upon to perform a regulated activity;
• relied upon to make a GxP decision;
• submitted electronically to FDA; or
• used instead of a required paper record.

The assessment should determine whether the electronic information represents:

• the original record;
• a true copy;
• a temporary working record;
• a supporting data source;
• a report derived from underlying data;
• a submitted record;
• or information that is not relied upon for regulated purposes.

A system may contain both regulated and nonregulated records. Applicability should be defined by record type and intended use rather than by the product name alone.

Electronic Records Relied Upon

Electronic reliance is central to the assessment. An organization relies upon an electronic record when the electronic information is used to:

• perform a regulated activity;
• demonstrate completion of an activity;
• calculate a regulated result;
• establish product or material status;
• support release or rejection;
• document review or approval;
• reconstruct a regulated activity;
• demonstrate compliance during an inspection; or
• preserve the required record throughout retention.

Printing a report does not necessarily remove electronic-record reliance. The underlying electronic record may contain required:

• metadata;
• audit trails;
• processing methods;
• calculation parameters;
• electronic signatures;
• attachments;
• record relationships;
• review history; or
• dynamic functionality.

The assessment should identify the authoritative record source and explain which electronic and paper elements together constitute the complete regulated record.

Electronic Signatures

Part 11 electronic-signature requirements apply when an electronic signature is used to satisfy a required signature, initial, approval, authorization, review, or responsibility requirement.

An electronic signature is more than entering a user name into a field or adding a scanned image of a handwritten signature.

The assessment should determine:

• what action is being signed;
• why the signature is required;
• who may sign;
• the meaning of the signature;
• how the signer is authenticated;
• how the signature is linked to the record;
• what information appears in the signed record;
• whether the signed record can be altered afterward; and
• how the signature remains available throughout retention.

Electronic records can be subject to Part 11 even when no electronic signature is used. Electronic-record applicability and electronic-signature applicability should therefore be documented separately.

Closed Systems

Under Part 11, a closed system is an environment in which access is controlled by persons responsible for the content of the electronic records. A closed-system assessment should consider whether the regulated organization controls:

• account creation and removal;
• authentication;
• assigned roles;
• privileged access;
• external access;
• system configuration;
• record modification;
• record retention;
• record export;
• administrative activity; and
• supplier access.

A cloud or software-as-a-service system is not automatically an open system. It may operate as a closed system when access to the regulated environment and records is effectively controlled by the responsible organization through technical controls, contracts, supplier oversight, and defined administration.

Controls for closed systems are specified in 21 CFR 11.10.

Open Systems

An open system is an environment in which access is not controlled by persons responsible for the content of the electronic records.

Open-system arrangements require the applicable closed-system controls and additional measures necessary to protect authenticity, integrity, and confidentiality from record creation through receipt.

Additional controls may include:

• encryption;
• digital signatures;
• secure transmission;
• certificate management;
• verification of sender and recipient;
• transmission logging;
• tamper detection;
• protected communication channels; and
• receipt acknowledgment.

The controls should reflect the actual threat and transmission model rather than treating the term “open system” as a generic synonym for internet-connected.

Requirements for open systems are addressed in 21 CFR 11.30.

Hybrid Arrangements

A hybrid arrangement uses both paper and electronic components to create, review, approve, or retain a regulated record.

Examples include:

• electronic data with a signed paper report;
• paper forms transcribed into a database;
• electronic records with handwritten approvals;
• printed reports supported by retained electronic raw data;
• paper attachments linked to an electronic workflow; or
• electronic signatures applied to records with external paper components.

A hybrid arrangement should clearly define:

• which component is the official record;
• which supporting electronic data must be retained;
• how paper and electronic components are linked;
• which version is authoritative;
• how changes are controlled;
• where review evidence resides;
• how the complete record is retrieved;
• how signatures apply;
• and how discrepancies between components are resolved.

Hybrid arrangements can create duplicate or competing records if ownership and authoritative-source rules are unclear. Printing electronic data should not be used to avoid controls needed for the underlying electronic record.

Documented Part 11 Assessment

The Part 11 assessment should be a controlled, approved lifecycle record. It should identify:

• system name and identification;
• business process;
• intended use;
• system boundary;
• system owner and process owner;
• applicable predicate rules;
• required record types;
• authoritative record source;
• electronic records relied upon;
• electronic signatures used;
• closed, open, or hybrid arrangement;
• applicable Part 11 requirements;
• implemented controls;
• identified gaps;
• compensating controls;
• remediation actions;
• approval;
• and reassessment triggers.

A useful assessment addresses applicability at the record and function level.

The assessment should be revised when intended use, records, signatures, interfaces, hosting, access arrangements, configuration, or retention methods change.

Validation

For closed systems, 21 CFR 11.10(a) requires validation to ensure accuracy, reliability, consistent intended performance, and the ability to identify invalid or altered records.

Part 11 validation should be integrated into the overall computerized-system validation lifecycle rather than treated as a separate protocol.

Validation should address the applicable:

• electronic-record functions;
• data creation and modification;
• calculations;
• workflows;
• record status;
• security roles;
• authority checks;
• operational checks;
• audit trails;
• electronic signatures;
• signature manifestation;
• signature linking;
• interfaces;
• copies;
• retention;
• retrieval;
• backup;
• restoration; and
• error handling.

The validation approach should be based on intended use and risk, as described in Computerized System Validation Planning and Strategy and Computerized System Risk Assessment and Test Strategy.

A supplier’s standard testing may support validation, but it does not replace verification of the organization’s configuration, records, interfaces, roles, procedures, and intended use.

Accurate and Complete Copies

The system should be capable of producing accurate and complete copies of electronic records in both human-readable and electronic form suitable for inspection, review, and copying.

Copy capability should be evaluated for:

• record content;
• metadata;
• audit trails;
• electronic signatures;
• signature meaning;
• attachments;
• relationships;
• calculations;
• processing history;
• date and time information;
• status;
• comments;
• and applicable configuration context.

A human-readable PDF may support inspection but may not represent a complete electronic copy if significant metadata, audit trails, dynamic data, or relationships are excluded.

The organization should define:

• available copy formats;
• export procedures;
• authorized personnel;
• verification of exported content;
• protection of exports;
• required software for review; and
• response procedures for regulatory requests.

Copy capability should be tested before release and periodically when software, reporting tools, or export functions change.

Record Protection

Electronic records should be protected against:

• unauthorized creation;
• unauthorized modification;
• deletion;
• overwriting;
• corruption;
• loss;
• incomplete transfer;
• inappropriate reprocessing;
• accidental damage;
• and technology obsolescence.

Protection may depend on:

• access control;
• role restrictions;
• workflow status;
• database controls;
• audit trails;
• backup;
• restoration;
• encryption;
• storage protection;
• retention settings;
• archival;
• monitoring;
• cybersecurity;
• and controlled administration.

A record should not become editable merely because it is old, approved, archived, or transferred to another repository.

Retention and Retrieval

Retention periods originate from applicable predicate rules and approved record-retention schedules.

The system should maintain required records so they remain:

• complete;
• accurate;
• readable;
• protected;
• attributable;
• searchable;
• retrievable;
• and available for inspection.

Retention planning should address:

• data;
• metadata;
• audit trails;
• electronic signatures;
• attachments;
• relationships;
• indexes;
• proprietary formats;
• encryption keys;
• required viewing software;
• backup;
• archival;
• migration;
• system retirement;
• and retrieval testing.

System retirement does not end the retention obligation. Controls for long-term records are addressed in Electronic Records Lifecycle, Retention, and Archival and Computerized System Periodic Review and Retirement.

Access Control

System access should be limited to authorized individuals. Access controls should address:

• unique user accounts;
• identity verification;
• account approval;
• role assignment;
• least privilege;
• segregation of duties;
• administrator access;
• service accounts;
• authentication;
• password controls;
• multifactor authentication where appropriate;
• session management;
• remote access;
• account suspension;
• account removal;
• periodic access review;
• and emergency access.

The organization should prevent one individual from performing incompatible functions when independent review or approval is required.

Shared accounts undermine attribution and should not be used for regulated actions. Technical exceptions should be justified, restricted, and supported by controls that preserve individual accountability.

Detailed access controls are addressed in User Access, Privileged Accounts, and Electronic Signatures.

Secure Time-Stamped Audit Trails

Secure, computer-generated, time-stamped audit trails should independently record applicable actions that create, modify, or delete electronic records. Audit trails should capture, as appropriate:

• user identity;
• date and time;
• affected record;
• action performed;
• original value;
• new value;
• reason for change;
• record status;
• invalidation;
• reprocessing;
• configuration changes;
• master-data changes;
• and privileged activity.

Previously recorded information should not be obscured.

The assessment should determine:

• which events require an audit trail;
• whether audit trails are always enabled;
• who can access or administer them;
• whether they can be altered;
• how long they are retained;
• how they are searched and exported;
• who reviews them;
• when review occurs;
• and how exceptions are investigated.

An audit trail that exists but is not accessible or reviewed when required does not provide an effective control. See Audit Trails, Data Changes, and Review Controls.

Operational Checks

Operational checks enforce the permitted sequence of steps and events. Examples include controls that prevent:

• approval before required review;
• release before required testing;
• closure before mandatory fields are complete;
• use of an unapproved method;
• execution of a later workflow step before its prerequisite;
• use of expired material;
• or bypass of a required authorization.

Operational checks should reflect the regulated workflow and should be verified with positive and negative testing.

A written procedure instructing users to follow a sequence is not equivalent to an automated operational check when the system is intended to enforce that sequence.

Authority Checks

Authority checks ensure that only authorized individuals can:

• use the system;
• perform a regulated function;
• create or modify a record;
• approve or reject a record;
• electronically sign;
• change configuration;
• access restricted data;
• operate an input or output device;
• or perform the action at hand.

Authority should be based on approved roles and responsibilities rather than only on general system access.

Testing should challenge unauthorized actions as well as confirm permitted actions.

Device Checks

Device checks determine, where appropriate, the validity of the source of data input or operational instruction. Examples may include:

• instrument identity;
• terminal identity;
• scanner validation;
• equipment connection;
• source-system verification;
• interface endpoint;
• device status;
• calibration status;
• and permitted input source.

The applicability of device checks depends on the system architecture and process risk.

A manual data-entry application may require different device controls from an automated manufacturing system, analytical instrument, or networked laboratory interface.

Training and Accountability

Individuals who develop, maintain, administer, or use electronic-record and electronic-signature systems should have the education, training, and experience needed for their assigned tasks. Training should reflect the individual’s role.

It may include:

• routine operation;
• record creation;
• review and approval;
• electronic signatures;
• data correction;
• audit-trail review;
• access administration;
• configuration management;
• incident response;
• backup and recovery;
• and documentation control.

Organizations using electronic signatures should establish policies that hold individuals accountable for actions performed under those signatures.

Users should understand that electronic signatures represent legally significant actions and should not be shared, delegated, or applied on another person’s behalf.

Documentation Control

System documentation should be controlled throughout the lifecycle. Controlled documentation may include:

• requirements;
• specifications;
• configuration records;
• validation plans;
• risk assessments;
• test evidence;
• traceability;
• procedures;
• administrator guides;
• architecture;
• data-flow diagrams;
• supplier documentation;
• release records;
• change records;
• periodic reviews;
• and retirement records.

Controls should address:

• approval;
• revision;
• distribution;
• access;
• use;
• retention;
• change history;
• and prevention of unauthorized modification.

Documentation should reflect the current production system rather than only its original validated configuration.

Signature Manifestation

Under 21 CFR 11.50, signed electronic records should clearly show:

• the printed name of the signer;
• the date and time of signature; and
• the meaning associated with the signature.

Signature meaning may include:

• review;
• approval;
• authorship;
• verification;
• release;
• responsibility;
• or rejection.

The manifestation should appear in the human-readable form of the signed record. A generic indication such as “completed” may be inadequate when it does not explain the signer’s action.

Testing should confirm manifestation on system displays, reports, exports, and inspection copies where applicable.

Signature and Record Linking

Under 21 CFR 11.70, electronic and handwritten signatures executed to electronic records should be linked to their records so they cannot be removed, copied, or transferred to falsify another electronic record.

The assessment should determine whether:

• the signature remains linked to the exact record;
• subsequent record changes affect signature status appropriately;
• copied records preserve the correct signature context;
• exported records retain signature information;
• database changes cannot reassign signatures;
• and migration preserves the signature-record relationship.

A displayed signature image alone does not establish secure linking.

Electronic-Signature Identity and Uniqueness

Electronic signatures should be unique to one individual and should not be reused or reassigned. Controls should address:

• identity verification before assignment;
• unique credentials;
• signature authorization;
• credential issuance;
• credential protection;
• credential loss or compromise;
• account disabling;
• prohibited sharing;
• and retention of identity records.

Electronic signatures based on identification codes and passwords should use controls appropriate to 21 CFR 11.200 and 21 CFR 11.300.

The system should require the signing individual to perform the signature action. A user should not remain able to sign through another person’s unattended session.

Signature Execution

Electronic signatures not based on biometrics generally use at least two distinct identification components, such as an identification code and password.

The assessment should address:

• use during a continuous controlled session;
• use outside a continuous session;
• credential re-entry;
• session timeout;
• failed attempts;
• account locking;
• password expiration;
• compromised credentials;
• and administrator reset.

Signing controls should be tested under realistic conditions, including unauthorized attempts and interrupted sessions.

Open-System Security Controls

Open systems require additional protection appropriate to the circumstances. The control strategy may include:

• encryption in transit;
• encryption at rest;
• digital signatures;
• certificate validation;
• trusted endpoints;
• sender authentication;
• recipient authentication;
• transmission integrity checks;
• protected APIs;
• secure file exchange;
• receipt acknowledgment;
• monitoring;
• and nonrepudiation controls.

The assessment should identify the period during which the record is outside the responsible organization’s controlled environment and the controls protecting it throughout that period.

Hybrid-System Control

Hybrid systems require controls over the connection between paper and electronic components. Controls may include:

• unique record identifiers;
• controlled printouts;
• page numbering;
• verified transcription;
• reconciliation;
• signed references;
• attachment control;
• document scanning verification;
• true-copy procedures;
• and retrieval of the complete combined record.

The organization should prevent a paper component from being changed without corresponding control of the electronic component, or vice versa.

Legacy Systems

A legacy system is not automatically exempt from Part 11 because it predates the regulation, current guidance, or the organization’s validation program. The assessment should determine whether the legacy system:

• maintains required electronic records;
• remains relied upon;
• uses electronic signatures;
• has adequate validation evidence;
• protects records;
• restricts access;
• retains audit trails;
• produces accurate and complete copies;
• supports retrieval;
• and remains technically supportable.

The absence of a modern feature does not by itself determine whether the system must be retired. The organization should evaluate the regulatory and data-integrity risk, available procedural or technical controls, and feasibility of remediation.

Remediation

Part 11 gaps should be evaluated and prioritized according to risk. Remediation may include:

• correcting intended-use and applicability assessments;
• enabling audit trails;
• restricting access;
• separating user and administrator roles;
• implementing electronic signatures;
• improving signature manifestation;
• correcting signature linking;
• revising workflows;
• validating unverified functions;
• testing record copies;
• improving retention and retrieval;
• implementing backup and restoration controls;
• revising procedures;
• training users;
• upgrading software;
• replacing unsupported components;
• migrating data;
• or retiring the system.

Where immediate correction is not possible, the organization should document:

• the affected requirement;
• failure risk;
• affected records and processes;
• interim controls;
• monitoring;
• responsible owner;
• target completion date;
• residual-risk acceptance;
• and criteria for continued use.

Procedural controls should not be assumed equivalent to technical controls when the system is capable of preventing, detecting, or recording the relevant action.

Downloadable 21 CFR Part 11 Assessment Checklist

The downloadable checklist provides a structured questionnaire for assessing Part 11 applicability and documenting the controls implemented for a specific computerized system. It covers predicate-rule records, electronic records, system validation, record protection and retrieval, access control, audit trails, operational and authority checks, electronic signatures, identification codes and passwords, and supporting procedural controls.

Each response should be supported by appropriate documentation:

• Yes — identify the implemented control and supporting objective evidence.
• No — describe the identified gap and required corrective action.
• N/A — provide a documented system-specific justification.
• Not assessed — identify the responsible person and planned completion date.

The completed checklist should identify the system, intended use, regulated records, authoritative record source, hosting arrangement, system owner, assessor, assessment date, identified gaps, and required approvals.

The checklist supports a documented system assessment but does not replace evaluation of applicable predicate rules, review of 21 CFR Part 11, applicable FDA guidance, system-specific validation evidence, or Quality-unit approval.

Maintaining Part 11 Compliance

Part 11 compliance should be maintained through:

• change control;
• access review;
• privileged-activity review;
• audit-trail review;
• incident management;
• backup monitoring;
• restoration testing;
• supplier assessment;
• patch management;
• periodic review;
• record migration;
• and controlled retirement.

Changes to workflows, roles, audit trails, reports, interfaces, authentication, hosting, or retention can alter the original Part 11 assessment.

The lifecycle controls are addressed further in Computerized System Change Control, Patching, and Revalidation and Computerized System Periodic Review and Retirement.

Practical Part 11 Outcome

A useful Part 11 assessment produces more than a completed checklist. It establishes:

• which predicate-rule records exist;
• which electronic records are relied upon;
• which signatures are required;
• whether electronic signatures are used;
• which system arrangement applies;
• where the authoritative record resides;
• what controls are required;
• how those controls were verified;
• which gaps remain;
• how records will remain protected and retrievable; and
• how compliance will be maintained through change and retirement.

The objective is not to label an entire software product “Part 11 compliant.” The objective is to demonstrate that the configured computerized system, procedures, users, suppliers, and lifecycle controls collectively protect the electronic records and signatures relied upon for regulated activities.