Annex 11 Entwurf 2025: Was sich ändern soll und was Sie heute prüfen können

1. Geltende Fassung, Entwurf und Arbeitsplan unterscheiden

Die Konsultation zum überarbeiteten Annex 11 lief gemeinsam mit Kapitel 4 und Annex 22 vom 7. Juli bis 7. Oktober 2025. Der Entwurf ist in der offiziellen Konsultationssammlung verfügbar. Die geltende Leitlinienübersicht führt für Humanarzneimittel weiterhin die Revision Januar 2011, deren Anwendungsbeginn der 30. Juni 2011 war.

Im EMA-Arbeitsplan 2026–2028 steht Q4 2026 als Ziel für einen finalen Text an die Kommission. Die Planung bestätigt keinen bereits verabschiedeten neuen Annex und keine zusätzliche Übergangsfrist. In einer Gap-Bewertung sollten die verwendete Fassung, das Prüfdatum und der Status jeder vermeintlich neuen Anforderung deshalb ausdrücklich stehen.

Quellen: [1] [2] [4] [3]

2. Ausgewählte Veränderungen richtig lesen

Der Entwurf ordnet viele Themen detaillierter und ergänzt ausdrückliche Bezüge etwa zu PQS und Sicherheitsmanagement. Dennoch beginnt der Lebenszyklusgedanke nicht erst mit dieser Revision. Risikomanagement, nachvollziehbare Anforderungen, Lieferantenbewertung, Änderungen, Zugriffe und regelmäßige Bewertung gehören bereits zur Fassung 2011.

Die folgende Matrix zeigt ausgewählte Anker. Sie ist kein vollständiger Wortlautvergleich und keine verbindliche Checkliste sämtlicher Pflichten. Für einen konkreten Befund zählt die tatsächliche Kontrolle, nicht allein die Frage, ob ein Dokument schon den neuen Kapitelaufbau verwendet.

Quellen: [4] [5]

3. Anforderungen an die heutige Nutzung zurückbinden

Eine alte URS kann noch gültige Anforderungen enthalten. Problematisch wird es, wenn Erweiterungen, Schnittstellen oder abweichende Betriebsweisen in keinem kontrollierten Soll erscheinen. Beginnen Sie bei den Entscheidungen, die das System unterstützt: Welche Eingabe wird übernommen, welcher Status verändert sich und welcher Nachweis wird später benötigt?

Der Entwurf beschreibt Anforderungen unabhängig von SaaS-Betrieb oder Entwicklungsmodell und verbindet sie mit Gestaltung und Prüfnachweisen. Auch eine Lieferanten-URS braucht Bewertung für den konkreten Einsatz. Eine praktikable Vorbereitung ist eine kleine Zuordnung je kritischer Funktion: aktuelle Anforderung, Konfigurationsstand, passender Test und bekannte Einschränkung. Fehlende Zuordnung und nachgewiesener Funktionsfehler sind dabei unterschiedliche Befunde.

Quellen: [4] [5]

4. Lieferantenbelege auf ihre tatsächliche Reichweite prüfen

Cloudbetrieb ändert die Verteilung von Aufgaben, nicht die Notwendigkeit einer nachvollziehbaren Zuständigkeit. Schon die Fassung 2011 verlangt geeignete Vereinbarungen und eine risikobezogene Lieferantenbetrachtung. Der Entwurf macht Steuerung, Leistungsüberwachung und Zugang zu erklärbaren Unterlagen ausführlicher sichtbar.

Fordern Sie deshalb nicht pauschal das gesamte Entwicklungsarchiv oder stets ein Vor-Ort-Audit. Klären Sie zunächst, welche Leistungen kritisch sind, welche Versionen die Unterlagen betreffen und welche Fragen offenbleiben. Ein geeigneter Herstellerbeleg kann eine konkrete Anforderung stützen. Er bestätigt nicht automatisch kundenspezifische Rollen, Schnittstellen oder Prozessentscheidungen, die außerhalb seines geprüften Umfangs liegen.

Quellen: [4] [5]

5. MFA und Sicherheitsmanagement nicht aus dem Kontext lösen

Der Entwurf nennt MFA für die Fernauthentifizierung an kritischen Systemen von außerhalb kontrollierter Bereiche. Daraus sollte kein Satz werden, Annex 11 verlange heute ausnahmslos MFA an jedem Arbeitsplatz. Ebenso wenig bedeutet der Entwurfsstatus, bekannte aktuelle Sicherheitsrisiken bis zur Revision unbearbeitet zu lassen.

