Skip to content

EU GMP Annex 11 Compliance Traceability

Standard: EudraLex Volume 4, Annex 11, "Computerised Systems", the 2011 text. PIC/S PE 009 Annex 11 carries the same wording. Applicability: Pharmaceutical batch manufacturing records, recipe approval, control logic changes, equipment configuration, and the supplier relationship around them Overall Status: Substantially Implemented (see Gap Analysis for the remaining items)

How this matrix relates to the 21 CFR Part 11 matrix

Annex 11 and Part 11 regulate the same records with different scopes. Part 11 is about electronic records and signatures. Annex 11 covers the whole lifecycle of a computerised system, from risk management to archiving, and several of its clauses have no Part 11 counterpart. Where a row here rests on Part 11 evidence, its Derived from column names the row of the Part 11 matrix it derives from, and the evidence is not restated. Where it does not, the column names the product document that carries the evidence. A change to a Part 11 row is a change to every Annex 11 row that derives from it.

Annex 11 binds the manufacturing authorisation holder, and a supplier cannot be Annex 11 compliant on its own. This matrix claims that the named controls exist in the product, that each is documented, and that a reader can inspect the evidence. No compliance, validation or certification is claimed. Where a clause is an obligation on the regulated company's organisation, the row says so, states what the product supplies to that obligation, and asserts nothing about the customer. The Customer's part column names the half of each clause the product cannot carry.

Status Legend

Indicator Meaning
Implemented Requirement is fully implemented with tests and evidence
Partial Core functionality exists but gaps remain
Planned Architecture is designed but implementation has not started
Supported The obligation is the regulated company's, and the product supplies the named input to it
N/A Requirement does not apply to this system

GAMP 5 Categorization

Annex 11 opens with a principle: the application should be validated and the IT infrastructure qualified, and where a computerised system replaces a manual operation there should be no resultant decrease in product quality, process control or quality assurance, and no increase in overall risk. The product's position on the principle is its GAMP 5 categorisation. The shipped software is a Category 4 configured product. Everything a site authors to describe its process is configuration, applied as declarative, schema-validated resources under version control. The platform beneath it, Kubernetes and the database, is Category 1 infrastructure the customer qualifies. The per-layer rationale, including the Category 5 boundary for forked images, and the V-model mapping live in the dedicated GAMP 5 Computerized System Validation document. The final categorisation is the customer's quality unit's to make.

General

Clause Requirement Status Implementation Derived from Customer's part
1. Risk management Risk management applied throughout the lifecycle, taking patient safety, data integrity and product quality into account, with the extent of validation and data-integrity controls based on a justified and documented risk assessment Supported The product supplies the inputs a risk assessment consumes: a stated software category per layer (gamp5.md), a threat model with a disposition per threat (threat-model.md), the interface catalogue (secure-design.md), and the traceability matrices in this directory, which say which control carries which requirement GAMP 5 document; threat model; SDL audit file The risk assessment itself, under ICH Q9 and the customer's procedures
2. Personnel Close cooperation between process owner, system owner, qualified persons and IT, with appropriate qualifications and defined responsibilities N/A Organisational policy; outside system scope None The customer's role definitions and training
3.1 Suppliers: formal agreements Formal agreements with third parties supplying, installing, configuring, integrating, validating, maintaining or modifying a system, with clear statements of responsibilities Supported The responsibility split is written into every row of this matrix as its last column, so a quality agreement can be drafted from it This matrix The quality agreement, on the customer's template or the supplier's
3.2 Suppliers: competence and reliability The competence and reliability of a supplier are key factors when selecting a product, and the need for an audit is based on a risk assessment Supported The supplier-assessment deliverable is the Secure Development Lifecycle Audit File: the whole development lifecycle mapped to the 47 requirements of IEC 62443-4-1 with an evidence column an auditor can inspect, an open-gaps register, and a crosswalk from the usual questionnaire areas. Its dispositions are held identical to the internal IEC 62443-4-1 assessment by make lint-sdl-audit-parity SDL audit file The risk-based decision whether to audit, and the audit
3.3 Suppliers: documentation review Documentation supplied with commercial off-the-shelf products is reviewed by regulated users to check that user requirements are fulfilled Supported The product documentation is public at docs.cndcs.io, with the compliance matrices, the operating and hardening guides, and the runbooks. A user requirement citing ISA-88, Part 11, Annex 11 or IEC 62443 traces to a matrix row directly Product documentation The documentation review against the customer's user requirements
3.4 Suppliers: quality system and audit information Quality-system and audit information relating to the supplier or product is made available to inspectors on request Supported The SDL audit file and the matrices in this directory are written to be handed to an inspector, and each carries its open gaps in full SDL audit file Holding the current versions in the customer's supplier file

