Annex 11 Revision Readiness: A Gap Assessment Template

Where the Annex 11 Revision Actually Stands

Getting the status right matters, because a gap assessment built on a wrong assumption about timing produces the wrong sequencing. Here is what can be established from primary sources.

The revision was recommended jointly by the EMA GMP/GDP Inspectors Working Group and the PIC/S Committee, and a concept paper setting out the reasons went out for public consultation in November 2022.⁷⁸ The draft guideline itself was released on 7 July 2025 as part of a package of three linked documents: a revised Chapter 4 on documentation, the revised Annex 11 on computerised systems, and an entirely new Annex 22 on artificial intelligence. The consultation was run jointly by the European Commission and PIC/S and closed on 7 October 2025.¹⁶

Since then, the drafting group has been working through the responses. At the 2026 ISPE European Annual Conference in April 2026, the EMA reported that roughly 2,900 comments on Annex 11 had been classified, with the detailed review still to follow and completion of that review expected over the summer.¹⁰ Comment review on Chapter 4 and Annex 22 was further along.

The EudraLex Volume 4 index remains the plainest test of status, and it still lists “Annex 11 Computerised Systems (revision January 2011)”.⁴ Nothing has replaced it. The concept paper’s own proposed timetable had the European Commission publishing the final text in June 2026 and PIC/S adopting it in September 2026, but that schedule was built on a consultation opening in December 2024. The consultation actually opened seven months later than planned, and the published timetable has moved with it.

We covered the shape of the whole package, including Annex 22 and the AI provisions, in a separate piece: Annex 11 and Annex 22 Revisions: Preparing GxP Systems for EMA’s New AI and Data Integrity Rules. This article does something narrower and more useful: it turns the Annex 11 draft into an assessment a team can run next week.

What Genuinely Changed: Six Areas Where the Draft Moves

A useful gap assessment does not walk all 111 clauses with equal weight. Most of the draft restates principles you already meet or already know you owe. The assessment should concentrate where the text genuinely moves, and where the 2011 wording was permissive enough that reasonable organizations landed somewhere the draft would not accept.

The 2011 Annex 11 was written before mainstream cloud hosting, before software as a service was normal in regulated manufacturing, before continuous delivery, and before data lakes. Its supplier section runs to four sentences, its audit trail section to one paragraph, and its periodic evaluation section to two sentences.³ Those three sections are where most of the new length went.

1. Supplier and service provider oversight becomes an operating requirement

In 2011, the requirement was that “formal agreements must exist” with third parties, that the need for an audit “should be based on a risk assessment”, and that supplier quality and audit information be made available to inspectors on request.³ The draft turns this into a full section covering responsibility, audit or thorough assessment, ongoing oversight against service levels and performance indicators, documentation accessibility from your own facility, and a list of nine things the contract must address, including an exit strategy that lets you retain control of your data and a defined process for testing new system versions before release.²

2. Data integrity stops being implied and becomes explicit

The draft names data integrity in its principles, ties it to ALCOA+, and points to the specific sections that carry it: handling of data, identity and access management, audit trails, electronic signatures, and security.² It also asks that quality risk management be used to assess data criticality, the vulnerability of data to alteration or deletion, and the likelihood that such changes would be detected. That last element, detectability, is the one most data integrity assessments skip.

3. Criticality and risk move from a validation gate to a lifecycle discipline

The 2011 text applied risk management to the lifecycle in one paragraph and used it mainly to size validation effort. The draft applies quality risk management across all lifecycle phases and asks that the risk outcome drive the choice of system architecture and functionality, not just the depth of testing.² That is a different question asked at a different point in a project.

4. Audit trail review becomes a defined activity with named attributes

This is the single largest change by weight. The 2011 text asked that audit trails be “regularly reviewed” and left it there. The draft asks for a documented procedure for the specific system or type of system, stating who reviews, what is reviewed, and when; targeted risk-based scope rather than reading every entry; review by personnel not directly involved in the activity under review; review before batch release unless a later review can be justified; and documented action following the review.²

5. Periodic review gets a defined scope

Where 2011 asked for periodic evaluation covering functionality, deviations, incidents, upgrade history, performance, reliability, security, and validation status, the draft lists twelve items, including the combined effect of multiple changes across systems, identification of undocumented changes through configuration auditing, the conduct of audit trail and access reviews, supplier contracts and performance indicators, restore test adequacy, and changes to regulatory requirements.²

6. Configuration and customization are separated and both must be traceable

