How to read Annex 11
EU GMP Annex 11 is seventeen numbered clauses that most vendors quote as a feature checklist and most inspectors read as a lifecycle. The difference matters. The annex opens with three general clauses — risk management, personnel, suppliers — then splits into a project phase (clause 4, validation) and an operational phase (clauses 5–17: data, accuracy checks, storage, printouts, audit trails, change management, periodic evaluation, security, incidents, e-signatures, batch release, business continuity, archiving). A system can pass every project-phase expectation and still fail an inspection on the operational half — that is where most findings actually land.
This playbook walks the lifecycle in the order a real deployment meets it: what to settle before validation starts, the specification chain, qualification, the operational controls, and what keeps the validated state alive afterwards.
The binding text is the 2011 revision. A draft revision went to public consultation in 2025 and will modernize the annex substantially — cloud and service providers, audit trail review, security expectations — but until it is adopted, the 2011 clauses below are what an inspector holds you to. What the draft signals is covered at the end of this guide.
Before validation starts: inventory, impact, suppliers
Three things have to exist before the first test script is worth writing, and two of them are the clauses teams most often skim.
A system inventory with GxP impact decisions (clause 4.3). An up-to-date list of GMP-relevant systems, each with a documented decision about whether and why it is in scope. Inspectors ask for this early because it reveals how the firm thinks: a missing inventory means nobody owns the boundary of the validated estate.
A risk basis (clause 1). Risk management applies across the lifecycle — it is the first clause for a reason. In practice this means the depth of everything that follows (specification detail, test rigor, review frequency) is justified by documented risk reasoning, not by habit. GAMP 5 categories are the standard tool for sizing that effort; a configured eQMS typically lands at Category 4.
A supplier you have actually assessed (clause 3). For a cloud-hosted system the vendor is an IT service provider in the annex's meaning: a formal agreement is required, and for high-risk systems an audit of the supplier is the expectation, not a courtesy. The assessment has to reach the things that matter — development discipline, testing practice, release process — because clause 4.5 lets you leverage supplier documentation only to the extent you have assessed the supplier.
"What do you hand me for my supplier assessment of you?" A vendor that answers with a marketing PDF is telling you your clause 3 file will be thin. The useful answer is an audit-ready package: quality system description, development and testing practices, release and change process, and the evidence behind them.
The specification chain: URS to traceability
Clause 4.4 asks for user requirements that describe your intended use — traceable through risk assessment into the specifications and tests that answer them. For a configured system the chain runs: URS (what you need) → functional/configuration specification (how the system as configured meets it) → qualification tests (proof it does) → traceability matrix (the map an inspector actually opens first).
The most common weakness here is a URS copied from the vendor's feature list. It validates beautifully and describes nobody's process. Write requirements from your SOPs and your data flows; if a requirement cannot fail a test, it is a description, not a requirement.
Qualification phases and what they cover
Installation Qualification (IQ) confirms the system is installed correctly and configured to specification. Operational Qualification (OQ) verifies that workflows behave as intended under normal and boundary conditions. Performance Qualification (PQ) demonstrates that the system performs reliably in the actual operating environment over time.
- IQ — installation and configuration verification: environment, versions, configuration against the CS
- OQ — workflow and function testing against the URS, with pre-defined expected results and captured evidence
- PQ — real-environment performance evidence, run by the people who will operate the system
Two disciplines make the phase evidence stand up later. First, deviations during qualification are documented and dispositioned, not quietly re-run — an inspector who finds re-executed tests with no deviation record now questions every other pass. Second, every test traces to a requirement; orphan tests prove effort, not fitness for intended use.
The operational controls inspectors read next
Once qualification evidence exists, inspection attention moves to the operational clauses — the ones that show whether control survived go-live. The table below is the short map from clause to the evidence worth having ready.
| Clause | Expectation | Evidence an inspector asks for |
|---|---|---|
| 5–6 Data & accuracy checks | Interfaced data is checked; critical manual entries get a second check. | Where the checks happen, and a record that they ran. |
| 9 Audit trails | GMP-relevant changes and deletions are recorded with reasons; the trail is reviewed. | The trail itself — and evidence of periodic audit trail review, the expectation firms most often miss. |
| 12 Security | Physical and logical access restricted to authorized individuals; attribution of who entered or changed data. | Role definitions, access reviews, and the joiner-leaver record. |
| 14 Electronic signatures | Same impact as handwritten, permanently linked to their record, time-stamped. | A signed record walked end to end during the inspection. |
Maintaining the validated state after go-live
Validation does not end at launch — the annex dedicates more clauses to what happens after go-live than to the project itself. The operational half of the lifecycle runs on four mechanisms:
- Change and configuration management (clause 10). Every change to the system, its configuration, or its use passes through change control with an impact assessment that decides what re-testing and re-training the change owes. Vendor releases and customer configuration changes are distinct streams — treat them that way.
- Periodic evaluation (clause 11). A recurring, documented confirmation that the system still meets its requirements and its controls still work — covering changes since last review, deviations, incidents, audit trail review outcomes, and whether the risk picture moved. The interval is risk-justified, and "we validated it in 2023" is precisely the answer this clause exists to prevent.
- Incidents (clause 13). System failures and data errors are reported, assessed, and fed into CAPA where they warrant it — with the link between the incident record and the corrective action visible.
- Continuity of the record (clauses 7.2, 16, 17). Backups are made, and periodically restored-from to prove they work; continuity plans exist for critical systems; archived data stays readable for its full retention period, including through system retirement and migration.
Three places Annex 11 validation goes wrong
- Validating the demo instead of the configuration. The tests exercise vendor-default workflows, then the live system runs configured ones. The qualification evidence describes a system nobody uses. The configuration specification is what protects you here — test against it.
- Supplier assessment as a returned questionnaire. A checkbox form the vendor filled in, filed unread, satisfies nobody once an inspector asks what you concluded from it and what you did about the gaps.
- The periodic review that never runs. The SOP promises an annual evaluation; the last one predates the SOP. This is among the easiest findings for an inspector to establish — it needs one date — and it quietly voids the "validated state" claim for every year the review skipped.
The revealing request is rarely "show me your IQ." It is "show me a change you made last year, and walk me from the change record to the impact assessment, the re-test, the training update, and the audit trail entries." That single thread crosses clauses 9, 10, 11, and 12 — and it is either connected or it is not.
What the 2025 draft revision changes
The draft revision published for consultation in 2025 points one direction: more explicit, not less. Expanded expectations for cloud services and service providers, firmer audit trail review language, and security expectations written for the current threat environment rather than 2011's. None of it rewards waiting — a team running the lifecycle above meets the revision as an increment, while a team that validated once and stopped meets it as a project. Build to the lifecycle now and the revision is an update to your periodic review checklist, not a remediation program.
How Complere supports Annex 11 validation
Complere's role in this playbook is to shorten the project phase and carry the operational phase:
- A validation pack delivered with the platform — VMP, URS, risk assessment, traceability matrix, and IQ/OQ/PQ protocols per module, ready to extend for your intended use rather than written from a blank page.
- An immutable audit trail — database-enforced — audit records cannot be modified or deleted, enforced by database-level constraints, which is the posture clause 9 conversations start from.
- Change control that carries the thread — change requests link the documents, training, and records a change touches, so the change-to-evidence walk an inspector asks for is a query, not an archaeology project.
- Supplier assessment support on both sides — supplier qualification workflows for your vendors, and an audit-ready evidence package when the supplier being assessed is us.
See the validation approach and the validation pack for the artefacts themselves, and the Annex 11 vs Part 11 comparison for where these expectations differ from FDA's.