Prüfen Sie für Ihren Einsatz Identitäten, privilegierte Zugriffe, tatsächliche Angriffswege, verfügbare Unterstützung und Wiederherstellung. Ein Sicherheitszertifikat ist dabei ein möglicher Beleg mit definiertem Scope. Es beantwortet nicht automatisch, ob ein ausgeschiedener Benutzer im eigenen Mandanten noch eine qualitätsrelevante Freigabe auslösen kann. Genau diese Verbindung zwischen technischer Kontrolle und Prozessfolge macht eine Bewertung nützlich.

Quellen: [4] [5]

6. Eigener Arbeitsfall: eine Änderung mit vier verschiedenen Entscheidungen

Illustratives Beispiel, kein Kundenprojekt: Ein elektronisches Dokumentensystem hat zwölf festgelegte Anforderungen. Acht sind anhand passender aktueller Belege nachvollziehbar erfüllt. Zwei betreffen inzwischen ergänzte Rollen, eine den getesteten Wiederanlauf und eine eine bisher nur im Entwurf ausdrücklich betrachtete Zugriffskonstellation. Das Team zählt somit vier offene Bewertungspositionen, nicht automatisch vier heutige Verstöße.

Die zwei Rollenthemen und der Wiederanlauf werden gegen heutige Nutzung und geltenden Rahmen bewertet. Die vierte Position erhält einen eigenen Status Entwurfsvorschlag. Wenn ein konkretes Sicherheitsrisiko besteht, kann eine Maßnahme trotzdem heute notwendig oder sinnvoll sein; diese Begründung muss dann aus dem Risiko folgen. Eine Prozentzahl allein würde diese Unterscheidung verschleiern.

Nach Bearbeitung der beiden Rollenpositionen sind zehn von zwölf Bewertungspositionen geschlossen. Die Quote 83,3 Prozent ist lediglich ein Arbeitsstand. Solange der benötigte Wiederanlauf ungeklärt ist, sagt sie nichts über die Vertretbarkeit des Betriebs. Das Team dokumentiert deshalb Entscheidung und Befund je Position.

Quellen: [4] [5]

7. Maßnahmen in den Lebenszyklus übernehmen

Eine Vergleichstabelle ist erst dann hilfreich, wenn Entscheidungen umgesetzt werden. Ordnen Sie jeder Änderung einen Verantwortlichen, betroffene Anforderungen, erforderliche Nachweise und einen Abschlussentscheid zu. Der Prüfbedarf kann auch unveränderte verbundene Funktionen betreffen, wenn die Änderung deren Verhalten beeinflusst. Umgekehrt können passende bestehende Belege begründet gültig bleiben.

Die regelmäßige Bewertung sollte diese Informationen zusammenführen: Änderungen, relevante Vorfälle, Lieferantenlage, Sicherheitsfragen und fortbestehende Eignung. Der Entwurf spricht eine risikobezogene Reviewfrequenz ausdrücklich an. Er liefert keinen universellen jährlichen Rhythmus, der die Betrachtung Ihres Systems und seiner tatsächlichen Veränderungen ersetzt.

Quellen: [4] [5]

8. Eine kompakte Vorbereitung für QA und IT

Beginnen Sie mit einem wichtigen Ablauf und seinen vorhandenen Unterlagen. Dadurch wird sichtbar, ob das Problem im Regelwerksverständnis, in fehlender Dokumentation oder in einer unwirksamen Kontrolle liegt. Ein kleines Team braucht dafür klare Mitwirkung des Prozesseigners und Zugriff auf relevante IT- und Lieferanteninformationen.

Die folgende eigene Checkliste verhindert, dass das gesamte Framework vorschnell nach einem Entwurf umbenannt wird. Sie kann zugleich vorhandene Verbesserungen bündeln, die unabhängig von der späteren Textfassung nützlich bleiben.

• Aktuelle Fassung und Entwurf eindeutig kennzeichnen.
• GMP-relevanten Einsatz und betroffene Entscheidungen abgrenzen.
• Bestehende Kontrollen mit konkreten Belegen bewerten.
• Heutige Lücke, künftigen Vorschlag und freiwillige Verbesserung unterscheiden.
• Lieferantenbelege auf Version und tatsächlichen Umfang prüfen.
• Prüftiefe aus der Auswirkung ableiten und begründen.
• Entscheidung, Verantwortlichen und Abschlussnachweis festhalten.
• Veröffentlichung und Anwendungsdatum einer endgültigen Revision erneut prüfen.

Quellen: [4] [5]