EU requirements for computerised systems used in GxP activities — the risk-based EU counterpart to FDA's 21 CFR Part 11, currently mid-revision to add AI governance.
EU GMP Annex 11 (Computerised Systems) Audit-Readiness Rubric — Regscribe v0
What this is: EudraLex Volume 4 Annex 11 is the EU's GMP annex governing computerised systems used in GxP-regulated activities — the direct EU counterpart to FDA's 21 CFR Part 11 (docs/part11-rubric.md), though structured very differently: Part 11 is a prescriptive, clause-numbered CFR regulation with a documented 2003 enforcement-narrowing; Annex 11 is a short, principle-based GMP annex (17 numbered sections across four headings — Principle, General, Project Phase, Operational Phase — plus a glossary) that leans heavily on risk-based justification rather than bright-line rules. There is no Annex-11 equivalent of Part 11's "enforcement discretion" carve-out — every numbered section below is a live, current requirement.
Sourcing note — read before using this in production scoring: the primary-source text below is pulled directly from the European Commission's own PDF — EudraLex Volume 4, Annex 11: Computerised Systems, Revision 1 (SANCO/C8/AM/sl/ares(2010)1064599), "deadline for coming into operation: 30 June 2011" — fetched from health.ec.europa.eu (https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf) and converted to text with pdftotext -layout this session. Every clause number, heading, and quoted/near-verbatim requirement below is taken from that extracted text, not paraphrased from a consultancy summary. This is the current, legally operative version — it has not been amended since 2011.
For the "common failure pattern" columns, this session successfully fetched and extracted (via pdftotext -layout) the MHRA's "'GXP' Data Integrity Guidance and Definitions," Revision 1, March 2018 (assets.publishing.service.gov.uk/media/5aa2b9ede5274a3e391e37f3/MHRA_GxP_data_integrity_guide_March_edited_Final.pdf) — this is the UK/EU practical equivalent of FDA's 2018 Data Integrity Q&A guidance the Part 11 rubric flagged as unreachable, and it explicitly cross-references Annex 11 by number throughout (e.g. its §6.19 heading reads "Validation – for intended purpose (GMP; See also Annex 11, 15)"). Quotes from it below are marked accordingly. A second real source — a named, dated MHRA GMP inspection deficiency statistic specific to Annex 11 — was found via a secondary trade-press analysis (Pharmaceutical Online, published 18 January 2021, analysing MHRA's 2019 inspection deficiency dataset) rather than a directly-fetched MHRA raw dataset; the raw MHRA deficiency spreadsheets themselves (a ~5,300-row 2019 Excel file MHRA published via FOI/routine disclosure) were not independently fetched this session — flagged in Gaps below rather than treated as directly sourced.
Nothing in this document is fabricated. Where a specific deficiency statistic or example could not be independently verified against a primary regulator source this session, it is marked as secondary-sourced or flagged as a gap rather than presented as a directly-verified fact.
0. READ THIS FIRST — a major revision is mid-consultation (critical context, not yet in force)
Annex 11 as scored below is the current, legally operative 2011 text — but do not build long-term product assumptions on it being static. Multiple independent trade sources (ECA Academy/gmp-compliance.org, and corroborating coverage from PQE Group, Rephine, and GMP Insiders) confirm the European Commission released a draft revision of Annex 11 for public consultation on 7 July 2025, alongside a revised GMP Chapter 4 (Documentation) and a brand-new Annex 22 (Artificial Intelligence) — the first EU GMP annex to formally address AI/ML systems. The consultation period ran 7 July – 7 October 2025 (now closed); trade coverage places final publication around mid-2026, with a transition period before the revised text takes legal effect (one secondary source estimated implementation around 2027, but this specific date was not confirmed against an EC or PIC/S primary source this session and should be treated as indicative only).
The draft reportedly expands Annex 11 substantially (secondary sources describe it growing from roughly 5 pages / 17 short sections to a much longer document addressing cloud/SaaS qualification, cybersecurity, and AI governance explicitly) — this is a genuine, EU-specific parallel to how Part 11's 2003 guidance reshaped enforcement of the 1997 rule, except here the underlying regulation itself is being rewritten, not just its enforcement posture.
Practical implication for Regscribe scoring, right now (2026):
- Score exclusively against the 2011 text below — it remains the current legal requirement and the only version with a real citation trail.
- Do not cite the 2025 draft's content as if it were in force — it is not, and its provisions could still change before final publication.
- Flag this as a live product/roadmap item: once the revision is finalised (expected mid-2026 per secondary sources), this rubric will need a full rewrite, and Annex 22 (AI) will likely become a separate rubric entry in its own right given Regscribe's own nature as an AI tool operating in this exact regulatory space.
Rubric legend
Each row: Requirement (plain language / near-verbatim) → Citation → Evidence that demonstrates compliance → Common failure pattern
Principle (governs the whole annex)
| |
|---|
| Requirement | "This annex applies to all forms of computerised systems used as part of a GMP regulated activities. A computerised system is a set of software and hardware components which together fulfill certain functionalities." "The application should be validated; IT infrastructure should be qualified." "Where a computerised system replaces a manual operation, there should be no resultant decrease in product quality, process control or quality assurance. There should be no increase in the overall risk of the process." (verbatim) |
| Citation | Annex 11, Principle |
| Evidence of compliance | System inventory identifying every computerised system touching a GMP-regulated activity (manufacturing, QC, QA, distribution records); for each, an application-validation record and a separate IT-infrastructure qualification record (these are two distinct deliverables per the Principle's own wording, not one document); a documented before/after risk comparison for any system introduced to replace a manual/paper process. |
| Common failure pattern | Treating "the system was validated" as covering IT infrastructure qualification too — the Principle text keeps these grammatically and conceptually separate ("The application should be validated; IT infrastructure should be qualified"), and a validation package that only exercises application functionality without separately evidencing infrastructure qualification (servers, network, OS patching baseline) is a common documentary gap. |
General
1. Risk Management
| |
|---|
| Requirement | "Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system." (verbatim) |
| Citation | Annex 11, §1 |
| Evidence | A documented, system-specific risk assessment (not a generic template) that explicitly drives — and is referenced by — the validation scope and data-integrity control decisions made for that system; evidence the assessment was revisited across the lifecycle (at major changes, periodic evaluation), not only at initial deployment. |
| Common failure pattern | A risk assessment that exists as a one-time, initial-deployment artifact disconnected from later validation/change decisions — the clause requires risk management "throughout the lifecycle," so a stale, never-revisited risk assessment is itself a gap, independent of its original content quality. |
2. Personnel
| |
|---|
| Requirement | "There should be close cooperation between all relevant personnel such as Process Owner, System Owner, Qualified Persons and IT. All personnel should have appropriate qualifications, level of access and defined responsibilities to carry out their assigned duties." (verbatim) |
| Citation | Annex 11, §2 |
| Evidence | RACI or equivalent role-definition document naming a Process Owner and System Owner (per the Annex's own Glossary definitions — see below) for each critical system; training/qualification records tied to each named role; access-level documentation matching the defined responsibilities. |
| Common failure pattern | Process Owner and System Owner roles left undefined or informally merged (e.g. IT holds both roles by default) — the Annex's Glossary treats these as distinct, named roles with different accountabilities (business-process ownership vs. system availability/security/maintenance ownership), and an inspector can reasonably ask "who is your System Owner for this system" as a direct, citable question. |
3. Suppliers and Service Providers
| Clause | Requirement (verbatim/near-verbatim) | Evidence |
|---|
| 3.1 | "When third parties (e.g. suppliers, service providers) are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party. IT-departments should be considered analogous." | Signed technical/quality agreements with every third-party system provider (including cloud/SaaS/hosting vendors and remote-maintenance providers) with explicit responsibility statements; an equivalent internal responsibility document where an internal IT department plays the "third party" role. |
| 3.2 | "The competence and reliability of a supplier are key factors when selecting a product or service provider. The need for an audit should be based on a risk assessment." | Documented supplier-selection/qualification rationale; a risk-based audit-need determination for each supplier (not a blanket "audit everyone" or "audit no one" policy — the clause requires the decision itself to be risk-based and documented). |
| 3.3 | "Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled." | A documented review record showing COTS vendor documentation was checked against the site's own User Requirements Specification (URS), not simply filed unread. |
| 3.4 | "Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request." | Retrievable supplier quality-system/audit records (own audits or third-party certifications) that can be produced on request during an inspection, without needing to chase the vendor mid-inspection. |
| Common failure pattern (whole section) | Cloud/SaaS vendor relationships are the most common gap area here in practice: agreements that don't clearly state who is responsible for validation, change control, or data retrieval on contract termination, and a COTS/SaaS URS-review step that gets skipped because the vendor is treated as "already compliant" by reputation rather than independently checked against the site's own requirements. | |
Project Phase
4. Validation
| Clause | Requirement (verbatim/near-verbatim) | Evidence |
|---|
| 4.1 | "The validation documentation and reports should cover the relevant steps of the life cycle. Manufacturers should be able to justify their standards, protocols, acceptance criteria, procedures and records based on their risk assessment." | Validation master plan/protocol/report set spanning the full system lifecycle (not just initial qualification), with each standard/protocol/acceptance criterion traceable to the §1 risk assessment. |
| 4.2 | "Validation documentation should include change control records (if applicable) and reports on any deviations observed during the validation process." | Change-control records embedded within (or clearly cross-referenced from) the validation package; deviation reports from the validation exercise itself, not only from routine operation. |
| 4.3 | "An up to date listing of all relevant systems and their GMP functionality (inventory) should be available. For critical systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes, any hardware and software pre-requisites, and security measures should be available." | A maintained, current system inventory covering every GMP-relevant computerised system; for systems classified as critical, a separate, current system description covering architecture, data flows, interfaces, hardware/software prerequisites, and security measures. |
| 4.4 | "User Requirements Specifications should describe the required functions of the computerised system and be based on documented risk assessment and GMP impact. User requirements should be traceable throughout the life-cycle." | A URS for each system, explicitly linked to the risk assessment/GMP-impact determination; a traceability matrix connecting URS items through design, testing, and (where relevant) later changes. |
| 4.5 | "The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately." | Supplier QMS assessment records (audit, certification review, or questionnaire-based assessment proportionate to risk) held by the regulated user, not merely asserted by the supplier. |
| 4.6 | "For the validation of bespoke or customised computerised systems there should be a process in place that ensures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of the system." | A defined SDLC/validation methodology specifically for bespoke/customised systems (distinct from COTS handling), with quality/performance measures reported at each lifecycle stage. |
| 4.7 | "Evidence of appropriate test methods and test scenarios should be demonstrated. Particularly, system (process) parameter limits, data limits and error handling should be considered. Automated testing tools and test environments should have documented assessments for their adequacy." | Test scripts/cases covering parameter limits, data limits, and error/exception handling (not just "happy path" testing); a documented adequacy assessment for any automated testing tool or test environment used. |
| 4.8 | "If data are transferred to another data format or system, validation should include checks that data are not altered in value and/or meaning during this migration process." | Migration validation records with explicit before/after data-comparison evidence (value and meaning, e.g. unit/format/precision preserved) for any system migration, upgrade, or data-format conversion. |
| Common failure pattern (whole section) | Vendor-supplied validation/testing evidence accepted at face value without the regulated user demonstrating its own performance qualification in the actual intended-use configuration — this is precisely the gap the MHRA's 2018 GXP Data Integrity Guidance calls out directly (§6.19, cross-referencing Annex 11 and 15 by name): "the acceptance of vendor-supplied validation data in isolation of system configuration and users intended use is not acceptable. In isolation from the intended process or end-user IT infrastructure, vendor testing is likely to be limited to functional verification only and may not fulfil the requirements for performance qualification." Migration validation (§4.8) is also commonly incomplete in practice — value-level checks (did the number come across correctly) without meaning-level checks (did a unit, timezone, or field-mapping change silently alter what the value represents). | |
Operational Phase
5. Data
| |
|---|
| Requirement | "Computerised systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data, in order to minimize the risks." |
| Citation | Annex 11, §5 |
| Evidence | Documented interface/integration controls (validation checks, checksums, reconciliation routines) for any system-to-system electronic data exchange, tested as part of validation. |
| Common failure pattern | Interfaces between systems (e.g. LIMS↔ERP, MES↔historian) validated for the "happy path" data flow but without built-in checks for malformed, incomplete, or out-of-sequence data arriving from the sending system. |
6. Accuracy Checks
| |
|---|
| Requirement | "For critical data entered manually, there should be an additional check on the accuracy of the data. This check may be done by a second operator or by validated electronic means. The criticality and the potential consequences of erroneous or incorrectly entered data to a system should be covered by risk management." |
| Citation | Annex 11, §6 |
| Evidence | A documented determination of which manually-entered data fields are "critical"; a defined second-check mechanism (second-operator verification or validated electronic check) applied to those fields specifically, referenced back to the §1 risk assessment. |
| Common failure pattern | Second-person/electronic verification applied uniformly (or not at all) rather than risk-differentiated by data criticality — the clause requires the criticality determination itself to be documented, so "we double-check everything" without a documented criticality basis is itself incomplete against the letter of the clause. |
7. Data Storage
| Clause | Requirement (verbatim) | Evidence |
|---|
| 7.1 | "Data should be secured by both physical and electronic means against damage. Stored data should be checked for accessibility, readability and accuracy. Access to data should be ensured throughout the retention period." | Physical security controls (server room access, environmental controls) and electronic security controls (encryption, access permissions) both evidenced; periodic accessibility/readability/accuracy checks of stored data, not just at point of creation. |
| 7.2 | "Regular back-ups of all relevant data should be done. Integrity and accuracy of back-up data and the ability to restore the data should be checked during validation and monitored periodically." | Backup schedule/logs; restore-test records at validation and on a periodic (not one-time) basis, confirming both that data restores and that restored data is accurate/complete. |
| Common failure pattern | Backup jobs confirmed to run (a green checkmark in backup software) without periodic restore testing — a backup that has never been proven restorable is not compliant evidence under §7.2, which explicitly requires the ability to restore to be checked, not just the backup's existence. This ranked among the most-cited Annex 11 deficiency areas in MHRA's published 2019 inspection deficiency analysis (see Common Failure Patterns summary below). | |
8. Printouts
| Clause | Requirement (verbatim) | Evidence |
|---|
| 8.1 | "It should be possible to obtain clear printed copies of electronically stored data." | Sample printout/export demonstrating legible, complete rendering of electronically stored records. |
| 8.2 | "For records supporting batch release it should be possible to generate printouts indicating if any of the data has been changed since the original entry." | For batch-release-supporting records specifically: a printout/report function that flags where underlying data has been changed since original entry (not merely a static snapshot indistinguishable from an unedited record). |
| Common failure pattern | A generic PDF/print export function exists (§8.1 satisfied) but no batch-release-specific "changed since original entry" indicator (§8.2 not satisfied) — these are two distinct requirements and a system can meet one without the other. | |
9. Audit Trails
| |
|---|
| Requirement | "Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated 'audit trail'). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed." (verbatim) |
| Citation | Annex 11, §9 |
| Evidence | Risk assessment determining which systems/data require an audit trail; where implemented, audit-trail configuration evidence covering GMP-relevant create/modify/delete actions with reason-for-change capture; an audit-trail export in human-readable form; documented periodic audit-trail review records (not just existence of the trail). |
| Common failure pattern | This is the single most consequential clause in the Annex for data-integrity findings in practice. The MHRA's 2018 GXP Data Integrity Guidance (§6.13, directly informing how Annex 11 audit-trail findings are assessed) states: "Audit trails (identified by risk assessment as required) should be switched on. Users should not be able to amend or switch off the audit trail. Where a system administrator amends, or switches off the audit trail a record of that action should be retained." and separately: "Where systems do not meet the audit trail and individual user account expectations, demonstrated progress should be available to address these shortcomings... Where remediation has not been identified or subsequently implemented in a timely manner a deficiency may be cited." In other words: audit trail switched off, switchable by ordinary users, or configured but never actually reviewed are all independently citable — the clause requires the trail to exist, be tamper-resistant, and be reviewed, not just be technically present. Legacy systems genuinely lacking audit-trail capability are not automatically exempt — MHRA's guidance requires a documented alternative control (SOP-based process, logbooks) proven effective, plus evidence of active progress toward remediation. |
10. Change and Configuration Management
| |
|---|
| Requirement | "Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure." |
| Citation | Annex 11, §10 |
| Evidence | A change-control SOP covering both application changes and underlying configuration changes; change records showing impact assessment, approval, and (where applicable) re-validation/re-qualification prior to implementation. |
| Common failure pattern | Configuration changes (permissions, integration settings, report definitions) made outside formal change control because they're perceived as "just settings" rather than a change to the validated state — the clause explicitly includes "system configurations," not only code/application changes. |
11. Periodic Evaluation
| |
|---|
| Requirement | "Computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP. Such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports." |
| Citation | Annex 11, §11 |
| Evidence | A scheduled periodic-review programme with defined frequency per system (risk-based); review records addressing each of the named elements (functionality, deviations, incidents, problems, upgrade history, performance, reliability, security, validation status) — not a single "system still works" sign-off. |
| Common failure pattern | Periodic review reduced to a re-approval signature with no substantive content review against the named elements — this is one of MHRA's most-cited Annex 11 deficiency areas in practice (see summary below), and mirrors the same "checkbox review" pattern flagged in the sibling eu-annex1-rubric.md for CCS effectiveness reviews. |
12. Security
| Clause | Requirement (verbatim) | Evidence |
|---|
| 12.1 | "Physical and/or logical controls should be in place to restrict access to computerised system to authorised persons. Suitable methods of preventing unauthorised entry to the system may include the use of keys, pass cards, personal codes with passwords, biometrics, restricted access to computer equipment and data storage areas." | Access-control mechanism documentation (physical and/or logical) matched to actual deployed controls; evidence access is genuinely restricted to authorised individuals (no generic/shared accounts). |
| 12.2 | "The extent of security controls depends on the criticality of the computerised system." | Documented criticality tiering of systems with security-control intensity scaled accordingly, referencing the §1 risk assessment. |
| 12.3 | "Creation, change, and cancellation of access authorisations should be recorded." | User-access lifecycle records (provisioning, role change, deprovisioning) — particularly deprovisioning-on-termination evidence, a common gap. |
| 12.4 | "Management systems for data and for documents should be designed to record the identity of operators entering, changing, confirming or deleting data including date and time." | System configuration/design evidence that every data/document action is attributable to a named individual with timestamp — this is the identity-attribution backbone that §9's audit trail depends on. |
| Common failure pattern (whole section) | This was the single most-cited Annex 11 deficiency area in MHRA's published 2019 GMP inspection deficiency analysis (secondary-sourced, see summary below) — most commonly, shared/generic logins and inadequate deprovisioning of access on role change or termination, which independently undermines §9's audit-trail attribution requirement even where an audit trail is technically switched on. | |
13. Incident Management
| |
|---|
| Requirement | "All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions." |
| Citation | Annex 11, §13 |
| Evidence | Incident log covering the full range of incident types (not only outright failures — near-misses, data anomalies, performance issues); root-cause analysis records for incidents classified critical, with a documented CAPA trail back to that root cause. |
| Common failure pattern | Incident logging scoped too narrowly to hard system failures, missing "soft" incidents (a report that produced a plausible-but-wrong number, a near-miss access breach) that the clause's "not only system failures and data errors" language explicitly requires to be captured. |
14. Electronic Signature
| |
|---|
| Requirement | "Electronic records may be signed electronically. Electronic signatures are expected to: a. have the same impact as hand-written signatures within the boundaries of the company, b. be permanently linked to their respective record, c. include the time and date that they were applied." |
| Citation | Annex 11, §14 |
| Evidence | An internal policy establishing the legal/organisational equivalence of electronic and handwritten signatures; technical evidence the signature is permanently bound to its record (cannot be transferred/reused, echoing Part 11 §11.70's signature/record-linking requirement — a useful cross-rubric consistency check); timestamp capture on every electronic signature. |
| Common failure pattern | Signature stored as an editable metadata field not structurally/cryptographically bound to the specific record version — the same failure pattern flagged under Part 11 §11.70 in part11-rubric.md, and worth cross-checking jointly for any system operating in both the US and EU. |
15. Batch Release
| |
|---|
| Requirement | "When a computerised system is used for recording certification and batch release, the system should allow only Qualified Persons to certify the release of the batches and it should clearly identify and record the person releasing or certifying the batches. This should be performed using an electronic signature." |
| Citation | Annex 11, §15 |
| Evidence | Role-based restriction in the batch-release system limiting certification/release actions to individuals designated as Qualified Persons (QP); an electronic signature applied at the point of release, individually attributed and timestamped. |
| Common failure pattern | Batch-release permission scoped to a QA role/group broadly rather than specifically to designated QP individuals — the clause requires restriction to Qualified Persons specifically, a formally designated role under EU GMP, not QA staff generally. |
16. Business Continuity
| |
|---|
| Requirement | "For the availability of computerised systems supporting critical processes, provisions should be made to ensure continuity of support for those processes in the event of a system breakdown (e.g. a manual or alternative system). The time required to bring the alternative arrangements into use should be based on risk and appropriate for a particular system and the business process it supports. These arrangements should be adequately documented and tested." |
| Citation | Annex 11, §16 |
| Evidence | Documented business-continuity/disaster-recovery plan for each critical system, with a risk-justified recovery-time target; evidence the fallback arrangement (manual process or alternative system) has actually been tested, not just written. |
| Common failure pattern | A written continuity plan that has never been exercised/tested — the clause explicitly requires arrangements to be "adequately documented and tested," and an untested plan is incomplete evidence even if well-written. |
17. Archiving
| |
|---|
| Requirement | "Data may be archived. This data should be checked for accessibility, readability and integrity. If relevant changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data should be ensured and tested." |
| Citation | Annex 11, §17 |
| Evidence | Archive-accessibility/readability/integrity check records at defined intervals; specifically, retrieval-testing evidence performed around any hardware/software change affecting the archive (migration, format change, platform retirement), not only at initial archiving. |
| Common failure pattern | Archived data assumed to remain retrievable indefinitely without periodic verification, and no retrieval test performed at the point of a hardware/software change that could affect readability (e.g. archiving format tied to a legacy application being decommissioned) — this is the archival analogue of the §7.2 "backup never restore-tested" gap. |
Glossary (Annex 11's own definitions — reference, not scored directly)
Per the Annex's own Glossary: Application (software on a defined platform providing specific functionality); Bespoke/Customized computerised system (individually designed for a specific business process); Commercial off-the-shelf (COTS) software (commercially available, fitness for use demonstrated by a broad spectrum of users); IT Infrastructure (hardware/software — networking, operating systems — enabling the application to function); Life cycle (all phases from initial requirements through retirement: design, specification, programming, testing, installation, operation, maintenance); Process owner (person responsible for the business process); System owner (person responsible for availability, maintenance, and data security of a computerised system); Third Party (parties not directly managed by the holder of the manufacturing/import authorisation).
Use these definitions to correctly classify each system (bespoke vs. COTS; who the named Process/System Owner is) before scoring — several clauses above (§2, §4.5, §4.6) apply differently depending on this classification.
Annex 11 ↔ Annex 15 (Qualification and Validation) boundary
Annex 11's own text (§4, Validation) does not cite Annex 15 by name anywhere in the primary source fetched this session — this boundary is established by industry/regulatory practice and by secondary guidance, not by an explicit cross-reference inside Annex 11 itself. Flagging this distinction explicitly rather than asserting a textual link that isn't actually there.
What is independently confirmed: the MHRA's 2018 GXP Data Integrity Guidance groups the two together explicitly — its §6.19 is headed "Validation – for intended purpose (GMP; See also Annex 11, 15)" — and multiple industry sources (ECA Academy / gmp-compliance.org among them) describe the practical division as: Annex 15 sets the general qualification/validation methodology and lifecycle (URS→DQ→IQ→OQ→PQ, change control, revalidation triggers) applicable to facilities, utilities, equipment, and processes generally; Annex 11 applies that same general discipline specifically to computerised systems, adding system-specific concerns Annex 15 doesn't address on its own — audit trails, electronic signatures, data integrity controls, and IT infrastructure qualification as a concept distinct from application validation (Annex 11's Principle explicitly separates "the application should be validated" from "IT infrastructure should be qualified").
Practical scoring implication: where a computerised system's validation package is being assessed, general validation-methodology gaps (missing DQ, no defined acceptance criteria, absent revalidation trigger) should be considered against Annex 15 principles even when the primary citation is an Annex 11 clause (most directly §4.1–4.2) — the two are complementary, not competing, frameworks, and a mature validation package for a GMP-relevant computerised system should be defensible against both simultaneously. Regscribe does not yet have a standalone Annex 15 rubric; this is noted as a gap below.
Common failure patterns (cross-cutting summary)
Sourcing caveat: items 1–2 below are directly sourced verbatim from MHRA's 2018 GXP Data Integrity Guidance (independently fetched and extracted this session). Item 3 is sourced from a secondary trade-press analysis (Pharmaceutical Online, 18 January 2021) of MHRA's published 2019 GMP inspection deficiency dataset — the raw MHRA dataset itself was not independently fetched this session, so this statistic should be treated as secondary-sourced, not primary-verified, and is flagged accordingly rather than presented as directly confirmed.
- Audit trail switched off, user-switchable, or configured but never reviewed (§9) — MHRA's GXP DI Guidance §6.13 treats each of these as independently citable, and states unremediated systems lacking compliant audit-trail/user-account functionality may be cited as a deficiency in their own right if progress toward remediation isn't demonstrated.
- Vendor-supplied validation evidence accepted without the regulated user's own performance qualification in its actual intended-use configuration (§4.5, §4.7) — MHRA's GXP DI Guidance §6.19 states this directly: vendor testing in isolation "may not fulfil the requirements for performance qualification."
- (Secondary-sourced, not independently re-verified this session) Per Pharmaceutical Online's analysis of MHRA's 2019 GMP inspection deficiency data (published 18 January 2021): Annex 11 (Computer Systems) ranked ninth among the top ten most-cited chapters/annexes overall; within Annex 11 specifically, Security (§12) was the single most frequently cited clause, at just under 25% of all Annex 11 citations, with Security (§12), Validation (§4), Data Storage (§7), and Periodic Evaluation (§11) together accounting for "slightly over 60 percent" of all Annex 11 citations. The article frames Annex 11 deficiencies as "frequently associated with the broader data governance and data integrity area" — i.e. systemic control weaknesses (access management, backup/restore discipline, substantive periodic review) rather than isolated one-off technical defects.
- Configuration changes made outside formal change control because they aren't perceived as "real" changes (§10) — a recurring theme in how §10 findings are described in practice: permission changes, integration settings, and report-definition edits treated as routine admin work rather than changes to a validated state.
- Backup/archive existence confirmed but restore/retrieval never actually tested (§7.2, §17) — the clause language in both sections explicitly requires the ability to restore/retrieve to be checked and tested, not merely the backup or archive's existence, making "we have backups" alone insufficient evidence.
Gaps / follow-ups before this goes into production scoring
- The 2025 draft revision (Annex 11 rewrite + new Annex 22 on AI) is not reflected in the clause-by-clause scoring above, by design — it is not yet in force (consultation closed 7 October 2025; secondary sources place final publication around mid-2026, implementation potentially 2027, neither date independently confirmed against an EC/PIC/S primary source this session). This rubric will need a substantial rewrite once the revision is finalised, and Annex 22 (AI) is a strong candidate for its own standalone rubric entry given Regscribe's own position as an AI tool operating in exactly this regulatory space — flag this to Sonic/product roadmap as a forward-looking item, not an immediate gap.
- Raw MHRA GMP inspection deficiency dataset not independently fetched this session — the §12/Security "just under 25%" and top-four-clauses "slightly over 60%" statistics above come from a secondary trade-press analysis (Pharmaceutical Online, 18 Jan 2021) of MHRA's 2019 data, not from directly parsing MHRA's own published Excel dataset. A follow-up pass pulling MHRA's raw deficiency spreadsheet directly (published via routine FOI-style disclosure, per that same secondary source) would let these statistics be re-cited as primary-sourced rather than secondary-sourced, and would allow adding more recent inspection-year data if MHRA has published newer datasets since 2019.
- Annex 15 (Qualification and Validation) does not yet have its own Regscribe rubric. The boundary section above notes where Annex 11 validation clauses (§4.1–4.2 especially) lean on general Annex 15 methodology; without a standalone Annex 15 rubric, findings that are really "generic validation methodology gaps" will currently get cited only against Annex 11's narrower computerised-systems framing. Worth a dedicated Annex 15 rubric as a follow-up, given it's referenced by name in the MHRA GXP DI Guidance alongside Annex 11 and underlies validation clauses across multiple existing Regscribe rubrics (Part 11 §11.10(a), Annex 1 references to qualification/validation, this Annex 11 §4).
- PIC/S mirror of the current (2011) Annex 11 text not independently re-fetched this session — following the same convention as
eu-annex1-rubric.md's Gap #2, this rubric relies solely on the European Commission's own PDF for the current, in-force text. PIC/S PE 009 is understood to mirror EU GMP Vol. 4 text closely (confirmed for Annex 1 in the sibling rubric's sourcing), but this was not independently re-verified for Annex 11 specifically this session.
- MHRA GXP DI Guidance is UK-specific (post-Brexit) rather than an EU/EMA-published document. It is used here because it is the closest, most directly Annex-11-referencing practical guidance found (paralleling how the Part 11 rubric uses FDA's own guidance), and MHRA states it was "harmonised with other published guidance" including EMA's — but it is not itself an EU Commission or EMA publication. If Regscribe later needs an EU27-specific (rather than UK-specific) data-integrity companion source, EMA's own GMP/GDP inspectors working group guidance on data integrity would be the primary-source target for a follow-up fetch.