Decide before you assess
Does Part 11 apply to this record and workflow?
Part 11 applicability is record- and use-specific. Begin with the underlying FDA record requirement, then examine the electronic workflow and reliance.
- 01
Is a record required?
Identify the record required by an applicable FDA predicate rule or submitted to FDA.
- 02
Is that record electronic?
Identify the authoritative format, including any hybrid paper and electronic process.
- 03
Do you rely on the electronic record?
Determine whether the electronic record is used to perform regulated work, make a decision, demonstrate compliance, or meet retention duties.
- 04
Assess the applicable Part 11 controls
Map the record and workflow to the relevant electronic-record requirements, risks, controls, tests, and operating procedures.
Requirement map
Requirements at a glance
Select a section number to move to the corresponding requirement card. Applicability depends on the record, workflow, system boundary, and signature use.
| Section | Requirement | Subpart | Primary control area |
|---|---|---|---|
| § 11.1 | Scope | A | Records |
| § 11.2 | Implementation | A | Records |
| § 11.3 | Definitions | A | Records |
| § 11.10(a) | Validation of Systems | B | Validation |
| § 11.10(b) | Accurate and Complete Copies | B | Records |
| § 11.10(c) | Record Protection and Retrieval | B | Records |
| § 11.10(d) | Authorized System Access | B | Access |
| § 11.10(e) | Secure, Computer-Generated Audit Trails | B | Audit Trail |
| § 11.10(f) | Operational Checks | B | Validation |
| § 11.10(g) | Authority Checks | B | Access |
| § 11.10(h) | Device Checks | B | Validation |
| § 11.10(i) | Education, Training, and Experience | B | Documentation |
| § 11.10(j) | Electronic-Signature Accountability Policy | B | Electronic Signature |
| § 11.10(k)(1) | System Documentation Distribution and Access | B | Documentation |
| § 11.10(k)(2) | Documentation Revision and Change Control | B | Documentation |
| § 11.30 | Controls for Open Systems | B | Security |
| § 11.50(a) | Signature Manifestations | B | Electronic Signature |
| § 11.50(b) | Human-Readable Signature Display | B | Electronic Signature |
| § 11.70 | Signature and Record Linking | B | Electronic Signature |
| § 11.100(a) | Signature Uniqueness | C | Electronic Signature |
| § 11.100(b) | Identity Verification Before Assignment | C | Electronic Signature |
| § 11.100(c) | Certification to FDA | C | Electronic Signature |
| § 11.200(a)(1) | Non-Biometric Signature Components | C | Electronic Signature |
| § 11.200(a)(2) | Use Only by Genuine Owners | C | Electronic Signature |
| § 11.200(a)(3) | Controls Against Signature Misuse | C | Electronic Signature |
| § 11.200(b) | Biometric Signatures | C | Electronic Signature |
| § 11.300(a) | Unique Identification Code and Password Combination | C | Access |
| § 11.300(b) | Periodic Code and Password Review | C | Access |
| § 11.300(c) | Lost or Compromised Credentials and Tokens | C | Access |
| § 11.300(d) | Transaction Safeguards and Unauthorized-Use Detection | C | Security |
| § 11.300(e) | Testing of Tokens and Cards | C | Security |
Interactive practitioner guide
Requirement explorer
Choose how you want to work: scan the regulation in order, apply it to a system type, or concentrate on one control area.
Showing 31 of 31 requirements.
21 CFR Part 11
Subpart A — General Provisions
§ 11.1ScopeApplicability
Regulation source summary
What the regulation addresses
Part 11 sets the criteria under which the Food and Drug Administration considers specified electronic records and electronic signatures trustworthy, reliable, and generally equivalent to paper records and handwritten signatures.
Read § 11.1 in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Start with the record required by an applicable FDA predicate rule or submitted to FDA. Then determine whether the organization creates or maintains that record electronically, relies on the electronic version, or uses an electronic signature.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- The predicate rule and required record
- The authoritative record format throughout its lifecycle
- Whether an electronic signature is used in place of a handwritten signature
How to address it
- Approved applicability assessment tied to named records
- Record inventory showing system of record and retention owner
- Separate electronic-signature applicability conclusion
What should I test?
- Trace one required record from creation to retrieval
- Confirm the declared authoritative record matches actual practice
- Verify hybrid paper/electronic responsibilities where used
Evidence to retain
- Part 11 applicability assessment
- Record inventory or data-flow map
- Predicate-rule reference and approved rationale
CSA testing approach
Test the control where failure matters
Use a record-centered walkthrough before selecting detailed controls. Test the boundary and reliance decision, not only a feature list.
eQMS example
Worked application
For an eQMS deviation, identify whether the electronic deviation record, approval history, and associated attachments are the records retained to satisfy the applicable Quality-system requirement.
Common mistake
Declaring that Part 11 applies—or does not apply—to an entire application without identifying the regulated record.
Better approach
Document applicability at the record and workflow level, including the point at which the electronic record is relied upon.
§ 11.2ImplementationApplicability
Regulation source summary
What the regulation addresses
Records may be kept electronically instead of on paper when Part 11 requirements are met; records submitted to FDA electronically must comply with applicable agency requirements.
Read § 11.2 in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The organization should define how electronic records are created, maintained, inspected, copied, and—when relevant—submitted. A system being electronic does not by itself establish a compliant implementation.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- How required records are maintained and supplied for inspection
- Whether an FDA submission path has separate technical requirements
- Whether procedures match the configured workflow
How to address it
- Controlled implementation decision
- Inspection-copy process
- Submission controls where applicable
What should I test?
- Generate an inspection-ready record copy
- Confirm the copy is complete and understandable
- Reconcile procedure steps with the live configuration
Evidence to retain
- Implementation or validation plan
- Approved copy/export procedure
- Demonstrated sample retrieval
CSA testing approach
Test the control where failure matters
Perform a representative end-to-end record demonstration with objective output comparison.
LIMS example
Worked application
For a LIMS result, demonstrate both the human-readable report and the supporting electronic context needed to reconstruct sample receipt, testing, calculation, review, and approval.
Common mistake
Treating an electronic PDF printout as proof that the underlying electronic record is adequately controlled.
Better approach
Evaluate the native record, metadata, audit history, and available inspection copy together.
§ 11.3DefinitionsApplicability
Regulation source summary
What the regulation addresses
Part 11 defines key terms including electronic record, electronic signature, digital signature, biometrics, closed system, and open system.
Read § 11.3 in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Use the regulatory definitions consistently in the applicability assessment and validation records. In particular, determine whether system access is controlled by persons responsible for the content of the records.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Closed-system or open-system classification
- What constitutes the complete electronic record
- Whether the signature method is electronic, digital, or biometric
How to address it
- Defined terms in the assessment template
- Architecture-based system classification
- Documented signature method and identity mechanism
What should I test?
- Confirm access boundaries described in the assessment
- Inspect the native record components and metadata
- Verify signature behavior matches the documented method
Evidence to retain
- System boundary diagram
- Terminology and applicability record
- Identity and signature design description
CSA testing approach
Test the control where failure matters
Use architecture review plus focused demonstrations of access, identity, and record composition.
SaaS example
Worked application
A vendor-hosted SaaS QMS can still operate as a closed system when access is controlled by the parties responsible for the records; document the shared identity and administration boundary.
Common mistake
Calling every typed name a digital signature or assuming cloud hosting automatically makes a system open.
Better approach
Classify the actual access boundary, identity mechanism, and record structure using the regulation’s definitions.
21 CFR Part 11
Subpart B — Electronic Records
§ 11.10(a)Validation of SystemsElectronic Records
Regulation source summary
What the regulation addresses
Closed systems must use controls including validation to support accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
Read § 11.10(a) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Validate the configured system for its approved intended use. The validation approach should address GxP functions, realistic failure scenarios, existing controls, and proportionate testing—not simply reproduce a supplier test library.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Intended use and GxP functions
- Failure effects and detectability
- Configuration, interfaces, data, and operating procedures
How to address it
- Approved validation plan and functional risk assessment
- Requirements and configuration control
- Traceable testing and release decision
What should I test?
- Challenge high-risk functions with scripted tests
- Use unscripted or exploratory testing for variable workflows
- Confirm detection of invalid or altered records
Evidence to retain
- Validation plan
- URS and functional risk assessment
- Protocols, results, deviations, traceability, and validation summary
CSA testing approach
Test the control where failure matters
Combine scripted critical-path challenges with exploratory testing around exceptions and configuration boundaries.
MES example
Worked application
For an MES recipe workflow, challenge wrong-step execution, skipped checks, exception handling, role restrictions, and the resulting electronic batch record—not only happy-path recipe completion.
Common mistake
Using test-script count as the main measure of validation completeness.
Better approach
Show why the selected testing addresses the intended use, failure risk, and configured controls.
§ 11.10(b)Accurate and Complete CopiesRecord Retention & Retrieval
Regulation source summary
What the regulation addresses
The system must be able to generate accurate and complete copies of records in both human-readable and electronic form for FDA inspection, review, and copying.
Read § 11.10(b) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
A report can be readable yet incomplete. Define which data, metadata, attachments, signatures, and audit history are needed to understand and reconstruct the record.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Human-readable and electronic export capability
- Completeness of metadata, attachments, and audit history
- Format usability throughout retention
How to address it
- Approved record-copy specification
- Controlled export procedure
- Periodic verification of supported formats
What should I test?
- Compare exported and native records field by field
- Include changed data, signatures, attachments, and audit history
- Open the electronic copy with the planned inspection tool
Evidence to retain
- Copy-verification protocol and comparison
- Example export package
- Procedure defining responsible role and format
CSA testing approach
Test the control where failure matters
Use a content reconciliation test with normal, corrected, and exceptional records.
Laboratory Software example
Worked application
For chromatography data, verify that the retained package can provide raw data, sequence details, method versions, processing history, results, approvals, and relevant audit trails.
Common mistake
Testing that a PDF opens without checking whether it contains the complete regulated record.
Better approach
Define completeness first, then verify content and context against the native record.
§ 11.10(c)Record Protection and RetrievalRecord Retention & Retrieval
Regulation source summary
What the regulation addresses
Records must be protected to support accurate and ready retrieval throughout the required retention period.
Read § 11.10(c) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Backup alone is not retention. The organization must protect the record from loss or unauthorized alteration and prove that an understandable record can be retrieved for the full retention period.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Retention period and archival responsibility
- Backup, restore, migration, and format-obsolescence controls
- Search and retrieval performance
How to address it
- Retention schedule and archive design
- Backup and restore monitoring
- Migration verification and periodic retrieval checks
What should I test?
- Restore a representative regulated record
- Retrieve old records using defined search criteria
- Verify readability and context after migration
Evidence to retain
- Retention requirements
- Restore-test result
- Archive retrieval and migration reconciliation
CSA testing approach
Test the control where failure matters
Use risk-based recovery and long-aged-record scenarios, including a restore to an alternate environment where feasible.
Training System example
Worked application
Retrieve a historical qualification record showing the learner, course version, completion, assessment, approval, and later curriculum changes without overwriting the earlier context.
Common mistake
Citing successful backup jobs without demonstrating record restoration and readability.
Better approach
Test restore and retrieval against the complete-record definition and retention schedule.
§ 11.10(d)Authorized System AccessSystem Access
Regulation source summary
What the regulation addresses
System access must be limited to authorized individuals.
Read § 11.10(d) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Access control includes identity lifecycle, role design, privileged administration, authentication, periodic review, and timely removal—not just a login screen.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Role-to-job alignment and segregation of duties
- Joiner, mover, leaver timing
- Privileged and service-account governance
How to address it
- Approved role matrix
- Identity provisioning and deprovisioning workflow
- Periodic access and administrator review
What should I test?
- Attempt permitted and prohibited actions for representative roles
- Verify a terminated account cannot authenticate
- Review privileged-role assignment and activity
Evidence to retain
- Access-control matrix
- Provisioning and removal records
- Periodic access-review result
CSA testing approach
Test the control where failure matters
Use role-pair and negative-permission tests focused on GxP transactions and administrator pathways.
ERP example
Worked application
Confirm that a warehouse user cannot change released material status or approve the same transaction, while the authorized Quality role can perform and trace the defined action.
Common mistake
Testing one valid login and treating access control as complete.
Better approach
Test authorization at critical transactions and review how access remains appropriate over time.
§ 11.10(e)Secure, Computer-Generated Audit TrailsAudit Trails
Regulation source summary
What the regulation addresses
Secure, computer-generated, time-stamped audit trails must independently record operator actions that create, modify, or delete electronic records, without obscuring prior information, and be retained and available for review and copying.
Read § 11.10(e) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
An audit trail is useful only when it captures the right events, protects prior values, identifies the actor and time, remains linked to the record, and is reviewed when the process risk requires it.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Events and fields subject to change
- Old value, new value, actor, date/time, reason, and record linkage
- Audit-trail review scope, frequency, and escalation
How to address it
- Non-editable audit history
- Synchronized time and controlled reason-for-change
- Risk-based review procedure and review report
What should I test?
- Create, modify, and where permitted delete or void a record
- Attempt to alter or bypass the audit history
- Review, filter, export, and retain the audit trail with the record
Evidence to retain
- Audit-trail assessment
- Configuration record
- Challenge-test results and completed review record
CSA testing approach
Test the control where failure matters
Use targeted scripted challenges for critical events, followed by an exploratory review of filtering, context, export, and exception handling.
LIMS example
Worked application
Change a reportable result under an authorized correction workflow and verify sample ID, old and new values, user, timestamp, reason, review status, and the original result remain available.
Common mistake
Confirming that an audit-trail screen exists without testing completeness, security, reviewability, or retention.
Better approach
Map critical record changes to expected audit events, challenge each event, and verify the operational review process.
§ 11.10(f)Operational ChecksOperational and Authority Checks
Regulation source summary
What the regulation addresses
Operational system checks must enforce the permitted sequencing of steps and events where appropriate.
Read § 11.10(f) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Where order matters to product quality, data integrity, or a required review, the system should prevent or clearly control out-of-sequence execution.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Critical workflow sequence and prerequisites
- Override and exception paths
- State transitions and status controls
How to address it
- Configured workflow gates
- Controlled exception handling
- Status and prerequisite rules
What should I test?
- Attempt to skip a required step
- Attempt an out-of-sequence approval
- Challenge exception and rework paths
Evidence to retain
- Workflow specification
- Configuration evidence
- Negative and exception-path test results
CSA testing approach
Test the control where failure matters
Prioritize negative tests at high-risk gates and supplement them with unscripted operator-path exploration.
MES example
Worked application
Attempt to execute a dispensing step before equipment clearance and material verification; verify the batch cannot proceed without the required sequence or an approved exception.
Common mistake
Testing only the approved sequence and never attempting to bypass it.
Better approach
Challenge prohibited transitions and verify that exceptions are controlled, recorded, and reviewed.
§ 11.10(g)Authority ChecksOperational and Authority Checks
Regulation source summary
What the regulation addresses
Authority checks must ensure that only authorized individuals can use the system, electronically sign, access operations or devices, alter records, or perform the operation at hand.
Read § 11.10(g) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The permission must be evaluated at the business action, not only at application entry. Sensitive actions may need role, status, location, or segregation-of-duty restrictions.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Who may perform each critical action
- Who may approve or electronically sign
- Administrator capabilities and conflicts
How to address it
- Transaction-level authorization
- Segregation-of-duty rules
- Privileged-action monitoring
What should I test?
- Attempt a critical action with an unauthorized role
- Test self-approval restrictions
- Verify administrator activity is attributable and reviewed
Evidence to retain
- Role/action matrix
- Negative authorization tests
- Privileged-access review
CSA testing approach
Test the control where failure matters
Use role-based negative testing around approval, record change, status change, and administration.
eQMS example
Worked application
Verify that a CAPA owner can update assigned actions but cannot approve CAPA effectiveness when procedure requires an independent Quality approver.
Common mistake
Equating authenticated access with authority to perform every available transaction.
Better approach
Link permissions to GxP responsibilities and challenge them at the transaction level.
§ 11.10(h)Device ChecksOperational and Authority Checks
Regulation source summary
What the regulation addresses
Device checks must determine, as appropriate, the validity of the source of data input or operational instruction.
Read § 11.10(h) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Where a device, instrument, scanner, or interface supplies critical data or commands, confirm that the system accepts information from the correct source and detects invalid or disconnected sources.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Critical input devices and interfaces
- Source identity and connection status
- Behavior when the source is invalid, unavailable, or misconfigured
How to address it
- Device or interface identification
- Connection and plausibility checks
- Alarm and exception handling
What should I test?
- Disconnect or substitute the data source where safe
- Send invalid or out-of-range input
- Verify source identity is recorded
Evidence to retain
- Interface or device specification
- Configuration record
- Fault-injection or simulation test
CSA testing approach
Test the control where failure matters
Use controlled fault injection or a validated simulator when direct disruption would be unsafe.
Laboratory Software example
Worked application
Challenge an instrument connection so the data system rejects or flags results from an unapproved instrument identifier and preserves the exception.
Common mistake
Assuming a technically successful interface guarantees that the data came from the intended source.
Better approach
Verify source identity, data mapping, error behavior, and transaction reconciliation.
§ 11.10(i)Education, Training, and ExperienceSystem Documentation
Regulation source summary
What the regulation addresses
Persons who develop, maintain, or use electronic record and signature systems must have the education, training, and experience needed for their assigned tasks.
Read § 11.10(i) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Qualification should match the role: users, reviewers, administrators, support staff, developers, and validators do not need identical training, but each needs evidence of competence for assigned responsibilities.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Role-specific knowledge and task qualification
- Training completion before access or responsibility
- Supplier and contractor competence where relied upon
How to address it
- Role-based curriculum
- Training-to-access linkage
- Competence records for specialized tasks
What should I test?
- Sample users against required curricula and access dates
- Verify administrator qualification
- Trace an outsourced validation task to qualified personnel
Evidence to retain
- Training matrix
- Completion and qualification records
- Role or job-description linkage
CSA testing approach
Test the control where failure matters
Use record sampling across user, reviewer, administrator, and support roles rather than a feature test alone.
Training System example
Worked application
Confirm a new Quality approver completes the applicable procedure and e-signature training before the approval role is granted.
Common mistake
Using a single awareness course as evidence for all system responsibilities.
Better approach
Define competence by role and verify training before the person performs the regulated task.
§ 11.10(j)Electronic-Signature Accountability PolicySignature Controls
Regulation source summary
What the regulation addresses
Written policies must hold individuals accountable and responsible for actions initiated under their electronic signatures to deter record and signature falsification.
Read § 11.10(j) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The policy should state that credentials and signatures are personal, actions are attributable, sharing is prohibited, and suspected misuse must be reported and investigated.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Policy language and employee acknowledgement
- Consequences and reporting route
- Alignment with training and access procedures
How to address it
- Approved accountability policy
- Documented acknowledgement
- Investigation and disciplinary process
What should I test?
- Sample acknowledgements for active signers
- Interview representative users
- Trace a suspected misuse scenario to the response process
Evidence to retain
- Signed policy acknowledgement
- Training record
- Controlled incident procedure
CSA testing approach
Test the control where failure matters
Review policy design and sample operating evidence; software testing alone cannot demonstrate this control.
ERP example
Worked application
A release approver acknowledges that their electronic signature is personal and that approving a material-status change represents their own documented decision.
Common mistake
Relying on a generic acceptable-use policy that never addresses electronic signatures.
Better approach
Make accountability explicit and connect it to onboarding, recurrent training, and incident handling.
§ 11.10(k)(1)System Documentation Distribution and AccessSystem Documentation
Regulation source summary
What the regulation addresses
Controls must address adequate distribution of, access to, and use of documentation for system operation and maintenance.
Read § 11.10(k)(1) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Current procedures, specifications, manuals, runbooks, and administration instructions should be available only to appropriate roles, while obsolete versions remain controlled as required.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Document ownership and approved versions
- Role-based access to operational and technical instructions
- Supplier-document updates
How to address it
- Document management workflow
- Read access by role
- Periodic review and superseded-document control
What should I test?
- Retrieve the effective procedure from a user role
- Confirm obsolete instructions are not presented as current
- Verify restricted technical documents are appropriately limited
Evidence to retain
- Document index
- Effective-version record
- Access and distribution evidence
CSA testing approach
Test the control where failure matters
Use document sampling and role-based retrieval demonstrations, supported by procedure review.
SaaS example
Worked application
Maintain approved customer configuration and administration procedures while evaluating vendor release documentation through change control.
Common mistake
Keeping uncontrolled copies of administrator instructions in shared folders.
Better approach
Control the source, effective version, intended audience, and change path for system documentation.
§ 11.10(k)(2)Documentation Revision and Change ControlSystem Documentation
Regulation source summary
What the regulation addresses
Revision and change-control procedures must maintain an audit trail documenting the time-sequenced development and modification of system documentation.
Read § 11.10(k)(2) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Specifications, configurations, procedures, code, and support documentation should show what changed, who changed it, why, when, and which version became effective.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Documents that define or support the validated system
- Versioning and approval workflow
- Link between system changes and document changes
How to address it
- Controlled document revision
- Change record with impact assessment
- Traceability to release and effective date
What should I test?
- Follow one changed requirement through approval and release
- Verify prior versions remain retrievable
- Confirm unauthorized users cannot issue revisions
Evidence to retain
- Revision history
- Approved change control
- Document audit trail and effective-version report
CSA testing approach
Test the control where failure matters
Trace a real or staged revision end to end and inspect chronology, authorization, and retrievability.
Spreadsheet example
Worked application
A controlled calculation workbook revision links formula changes, independent verification, test results, approval, effective date, and the retired prior template.
Common mistake
Updating validation documents after implementation without a contemporaneous change history.
Better approach
Make documentation change part of the same controlled change that modifies the system or process.
§ 11.30Controls for Open SystemsOpen Systems
Regulation source summary
What the regulation addresses
Open systems require the controls used for closed systems plus additional measures—such as document encryption and appropriate digital-signature standards—to support authenticity, integrity, and confidentiality as needed.
Read § 11.30 in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
When persons responsible for the records do not control access to the system, assess transmission, external access, identity, tamper protection, and confidentiality risks beyond the normal closed-system controls.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Why the system is classified as open
- External communication and trust boundaries
- Need for encryption, digital signatures, or equivalent controls
How to address it
- Protected transport and storage
- Strong identity and integrity verification
- Security monitoring and incident response
What should I test?
- Verify encrypted transmission and certificate handling
- Challenge tamper detection where applicable
- Test unauthorized external-access attempts
Evidence to retain
- Open-system assessment
- Architecture and security configuration
- Security and integrity test results
CSA testing approach
Test the control where failure matters
Combine architecture review, configuration inspection, and targeted security tests at the external trust boundary.
SaaS example
Worked application
For a portal receiving externally submitted regulated data, protect transport, verify submitting identity, detect altered payloads, and preserve receipt history before data enters the controlled record.
Common mistake
Classifying every internet-accessible SaaS service as open without examining who controls access to the records.
Better approach
Document the access boundary first; then select additional controls for the actual authenticity, integrity, and confidentiality risks.
§ 11.50(a)Signature ManifestationsElectronic Signatures
Regulation source summary
What the regulation addresses
Signed electronic records must show the signer’s printed name, the date and time of signing, and the meaning associated with the signature.
Read § 11.50(a) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
A reviewer should be able to see who signed, when, and whether the act meant review, approval, responsibility, authorship, or another defined meaning.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Displayed signer identity
- Timestamp and time-zone handling
- Signature meaning for each workflow action
How to address it
- Configured signature manifestation
- Controlled signature-meaning vocabulary
- Time-source and display rules
What should I test?
- Sign with each critical meaning
- Inspect the native record and generated copy
- Verify date, time, and identity after later workflow changes
Evidence to retain
- Signature configuration
- Test record for each meaning
- Copy showing complete manifestation
CSA testing approach
Test the control where failure matters
Use a compact scripted matrix covering each signature meaning, workflow state, and output format.
eQMS example
Worked application
A change-control approval shows “Sandip Thorat,” the signing timestamp, and “Quality approval,” both in the application and in the inspection copy.
Common mistake
Displaying “Approved” and a date without the signer’s printed name or defined meaning.
Better approach
Verify all three manifestation elements in every place the signed record is viewed or exported.
§ 11.50(b)Human-Readable Signature DisplayElectronic Signatures
Regulation source summary
What the regulation addresses
The signature information required by § 11.50(a) must be subject to the same controls as electronic records and included in human-readable forms of the record, including display and printout.
Read § 11.50(b) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The signature must travel with the readable record. A printout or PDF that drops the signer, time, or meaning is not a complete signed-record presentation.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- On-screen display
- Print and PDF output
- Archive and migrated-record presentation
How to address it
- Output templates including signature fields
- Version-controlled report design
- Copy-verification procedure
What should I test?
- Compare screen, PDF, and print presentations
- Retrieve a historical signed record
- Verify multi-signature sequences remain understandable
Evidence to retain
- Approved report template
- Output comparison
- Historical retrieval result
CSA testing approach
Test the control where failure matters
Use output equivalence tests across current and retained records.
Training System example
Worked application
A training-completion report preserves the learner identity, completion time, attestation meaning, and any reviewer approval when exported.
Common mistake
Testing the signature in the application but not in the record copy used for inspection.
Better approach
Verify manifestation at every supported human-readable presentation point.
§ 11.70Signature and Record LinkingSignature Controls
Regulation source summary
What the regulation addresses
Electronic and handwritten signatures executed to electronic records must be linked to their respective records so they cannot be excised, copied, or transferred to falsify another record by ordinary means.
Read § 11.70 in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The signature relationship must be structural, not a loose image or text field. Copying, exporting, migrating, or revising the record should not permit the signature to be reassigned to different content.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Technical link between signature and record version
- Behavior after record revision or copy
- Migration and export preservation
How to address it
- System-enforced record/signature association
- Immutable signature metadata
- Controlled migration mapping
What should I test?
- Attempt to copy a signature to another record
- Modify signed content and observe signature status
- Export and migrate a signed record
Evidence to retain
- Design or configuration description
- Tamper and transfer test results
- Migration verification
CSA testing approach
Test the control where failure matters
Perform negative tamper, copy, and version-change tests against the signed record.
ERP example
Worked application
Changing a released material record creates a new controlled transaction or invalidates the prior approval; the original signature cannot be moved to the revised data.
Common mistake
Using a pasted signature image or editable signer field as an electronic signature.
Better approach
Use a system transaction that binds identity, meaning, time, and the signed record state.
21 CFR Part 11
Subpart C — Electronic Signatures
§ 11.100(a)Signature UniquenessElectronic Signatures
Regulation source summary
What the regulation addresses
Each electronic signature must be unique to one individual and must not be reused by, or reassigned to, anyone else.
Read § 11.100(a) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Identity is personal and enduring. Shared accounts, recycled identifiers, and reassigned signature identities undermine attribution even when business roles change.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Identifier assignment and uniqueness
- Handling of names, contractors, and rehires
- Prohibition of shared accounts
How to address it
- Unique identity source
- Non-reassignment rule
- Duplicate-identity check
What should I test?
- Attempt duplicate identity creation
- Review inactive and rehire handling
- Sample for shared or generic signers
Evidence to retain
- Identity-management procedure
- User master extract
- Uniqueness review result
CSA testing approach
Test the control where failure matters
Use identity-lifecycle record sampling plus duplicate and reassignment challenge tests.
LIMS example
Worked application
Historical result approvals remain attributed to the original analyst even after that analyst leaves and a new analyst assumes the same laboratory role.
Common mistake
Reassigning a departed employee’s account to a replacement worker.
Better approach
Disable the prior identity and create a new, unique identity for the new individual.
§ 11.100(b)Identity Verification Before AssignmentElectronic Signatures
Regulation source summary
What the regulation addresses
An organization must verify an individual’s identity before establishing, assigning, certifying, or otherwise sanctioning that individual’s electronic signature.
Read § 11.100(b) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Before signature capability is issued, a defined process should establish that the digital identity belongs to the real person and that approval to sign has been granted.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Identity proofing method
- Approval authority for signature assignment
- Remote and contractor onboarding
How to address it
- Documented identity proofing
- Authorized signature enrollment
- Identity-provider linkage
What should I test?
- Sample signer enrollment records
- Verify identity attributes across source systems
- Challenge unapproved signature activation
Evidence to retain
- Identity-verification record
- Enrollment approval
- Signer-to-account reconciliation
CSA testing approach
Test the control where failure matters
Review a risk-based sample of enrollment records and attempt activation without the required approvals.
SaaS example
Worked application
A remote contractor receives eQMS signature capability only after identity proofing, sponsor approval, required training, and verified identity-provider linkage.
Common mistake
Granting signature permissions through routine role provisioning without documented identity verification.
Better approach
Make identity verification and signature authorization explicit gates before activation.
§ 11.100(c)Certification to FDAElectronic Signatures
Regulation source summary
What the regulation addresses
Persons using electronic signatures must certify to FDA that the signatures used after the specified date are intended to be the legally binding equivalent of traditional handwritten signatures, with certification submitted as required.
Read § 11.100(c) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The organization should determine whether and how the certification requirement applies, retain evidence of the certification, and ensure the legal-equivalence intent is reflected in policy and training.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Applicability of FDA certification
- Submitting legal entity and records
- Alignment with signature policy
How to address it
- Responsible organizational owner
- Retained certification evidence
- Procedure for additional certification or testimony if requested
What should I test?
- Verify certification evidence is retrievable
- Confirm covered organizations and signature uses
- Check policy consistency
Evidence to retain
- Certification correspondence or retained record
- Applicability rationale
- Electronic-signature policy
CSA testing approach
Test the control where failure matters
Treat this as a document and governance verification rather than a software functional test.
eQMS example
Worked application
The manufacturer retains its Part 11 electronic-signature certification and can connect it to the policy governing eQMS approvals.
Common mistake
Assuming the software supplier’s statement satisfies the regulated organization’s certification responsibility.
Better approach
Assign a legal or regulatory owner and retain the organization-specific certification evidence.
§ 11.200(a)(1)Non-Biometric Signature ComponentsElectronic Signatures
Regulation source summary
What the regulation addresses
Non-biometric electronic signatures must use at least two distinct identification components, such as an identification code and password, with specified behavior for continuous and non-continuous controlled-access sessions.
Read § 11.200(a)(1) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The signature transaction must require the appropriate identity components based on session context. A user merely being logged in may not be sufficient for a later signing action outside a continuous controlled session.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- The two distinct signature components
- Continuous-session definition and timeout
- Reauthentication behavior for later signatures
How to address it
- Configured signature challenge
- Session timeout and lock
- Identity-provider and application behavior alignment
What should I test?
- Sign first and later records within one session
- Sign after logout, timeout, or session interruption
- Attempt signing with a remembered or delegated session
Evidence to retain
- Authentication design
- Session and signature configuration
- Timed challenge-test results
CSA testing approach
Test the control where failure matters
Use deterministic scripted tests with controlled timers and clearly recorded session state.
Training System example
Worked application
The learner completes an attestation in a controlled session, then must re-enter both required components after the session expires before signing another completion.
Common mistake
Testing one signature immediately after login and ignoring subsequent or interrupted sessions.
Better approach
Test the first signature, later signatures, timeout, logout, and reauthentication as separate scenarios.
§ 11.200(a)(2)Use Only by Genuine OwnersSignature Controls
Regulation source summary
What the regulation addresses
Electronic signatures not based on biometrics must be used only by their genuine owners.
Read § 11.200(a)(2) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Technology, policy, training, and monitoring should work together to prevent credential sharing and to identify suspected use by someone other than the assigned signer.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Credential-sharing risks
- Authentication strength and device/session controls
- Monitoring and investigation of unusual use
How to address it
- Personal credentials and prohibited-sharing policy
- Appropriate multifactor or contextual safeguards
- Security monitoring and incident response
What should I test?
- Verify concurrent-session behavior
- Review unusual-login monitoring
- Confirm suspected misuse follows the incident process
Evidence to retain
- Security configuration
- Accountability acknowledgement
- Monitoring or investigation records
CSA testing approach
Test the control where failure matters
Combine configuration tests with workflow observation and security-event sampling.
MES example
Worked application
Shared shop-floor terminals support rapid personal authentication so each operator signs their own batch-record action without borrowing a coworker’s session.
Common mistake
Relying on policy alone while shared terminals or operational pressure make credential sharing easy.
Better approach
Design the workflow so each user can authenticate efficiently without sharing and monitor for misuse.
§ 11.200(a)(3)Controls Against Signature MisuseSignature Controls
Regulation source summary
What the regulation addresses
Attempted use of an individual’s electronic signature by anyone else must require collaboration of two or more individuals.
Read § 11.200(a)(3) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Administrative reset, impersonation, emergency access, or recovery processes must not let one person quietly assume another person’s signature identity.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Credential reset and recovery process
- Administrator impersonation capabilities
- Emergency-access and break-glass paths
How to address it
- Dual authorization for sensitive recovery
- No administrator ability to sign as another user
- Logged and reviewed emergency actions
What should I test?
- Attempt administrative signature impersonation
- Walk through lost-credential recovery
- Verify dual control and independent records
Evidence to retain
- Recovery procedure
- Configuration or design evidence
- Dual-authorization record
CSA testing approach
Test the control where failure matters
Use a controlled recovery exercise and negative administrator-impersonation test.
ERP example
Worked application
A privileged administrator can unlock an approver’s account but cannot know the replacement secret or execute an approval as that person.
Common mistake
Allowing a help-desk administrator to reset credentials and then use the account without an independent control.
Better approach
Separate reset authority from signature use and require independent collaboration for exceptional access.
§ 11.200(b)Biometric SignaturesElectronic Signatures
Regulation source summary
What the regulation addresses
Electronic signatures based on biometrics must be designed so they cannot be used by anyone other than their genuine owners.
Read § 11.200(b) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Biometric use adds enrollment, matching, fallback, spoof-resistance, privacy, and device-control questions. The regulated organization must understand the complete authentication design.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Enrollment and identity binding
- False acceptance and spoofing controls
- Fallback and recovery paths
How to address it
- Controlled biometric enrollment
- Appropriate matching and liveness controls
- Non-biometric fallback with equivalent governance
What should I test?
- Attempt use by an unenrolled person
- Challenge fallback and device replacement
- Verify biometric events are attributable and protected
Evidence to retain
- Biometric design assessment
- Enrollment record
- Challenge and fallback test results
CSA testing approach
Test the control where failure matters
Use boundary-focused security and functional tests, including controlled failure and fallback scenarios.
Laboratory Software example
Worked application
If analysts use a biometric-enabled workstation to sign results, validation covers enrollment, workstation binding, application reauthentication, fallback, and audit history.
Common mistake
Assuming a device-native biometric automatically satisfies regulated signature controls.
Better approach
Assess the application, identity provider, device, biometric service, and fallback process as one control chain.
§ 11.300(a)Unique Identification Code and Password CombinationID / Password Controls
Regulation source summary
What the regulation addresses
Identification-code and password combinations must be maintained so no two individuals have the same combination.
Read § 11.300(a) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Each user needs a unique identifier and personal secret or equivalent authentication factor. Shared credentials defeat attribution even if the work area is shared.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Uniqueness across active and inactive accounts
- Generic, shared, and service accounts
- Identity synchronization between systems
How to address it
- Unique-user enforcement
- Controlled non-human accounts
- Identity-source reconciliation
What should I test?
- Attempt duplicate account creation
- Review generic and service-account use
- Reconcile a sample across identity provider and application
Evidence to retain
- Account standard
- User inventory
- Uniqueness and reconciliation report
CSA testing approach
Test the control where failure matters
Use configuration inspection, account analytics, and representative negative tests.
LIMS example
Worked application
Every analyst has a unique LIMS identity; the instrument interface uses a separately controlled service account that cannot review or sign results.
Common mistake
Using one laboratory or production login for multiple operators.
Better approach
Provide efficient personal authentication and tightly restrict non-human accounts from human signing actions.
§ 11.300(b)Periodic Code and Password ReviewID / Password Controls
Regulation source summary
What the regulation addresses
Identification codes and passwords must be checked, recalled, or revised periodically, for example through password aging.
Read § 11.300(b) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
The control set should keep authentication current as people, threats, and credentials change. Modern identity controls may use risk-based authentication, multifactor authentication, compromise detection, and lifecycle review alongside password rules.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Credential review and expiration controls
- Compromised-credential detection
- Inactive and dormant-account handling
How to address it
- Approved authentication standard
- Periodic account review
- Identity-provider monitoring and credential reset
What should I test?
- Verify configured credential rules
- Test expired or disabled credentials
- Review dormant-account identification
Evidence to retain
- Authentication configuration
- Periodic review result
- Credential-reset or compromise record
CSA testing approach
Test the control where failure matters
Inspect effective configuration at both identity-provider and application layers, then test key failure states.
SaaS example
Worked application
A SaaS QMS uses corporate single sign-on; the assessment verifies identity-provider policies, multifactor authentication, dormant-account reviews, and application session behavior.
Common mistake
Documenting a password-aging requirement that is not implemented in the actual identity provider.
Better approach
Validate the effective authentication control chain, including federated identity and monitoring.
§ 11.300(c)Lost or Compromised Credentials and TokensID / Password Controls
Regulation source summary
What the regulation addresses
Procedures must electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and similar devices and issue replacements under suitable controls.
Read § 11.300(c) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Loss or suspected compromise must trigger prompt revocation, documented investigation, controlled replacement, and assessment of potentially affected regulated actions.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Reporting and revocation time
- Replacement identity verification
- Review of activity during the exposure window
How to address it
- Immediate revocation capability
- Controlled replacement enrollment
- Security-event and signature review
What should I test?
- Revoke a test token and attempt reuse
- Walk through replacement issuance
- Confirm activity can be reviewed for the exposure period
Evidence to retain
- Lost-credential procedure
- Revocation and replacement record
- Event-review result
CSA testing approach
Test the control where failure matters
Use a tabletop plus technical revocation test, including evidence of event review.
Training System example
Worked application
After a lost authentication device is reported, access is revoked, recent attestations are reviewed, and a replacement is issued only after renewed identity verification.
Common mistake
Replacing a lost token without reviewing actions that occurred before revocation.
Better approach
Treat loss as a security event affecting both future access and the trustworthiness of recent actions.
§ 11.300(d)Transaction Safeguards and Unauthorized-Use DetectionID / Password Controls
Regulation source summary
What the regulation addresses
Transaction safeguards must prevent unauthorized use of passwords or identification codes and detect and report attempts at unauthorized use to system security and, as appropriate, organizational management.
Read § 11.300(d) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Authentication safeguards should prevent guessing and misuse, record unsuccessful activity, alert the right responders, and connect security events to possible impact on regulated records.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Lockout, throttling, and risk-based controls
- Detection and alert routing
- Escalation to Quality when regulated records may be affected
How to address it
- Authentication safeguards
- Security monitoring and alerts
- Documented incident triage
What should I test?
- Generate repeated failed authentication attempts
- Verify alert content and delivery
- Walk through GxP impact assessment
Evidence to retain
- Security configuration
- Alert or log record
- Incident-response exercise
CSA testing approach
Test the control where failure matters
Use controlled security-event simulation with response evidence, not only configuration screenshots.
AI-Enabled System example
Worked application
Repeated attempts to access an AI-assisted Quality review service with invalid credentials create a security alert and trigger review of any affected recommendation or approval records.
Common mistake
Relying on logs that are never monitored or connected to a response procedure.
Better approach
Test the full chain from attempted misuse through detection, escalation, investigation, and record-impact decision.
§ 11.300(e)Testing of Tokens and CardsID / Password Controls
Regulation source summary
What the regulation addresses
Devices that bear or generate identification-code or password information, such as tokens or cards, must be initially and periodically tested to confirm proper function and absence of unauthorized alteration.
Read § 11.300(e) in the current eCFRCSVtoCSA practitioner interpretation
What this means for CSV and CSA
Where physical or logical authenticators are used, define how they are qualified, checked, maintained, replaced, and monitored for tampering throughout use.
Apply this interpretation to the actual predicate rule, intended use, system configuration, and Quality procedures. The primary source controls.
What to assess
- Authenticator types and criticality
- Initial and periodic test method
- Tamper, failure, and replacement handling
How to address it
- Approved device inventory
- Qualification and periodic checks
- Tamper reporting and controlled replacement
What should I test?
- Perform the defined functional check
- Challenge a failed or altered device
- Verify overdue devices are identified
Evidence to retain
- Device inventory
- Initial and periodic test results
- Failure and replacement record
CSA testing approach
Test the control where failure matters
Combine device qualification with a periodic sampling program and controlled failure challenge.
MES example
Worked application
Badge readers used for production signatures are function-checked before use and periodically thereafter; failed readers are removed and investigated.
Common mistake
Validating the application login while omitting the physical token lifecycle.
Better approach
Include the authenticator device and its operational controls in the validated boundary.
Technical figure
Audit trail assessment workflow
Evaluate the audit trail as an operational control around a critical record—not as an isolated screen.
- 1Critical record eventCreate · modify · delete or void
- 2Independent captureUser · timestamp · old/new value · reason
- 3Secure retentionPrior information preserved and linked
- 4Risk-based reviewFilter · assess · investigate · document
- 5Inspection copyReadable record and audit context
Apply the regulation
System examples
Use these boundaries to start a system-specific assessment. They are fictional learning examples, not validation conclusions or evidence of actual project outcomes.
eQMS
approved deviation, CAPA, change-control, or document record
- Boundary
- configured workflows, roles, signature meanings, audit trail, reports, and retention
- Assessment focus
- Verify the complete Quality record from creation through approval, correction, retrieval, and archival.
LIMS
sample, test result, calculation, specification, and approval record
- Boundary
- instrument interfaces, result entry, calculations, review, audit trail, and report generation
- Assessment focus
- Challenge controls at the points where laboratory data can be created, changed, calculated, approved, or exported.
MES
electronic batch record and associated exception or review history
- Boundary
- recipe execution, equipment status, operator actions, exceptions, approvals, and batch-record output
- Assessment focus
- Confirm the enforced manufacturing sequence and the enduring context of every critical action.
ERP
material, status, master-data, inventory, or release transaction
- Boundary
- roles, workflows, interfaces, master data, transaction history, and reports
- Assessment focus
- Trace regulated decisions across configuration, interfaces, transaction history, and downstream reports.
Training System
assigned curriculum, completion, qualification, and retraining record
- Boundary
- assignment rules, user identity, completion evidence, curriculum versions, and historical reports
- Assessment focus
- Verify that the system shows who completed which effective training, when, and under which curriculum version.
Laboratory Software
raw data, method, sequence, processing parameter, result, and approval record
- Boundary
- acquisition, processing, reprocessing, audit trail, review, export, and archival
- Assessment focus
- Protect raw data and retain the relationship between methods, processing choices, results, reviewers, and reports.
Spreadsheet
controlled workbook, entered data, formula, calculated result, and approval record
- Boundary
- template control, cell protection, access, versioning, review, output, and retention
- Assessment focus
- Determine whether the spreadsheet platform and surrounding procedure preserve the required record and change history.
SaaS
regulated record managed in a vendor-hosted service
- Boundary
- customer configuration, identity provider, supplier controls, exports, releases, integrations, and retention commitments
- Assessment focus
- Separate supplier platform controls from customer-configured workflows and verify both for the intended use.
AI-Enabled System
regulated input, generated recommendation, human decision, model or prompt context, and final approved record
- Boundary
- data provenance, model version, prompt or configuration, human review, audit history, monitoring, and change control
- Assessment focus
- Preserve enough context to reconstruct how an AI-assisted output informed—but did not obscure—the accountable GxP decision.
Usable deliverable
Part 11 Assessment Worksheet
Record applicability, implemented controls, procedures, testing, retained evidence, ownership, and status for each requirement. The CSV file contains all 31 requirement rows and blank assessment fields.
| § | Requirement | Applicable? | System control | Procedure | Testing | Evidence | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| § 11.1 | Scope | — | — | — | — | — | — | — |
| § 11.2 | Implementation | — | — | — | — | — | — | — |
| § 11.3 | Definitions | — | — | — | — | — | — | — |
Preview shows the first three rows. Blank fields are intentional; complete them using approved information for the system being assessed.
Review before release
Common Part 11 assessment mistakes
Starting with a software checklist
Start with the predicate-rule record, electronic reliance, signature use, and actual workflow boundary.
Treating vendor validation as customer validation
Use relevant supplier evidence, then test customer configuration, roles, interfaces, data, procedures, and intended use.
Testing only the happy path
Challenge prohibited actions, exceptions, record corrections, output, retention, recovery, and security events.
Equating backup with retention
Demonstrate restoration, ready retrieval, readability, metadata, signatures, and audit history for the required period.
Reviewing audit trails without a risk basis
Define which events matter, who reviews them, when review occurs, and how exceptions are resolved.
Using signatures as decorative fields
Bind identity, time, meaning, and the signed record state through a controlled transaction.
Authoritative references
Primary sources
- Electronic Code of Federal Regulations — 21 CFR Part 11Current official regulatory text. Verify the live source before making a regulated decision.
- FDA — Part 11, Electronic Records; Electronic Signatures — Scope and ApplicationFinal guidance for industry, September 2003. Guidance represents the agency’s current thinking and is not itself binding law.
Revision history
| Version | Date | Change |
|---|---|---|
| 1.0 | 13 September 2026 | Initial interactive practitioner guide with requirement records, system views, testing guidance, sources, and assessment worksheet. |