EU GMP Annex 11 makes supplier responsibility a formal record

A supplier relationship is part of the system boundary

Annex 11 does not treat the application as an isolated software object. Its supplier provision covers third parties that provide, install, configure, integrate, validate, maintain, modify, retain, or process data for a computerised system. The operating record therefore needs to identify the service, system component, GMP function, data, access, environment, responsible parties, and lifecycle stage—not simply the software vendor named on a contract.

Formal responsibility statements matter because several parties can influence the same regulated record. A software provider may maintain code and hosting, an implementation partner may configure workflows, an internal IT group may administer access, and the regulated process owner may approve intended use and procedures. A generic shared-responsibility label is insufficient if reviewers cannot see who performs, approves, verifies, and retains evidence for each material activity.

Provider documentation begins the review; it does not finish it

The Annex says documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled. That creates a precise evidence boundary. Official product material can establish what a provider documents for a named release or service. It cannot establish the customer's intended use, configured behavior, integration results, procedural controls, data quality, or continuing validated state.

A requirements record should trace each GMP-relevant function to source, risk rationale, configuration, test evidence, deviation, acceptance, and accountable approval. Buyers should also record what is standard product behavior, what is configured, what is custom, what depends on another service, and what remains unverified. Broad claims such as Annex 11 ready should not replace that version- and use-specific chain.

The evidence must survive change and operation

Annex 11 carries the record beyond initial validation. It calls for controlled changes, periodically evaluated systems, recorded access changes, incident assessment, continuity arrangements, and accessible, readable, integral archives. Supplier releases, infrastructure changes, integration updates, security changes, data migrations, and service incidents can each alter evidence that supported the earlier decision.

A credible system should show which open and historical records are affected by a change, who assessed GMP impact, how testing was selected, which deviations arose, who approved release, and how the prior configuration remains reconstructable. Periodic evaluation should draw on current functionality, deviations, incidents, upgrade history, performance, reliability, security, and validation status rather than becoming a calendar task with no connected evidence.

What a regulated-system buyer should test

The demonstration should follow a representative GMP record through configuration, entry, review, electronic signature where applicable, audit trail, correction, retention, export, and restoration. Then introduce a supplier release and an integration change. The provider should show responsibility assignment, impact assessment, traceable requirements, test selection, exception handling, access control, business continuity, archival retrieval, and the evidence available to an inspector.

Annex 11 is GMP guidance for computerised systems; it does not certify a product, validate a customer's implementation, or prescribe one architecture. RegQuality Review treats provider documentation as evidence of documented capability only. Qualified quality, validation, regulatory, information-security, legal, and process owners remain responsible for interpreting applicability and deciding whether the configured system and operating controls are adequate.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

RegQuality Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.