The draft asks that it be clear what functionality is modified or added by configuration, that configurable options appear in the requirements specification, and that the chosen configuration be captured in a controlled configuration specification. Qualification and validation must address standard functionality, configured functionality, and anything realized through customization, and test cases that do not trace to a requirement or specification are stated not to meet the requirement at all.²

How to Run the Gap Assessment

Before the table is useful, the assessment needs a scope, a unit of analysis, and an evidence standard. Teams that skip these three decisions end up with a spreadsheet of opinions.

Who should be in the room

The draft itself asks for close cooperation between the process owner, system owner, users, subject matter experts, QA, the Qualified Person, the internal IT department, vendors, and service providers.² A gap assessment run entirely by quality, without IT in the room, will misjudge what the systems can actually do. A gap assessment run entirely by IT will misjudge which data are critical. Both failure modes are common and both produce assessments that have to be redone.

The Gap Assessment Template

The tables below are the instrument. Each row gives the expectation drawn from the draft with its clause reference, the evidence that satisfies it, the gap most commonly found, and an indication of remediation effort. Effort is rated as Low (procedural or documentary work, weeks), Medium (procedural change plus records, plus some technical work, a quarter), or High (system change, vendor negotiation, or program-level work, multiple quarters).

Read the effort ratings as a planning aid, not a promise. The same gap can be low effort in a company with two GMP systems and high effort in a company with two hundred.

Domain A: Supplier and service provider oversight (draft section 7)

Domain B: Data integrity, handling of data, and risk (draft sections 2, 4, 10)

Domain C: Audit trails and audit trail review (draft section 12)

Domain D: Access, periodic review, and requirements (draft sections 6, 11, 14)

Audit Trail Review: Where Most Organizations Are Weakest

If you assess only one domain properly, make it this one. The pattern across sites is remarkably consistent: the audit trails exist, they are switched on, they are reasonably complete, and there is no defined review. Or there is a review, and it is a monthly exercise performed by the person who generated the data, on a report nobody can filter, with no record of what was looked at or what was concluded.

The draft is unusually specific about what a review is, and the specificity is the point. Clause 12.5 asks for a documented procedure for the specific system or type of system that states who reviews, what is reviewed, and when. Clause 12.7 says that reviewing every entry may not be effective and that reviews should instead be targeted and risk-based, focused on detecting deliberate or unintentional changes to critical processes or data, with verification of the reason a change was made described as a key element. Clause 12.8 asks that the review be conducted before batch release unless a justification exists for detecting changes later.²

What good actually looks like

The three failure modes worth naming

Reviewing everything. A high-throughput chromatography system can generate tens of thousands of audit trail entries a month. A procedure that says all entries are reviewed will not survive contact with the volume, and what actually happens is that the reviewer scans and signs. The draft explicitly says this may not be effective. Targeting is not a shortcut, it is the expectation.

Reviewing the wrong log. Systems produce audit trails, alarm logs, access logs, and general event logs, and they are frequently mixed. The draft treats them separately: alarm logs get their own periodic review under clause 8.7, access logs sit under clause 11.9, and the audit trail review under section 12 is about manual changes to data and settings. ISPE’s consultation comments asked the drafting group to distinguish these more clearly, noting the concepts are currently mixed up in the text.⁹ Until that is resolved, be explicit in your own procedures about which log is reviewed under which activity.

Reviewing without the reason. The draft calls verification of why a change was made a key element of the review. If your system does not prompt for a reason, or the reason field accepts anything, the review cannot do the work it is supposed to do. This is one of the few gaps in this domain that is genuinely a system change rather than a procedural one, and it should be raised as such.

Cloud and Supplier Oversight: What You Must Hold Yourself

The draft’s introduction names the increased use of cloud services as one of the reasons for the revision.² There is no separate cloud section. The expectations sit in section 7 on supplier and service management, in section 6 on requirements, in section 9 on qualification and validation, and in section 15 on security. The practical question for a regulated company is simple to state and hard to answer: when the software, the infrastructure, and the qualification evidence all sit with a vendor, what must you hold yourself?

Four things you must be able to produce from your own site

Clause 7.4 sets the standard plainly: documentation for the activities required by Annex 11 should be accessible and able to be explained from your facility.² That phrasing is doing real work. Accessible is not enough. Explainable from your facility means someone at your site has read it and understands it well enough to walk an inspector through it.