Project phase

Clause Requirement Status Implementation Derived from Customer's part
4.1 Validation documentation and reports Validation documentation and reports cover the relevant steps of the lifecycle, and manufacturers justify their standards, protocols, acceptance criteria, procedures and records by risk assessment Implemented The right leg of the V-model ships as executable protocols: dcs qualify iq against an approved baseline, dcs qualify oq through all eight ISA-88 commands with every transition audited, dcs qualify pq computing Cpk to a verdict. Every run persists as a signed Qualification AuditRecord and is exportable (validation.md). The supplier's own lifecycle documentation is the SDL audit file Part 11 §11.10(a); GAMP 5 document The validation plan, the acceptance criteria, the review and approval of runs, and the validation report
4.2 Change control and deviations Validation documentation includes change-control records and reports on deviations observed during validation Implemented Every ChangeRequest carries its proposed and approved signatures, the review-time snapshot of the target, and the semantic diff from that base, so "what was approved" is answerable from a terminal ChangeRequest after the target has changed. A qualification run that fails persists as a failed run and --fail-on-deviation lets it gate a deployment Part 11 §11.10(k); Part 11 §11.10(a) The deviation procedure and the deviation reports
4.3 System inventory An up-to-date listing of all relevant systems and their GMP functionality is available, with a description of the physical and logical arrangements, data flows, interfaces and security measures for critical systems Supported The IQ baseline is a machine-readable inventory of the deployed system: Kubernetes version, CRDs, chart release and values digest, deployments and image digests, RBAC hash, volumes and service accounts. architecture.md and network-requirements.md describe the arrangement and the data flows. The interface catalogue in secure-design.md lists every product interface with its exposure, users, reachable assets and safeguards Part 11 §11.10(a); architecture and network documentation; SDL audit file The site's system inventory, in which the product is one entry
4.4 User requirements User requirement specifications describe the required functions and are based on documented risk assessment and GMP impact, and requirements are traceable throughout the lifecycle Supported The compliance matrices map regulatory clauses to implemented controls, so a user requirement citing a clause traces to the row and the evidence in one step. The applied configuration is itself the functional specification: site-authored resources are declarative, schema-validated at admission, and version-controlled, so specified and applied cannot drift GAMP 5 document The user requirements specification and the traceability matrix the customer maintains
4.5 Supplier quality and development methodology The regulated user takes all reasonable steps to ensure the system was developed in accordance with an appropriate quality management system, and the supplier is assessed appropriately Supported The SDL audit file states the development process, the roles, the gates, the release pipeline, the defect and update management, and the maturity position per practice, with the open gaps in a register. It is explicit about the largest of them: no independent verification and validation has been performed, and a single-founder organisation has no internal person who can satisfy an independence requirement SDL audit file The supplier assessment
4.6 Customised systems For customised systems there is a process to ensure the formal assessment and reporting of quality and performance measures for all lifecycle stages Partial The shipped product is not customised. Site process definitions are configuration within Category 4. A site that authors new function-block types in Go and builds a forked image moves that code into Category 5 and owns proportionally more documentation, and gamp5.md says where the boundary is GAMP 5 document Avoiding Category 5 work where the configuration surface suffices, or documenting it where it does not
4.7 Test methods and scenarios Evidence of appropriate test methods and test scenarios, including parameter limits, data limits and error handling Implemented CRD schema validation enforces data limits at the API server. A manual entry through an operator prompt is bounded to its declared range, and a value from an external system is validated against the same bounds through the same code path (validateBoundedNumber, shared by the prompt-response and external-result handlers). The OQ suite covers the happy path, abort, pause and resume, stop and reset. The product's own CI includes fault-injection and failover drills, with the measured results published in ha-failure-modes.md Part 11 §11.10(a); Part 11 §11.10(f); validation documentation Site-specific test scenarios and their acceptance criteria
4.8 Data migration Where data are transferred to another format or system, validation includes checks that data are not altered in value or meaning Supported Exports carry a completeness footer naming any record kind that could not be read. Archived records are covered by signed manifests whose digests are recomputed on verification, so a migrated archive can be re-verified after the move. The archive format is stable JSON, portable across PostgreSQL versions Part 11 §11.10(b); Part 11 §11.10(c) The migration plan and its verification

