EU GMP Annex 11 is the EU GMP guideline for computerised systems used in GMP-regulated work. It calls for risk-based validation, formal agreements with suppliers, access security, periodic evaluation, audit trails scoped by risk, and rules for electronic signatures where a system uses them. The version in force is the 2011 revision, in operation since 30 June 2011. A revised draft was published on 7 July 2025 and its consultation closed on 7 October 2025, but as of September 2026 it has not been adopted: the European Commission still lists the 2011 text, and no final version or date of application exists. If you are building or validating a system today, the 2011 text is the version in force. The draft shows where the requirements are heading.
That split matters for engineering. The 2011 text leaves the extent of validation and data integrity controls to risk management. The draft shifts its weight towards security, identity and access management, and audit trails.
Where Annex 11 sits in EudraLex Volume 4, and how binding it is
EudraLex Volume 4 is the EU GMP Guide. It has three parts plus annexes: Part I covers GMP principles for manufacturing medicinal products, Part II covers active substances used as starting materials, and Part III holds GMP-related documents that clarify what regulators expect. Annexes add detail for specific areas of activity, such as sterile drug manufacturing, and several can apply to one process at the same time. On the Commission’s Volume 4 index, Chapter 4 (Documentation) is still listed at its January 2011 version.
Is EudraLex legally binding? Not in the way a statute is. Annex 11 is EU GMP guidance under EudraLex Volume 4 rather than a standalone law, but it is the working inspection standard across the EU/EEA and the PIC/S member states. The EMA describes Annex 11 as common to the EU/EEA member states and to the authorities taking part in the Pharmaceutical Inspection Co-operation Scheme (PIC/S).
What the 2011 Annex 11 requires of computerised systems
The scope is wide. The 2011 annex applies to every kind of computerised system used in GMP-regulated activities, and it defines a computerised system as a set of software and hardware components that together deliver certain functions. The application should be validated and the IT infrastructure qualified. Where a system replaces a manual operation, product quality, process control and quality assurance must not get worse, and the overall risk of the process must not rise.
Risk management is the annex’s named opening principle. It applies across the whole lifecycle, takes patient safety, data integrity and product quality into account, and decides how much validation and how many data integrity controls a system needs. Because so much rests on it, we hold the risk assessment to be the document that most deserves engineering attention. A thin risk assessment leaves every downstream control without a justification.
The remaining clauses fall into a few groups:
- Data entry and exchange. Systems that exchange data electronically need built-in checks that data is entered and processed correctly and securely. Critical data entered by hand needs an extra accuracy check, either by a second operator or by validated electronic means.
- Storage and backup. Data must be protected by physical and electronic means, checked for accessibility, readability and accuracy, and kept accessible for the whole retention period. Backup integrity and the ability to restore must be checked during validation and monitored periodically after that.
- Access. Physical or logical controls must limit access to authorised people. The strength of those controls depends on how critical the system is, and every creation, change and cancellation of an access authorisation must be recorded.
- Operator identity. Systems that manage data and documents must record who entered, changed, confirmed or deleted data, with the date and time.
- Suppliers. Section 3 calls for formal agreements that state responsibilities clearly (internal IT counts as a third party here), a supplier audit scaled to risk, and documented review of commercial off-the-shelf software.
- Inventory. Section 4.3 calls for an up-to-date list of relevant systems and their GMP functions, with a fuller description for systems judged critical.
- Periodic evaluation. Section 11 requires periodic checks that a live system is still in a valid, compliant state, covering functionality, deviations, incidents, upgrade history, performance, security and validation status.
- Business continuity. Section 16 expects a way to keep critical processes supported if a system breaks down, such as a defined manual fallback.
- Electronic signatures. Section 14 requires a signature to carry the same weight as a handwritten one within the company, to be permanently linked to its record, and to include the date and time it was applied.
What does an Annex 11 audit trail have to record?
Under the 2011 text, the audit trail is a risk-based decision, not an absolute duty. The annex says that, based on a risk assessment, you should consider building in a system-generated record of all GMP-relevant changes and deletions. When GMP-relevant data is changed or deleted, the reason must be documented, and audit trails must be available, convertible to a generally intelligible form, and reviewed regularly. Together with the operator identity clause, that gives the familiar list of contents: who made the change, what changed, when it happened, and why.
Two parts of this deserve design attention. We read “convertible to a generally intelligible form” as ruling out a trail that only a database administrator can read. “Regularly reviewed” means someone has to be able to filter the trail down to the changes that matter, so in our view reviewability should be designed into the data model from the start rather than bolted on as a report later. One secondary implementation guide describes a hash-chained, insert-only trail that records who, what, old and new values, the reason and the time, with export and a signed periodic review over a risk-focused view. Annex 11 does not prescribe that design, but it is a sensible way to meet the clause.
The 2025 draft section below covers what would change. In short, the draft drops “consider”: systems where users can change data or settings should have an audit trail.
Annex 11 vs Part 11: where the two regimes differ
Part 11 is a US federal regulation, codified and in force since 20 August 1997, while Annex 11 is EU guidance that works as an inspection standard. The second difference is structural. Annex 11 scales its controls to assessed risk, while Part 11 applies its controls uniformly once a record is in scope.
| Legal form | EU GMP guidance in EudraLex Volume 4; inspection standard across EU/EEA and PIC/S | US federal regulation, in force since 20 August 1997 |
| Risk management | Named opening principle; validation effort and data integrity controls match assessed GMP risk | No standalone risk clause; risk-based scaling comes from separate FDA guidance |
| Audit trails | Scope set by documented risk assessment; GMP-relevant changes and deletions, intelligible, reviewed | Secure, computer-generated, time-stamped trails for every closed system in scope, not scaled to risk by the rule itself |
| Electronic signatures | Principles: equal effect to handwritten, permanently linked, dated and timed | Prescribed: printed name, date and time, meaning of signature; rules for signing sessions |
| Suppliers | Formal agreements, risk-based supplier audit, COTS review | No explicit supplier provision |
| System inventory | Required, with fuller descriptions for critical systems | No inventory requirement in the text |
| Periodic review | Required, with a near-checklist of topics | No clause; handled through the site’s quality system |
| Business continuity | Required for critical processes | No clause |
The table shows Part 11’s text, not the FDA’s enforcement policy: in its 2003 guidance the FDA said it would interpret Part 11 narrowly and not enforce its validation, audit trail, record retention and record copying requirements, while the underlying predicate rules still apply.
For a system sold into both markets, we recommend designing to the stricter side of each row: Part 11’s signature display components and Annex 11’s supplier, inventory, review and continuity duties. One system can then meet both, with no regional variants to keep in step.
What the 2025 draft of Annex 11 changes
Everything in this section is draft text from the consultation version, which, as noted at the top, has not been adopted. Three documents were published together on 7 July 2025: the draft Annex 11, the new draft Annex 22 on artificial intelligence, and a revised Chapter 4 on documentation. The EMA GMDP Inspectors Working Group wrote them in cooperation with PIC/S.
The draft is much longer. The ECA Academy reports that it grew from 5 to 19 pages, and that its emphasis moved: validation dominates the current annex, while the top topics in the draft are security, identity and access management, qualification and validation, audit trails, and supplier and service management. The Commission describes the revision as strengthening lifecycle quality risk management, the definition and maintenance of system requirements, supplier oversight, and controls on data integrity, audit trails, electronic signatures and security.
Audit trails become mandatory and more specific
The EMA concept paper behind the revision says an audit trail that automatically logs all manual interactions on GMP-critical systems should be mandatory, not just “considered based on a risk assessment”, and that any grace period has long expired. The draft text writes this in. Systems where users can create, modify or delete data, settings or access privileges, acknowledge alarms or sign electronically should have an audit trail that automatically logs every manual user interaction. The draft also asks for the user’s role where users can hold more than one, the time zone where relevant, recording at the time of the event rather than at the end of a process, and an automatic prompt for the reason whenever a value changes. The trail should be enabled and locked at all times, and no user should be able to edit it. Changing its settings, changing system time or switching it off should itself create an entry, and should only be possible for a system administrator with no part in GMP activities. Alarm logs get similar treatment: automatic, uneditable, and reviewed periodically for trends.
Identity, access and signatures
The draft calls for unique, personal accounts for all users. It treats shared accounts as a data integrity violation unless they are read-only. Remote authentication to critical systems from outside controlled perimeters should include multifactor authentication. One summary of the draft adds automatic lockout after failed attempts, an inactivity logout users cannot switch off, an access log, segregation of duties, least privilege and recurring access reviews. The access reviews, segregation of duties and least privilege follow the concept paper’s call to manage access continuously rather than just record it. For electronic signatures, the draft asks for full re-authentication at the moment of signing, a displayed signature showing name, username, role where relevant, meaning, date and time, and a rule that a signed record cannot change without showing as unsigned. We read that as moving Annex 11 closer to Part 11’s prescriptive model.
Security, data lifecycle and suppliers
Regulated users would need an information security management system that safeguards authorised access and detects and prevents unauthorised access. Critical systems facing the internet would need regular penetration testing. The concept paper introduces requirements for data in motion and data at rest (backup, archive and disposal). The draft asks for regular backup of data and metadata, read-only protection of GMP data and audit trails once a process such as product release is complete, and integrity verification, for example by checksum, before any data is deleted during a move to archive. For suppliers, it calls for audit or assessment by risk, oversight through agreed SLAs and KPIs, and a contract covering nine elements, including an exit strategy that keeps you in control of your data.
Requirements traceability
The draft requires documented traceability between individual requirements, the design specifications beneath them, and the qualification and validation test cases that verify them. It defines user requirement specifications as a written statement of what the user expects the system to do.
Annex 22 and AI models inside computerised systems
The draft Annex 11 does not deal with artificial intelligence. That is left to the separate draft Annex 22. Annex 22 adds a model-specific layer on top of the revised Annex 11, which covers computerised systems in general, and the revised Chapter 4, which covers documentation. It applies to computerised systems where AI models are used in critical applications with a direct impact on patient safety, product quality or data integrity, such as predicting or classifying data. It covers machine learning models that learn their behaviour from training data rather than being explicitly programmed.
The scope is narrow. Annex 22 covers only static models, which do not adapt during use, and says dynamic models that keep learning should not be used in critical GMP applications. It covers only deterministic models, where identical inputs give identical outputs, and excludes probabilistic ones from critical use in the same way. Generative AI and large language models are outside its scope and should not be used in critical GMP applications. In non-critical uses, qualified people should always remain responsible for checking that the output suits its intended use. Within that scope, the annex sets requirements for intended use, performance metrics, training data quality, test data management and continuous oversight, including change control and performance monitoring. Test data should be kept independent of development, training and validation, and protected by access control and an audit trail. What GxP means for AI software more widely is covered in our piece on what GxP compliance actually requires for AI software in pharmaceutical manufacturing.
For engineers, the deterministic-output condition has a practical consequence. Non-deterministic GPU kernels, unfixed seeds or batch-dependent numerics can make a model’s output vary for the same input. In our view, bit-level reproducibility of inference should therefore be treated as a requirement to specify and test, not something assumed.
Turning Annex 11 duties into engineering requirements
The checklist below maps each duty to the engineering work that meets it. Where the draft would raise the bar, building to the draft now means you avoid the rework if it is adopted in a similar form.
| Validation proportionate to risk | A documented risk assessment per function, tied to each requirement’s test depth |
| Requirements traceability (draft) | Requirement IDs carried from URS through design specs into automated test cases, with the trace matrix generated from the repository, not kept by hand |
| Audit trail: who, what, when, why | Insert-only event store logging user, role, old and new values, timestamp with time zone, and a mandatory reason field on edits |
| Trail cannot be disabled or edited (draft) | No application path to change or delete trail records; configuration changes logged; admin role separate from GMP user roles |
| Access restricted and recorded | Role-based access control with an access-change log and scheduled access reviews |
| Personal accounts and remote MFA (draft) | No shared writable accounts; MFA enforced at the identity provider for remote sessions to critical systems |
| Backup and restore checked | Restore drills run as validation tests and repeated on a schedule, with results recorded |
| Read-only archive with integrity check (draft) | Status lock after release; checksums verified before source data is deleted on migration |
| Periodic evaluation | Review exports covering functionality, deviations, incidents, upgrade history, performance, security and validation status |
Annex 22 names change and configuration control before deployment explicitly for AI models. In our view, the same discipline (versioned configuration, build artefacts traceable to a validated release, and re-validation triggered by impact analysis) is how to keep any computerised system in the validated state the draft requires throughout its lifecycle.
How the validation work itself is planned and documented is the subject of two companion pages: one on computer system validation and what engineering teams need to implement, and one on applying the GAMP guide to automated systems. Our wider work is described on the AI engineering for life sciences and healthcare page.
Building against a moving target
The hard question for a team starting a system now is how far to build ahead of a draft that might still change. The direction is clear in the sources: more weight on security, identity and access management, audit trails and supplier management, with stronger lifecycle risk management. What remains uncertain is the final text and when it applies. Our judgement is to build the mechanisms now and keep the policy settings (review intervals, lockout thresholds, which roles need a reason prompt) configurable, so the final text becomes a configuration change rather than a redesign.
FAQ
What are the latest updates to EU GMP Chapter 4?
A revised draft of Chapter 4 (Documentation) was published for consultation on 7 July 2025, alongside the draft Annex 11 and Annex 22. The ECA Academy reports that it grew from 9 to 17 pages, and that it covers documentation in every format. The Commission’s Volume 4 index still lists Chapter 4 at its January 2011 version.