• An approved requirements specification you own. Clause 6.3 allows the vendor to supply the requirements specification for a purchased or as-a-service system, but asks that you review it, decide whether the system meets your GMP requirements as is or needs configuration or customization, take ownership of the document covering the implemented version, and approve and control it. ISPE argued in consultation that duplicating a vendor’s specification into the customer’s quality system creates a document that is hard to control and can introduce errors, and proposed referencing the vendor’s requirements instead where they adequately define your intended use.⁹ That is a reasonable position and it may influence the final wording, but it does not remove the need for a documented decision that the vendor’s specification is adequate for your use.
• A documented reliance decision. Clause 9.9 says third-party qualification and validation documentation may be used in part or in whole, and that the regulated user is fully accountable and should review it and authorize its use, deciding whether it must be repeated. The record you need is not the vendor package. It is the signed decision naming the version it covers and stating what you tested yourself and why.
• Evidence that you exercise oversight. Clause 7.3 asks for effective oversight against agreed service levels and performance indicators. If the vendor reports uptime quarterly and nobody reviews it, you have a contract term and no oversight.
• Terms that survive the relationship. Clause 7.5 lists an exit strategy by which you retain control of system data, and agreement on the process for releasing new system versions including your ability to test them before release. These two are missing from most software-as-a-service agreements signed before 2023, and they are the hardest to add later.

How far a vendor audit or a certification actually gets you

Clause 7.2 asks for an audit or a thorough assessment, scaled to risk and system criticality, to determine the adequacy of the vendor’s procedures and the documentation behind their deliverables, and the potential to rely on those rather than repeating the work.² Two things follow from that wording that are worth being direct about.

First, the draft allows a thorough assessment as an alternative to an on-site audit. That is a genuine and useful accommodation for hyperscale infrastructure providers who will not accept individual customer audits. It does not license you to accept a certificate without reading it.

Second, a certification is scoped, and the scope is where the answer lives. An information security certification such as those held by major cloud providers addresses the security management system. A service organization control report addresses controls at a service organization over a stated period against stated criteria, and the useful ones carry a description of the system, the controls tested, and any exceptions found.¹⁵ Registries maintained by industry bodies let you confirm what a provider has actually attested to and against which framework.¹⁴ None of these speak to whether the application configuration in your tenant matches your GMP process, whether your data are classified correctly, or whether your users hold appropriate privileges. Those remain yours.

The internal IT department is not exempt

One detail of the draft is easy to miss and lands harder than the cloud provisions in many organizations. Every clause in section 7 that applies to a service provider also applies to an internal IT department. Clause 7.5 asks for a contract with a service provider or approved procedures with an internal IT department covering the same nine topics.² Very few companies have a documented internal agreement between quality and IT that addresses reporting, response times, audit conditions, inspection support, and version release testing. Where GMP systems are operated by an internal shared services group, this is often the largest single gap in Domain A and it is invisible until someone looks for it.

Configuration, Customization, and the Requirements You Never Updated

The draft’s glossary keeps the 2011 distinction: configuration is an arrangement of functional units affecting function and performance, customization is a system individually designed to suit a specific business process.² What changes is the consequence. Clause 9.1 asks that qualification and validation address standard functionality, configured functionality, and anything realized through customization. Clause 6.6 asks that configurable options appear in the requirements specification and that the chosen configuration be captured in a controlled configuration specification.

The practical effect is that the boundary between configuration and customization stops being a classification exercise and becomes a documentation obligation. In a modern platform, most of what makes the system yours is configuration: workflows, approval steps, field definitions, calculations, report definitions, roles. If those are not described in a controlled specification, then when the vendor releases a new version and something behaves differently, you have no baseline to compare against and no way to say what changed.

This connects directly to periodic review. Clause 14.2 asks that undocumented and unapproved changes be effectively identified, giving configuration auditing as the example.² Configuration auditing means comparing the current configuration against an approved baseline. If the baseline does not exist as a controlled document, the periodic review cannot do what the clause asks. Many organizations will find that a single missing artifact, the controlled configuration specification, is what blocks compliance with three separate clauses.

Sequencing: What to Fix First and Why

No organization closes every gap at once, and pretending otherwise produces a remediation plan that stalls in month two. The sequence below is keyed to two things: current inspection exposure, and what the 2011 Annex 11 combined with existing data integrity guidance already requires. Gaps in the first category are not future work. They are open findings waiting to be written.

Wave one: gaps that already exist under the current rules

The 2011 Annex 11 already requires that audit trails be regularly reviewed, that periodic evaluation confirm systems remain in a valid state, that access authorizations be recorded, and that formal agreements exist with third parties.³ National and PIC/S data integrity guidance has expanded on all four for years, and the MHRA’s guidance in particular has set out expectations on audit trail availability and review since 2018.¹³ If you have no audit trail review procedure, no completed access review records, overdue periodic reviews, or hosted GMP systems with no agreement, those are current deficiencies. The Annex 11 revision is not what makes them a problem.

