---
title: "Annex 11 V4: What Is Changing, and What Your Company Might Have Skipped"
description: "EU GMP Annex 11 V4 is expected summer 2026. See what's changing from the 2011 version and which good practices your company may have skipped."
url: https://qbdgroup.com/en/blog/annex-11-v4-changes-what-companies-skipped
type: "Blog post"
language: en
published: 2026-06-30
author: "Jan Appelmans"
category: "Software Solutions & Services"
publisher: "QbD Group"
citation: "QbD Group, \"Annex 11 V4: What Is Changing, and What Your Company Might Have Skipped\", https://qbdgroup.com/en/blog/annex-11-v4-changes-what-companies-skipped"
---
# Annex 11 V4: What Is Changing, and What Your Company Might Have Skipped
> EU GMP Annex 11 V4 is expected summer 2026. See what's changing from the 2011 version and which good practices your company may have skipped.

The revised EU GMP **Annex 11 grew from roughly 4 pages of vague text to around 19 pages of detailed expectations**. The biggest shift is not a new rule — it is a change in status: industry good practice is becoming regulation.

The European Commission has been working on revising Annex 11 of the EU GMP guidelines for quite some time. The reasons are clear. The sector is changing at incredible speed, where information can feel outdated by the time you read it, while the regulation still dates back to 2011.

Just for perspective: 2011 is when people walked around with an iPhone 4 in their pocket, the Fukushima nuclear disaster happened, and quite a few of today's C​SV practitioners had not yet finished high school. You could say it was time to bring this up to date.

At QbD Group, we have followed these developments closely throughout and have tried to update you regularly along the way. **The final version is expected in summer 2026.** At the time of writing, the exact publication date and any final adjustments to the last draft are not yet confirmed. It is expected that there will be an adjustment period to adhere to this revision, but this is not confirmed at this point.

## The road to Annex 11 V4

| Date | Milestone |
|---|---|
| **2011** | Annex 11 V3 enters into force. Roughly 4 pages. Broad, principle-based guidance for computerised systems. |
| **Nov 2022** | Concept paper published. The Commission sets out the scope of the planned revision. |
| **Jul 2025** | Draft released for consultation. Draft Annex 11, new Annex 22 (AI) and revised Chapter 4 issued together. |
| **Oct 2025** | Public consultation closes. Industry comments submitted for review. |
| **Summer 2026** | Final V4 expected (date to confirm). Around 19 pages. Detailed, actionable, non-negotiable expectations. |

*The revision has been signalled for years. The content of V4 should come as no surprise.*

## From good practice to enforced by regulation

The update of Annex 11 was carried out together with representatives from the sector. That is why it is very much driven by the industry itself, and why it has become clearer, more actionable, and non-negotiable compared to before.

When we look at the difference between what was expected before and what will be expected, one thing stands out. What used to be seen as good practice — the way to achieve high levels of control and confidence in systems — is becoming **obligatory**.

> **Key takeaway:** For companies that already apply these good practices, the impact will be minimal. For companies that, in these times of cost-driven decision making, have been neglecting them, the impact can be extensive and overwhelming.

The clearest way to see the scale of the change is side by side. The intent of each chapter often stays the same. **What changes is the level of detail and, with it, the level of expectation.**

## V3 (2011) compared with V4 (expected 2026)

| Area | Annex 11 V3 (2011) | Annex 11 V4 (expected 2026) |
|---|---|---|
| **Audit trail review** | Audit trail required. Review expected but lightly framed. | Emphasis on the review. Every user can access, sort and search the trail. The review must be proceduralised. |
| **Outsourcing and ownership** | Responsibilities between regulated user and supplier left open in practice. | Section 2.6 is explicit. The regulated user owns adherence, evidence and regulatory review. |
| **Data integrity and interfaces** | ALCOA+ applies. Limited detail on data moving between systems. | Interfaces must be validated. Attention to data transformation when systems are connected. |
| **Periodic review** | Around 4 lines on the topic. | More than 8x longer. Detailed enough to serve as the chapter titles of your review report. |
| **Security** | Around 8 lines. Focused on the system itself. | Around 2 pages. Expectations span the entire IT infrastructure, not just CSV. |
| **Alarms** | Not addressed as a distinct topic. | A whole new chapter. Around a full page, with an automation perspective and a periodic review of alarms. |

*Page and line counts are approximate, based on the latest draft.*

## What you might have skipped before

With our clients, we regularly encounter **activities that get skipped**, mostly for cost or time reasons. Under the previous Annex 11, several of these were not specifically mentioned, so quite a few teams took the risk. The sections below focus on the activities that become obligatory once V4 is published, and that we most often see skipped or turned into points of attention.

