Decide before you assess
Does this computerized system support a GMP activity?
Annex 11 applies with the applicable Good Manufacturing Practice (GMP) requirements and pharmaceutical quality system. Start with the activity and regulated decision, not with the technology label.
- 01
Define intended use
State what the system does, who uses it, the process supported, and the decisions or records it enables.
- 02
Assess GxP relevance
Identify manufacturing, laboratory, batch release, Quality, training, materials, monitoring, control, or record-retention use.
- 03
Identify functions and records
Map the GxP functions, data, interfaces, records, approvals, and system boundaries relied upon.
- 04
Assess failure impact
Explain the effect of failure on patient safety, product quality, data integrity, and GMP decisions.
- 05
Select lifecycle controls
Choose proportionate supplier, validation, testing, procedural, operational, monitoring, and review controls.
Do not merge source statuses
Current requirement and proposed revision
The published 2011 Annex 11 is the operative source used throughout this guide. The European Commission’s 2025 consultation draft is tracked separately and is not presented as a current requirement.
Current requirement
Annex 11 — revision January 2011
- Status
- Published operative annex
- In operation
- 30 June 2011
- Used in this guide
- Yes — all 17 section records below
Proposed / draft change
Revised Annex 11 — 2025 consultation
- Status
- Consultation closed
- Consultation period
- 7 July–7 October 2025
- Used as current requirement
- No
Requirement map
Requirements at a glance
Select a section number to open its practitioner record. The 2011 source groups the requirements into General, Project Phase, and Operational Phase.
| Section | Area | Practitioner question | Lifecycle stage |
|---|---|---|---|
| § 1 | Risk Management | Are lifecycle controls proportionate to patient safety, data integrity, and product quality risk? | General |
| § 2 | Personnel | Do assigned personnel have suitable qualifications, access, and defined responsibilities? | Project Phase |
| § 3 | Suppliers and Service Providers | Are supplier capabilities, responsibilities, and available evidence understood and controlled? | Project Phase |
| § 4 | Validation | Does lifecycle validation demonstrate fitness for the configured intended use? | Project Phase |
| § 5 | Data | Are data exchanges checked so meaning is preserved across systems? | Operational Phase |
| § 6 | Accuracy Checks | Are critical manually entered data checked using a proportionate control? | Operational Phase |
| § 7 | Data Storage | Can regulated data be protected, restored, and checked throughout retention? | Operational Phase |
| § 8 | Printouts | Can users obtain clear, meaningful copies of electronically stored data? | Operational Phase |
| § 9 | Audit Trails | Are relevant GMP changes captured and reviewed in a usable audit trail? | Operational Phase |
| § 10 | Change and Configuration Management | Are system and configuration changes controlled using a defined procedure? | Operational Phase |
| § 11 | Periodic Evaluation | Does current evidence still support the validated-state conclusion? | Operational Phase |
| § 12 | Security | Are physical and logical controls restricting access to authorized people? | Operational Phase |
| § 13 | Incident Management | Are system incidents assessed for root cause, GMP impact, and corrective action? | Operational Phase |
| § 14 | Electronic Signature | Do electronic signatures clearly identify the signer, time, meaning, and signed record? | Operational Phase |
| § 15 | Batch Release | Is batch certification and release restricted, attributable, and signature-controlled? | Operational Phase |
| § 16 | Business Continuity | Can critical GMP processes continue safely during system unavailability? | Operational Phase |
| § 17 | Archiving | Will archived data remain accessible, readable, and intact for the retention period? | Operational Phase |
Interactive reference
Annex 11 requirement explorer
Review the operative requirements in source order or apply them to a specific system context. Search narrows the full practitioner record, including controls, tests, and evidence.
Showing 17 of 17 requirements.
General — lifecycle risk management
1 requirement§ 1Risk ManagementGeneral
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Risk management should be applied throughout the computerized-system lifecycle, considering patient safety, data integrity, and product quality. Decisions on validation and data-integrity controls should be based on a justified and documented risk assessment.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Use risk to decide where control and evidence must be strongest. Risk management is not a one-time score: it connects intended use, failure impact, controls, testing, release, monitoring, and reassessment.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- GMP functions and records within scope
- Credible failure modes and their effect on product, patient, and data
- Existing preventive and detective controls
- Uncertainty, complexity, and triggers for reassessment
How can it be addressed?
- Approved intended use and system boundary
- Function-level risk assessment with rationale
- Risk-based validation and test selection
- Lifecycle review of incidents, changes, and performance
What should you test?
- Challenge high-impact functions and control failures
- Use negative, boundary, and recovery cases where failure could escape detection
- Confirm risk controls operate in the configured production process
Typical evidence
- Intended-use statement
- Functional risk assessment
- Requirements-to-risk-to-test traceability
- Release rationale and reassessment criteria
Risk-based testing
Build evidence around the credible failure
Write testing around the failure chain: incorrect source value → wrong calculation → incorrect reported result → missed review → potential release decision.
LIMS example
Worked application
For a LIMS assay calculation, assess the risk of an incorrect dilution factor producing a reportable passing result. Credit locked calculation logic and independent review, then test configuration, boundary values, and a deliberately incorrect factor.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Using a single high/medium/low label to justify a standard package of documents and tests.
Better approach
Explain the failure, impact, existing control, residual uncertainty, and evidence selected for each important GMP function.
Project Phase — people, suppliers, and validation
3 requirements§ 2PersonnelProject Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
People involved with computerized systems should have appropriate qualifications, access levels, and defined responsibilities. Cooperation should exist among process owner, system owner, qualified persons, and information technology.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Define who owns the process, system, validation decisions, administration, Quality oversight, release, and continuing support. Training alone does not resolve incompatible authority or unclear accountability.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Process and system ownership
- Quality, qualified-person, IT, supplier, and administrator responsibilities
- Competence for configured tasks
- Segregation between administration and GMP decisions
How can it be addressed?
- Approved responsibility matrix
- Role-based access aligned to job duties
- Training and qualification records
- Escalation and deputy arrangements
What should you test?
- Verify representative users can perform only assigned tasks
- Confirm administrators cannot approve or release unless separately authorized
- Sample training and role records for current personnel
Typical evidence
- RACI or responsibility matrix
- Training records
- Role and access matrix
- Approved job or procedural responsibilities
Risk-based testing
Build evidence around the credible failure
Pair responsibility review with positive and negative authorization tests across project and operational activities.
MES example
Worked application
An MES administrator may configure a workflow but should not gain batch-release authority by virtue of the admin role. Test both the administration path and the qualified release path.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Listing project roles without defining lifecycle ownership after go-live.
Better approach
Connect every critical activity and decision to an accountable role, competence expectation, and access profile.
§ 3Suppliers and Service ProvidersProject Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Formal agreements should define third-party responsibilities. Supplier competence and reliability should be considered, and commercial documentation should be reviewed to determine whether it meets user requirements.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
A supplier can provide useful platform evidence, but the regulated organization remains accountable for the configured intended use, local procedures, data, interfaces, access, and release decision.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Supplier capability and quality-system evidence
- Contracted responsibilities and service levels
- Version, scope, and limitations of supplier documentation
- Customer configuration, integrations, data, and operating controls
How can it be addressed?
- Risk-based supplier assessment
- Quality or technical agreement
- Evidence-leverage assessment
- Release, incident, security, continuity, and exit obligations
What should you test?
- Confirm supplier evidence matches the released version and relevant functions
- Test local configuration and customer-owned controls
- Exercise notification, escalation, export, and continuity responsibilities
Typical evidence
- Supplier assessment
- Executed agreement
- Supplier test or assurance package review
- Local gap assessment and acceptance rationale
Risk-based testing
Build evidence around the credible failure
Test the seams between supplier and customer responsibility, not the controls already demonstrated adequately by credible supplier evidence.
SaaS example
Worked application
For a SaaS eQMS, map supplier controls for infrastructure, platform testing, backup, and release notification against customer controls for workflow configuration, roles, master data, procedures, and acceptance testing.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Writing “vendor validated” as the complete validation conclusion.
Better approach
Credit supplier evidence only where scope, version, configuration, method, and result are relevant; close local gaps explicitly.
§ 4ValidationProject Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Validation documentation and reports should cover relevant lifecycle steps. Requirements should be traceable, supplier documentation justified, custom or bespoke systems formally assessed, and data migration controlled. The extent of validation should be justified by risk.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Validation should make a defensible case that the system is suitable for its GMP use. Annex 11 does not prescribe a mandatory URS–FS–DS–IQ–OQ–PQ document chain for every system.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Lifecycle plan, inventory, intended use, and user requirements
- Functional risk, supplier evidence, configuration, customization, and procedures
- Testing, deviations, migration, traceability, and release decision
- Methods for maintaining the validated state
How can it be addressed?
- Risk-based validation plan
- Controlled requirements and configuration
- Fit-for-use supplier evidence assessment
- Traceable testing, migration verification, and validation summary
What should you test?
- Verify critical GMP functions and configured controls
- Challenge interfaces, calculations, roles, exceptions, and recovery
- Reconcile migrated data and confirm business use after migration
Typical evidence
- Validation plan
- Inventory and intended use
- URS and functional risk assessment
- Configuration records, test results, deviations, traceability, and validation summary report
Risk-based testing
Build evidence around the credible failure
Use scripted tests for critical deterministic controls and targeted exploratory testing for complex workflows, exceptions, and configuration interactions.
eQMS example
Worked application
For a configured eQMS, trace a high-risk deviation workflow from approved requirement through routing rules, permissions, signature meaning, testing, deviation resolution, and release acceptance.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Measuring rigor by document count or reproducing supplier tests without a local risk question.
Better approach
Build the validation package around intended use, risk, available evidence, remaining uncertainty, and a clear release rationale.
Operational Phase — controlled use and continued suitability
13 requirements§ 5DataOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Checks should be built into exchanges of data with other systems to support correct and secure entry and processing of data and to minimize risks.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
An interface test should prove that the correct business meaning reaches the correct record—not only that a message was transmitted successfully.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Source and target ownership
- Field mapping, units, precision, status, and identifiers
- Transformation and business rules
- Errors, retry, duplicate prevention, reconciliation, and monitoring
How can it be addressed?
- Approved interface specification and mapping
- Transport and application-level validation
- Error queue, alerting, retry, and reconciliation controls
- Controlled change across both systems
What should you test?
- Transfer correct, invalid, incomplete, duplicate, and boundary data
- Verify value, unit, batch, sample, status, and timestamp meaning end to end
- Challenge outages, retry, and reconciliation
Typical evidence
- Data-flow diagram
- Interface specification
- Challenge tests and reconciliation results
- Operational monitoring and exception records
Risk-based testing
Build evidence around the credible failure
Use an end-to-end dataset with normal, rejected, boundary, duplicate, delayed, and outage-recovery cases.
LIMS example
Worked application
For a LIMS-to-ERP result interface, verify result value, unit, batch, specification status, approval status, error handling, retry without duplication, and reconciliation into the intended ERP record.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Accepting a successful API response as evidence that the regulated data was complete and correct.
Better approach
Reconcile business fields and downstream use, including errors and recovery, at both ends of the interface.
§ 6Accuracy ChecksOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
When critical data are entered manually, an additional check should confirm accuracy. The check may be performed by another operator or validated electronic means, with criticality and consequences covered by risk management.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Select an independent, effective accuracy control. A second manual entry is one option, but barcode capture, validated lookup, format checks, range checks, or reconciliation may be stronger.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Which manually entered values are critical
- Likelihood and impact of entry error
- Independence and effectiveness of the check
- Evidence that the check occurred
How can it be addressed?
- Barcode or controlled lookup where feasible
- Format, range, checksum, and master-data validation
- Independent review for residual high-risk entries
- Exception and correction workflow
What should you test?
- Enter correct, incorrect, malformed, and boundary values
- Attempt to bypass or self-confirm the check
- Verify correction and audit history
Typical evidence
- Critical-data assessment
- Configured validation rules
- Accuracy-check test results
- Completed review or exception record
Risk-based testing
Build evidence around the credible failure
Deliberately introduce plausible entry errors and verify the selected control prevents, detects, or escalates each one.
MES example
Worked application
For manual lot entry in MES, compare barcode scanning, controlled material lookup, format validation, second-person review, and automated reconciliation against the specific risk of using the wrong lot.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Requiring two people to type every value without evaluating whether the second entry is independent or effective.
Better approach
Use the strongest practical automated prevention or detection, then add human verification where residual risk remains.
§ 7Data StorageOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Data should be secured against physical and electronic damage. Stored data should remain accessible, readable, and accurate. Backups should be regular, secure, monitored, and periodically tested for restoration.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
A successful backup job is infrastructure evidence, not proof that a complete GMP record can be restored and used.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Complete-record definition and retention period
- Backup scope, frequency, security, monitoring, and separation
- Restore objectives and dependencies
- Readability, accuracy, and retrieval after restore
How can it be addressed?
- Documented backup and restore design
- Protected and monitored backup copies
- Periodic representative restoration
- Retention and technology-obsolescence planning
What should you test?
- Restore representative records, attachments, metadata, signatures, and audit history
- Verify search, readability, and record relationships
- Challenge loss of a component or dependency
Typical evidence
- Backup configuration and monitoring records
- Restore protocol and result
- Restored-record reconciliation
- Retention and recovery procedure
Risk-based testing
Build evidence around the credible failure
Select representative normal and complex records, restore to a controlled environment, and verify completeness and business usability.
eQMS example
Worked application
Restore a completed CAPA including attachments, workflow history, approvals, signature meaning, audit trail, and linked effectiveness check—not only the database row.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Citing a nightly backup report without demonstrating usable record restoration.
Better approach
Restore a complete regulated record and reconcile it against the source definition and intended use.
§ 8PrintoutsOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Clear printed copies of electronically stored data should be available. Records supporting batch release should allow indication of whether data have changed since original entry.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Interpret “printout” as an inspection- or review-ready human-readable copy. It may be paper or a controlled electronic rendering, but it must preserve the content and context needed to understand the record.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Who needs the copy and for what decision
- Data, metadata, signatures, audit context, and change indication required
- Format readability and long-term availability
- Batch-release record expectations where applicable
How can it be addressed?
- Defined report or copy specification
- Controlled report configuration and access
- Change-history or audit-trail availability
- Periodic verification of output completeness
What should you test?
- Compare the copy with the native record
- Include changed and approved records
- Verify readability, pagination, identifiers, and change indication
Typical evidence
- Report specification
- Copy-verification result
- Sample readable record
- Procedure for inspection or release use
Risk-based testing
Build evidence around the credible failure
Use a content-and-context reconciliation across original, corrected, and exceptional records.
LIMS example
Worked application
For a LIMS result report, verify sample identity, method and specification context, result, unit, approval, correction status, and access to relevant audit information.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Treating any PDF export as complete without checking the underlying record components.
Better approach
Define what a meaningful copy must contain for its purpose, then reconcile output against the native record.
§ 9Audit TrailsOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Risk assessment should determine whether to build into the system the creation of records for GMP-relevant changes and deletions. Reasons should be documented, audit trails available and understandable, and review performed regularly.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Identify the changes that matter, verify capture and security, and design a review process that can find meaningful exceptions. An unused audit-trail feature is not an operating control.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- GMP-relevant creation, change, and deletion events
- Actor, timestamp, old/new value, reason, and record link
- Audit-trail security, availability, and retention
- Review scope, frequency, reviewer, and escalation
How can it be addressed?
- Configured audit trail for critical data and settings
- Controlled reason-for-change
- Risk-based audit-trail review procedure
- Exception investigation and trend review
What should you test?
- Create, modify, reprocess, and where permitted delete or void
- Attempt unauthorized change or audit-trail alteration
- Filter, review, export, and retain the audit record
Typical evidence
- Audit-trail assessment
- Configuration record
- Challenge tests
- Completed review and investigation records
Risk-based testing
Build evidence around the credible failure
Combine deterministic event challenges with an exploratory reviewer exercise using realistic filters and exceptions.
Chromatography System example
Worked application
Change an integration parameter, reprocess the chromatogram, and verify old and new settings, user, time, reason, affected result, review status, and original data remain connected.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Confirming that an audit-trail screen exists without testing completeness or the review workflow.
Better approach
Map each critical event to expected capture, then prove reviewers can find, understand, and act on the event.
§ 10Change and Configuration ManagementOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Changes to a computerized system, including system configurations, should be made in a controlled manner according to a defined procedure.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Treat configuration as software behavior when the GMP process relies on it. Assess every change for intended effect, unintended effect, evidence needed, release decision, and continuing validated state.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Change scope, reason, and affected GMP functions
- Configuration, integration, data, security, and procedure impact
- Regression risk and supplier evidence
- Deployment, rollback, verification, and documentation update
How can it be addressed?
- Approved change record and impact assessment
- Version-controlled configuration baseline
- Risk-based regression selection
- Authorized deployment and post-implementation review
What should you test?
- Verify the changed function and affected interfaces
- Challenge routing, permissions, calculations, and exceptions near the change
- Confirm production configuration and rollback readiness
Typical evidence
- Change request and impact assessment
- Configuration comparison
- Regression results
- Release approval and updated validation records
Risk-based testing
Build evidence around the credible failure
Test the changed decision path plus adjacent high-risk paths that share rules, roles, data, or integration dependencies.
SaaS example
Worked application
A SaaS eQMS update changes deviation severity logic and approval routing. Assess vendor release evidence, local configuration interaction, regression coverage, procedure impact, deployment timing, and post-release monitoring.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Classifying a no-code configuration change as non-software and skipping validation impact assessment.
Better approach
Judge the change by its effect on GMP process behavior, records, and controls—not by whether source code changed.
§ 11Periodic EvaluationOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Computerized systems should be evaluated periodically to confirm that they remain in a valid state and comply with GMP. Reviews should consider functionality, deviations, incidents, problems, upgrade history, performance, reliability, security, and validation status.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
A periodic evaluation should test whether the assumptions supporting release remain true. It is a current decision based on operating evidence, not a checklist confirming that documents exist.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Current intended use, scope, and ownership
- Changes, releases, incidents, deviations, problems, and CAPA
- Performance, reliability, security, access, supplier, backup, and continuity
- Validation gaps, procedures, training, obsolescence, and future plans
How can it be addressed?
- Risk-based review frequency and criteria
- Defined evidence inputs and owners
- Trend and exception analysis
- Approved conclusion, actions, and next review or trigger
What should you test?
- Sample live functions and records where change or adverse trend exists
- Verify representative restore, access, interface, or audit-trail controls as risk warrants
- Confirm open actions do not invalidate continued use
Typical evidence
- Periodic-evaluation report
- Change, incident, deviation, access, and performance summaries
- Supplier and security review
- Continued-use conclusion and action plan
Risk-based testing
Build evidence around the credible failure
Use data-driven sampling focused on changed, failing, overdue, or weakly monitored controls rather than repeating the original test suite.
SaaS example
Worked application
A periodic evaluation of a SaaS eQMS reviews 18 supplier releases, two local workflow changes, access recertification, restore assurance, incident trends, audit-trail review completion, open CAPA, and current service status before concluding continued suitability with named actions.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Repeating the prior validation summary and reporting “no major issues” without analyzing current operation.
Better approach
State what changed, what evidence was reviewed, what remains acceptable, what gaps exist, and why continued use is justified.
§ 12SecurityOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Physical and logical controls should restrict access to authorized persons. The extent depends on system criticality, and creation, change, and cancellation of access authorizations should be recorded.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Security for GMP use includes identity lifecycle, role design, privileged access, segregation of duties, authentication, periodic review, and traceable access changes.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Role design and critical transaction permissions
- Joiner, mover, leaver process
- Privileged, service, shared, and emergency access
- Physical access and external identity-provider dependencies
How can it be addressed?
- Approved role matrix and least privilege
- Controlled provisioning, modification, and removal
- Privileged-access governance
- Periodic access review and security monitoring
What should you test?
- Perform positive and negative tests for representative roles
- Verify removed users and expired access cannot authenticate
- Review administrator assignment and activity
Typical evidence
- Role and access matrix
- Access request and removal records
- Authorization challenge results
- Periodic review and privileged-activity records
Risk-based testing
Build evidence around the credible failure
Use a role-versus-critical-action matrix with both permitted and prohibited scenarios, including administrator pathways.
ERP example
Worked application
Verify a warehouse role can receive material but cannot release it, a Quality role can change disposition under the approved workflow, and neither role can self-assign elevated access.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Testing one successful login and treating authentication as the complete access-control assessment.
Better approach
Test authorization at the GMP actions that matter, including denied actions and the lifecycle of access.
§ 13Incident ManagementOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
All incidents, not only system failures and data errors, should be reported and assessed. Critical incidents should undergo root-cause analysis and support corrective and preventive action.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Connect technical events to affected functions, records, batches, decisions, and controls. Restore service, assess data and product impact, correct the cause, and decide whether validation evidence must change.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Detection, reporting, triage, and escalation
- Affected period, users, data, records, batches, and interfaces
- Root cause and recurrence risk
- CAPA, validation impact, and effectiveness
How can it be addressed?
- Integrated incident and Quality-event procedure
- GMP impact-assessment criteria
- Root-cause and CAPA process
- Trend review and validation feedback
What should you test?
- Exercise incident notification and escalation
- Reconstruct affected records from logs and reconciliation
- Verify corrective action and effectiveness evidence
Typical evidence
- Incident record
- GMP impact assessment
- Root-cause analysis and CAPA
- Reconciliation, recovery, and effectiveness results
Risk-based testing
Build evidence around the credible failure
Use tabletop and technical recovery scenarios that force reconciliation and a documented GMP-impact conclusion.
LIMS example
Worked application
Fictional example: a LIMS interface outage delayed 42 results. Reconcile each source and target record, check duplicate or missing transmissions, assess batch decisions during the outage, document root cause, and verify CAPA effectiveness.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Closing an infrastructure ticket when service returns without assessing regulated data or decisions.
Better approach
Define the affected GMP boundary, reconcile records, and document the product/data conclusion before closure.
§ 14Electronic SignatureOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Electronic records may be signed electronically. Signatures should have the same impact as handwritten signatures within the company, be permanently linked to their record, and include date and time.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
A signature is more than authentication. It should show who signed, when, why, and exactly which record and state were approved, with a durable link that survives copying and retention.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Signature purpose and legal or procedural meaning
- Signer identity and authentication
- Date, time, record state, and manifestation
- Permanent signature-to-record linkage
How can it be addressed?
- Unique identity and controlled authentication
- Configured signature meanings
- Reauthentication for critical signatures where appropriate
- Protected linkage and signature history
What should you test?
- Sign and reject representative records
- Verify identity, time, meaning, and record version
- Attempt to copy, remove, or transfer a signature independently
Typical evidence
- Signature requirements and configuration
- Identity and authentication procedure
- Signature challenge tests
- Representative signed-record copy
Risk-based testing
Build evidence around the credible failure
Include successful, rejected, expired-session, unauthorized, corrected, and copied-record scenarios.
Training System example
Worked application
Verify a learner’s completion signature includes authenticated identity, date/time, meaning such as “I completed and understood,” course version, result, and a permanent link to that training record.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Showing a user name in an approval field without verifying meaning or permanent linkage.
Better approach
Reconstruct the complete signing event and confirm the signature cannot be separated from or applied to another record.
§ 15Batch ReleaseOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
When a computerized system records batch certification and release, the system should allow only qualified persons to certify release, and the action should be performed using an electronic signature.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Protect the final release decision and the inputs that support it. Restrict authority, require the defined electronic signature, retain the exact released state, and make overrides or changes visible.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Qualified-person authorization
- Required review inputs and release prerequisites
- Electronic-signature controls
- Status transitions, override, reversal, and interface behavior
How can it be addressed?
- Restricted release role
- Enforced prerequisite and status rules
- Electronic signature with defined meaning
- Audit trail and exception handling
What should you test?
- Authorized user releases an eligible batch
- Unauthorized and unqualified users are denied
- Incomplete, failed, or pending prerequisites block release
- Signature, status, audit history, and downstream transmission remain consistent
Typical evidence
- Release-role approval
- Configured prerequisite rules
- Scripted release and negative-test results
- Representative signed release record
Risk-based testing
Build evidence around the credible failure
Use controlled scripted testing because authorization, sequence, and expected state transitions are deterministic and high impact.
ERP example
Worked application
For ERP batch release, test an authorized qualified person, an unauthorized warehouse user, missing laboratory approval, an open critical deviation, duplicate signature attempt, release reversal, and the exact audit and interface records created.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Testing only a successful release by an administrator or test account.
Better approach
Use scripted positive and negative cases that prove identity, qualification, prerequisites, signature, record state, and downstream effect.
§ 16Business ContinuityOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Provisions should support continuity of critical processes when the system breaks down, using suitable documented and tested alternative arrangements. Response time should be risk-based.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Business continuity is distinct from backup, disaster recovery, and record restoration. It addresses how the GMP process operates safely while the system is unavailable and how interim records are reconciled after recovery.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Critical process and maximum tolerable interruption
- Manual or alternate process, data, forms, and authority
- Entry and reconciliation after restoration
- Communication, training, exercises, and periodic testing
How can it be addressed?
- Documented continuity procedure
- Controlled interim records and decision rules
- Recovery and reconciliation ownership
- Scheduled continuity exercise
What should you test?
- Simulate loss during an active critical process
- Use the approved alternative arrangement
- Recover, enter, and reconcile interim records without duplication or loss
Typical evidence
- Business-continuity plan
- Exercise scenario and result
- Completed interim record and reconciliation
- Lessons learned and action closure
Risk-based testing
Build evidence around the credible failure
Run a process-level exercise with real roles, decision limits, handoffs, data capture, recovery, and reconciliation.
LIMS example
Worked application
During a simulated LIMS outage, use controlled worksheets for urgent sampling and testing, prevent premature batch decisions, restore service, enter approved interim data, and reconcile every sample and result.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Using successful backup restoration as the only business-continuity evidence.
Better approach
Test both the period of unavailable service and the controlled return to normal operation.
§ 17ArchivingOperational Phase
Current requirement
Operative 2011 Annex 11What Annex 11 addresses
Data may be archived. Archives should be checked for accessibility, readability, and integrity, and the ability to retrieve should be ensured and tested when relevant system changes occur.
Read the current official Annex 11CSVtoCSA practitioner interpretation
What does this mean?
Archiving preserves the complete regulated record and its meaning outside active processing. It requires defined content, context, format, access, integrity, retrieval, and verification after technology change or retirement.
Apply this interpretation within the pharmaceutical quality system, actual intended use, system configuration, and approved procedures. The current primary source controls.
What should you assess?
- Complete archive content and metadata
- Retention period, legal hold, ownership, and authorized access
- Format readability and technology obsolescence
- Retrieval after system, platform, or viewer change
How can it be addressed?
- Approved archive specification and procedure
- Integrity protection and restricted access
- Format and viewer strategy
- Periodic and change-triggered retrieval test
What should you test?
- Archive and retrieve normal, corrected, signed, and linked records
- Verify metadata, audit history, relationships, and readability
- Demonstrate retrieval after migration or system retirement
Typical evidence
- Archive inventory and specification
- Archive transfer and reconciliation record
- Integrity and retrieval test
- Decommissioning or migration report
Risk-based testing
Build evidence around the credible failure
Test the archive as a usable record system, including complex linked records and the conditions expected years after the source system is gone.
eQMS example
Worked application
For a legacy eQMS retirement, preserve deviations, CAPA, attachments, workflow history, signatures, audit trails, links, and reference data. Reconcile counts and samples, then test retrieval using the supported archive viewer.
Example status: Fictional learning scenario; not a validation conclusion or project result.
Common mistake
Exporting PDFs during retirement and assuming the complete record and context were preserved.
Better approach
Define the complete record for each use, preserve required relationships and metadata, and prove future retrieval with the planned tool.
Technical figure
Data exchange assurance workflow
Section 5 becomes practical when the test follows regulated meaning from the source record through transformation, receipt, and reconciliation.
- 01LIMS sourceApproved value · unit · batch · result status
- 02Interface controlIdentity · completeness · security · duplicate prevention
- 03TransformationMapping · precision · units · status logic
- 04ERP targetCorrect record · disposition · downstream use
- 05ReconciliationError queue · retry · exception closure · record match
Apply by system type
System-specific assessment boundaries
These examples identify useful starting boundaries. They are fictional learning examples, not validation conclusions or evidence of actual project outcomes.
eQMS
deviation, CAPA, change-control, document, and approval records
- Boundary
- configured workflows, roles, signatures, audit trail, integrations, reports, retention, and supplier service
- Assessment focus
- Confirm the complete Quality record and its approved workflow remain controlled through configuration and SaaS change.
LIMS
samples, specifications, raw results, calculations, review, and approval records
- Boundary
- instrument interfaces, manual entry, calculations, master data, review, reports, audit trail, and archival
- Assessment focus
- Challenge the points where laboratory data can be entered, transformed, changed, approved, transferred, or restored.
MES
master recipes, executed batch records, exceptions, equipment status, and release-supporting data
- Boundary
- recipe configuration, shop-floor execution, interfaces, user roles, exceptions, electronic signatures, and batch output
- Assessment focus
- Verify enforced manufacturing steps, exception handling, and the enduring meaning of the electronic batch record.
ERP
material, inventory, master-data, status, disposition, and release transactions
- Boundary
- roles, workflows, interfaces, master data, transaction history, reports, and continuity procedures
- Assessment focus
- Trace regulated decisions across configuration, segregation of duties, data exchange, and downstream reporting.
Training System
curricula, assignments, completion, qualification, retraining, and signature records
- Boundary
- user identity, curriculum versions, assignment rules, assessments, completion, signatures, and historical reporting
- Assessment focus
- Show who completed which effective training, when, under which curriculum version, and with what signature meaning.
Chromatography System
raw data, sequences, methods, processing parameters, results, audit history, and approvals
- Boundary
- acquisition, processing, reprocessing, audit trail, review, export, backup, and archival
- Assessment focus
- Protect raw data and preserve the relationship between method versions, processing choices, results, reviewers, and reports.
SaaS
GMP records and workflows managed in a vendor-hosted service
- Boundary
- supplier platform controls, customer configuration, identity provider, interfaces, releases, exports, service commitments, and exit plan
- Assessment focus
- Separate supplier responsibility from customer responsibility, then test the configured intended use and local operating controls.
Spreadsheet
controlled workbook, source inputs, formulas, calculated results, review, and approval evidence
- Boundary
- template version, cell protection, access, change control, calculation checks, output, backup, and retention
- Assessment focus
- Determine whether the spreadsheet and its surrounding procedure keep the calculation correct, controlled, reviewable, and retrievable.
AI-Enabled System
regulated input, AI output, human review, final decision, and supporting traceability
- Boundary
- data provenance, model and prompt version, configuration, access, human oversight, monitoring, supplier change, and retained decision record
- Assessment focus
- Demonstrate that the AI-supported use is bounded, monitored, attributable, and unable to obscure the accountable GMP decision.
Usable deliverable
Annex 11 Assessment Worksheet
Use the Excel workbook to record applicability, controls, procedures, testing, evidence, ownership, and status for all 17 operative sections. Editable assessment fields and controlled picklists are included.
| § | Requirement | Applicable? | Control | Procedure | Testing | Evidence | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| § 1 | Risk Management | — | — | — | — | — | — | — |
| § 2 | Personnel | — | — | — | — | — | — | — |
| § 3 | Suppliers and Service Providers | — | — | — | — | — | — | — |
Preview shows the first three rows. Blank fields are intentional and should be completed using approved, system-specific information.
Combined control view
21 CFR Part 11 and EU GMP Annex 11
Global organizations can often address overlapping control objectives through one computerized-system lifecycle and evidence set while documenting the distinct applicability and source requirements. The useful question is not which source is stricter, but which controls and evidence satisfy each applicable obligation.
| Topic | 21 CFR Part 11 | EU GMP Annex 11 | Common control and testing view |
|---|---|---|---|
| Applicability | Electronic records and electronic signatures required by FDA predicate rules or submitted to FDA. | Computerised systems used as part of GMP-regulated activities. | Identify the regulated record, process, intended use, and authoritative system boundary. |
| Validation | Validation supports accuracy, reliability, consistent intended performance, and detection of invalid or altered records. | Lifecycle validation documentation and evidence should be justified by risk and traceable to user requirements. | Use approved intended use, requirements, functional risk, supplier evidence, testing, traceability, and release rationale. |
| Risk | Part 11 does not prescribe one risk-management method; FDA guidance supports a risk-based approach in its interpretation. | Risk management is an explicit lifecycle expectation tied to patient safety, data integrity, and product quality. | Document failure impact, controls, remaining uncertainty, and proportionate evidence. |
| Suppliers | The regulated organization remains accountable; supplier controls may support system validation. | Formal agreements, supplier assessment, and justified review of commercial documentation are explicit. | Define shared responsibilities and credit supplier evidence only within its demonstrated scope. |
| Audit trails | Secure, computer-generated, time-stamped audit trails are specified for relevant electronic-record actions. | Risk assessment should determine GMP-relevant change/deletion capture and regular audit-trail review. | Map critical events to capture, protection, review, escalation, retention, and inspection copies. |
| Electronic signatures | Detailed requirements cover manifestation, record linking, uniqueness, identity verification, controls, and certification. | Signatures should have company-equivalent impact, be permanently linked, and contain date and time; batch release has a specific expectation. | Verify identity, meaning, time, signed state, linkage, authorization, and signature security. |
| Periodic evaluation | Continued control follows validation, change control, security, retention, and predicate-rule obligations. | Periodic evaluation is an explicit requirement with named evidence areas. | Review current changes, incidents, access, performance, supplier status, security, and validation actions. |
| Business continuity | Record protection and ready retrieval support continuity, while predicate rules and Quality procedures may add process expectations. | Alternative arrangements for critical process continuity should be documented and tested. | Exercise the unavailable period, interim records, return to service, and reconciliation. |
| Archiving | Records must remain protected and readily retrievable through retention, with accurate and complete copies available. | Archives should retain accessibility, readability, integrity, and tested retrieval after relevant change. | Define the complete record, archive format, access, integrity, viewer, and retrieval testing. |
| Change control | Documentation controls and validation support controlled change and continued reliability. | System and configuration changes should follow a defined controlled procedure. | Assess intended and unintended effects, regression needs, deployment, rollback, and updated evidence. |
| Batch release | Part 11 applies when in-scope electronic records or signatures support release; predicate rules define the underlying release requirement. | Only qualified persons should certify computerized batch release using an electronic signature. | Restrict release authority and test prerequisites, signature, status, audit history, and downstream effect. |
Open the full 21 CFR Part 11 guide to assess its electronic-record and electronic-signature requirements individually.
Authoritative references
Primary sources
- European Commission — EudraLex Volume 4Official directory identifying Annex 11, Computerised Systems, as the January 2011 revision.
- Annex 11: Computerised Systems — current published textOperative source used for the 17 requirement records in this guide; revision 1, in operation since 30 June 2011.
- European Commission — 2025 stakeholders consultationOfficial closed consultation record for the proposed revised Annex 11 and new Annex 22.
- Draft revised Annex 11 — consultation textProposal only. It is not used as the operative requirement in this guide.
Revision history
| Version | Date | Change |
|---|---|---|
| 1.0 | 13 September 2026 | Initial practitioner guide with 17 current requirement records, system views, testing and evidence guidance, official source-status separation, comparison table, and Excel assessment worksheet. |