• Write the audit trail review procedure, system by system or by system type, with scope, frequency, reviewer, and record content defined.
• Bring periodic reviews back onto schedule and close the overdue population.
• Retain access review records as GMP records, not as artifacts inside an IT tool.
• Name a GMP-accountable system owner for every hosted system.
• Confirm audit trail is enabled and locked on every critical system, and document the exceptions with a risk assessment.

Wave two: gaps where the draft raises the bar and the fix is procedural

These are new or newly explicit expectations that you can meet with documentation and process change rather than system work. They can wait for the final text, but they are cheap enough to start now and there is little risk that the final text will remove them entirely.

• Build the data criticality assessment to include detectability, not only criticality and vulnerability.
• Extend the periodic review template to the twelve named areas, and add a documented frequency rationale by criticality band.
• Write the internal agreement between quality and IT covering the topics that clause 7.5 requires of a service provider contract.
• Add the documented reliance decision to your process for accepting vendor validation packages.
• Define independence for audit trail review at your site, in writing, per system type.

Wave three: gaps needing system change, vendor negotiation, or program work

These have long lead times and should be started now precisely because they will not be finished quickly. They are also the items most likely to be affected by the final wording, so scope them with a review point once the final text publishes.

• Searchable and sortable audit trail export where systems currently produce flat or locked files.
• Reason-for-change prompting where systems do not currently enforce it.
• Elimination of shared accounts on equipment-embedded systems, or a documented and time-bound control strategy where elimination is not possible.
• Configuration specifications and configuration auditing for platform systems.
• Regression test sets that let you evaluate vendor releases against your configured functionality.
• Contract amendments adding exit strategy and pre-release testing rights, which typically move only at renewal.

What May Still Change Before the Final Text

A gap assessment run against a draft carries one risk worth managing: some clauses will not survive in their current form. Around 2,900 comments were classified on Annex 11 alone.¹⁰ ISPE’s published consultation response gives a useful indication of where industry pushed hardest, and several of its objections were structural rather than cosmetic.⁹

ISPE argued as a general point that the annex should state what regulators want to see rather than describing how industry should implement it, and that describing the how risks discouraging modern practice and current technology. It asked that the pharmaceutical quality system and quality risk management material be summarized in the scope or principles rather than repeated across clauses, on the grounds that duplicating Chapter 1 content invites inconsistency over time.

On specific clauses relevant to this assessment, ISPE asked for the deletion of clause 12.6 on independent review, arguing that audit trail review is very often performed by people closely involved in testing and release, including QA, laboratory supervisors, and Qualified Persons, and that this is appropriate. It asked that data audit trails be clearly distinguished from technical logs, access logs, and other event logs, noting the concepts are mixed in the current text. It described section 14 on periodic reviews as overly prescriptive and proposed replacing clauses 14.1 to 14.3 with a short risk-based statement. It asked for the deletion of clause 7.5 on contracts, on the basis that Chapter 7 on outsourced activities already applies. And it raised the inconsistency that the Annex 11 glossary defines ALCOA+ while the draft Chapter 4 uses ALCOA++.⁹⁵

One further point of judgment. Where the draft is more prescriptive than the 2011 text and industry has argued the prescription belongs elsewhere, the likely outcome is not that the expectation disappears. It is that the expectation moves or softens in wording while inspectors continue to ask the same underlying question. Planning on the assumption that a contested clause will be dropped entirely is a bet with poor odds and no upside.

Conclusion

The most useful thing about the Annex 11 revision is not the new expectations. It is the clarity. For fifteen years, the gap between what the 2011 text said and what inspectors expected has been filled by data integrity guidance, question and answer documents, industry practice, and inference. The draft closes most of that gap by writing the expectations down in one place, at a level of detail that makes disagreement difficult. That is uncomfortable in the short term and genuinely helpful in the long term, because it lets a quality organization know what it owes.

Run the assessment now, against the draft, with a clear separation between gaps that already existed and gaps the revision would create. Close the first group on their own merits, because they carry exposure today and the final text has no bearing on them. Scope the second group, start the long-lead items, and set a review point for when the final text publishes. That approach gives you a defensible position at any point on the timeline, including the point where the final text arrives with wording nobody predicted.

Sakara Digital works with pharma and biotech organizations preparing their computerised system estates for the revised Annex 11, including gap assessments, audit trail review programs, and supplier oversight for hosted and cloud-based GMP systems. If you are working out where to start, or want an independent read on what your current evidence would actually support in an inspection, we are happy to have that conversation.

For Further Reading