EU GMP Annex 11: Computerised Systems (2011)

Context and history

Annex 11 is the part of the EU GMP Guide that deals with computerised systems. It sits in EudraLex Volume 4, the European Commission's collection of GMP rules, and it interprets the GMP principles in Directive 2003/94/EC for human medicines and Directive 91/412/EEC for veterinary medicines. PIC/S carries an equivalent annex in its own GMP Guide, so the same text is widely used outside the EU.

This version is revision 1. The Commission published it in January 2011, with a deadline of 30 June 2011 for coming into operation. It was revised because computerised systems had become far more common and more complex. Consequential changes went into Chapter 4 on documentation at the same time, so the two should be read together.

Almost every GMP site relies on it, because almost every GMP site runs validated software, from laboratory systems to manufacturing execution systems and quality management tools. It is short, at about five pages, and principle-based, which is why inspectors and companies have needed guidance such as the EMA Q&A and the PIC/S documents to apply it. A full rewrite was published for consultation in July 2025. This 2011 version keeps applying until the revision is published and comes into operation.

Who and what it applies to

All forms of computerised systems used as part of GMP regulated activities. A computerised system is defined as a set of software and hardware components that together deliver certain functions.

It applies to manufacturers of medicinal products for human and veterinary use, and in practice to everyone involved in their systems: process owners, system owners, Qualified Persons, IT and QA. Suppliers and service providers are reached through the formal agreements the manufacturer must have with them. IT departments should be treated in the same way as third parties.

What it contains

Principle

Sets the baseline: the application should be validated and the IT infrastructure qualified. Replacing a manual operation must not reduce product quality, process control or quality assurance, or increase overall process risk.

1. Risk management

Applies across the whole system lifecycle, considering patient safety, data integrity and product quality. The extent of validation and data integrity controls should rest on a justified, documented risk assessment.

2. Personnel

Requires close cooperation between process owner, system owner, Qualified Persons and IT, with suitable qualifications, access levels and defined responsibilities.

3. Suppliers and service providers

Formal agreements with clear responsibilities must exist with third parties, including IT departments by analogy. Supplier competence is key, audits follow risk, off-the-shelf documentation should be reviewed against user requirements, and supplier quality information should be available to inspectors.

4. Validation

The project-phase clause. Covers lifecycle documentation, change control and deviations, an inventory of systems, descriptions of critical systems, user requirements traceable through the lifecycle, supplier quality systems, bespoke system assessment, test evidence, and checks on data migration.

5. Data

Systems that exchange data electronically need built-in checks for correct and secure entry and processing.

6. Accuracy checks

Critical data entered manually needs an additional check, by a second operator or by validated electronic means.

7. Data storage

Data should be protected physically and electronically, and remain accessible, readable and accurate throughout retention. Back-ups should be regular, and their restoration checked in validation and monitored.

8. Printouts

Clear printed copies must be possible, and printouts for batch release should show whether data has changed since entry.

9. Audit trails

Based on risk assessment, consider a system-generated record of GMP-relevant changes and deletions. The reason for a change or deletion should be documented, and trails should be available, intelligible and regularly reviewed.

10. Change and configuration management

Changes, including configuration changes, only under a defined procedure.

11. Periodic evaluation

Systems should be evaluated periodically to confirm they remain valid and compliant, looking at functionality, deviations, incidents, upgrades, performance, security and validation status.

12. Security

Controls to restrict access to authorised persons, scaled to criticality. Access changes are recorded, and systems should record who entered, changed, confirmed or deleted data, and when.

13. Incident management

All incidents, not only failures and data errors, should be reported and assessed, with root cause identified for critical incidents.

14. Electronic signature

Electronic signatures should have the same impact as handwritten ones within the company, be permanently linked to their record, and include time and date.

15. Batch release

Only Qualified Persons should be able to certify batch release in a system, using an electronic signature, with their identity recorded.

16. Business continuity

Critical processes need documented, tested alternative arrangements for a breakdown, proportionate to risk.

17. Archiving

Archived data should be checked for accessibility, readability and integrity, and retrieval should be tested when systems change.

Glossary

Defines application, bespoke or customised system, commercial off-the-shelf software, IT infrastructure, life cycle, process owner, system owner and third party.

Key points

• Risk assessment drives everything: how much validation you do and which data integrity controls you need must be justified and documented.
• Validate the application, and qualify the infrastructure beneath it.
• Keep a current inventory of relevant systems, and a fuller description of critical systems, including data flows and interfaces.
• User requirements must be based on risk and GMP impact, and traceable across the lifecycle.
• Audit trails are risk-based here, unlike the 2025 draft, but they must capture GMP-relevant changes and deletions, with reasons, and be regularly reviewed.
• Critical manual entries need a second check.
• Back-up restoration must be proven, not assumed.
• Periodic evaluation is required, not optional.
• Formal agreements with suppliers must spell out responsibilities, and off-the-shelf software documentation still needs your review.

In practice

General reading, not advice. This is drafted with AI and may not fit your situation. It does not replace the official text, your own quality system or qualified advice, and an inspector may take a different view.

• Start with the inventory. Inspectors commonly ask for it, and it drives risk assessment, validation scope and periodic evaluation.
• Show the reasoning behind your risk assessment, not only its result. A score with no rationale is hard to defend.
• Decide who reviews audit trails, how often and what they look for, and record that review in your procedure.
• Test back-up restoration on a schedule, and keep the evidence.
• Treat your cloud and SaaS providers as third parties: agreements, responsibilities and audit evidence should exist before go-live.
• Do not wait for the revision to fix known gaps, but do read the 2025 draft when planning new systems, as it signals where expectations are heading.

Read from the source document on 1 Nov 2026. This is our own description, not the official text. Check the full dated history in the change log below.