| Often skipped under V3 | Becomes obligatory under V4 |
|---|---|
| Audit trail review without a real procedure | Proceduralised, searchable audit trail review |
| SaaS audit trail access limited to admins | Audit trail access and search for every user |
| Responsibility left with the supplier | Regulated user owns evidence (Section 2.6) |
| Disaster recovery plan not tested | Tested recovery plan with a defined RTO |
| Interface validation between systems | Validated, controlled system interfaces |
| Alarm logging and review not enforced | Logged alarms with periodic review |

*The pattern is consistent: what was optional becomes expected, documented and evidenced.*

## Audit trail and audit trail review

The need for an **audit trail** is not new, and neither is the **audit trail review**. In the update, the emphasis is placed firmly on that review. In a landscape where SaaS systems are on the rise, the way you accommodate the review may be a point of attention. The expectation is that each user can access the audit trail and can sort and search it, inside the system or outside it via export. Many systems limit audit trail access to administrators only and **do not offer easy filtering or sorting**. It is also expected that you have proceduralised how and when the review takes place.

## People and cooperation

At first this seemed like an odd chapter to me. It felt obvious that, when needed, there should be **good collaboration between all stakeholders**. Then I asked myself why it was included at all. I have my own answer, and I think you should ask yourself the same question about the company, project or team you are working in.

## Ending the ownership discussion

More and more SaaS systems are in use, often running on servers owned or rented by the supplier. When it comes to who is responsible for what, we regularly hear two arguments. From the customer side: the software provider is responsible for activities like back-up, restore and safety. From the provider side: we are not a regulated company, so we do not need to comply with pharma regulations. This often leaves it unclear who is responsible, and creates a real risk that nobody takes ownership of certain areas.

Section 2.6 of the revised Annex 11, on outsourced activities, now states clearly that the **regulated user is responsible for adherence to the requirements**, for maintaining the evidence, and for providing it for regulatory review. So it will no longer be enough to say the supplier is responsible, without having controls and evidence in place that those activities are actually performed.

## Data integrity and data handling

It will come as no surprise that the **ALCOA+ principles** still apply. What has changed is the emphasis on how data is handled when it is transferred between systems, or, better said, interfaced between systems. The importance of these interfaces grows the more we connect systems. When we think about Pharma 4.0, it is all about these interfaces, and the intent of Annex 11 is to have them validated. When data moves from one system to another, transformations such as format changes may be needed to make the systems speak to each other, so attention must be given to how that data is manipulated.

## From periodic evaluation to periodic review

**Periodic review has seen a significant upgrade**. Where V3 dedicated only about 4 lines to the topic, V4 increases that by more than a factor of 8. The intent stays the same: making sure the system remains in a validated state and, although not stated explicitly in V3, fit for purpose. V3 left questions open on how this should be done. V4 answers them with so much detail that you can almost copy it straight into your periodic review report and use it as the chapter titles. The key takeaway: to run these reviews without turning them into a resource-heavy exercise with little benefit, look at how your organisation is structured and make it as efficient as possible.

## Security

This chapter has also seen a **major update**, growing **from about 8 lines to roughly two pages**. V3 left room for interpretation and focused mainly on the computerised system itself. V4 sets clearer expectations for the whole organisation. For some organisations, Annex 11 was mainly something for C​SV. With the revised security chapter, the scope broadens to expectations that span the entire IT infrastructure and its security. This blurs the line between validating a specific system and managing an IT infrastructure.

What we regularly see skipped here is the disaster recovery plan, and the testing of that plan, often for the practical reason that it is hard to say how it can be tested for a specific system. V4 adds a KPI on this topic, the Recovery Time Objective (RTO): how long it takes to recover from a foreseeable event such as storms, flooding, water leaks, earthquakes, fires, power outages and network failures.

## A whole new chapter

I did not mean that as a metaphor for dramatic effect. There is genuinely a whole new topic in this update. **An entire page is dedicated to alarms and everything related to them**, and the content shows a strong influence from an automation perspective. It seems obvious that when something goes wrong, the system should clearly warn users, and that the user should play an active role by acknowledging the alarm. It also seems obvious that these alarms and the related activities are logged in line with ALCOA+. Yet this was not enforced before, or at least not clearly. And, as you might expect by now, a periodic review of these alarms also becomes applicable.

## Conclusion

Even though the update to Annex 11 is extensive, the content does not come as a surprise. It enforces industry-wide, tried and tested ways of working to achieve and maintain confidence in the safe use of computerised systems across the entire lifecycle. **For teams that already work this way, V4 is a confirmation. For teams that have been cutting corners, it is a clear signal that the corners are no longer there to cut.**

**Need help getting your computerised systems Annex 11 V4 ready?**
Our team supports you with C​SV, system validation and audit trail setup, so the transition from good practice to compliant practice does not have to start from scratch. [Get in touch](https://qbdgroup.com/en/contact) with our software solutions team.
---
Source: https://qbdgroup.com/en/blog/annex-11-v4-changes-what-companies-skipped — © QbD Group. Quote freely with attribution and a link back.