Operational phase

Clause Requirement Status Implementation Derived from Customer's part
5. Data Systems exchanging data electronically with other systems include appropriate built-in checks for the correct and secure entry and processing of data Implemented Every interface is catalogued with its exposure, users, reachable assets and safeguards (secure-design.md, SD-1). A system writing to the gateway authenticates with an API key confined to the MES surface, and every mutating request from any caller must carry a unique X-DCS-Nonce; the anti-replay window is per gateway replica and the chart refuses more than one replica while it is on (mes-integration.md). A measurement delivered by another system is validated against the bounds the chart author declared, recorded with the delivering system, the credential and the sample identifier, and never joined to the list of operator actions; the delivery route is fenced to machine identities, so a person cannot file a value without a signature. MES integration follows the four ISA-95 categories with a documented round trip (isa95.md). OPC UA sessions support Sign and SignAndEncrypt (Basic256Sha256) with server-certificate pinning; the mode is declared per IOModule, an unresolvable posture is refused and no default is supplied (ADR 0057), and SignAndEncrypt is the posture the pharma reference deployments run. The product does not prohibit None or Sign where a site declares them Part 11 §11.10(h); Part 11 §11.200 (the machine-identity decision); MES integration guide; IEC 62443 matrices The interface specification with each connected system, its validation, and the security mode declared for each field device
6. Accuracy checks For critical data entered manually there is an additional check on the accuracy of the data, by a second operator or by validated electronic means Implemented The electronic check: a manual entry through an operator prompt is bounded to its declared range server-side and refused outside it, the runtime re-validates on delivery so a response injected past the gateway cannot resume the phase (ADR 0017), the entry carries an HMAC electronic signature with a required reason, and a choice prompt accepts only the authored options. The decision whether a second-person check is also required is the customer's, and the role model supports it: the prompt response can be gated to a role the deployment names Part 11 §11.10(f); Part 11 §11.50 Identifying the critical manual entries and choosing the check
7.1 Data storage: security and access Data are secured by physical and electronic means against damage, and stored data are checked for accessibility, readability and accuracy, with access maintained throughout the retention period Implemented Two-tier retention with signed archive manifests, scheduled archive re-verification every six hours by default, and an optional immutable Object-Lock mirror. The re-verification writes its own AuditRecord per run, so the accessibility check leaves a trail. Drilled 2026-04-22 (archive-corruption-drill-20260422.md) Part 11 §11.10(c) Physical security of the infrastructure, and the retention periods
7.2 Data storage: backups Regular backups of all relevant data, with the integrity and accuracy of backup data and the ability to restore checked during validation and monitored periodically Implemented Application-level backups of custom resources and audit records through dcs backup, continuous WAL shipping of the historian to object storage where a CNPG ScheduledBackup is configured, and platform snapshots of cluster state (backup-recovery.md). dcs backup exports custom resources only: secrets and signing keys are excluded from its sets by design and are re-provisioned on recovery, so a restored backup never reintroduces old key material. An etcd snapshot is a different backup set and does capture secrets, and the recovery documentation says so. A backup-and-restore drill on 2026-07-18 verified pre-restore tamper and truncation detection and caught a restore-path defect (backup-restore-drill-20260718.md) Part 11 §11.10(c); backup and recovery documentation Operating the backups and the periodic restore tests
8.1 Printouts Clear printed copies of electronically stored data can be obtained Implemented The batch production record renders section by section in the UI and exports as JSON or BatchML XML. The audit trail exports as JSON or CSV with the record order preserved in the export Part 11 §11.10(b) The printing and distribution procedure
8.2 Printouts for batch release For records supporting batch release, printouts indicate whether any data have been changed since the original entry Implemented The batch record carries its own change history, including a mid-batch control-logic change with the before and after hashes and the operator's justification. A ChangeRequest renders the semantic diff from the review-time base. The finalised record is write-once, and any later change is a new signed record Part 11 §11.10(e); Part 11 §11.10(k) The batch-release review procedure
9. Audit trails A system-generated audit trail records all GMP-relevant changes and deletions, the reason for a change is documented, audit trails are available and convertible to a readable form, and they are regularly reviewed Implemented Every record carries who, what, when and why. A reason is required at every signing ceremony and at every command ceremony. Deletion of a record is refused until it is attested as archived, and the attestation is verified cryptographically. Refused mutating actions are recorded. The trail is convertible to JSON or CSV and is queryable across active and archived tiers as one stream that says which halves it reached. The regular review is the customer's Part 11 §11.10(e) The regular review of the audit trail, on the cadence the customer sets
10. Change and configuration management Changes to a system, including configuration, are made in a controlled manner under a defined procedure Implemented (deployment-opt-in) The ChangeRequest workflow runs propose, approve and merge with verified signatures and refuses self-approval. The admission webhook gates control-program writes in production namespaces behind an allowlisted service account, an external reference and a signed approval. Out-of-band changes are detected, reverted and recorded with the foreign writer named. Enforcement is off in shipped defaults and binds only namespaces the deployment labels as production, exactly as the Part 11 row states Part 11 §11.10(k) Enabling the enforcement, and the change-control procedure it implements
11. Periodic evaluation Systems are periodically evaluated to confirm they remain in a valid state and compliant with GMP, covering functionality, deviations, incidents, problems, upgrade history, performance, reliability, security and validation status Supported The IQ compares the running system to the approved baseline and detects drift between runs, so re-running it is the periodic evaluation of installed state. The archive verifier runs on an interval. The supplier's own periodic reviews are defined in the SDL audit file, and the first instances of two of them are open gaps stated there Part 11 §11.10(a); SDL audit file The periodic review itself and its record
12.1 Security: physical and logical controls Physical and logical controls restrict access to authorised persons, by keys, pass cards, personal codes, biometrics or restricted access to equipment and storage areas Implemented Authentication through the customer's identity provider, group-claim authorisation against the cumulative role hierarchy, Kubernetes RBAC on the control plane, and NetworkPolicies enforcing the IEC 62443 zone and conduit model. Logical controls only Part 11 §11.10(d); IEC 62443 matrices Physical access controls, and identity-provider configuration
12.2 Security: extent The extent of security controls depends on the criticality of the system Supported The IEC 62443 matrices state a capability target per foundational requirement, and security-hardening.md says what the shipped defaults are and what the operator must add to reach the stated level IEC 62443 matrices; security hardening guide Choosing the target security level for the site
12.3 Security: authorisation records Creation, change and cancellation of access authorisations are recorded Partial Three kinds of authorisation exist and they are recorded differently. Human role membership is held in the customer's identity provider (ADR 0005), which records its own changes; the product holds no store of human users. Machine identities are MES API keys, and their creation and revocation each write an AuditRecord naming the creator or revoker. The change-control policy and its allowlist are gated by the same signed change control they enforce, so a change to who may write is itself an approved, audited change, in a deployment with enforcement on. The gateway roles file, which maps role names to permission tiers and per-action allow and deny, is deployment configuration loaded at startup and has no in-product signed-change gate; a change to it is a change to the deployment's values, recorded wherever the deployment records those Part 11 §11.10(k); Part 11 §11.10(g) The identity provider's change log and its review, and change control over the deployment's values
12.4 Security: identity on data entry Management systems for data and documents record the identity of operators entering or confirming critical data, and any alteration to an entry is authorised and recorded with the reason Implemented Every entry and every confirmation carries the authenticated identity. Alterations are new signed records with a required reason, since records are write-once Part 11 §11.10(e); Part 11 §11.50 The definition of critical data at the site
13. Incident management Incidents are reported and assessed, and the root cause of a critical incident is identified and forms the basis of corrective and preventive actions Supported The product's defect-management procedure covers intake from every source, a published acknowledgment window of 72 hours, CVSS severity adjusted for the operational-technology context, root cause recorded on the tracking issue and evaluated for a preventing gate, and disclosure through a security advisory. Operationally, a dropped audit record is never silent: it is counted on dcs_audit_record_failures_total, the chart ships a critical alert on any non-zero rate, and the alert carries its runbook link (security-operations.md) SDL audit file; monitoring documentation The customer's incident procedure, and the alerting configuration
14. Electronic signature Electronic records may be signed electronically, and the signature has the same impact within the company as a handwritten signature, is permanently linked to its record, and includes the time and date Implemented Signatures carry signer, printed name, time, meaning and an HMAC digest bound to the record content. The signature is stored inside the immutable record. The signing ceremony manifests the meaning before the act Part 11 §11.50; Part 11 §11.70 The company policy that gives the signature its internal standing
15. Batch release Where a system is used to record certification and batch release, it allows only qualified persons to certify release, and clearly identifies and records the person releasing or certifying, using an electronic signature Partial The batch record's review signature, meaning quality-review, is gated at the supervise permission, which the shipped role table grants to the supervisor and admin tiers, and records signer, name, time and digest. A deployment may define a role of its own name and grant it the review action alone, so who may sign is configurable. What is not: the record carries one review signature with one product-fixed meaning, approval collapses review and finalization into one act by one signer, and nothing can sign a Finalized record. The product does not claim to be the batch-certification system. The certification of a batch by a Qualified Person under Article 51 is a step in the customer's quality system, and a site that records that decision in the product does so with the review signature, which cannot be told from a quality review by its meaning (#2158) Part 11 §11.10(g); Part 11 §11.50 The batch-release procedure and where the QP certification is recorded
16. Business continuity For systems supporting critical processes, provisions ensure continuity of support in the event of a breakdown, and the alternative arrangements are documented and tested Implemented A unit runtime that loses the control plane runs its armed holding sequence at the edge, the active phase's holding chart or the unit's declared safe-state baseline (ADR 0008), wherever such a chart is declared and the node is alive, and its outputs do not freeze at last value there. A unit that declares no safe-state chart, and a node that dies outright, fall back to device fail-safe or last value by design. A failed controller fails over to a standby node, automatically in Failover mode and by an operator's confirmed command in the default Autonomy mode, with the control gap and the data gap disclosed in the batch record. The failure-mode analysis with measured recovery times, the failover runbook and the disaster-recovery runbook are published, and three disaster-recovery drills are recorded in this directory with their outcomes. The high-availability drill campaign behind the measured recovery times is recorded in the bench deployment repository and cited from ha-failure-modes.md HA and failure-modes documentation; DR runbook; drill logs The site's business-continuity plan and its periodic test
17. Archiving Archived data are checked for accessibility, readability and integrity, and if relevant changes are made to the system the ability to retrieve the data is ensured and tested Implemented Signed archive manifests, scheduled re-verification, and a stable JSON archive format portable across database versions. The restore path from a corrupted archive was drilled on 2026-04-22 with a signed qualification record Part 11 §11.10(c) Retrieval testing after the customer's own system changes

The 2025 draft revision

The European Commission published a draft revision of Annex 11 for public consultation in July 2025. It adds explicit expectations on cloud services, cybersecurity and artificial intelligence, and it states that responsibility for compliance stays with the regulated company even where a service is outsourced. This matrix will be re-issued against the revised text when it is adopted. Three properties of the product bear on the draft's direction and are stated now so a reader can judge them.

  • Nothing is outsourced to the supplier at runtime. The product runs on the customer's infrastructure and no customer data reaches the supplier. The cloud-service clauses of the draft apply to the customer's own platform. There is no supplier-hosted service for them to apply to.
  • Cybersecurity is assessed against IEC 62443. The system matrix, the component matrix and the development-lifecycle assessment are clause-verified against the purchased standard text, with the capability target and the conditional rows stated.
  • AI engineering agents are developer tooling. Their output lands as attributed commits under the same gates and the same review as any other change, and they hold no standing as persons. The product itself contains no machine-learning component that participates in control or in record keeping.

Gap Analysis

Every status below Implemented in the tables above appears here.

Gap Clause Priority Description
Category 5 boundary 4.6 Low Category 5 work is possible by forking the product, and the customer would own its documentation. Closes by staying on the configuration surface; gamp5.md draws the boundary
Change-control enforcement 10 Low Enforcement over control logic is off in shipped defaults and is enabled per deployment, as the Part 11 §11.10(k) row states
Authorisation-change records 12.3 Medium Human authorisation changes are recorded by the identity provider and not by the product. The gateway roles file has no in-product signed-change gate; a change to it is recorded wherever the deployment records changes to its values
Batch certification signature 15 Medium The batch record carries one review signature with one product-fixed meaning, and nothing can sign a Finalized record, so a QP certification recorded in the product cannot be told from a quality review. Tracked in #2158, which may close with the product position that it is not the batch-certification system
Inherited from Part 11 5, 6, 12, 14 Medium Two-factor enforcement is delegated to the identity provider (§11.200(a)(1) Partial), and identification-code and password controls are Planned (§11.300(a-b)). See the Part 11 Gap Analysis