Inhaltsverzeichnis
Das Wichtigste vorab
Wann ist ein System nach Part 11 offen oder geschlossen?
Part 11 definiert offene und geschlossene Systeme anhand der Zugangskontrolle durch die für die elektronischen Aufzeichnungen verantwortlichen Personen. Die Unterscheidung folgt nicht allein aus Cloud, Internet oder On-Premise-Betrieb. Für geschlossene Systeme beschreibt §11.10 Kontrollen. Bei offenen Systemen verlangt §11.30 entsprechende Kontrollen und zusätzliche Maßnahmen, soweit diese zum Schutz von Authentizität, Integrität und gegebenenfalls Vertraulichkeit erforderlich sind.
- Erst Part-11-Anwendbarkeit, dann die konkrete Systemgrenze bestimmen.
- Externe Benutzer oder Dienstleister führen nicht automatisch zur Einordnung offen.
- Eine Verschlüsselungsfunktion allein belegt weder geschlossenen Betrieb noch sämtliche erforderlichen Kontrollen.
1. Die Definition knüpft an Zugangskontrolle an
§11.3(b)(4) beschreibt ein geschlossenes System als Umgebung, deren Zugang durch Personen kontrolliert wird, die für den Inhalt der elektronischen Aufzeichnungen verantwortlich sind. Bei einem offenen System nach §11.3(b)(9) besteht diese Kontrolle nicht. Diese Formulierung stellt Verantwortung und tatsächliche Zugangskontrolle in den Mittelpunkt.
Sie beantwortet die Frage nicht mit einem bestimmten Netzwerktyp. Ein Firmengebäude, ein VPN oder ein abgeschottetes Netz ist deshalb kein alleiniger Nachweis. Umgekehrt kann eine extern betriebene Umgebung kontrollierte Zugänge besitzen. Dokumentieren Sie, wer Zugang erteilen, ändern und entziehen kann und wie diese Befugnisse dem verantworteten Record-Prozess zugeordnet sind.
Quellen: [1]
2. Bestimmen Sie zuerst, welche Umgebung Sie bewerten
Bevor Sie offen oder geschlossen eintragen, stellen Sie den Part-11-Scope für die betroffenen Records fest. Ein öffentlich zugänglicher Prospektserver wird nicht allein durch seine Offenheit zu einem Part-11-System. Für den eigentlichen Record-Prozess können dagegen Anwendung, Identitätsverwaltung, administrativer Zugriff und Übergabestrecke relevant sein.
Zeichnen Sie als Arbeitshilfe die Stationen vom Erstellen bis zum vorgesehenen Empfänger auf. Benennen Sie die maßgebliche Aufzeichnung und die Verantwortlichen je Station. Ein Export kann die kontrollierte Anwendung verlassen, ohne dass damit automatisch alle späteren Umgebungen dieselbe Einordnung übernehmen. Beurteilen Sie diese Grenze ausdrücklich.
3. Betrachten Sie mehr als die Anmeldung normaler Benutzer
Ein persönlicher Login ist ein wichtiger Baustein, aber noch kein vollständiges Bild. Wer kann neue Benutzer anlegen, Rollen verändern, Daten über Administrationswerkzeuge bearbeiten oder Zugriff über eine Schnittstelle erhalten? Welche technischen Konten existieren und wer verantwortet ihre Nutzung? Diese Fragen konkretisieren die Zugangskontrolle.
Bei einem Dienstleister sind vertragliche Zuständigkeit und technisch wirksame Regelung zusammen zu bewerten. Allein die Tatsache, dass Providerpersonal existiert, begründet nicht automatisch ein offenes System. Ebenso wäre die Behauptung geschlossen allein aufgrund eines Vertrags zu schwach. Sie brauchen geeignete Belege dafür, dass die beschriebenen Zugänge tatsächlich kontrolliert werden.
Quellen: [1]
4. Drei Zugriffssituationen getrennt einordnen
Die folgende Matrix ist ausdrücklich illustrativ. Sie klassifiziert keine vorhandene Installation. Die jeweiligen Annahmen sollen zeigen, welche Information eine begründete Entscheidung trägt und wann die Datenlage für eine Einordnung noch nicht ausreicht.
| Situation | Festgelegte Annahme | Einordnung und Restfrage |
|---|---|---|
| A: Lokale Anwendung für einen verantworteten Record-Prozess | Verantwortliche kontrollieren alle relevanten Benutzer- und administrativen Zugänge nach festgelegten Befugnissen. | Unter dieser Annahme geschlossen. Wirksamkeit der Kontrollen gemäß §11.10 bleibt zu prüfen. |
| B: Cloudportal mit Mitarbeitern und zugelassenen externen Prüfern | Anwenderzugänge werden gesteuert; Verfahren und Befugnisse für Provideradministration sind noch nicht belegt. | Cloud und externe Prüfer entscheiden die Einordnung nicht. Verantwortungs- und Zugangsnachweis vervollständigen; Status bis dahin offenlassen. |
| C: Elektronischer Record durchläuft eine Übertragungsumgebung | Die für den Record-Inhalt verantwortlichen Personen kontrollieren den Zugang dieser betrachteten Umgebung nicht. | Für diese angenommene Umgebung offen. Angemessene §11.30-Kontrollen und Übergaben zum Empfänger bestimmen. |
Quellen: [1]
5. Geschlossen bedeutet nicht kontrollfrei
§11.10 nennt unter anderem Validierung, geeignete Kopien, Schutz während der Aufbewahrung, Zugangsbeschränkung, Audit Trails sowie Ablauf-, Befugnis- und gegebenenfalls Geräteprüfungen. Die Klassifizierung geschlossen ist daher der Ausgangspunkt einer Kontrollbewertung, kein vereinfachtes Konformitätszertifikat.
Ein Beispiel: Alle Benutzer wurden ordentlich genehmigt, aber ein berechtigter Leser kann versehentlich Datensätze ändern. Die Zugangskontrolle auf Kontoebene beantwortet dann die Befugnisfrage für die konkrete Handlung nicht ausreichend. Testen Sie relevante Aktionen mit passenden Rollen, statt nur erfolgreiche Anmeldung und Passwortfehler zu prüfen.
Quellen: [1]
6. Zusatzkontrollen müssen zur offenen Umgebung passen
§11.30 fordert für offene Systeme geeignete Verfahren und Kontrollen, um Authentizität, Integrität und gegebenenfalls Vertraulichkeit vom Erstellen bis zum Empfang zu sichern. Dazu gehören die Kontrollen aus §11.10, soweit angemessen, sowie zusätzliche Maßnahmen. Der Text nennt beispielsweise Verschlüsselung und geeignete digitale Signaturstandards, soweit sie unter den Umständen erforderlich sind.
Daraus folgt weder ein universeller Algorithmus noch die Aussage, jede offene Verbindung müsse identisch abgesichert werden. Begründen Sie die Auswahl anhand des Datenwegs und der Risiken. Eine verschlüsselte Übertragung allein beantwortet etwa nicht, ob der richtige Empfänger den richtigen Record erhält oder ob ein veralteter Stand als aktuell verarbeitet wird.
Quellen: [1]
7. Prüfen Sie Zugangsentzug und Übergabe mit klaren Sollwerten
Illustrativer Fall: Drei Testidentitäten besitzen Zugänge: Bearbeiter A, Leser B und externer Prüfer C. C verliert seine Befugnis. Danach sollen zwei aktive berechtigte Identitäten verbleiben. Zusätzlich wird Record R-42, Revision 7, an einen festgelegten Empfänger übergeben. Die Zahlen dienen nur der Nachvollziehbarkeit; eine richtige Benutzeranzahl beweist keine richtigen Einzelrechte.
Der Fall ist eine eigene Prüfempfehlung. Er unterstellt weder ein bestimmtes Produktverhalten noch garantierte Schnittstellenfunktionen. Wenn ein System eine relevante Kontrolle nicht technisch bereitstellt, ist die Eignung des vorgesehenen Gesamtverfahrens zu bewerten; ein Verfahrensdokument kompensiert die Lücke nicht automatisch.
| Prüfschritt | Soll | Aussage und Grenze |
|---|---|---|
| Zugang C entziehen | C kann den betrachteten Record-Weg nicht weiter nutzen; A und B bleiben gemäß Rolle berechtigt. | 3 minus 1 = 2 berechtigte Identitäten; zusätzlich die konkreten Zugangswege prüfen. |
| Leser B versucht Änderung | Änderungsversuch wird entsprechend der festgelegten Leseberechtigung verhindert. | Prüft Befugnis für diese Aktion, nicht sämtliche Rollenfunktionen. |
| R-42 Revision 7 übertragen | Empfänger, Record-ID und Revision stimmen mit dem vorgesehenen Paket überein. | Gleiche Dateianzahl allein genügt nicht als Inhaltsnachweis. |
| Abweichenden Stand R-42 Revision 6 anbieten | Abweichung wird im vorgesehenen Kontrollverfahren erkannt und vor unzutreffender Nutzung geklärt. | Keine automatische Versionssperre eines konkreten Produkts behauptet. |
Quellen: [1]
8. Halten Sie die Einordnung im Betrieb aktuell
Ein neues Portal, ein zusätzlicher Dienstleister oder ein anderer Identitätsanbieter kann die bisherige Begründung verändern. Prüfen Sie bei solchen Änderungen die relevanten Verantwortlichkeiten, Zugänge und Übergaben. Eine vollständige Neuklassifizierung jedes unbedeutenden Updates ist dagegen kein Selbstzweck.
Für ein kleines Team ist ein kurzes Architekturblatt mit Nachweisreferenzen praktikabel: Systemgrenze, Record-Verantwortlicher, kontrollierende Rollen und bekannte offene Punkte. IT liefert die technischen Wege; die fachlich verantwortliche Stelle beschreibt den Record-Zweck und zulässige Handlungen. Die Entscheidung muss zu beiden Perspektiven passen.
- Part-11-Anwendbarkeit für die betrachteten Records feststellen.
- Bewertete Umgebung und Übergaben eindeutig abgrenzen.
- Verantwortung für Inhalt und Zugangskontrolle benennen.
- Benutzer-, administrative und technische Zugänge berücksichtigen.
- Einordnung mit tatsächlich verfügbaren Belegen begründen.
- Bei offener Umgebung erforderliche Zusatzkontrollen konkret auswählen.
- Zugangsentzug, Befugnisse und relevante Übertragungsfehler prüfen.
- Änderungen und ungelöste Zugangslücken nachvollziehbar behandeln.
Quellen: [1]
Häufige Fragen zu Offene und geschlossene Systeme
Sind Cloudsysteme nach Part 11 immer offene Systeme?
Nein. Die Definition verwendet die Kontrolle des Zugangs durch die für die Records verantwortlichen Personen. Cloudbetrieb allein beantwortet diese Frage nicht. Prüfen Sie Benutzerzugänge, Administration, Verantwortlichkeiten und relevante Übergaben für die konkrete Umgebung.
Quellen: [1]
Ist eine lokale Anwendung automatisch geschlossen?
Auch eine lokale Installation braucht eine begründete Zugangskontrolle. Netzwerkstandort oder Firmengebäude allein belegen diese nicht. Unkontrollierte administrative Zugänge oder unklare Zuständigkeiten müssen bewertet werden, selbst wenn die Anwendung nicht öffentlich aus dem Internet erreichbar ist.
Quellen: [1]
Machen externe Prüfer das System offen?
Nicht allein aufgrund ihrer externen Zugehörigkeit. Wenn Zugänge und Befugnisse im verantworteten Verfahren kontrolliert werden, ist die externe Rolle kein automatisches Ausschlusskriterium. Prüfen Sie insbesondere Vergabe, Umfang, Dauer und Entzug der Berechtigungen.
Quellen: [1]
Müssen wir jeden Provideradministrator persönlich benennen können?
Die Definition enthält keine solche pauschale Namenslistenregel. Sie müssen jedoch die relevante Zugangskontrolle und Verantwortung belastbar beurteilen können. Welche personenbezogenen oder prozessbezogenen Belege dafür geeignet sind, hängt von der konkreten Betriebsvereinbarung und dem Datenweg ab.
Quellen: [1]
Reicht ein Passwortschutz für die Einordnung geschlossen?
Ein Passwortschutz ist ein Teil möglicher Zugangskontrollen. Er beantwortet nicht allein, wer Konten erzeugt, privilegierte Zugänge nutzt oder Schnittstellen freischaltet. Prüfen Sie die vollständige betrachtete Umgebung und die Verantwortung für ihre Zugänge.
Quellen: [1]
Ist ein offenes System nach Part 11 grundsätzlich unzulässig?
Nein. §11.30 beschreibt ausdrücklich Kontrollen für offene Systeme. Deren angemessene Umsetzung muss zum Datenweg passen. Das ist keine automatische Eignungszusage: Wenn Authentizität, Integrität und erforderlicher Schutz nicht ausreichend gewährleistet werden, bleibt eine relevante Lücke.
Quellen: [1]
Verlangt §11.30 immer eine digitale Signatur?
Der Text nennt zusätzliche Maßnahmen wie Verschlüsselung und geeignete digitale Signaturstandards, soweit sie unter den Umständen erforderlich sind. Eine universelle Festlegung für jede Architektur wäre zu weit. Begründen Sie, welche Kontrollen für Ihre konkrete offene Umgebung erforderlich sind.
Quellen: [1]
Kann dieselbe Prozesskette unterschiedliche Systemgrenzen haben?
Ja. Eine kontrollierte Anwendung und eine gesonderte Übertragungsumgebung können unterschiedliche Zugangssituationen aufweisen. Beschreiben Sie die Grenzen und Übergaben ausdrücklich. Die Klassifizierung einer Station darf nicht ungeprüft auf sämtliche nachgelagerten Wege übertragen werden.
Quellen: [1]
Beweist eine verschlüsselte Übertragung vollständige Part-11-Eignung?
Nein. Verschlüsselung beantwortet nur bestimmte Schutzfragen. Sie belegt beispielsweise nicht allein richtige Empfängerzuordnung, vollständige Records, angemessene Befugnisse oder erforderliche Signaturkontrollen. Bewerten Sie den gesamten einschlägigen Kontrollumfang für den konkreten Zweck.
Quellen: [1]
Wann müssen wir die Einordnung erneut bewerten?
Wenn sich relevante Zugangswege, Verantwortlichkeiten oder Systemgrenzen ändern. Beispiele sind ein neuer externer Zugang, veränderte Administration oder eine zusätzliche Übertragungsstrecke. Diese Anlässe sind eine praktische Ableitung aus der Definition und den Kontrollen, keine universelle kalenderbezogene Prüffrist.
Quellen: [1]
Quellen & fachlicher Stand
Quellenstand 6. Oktober 2026: 21 CFR Part 11, insbesondere §§11.3, 11.10 und 11.30; eCFR-Anzeige bis 2. Oktober 2026. Die FDA-Guidance Scope and Application 2003 wird für die vorgelagerte Anwendbarkeit verwendet. Architektur- und Prüffälle sind eigene illustrative Arbeitshilfen, keine Klassifizierung eines konkreten Cloudprodukts.
- 21 CFR Part 11 — Electronic Records; Electronic Signaturese CFR: Title 21 konsolidiert bis02.10.2026; Title 21 zuletzt geändert30.09.2026. Anzeige ist keine Behauptung einer Part-11-Änderung an diesem Tag. Fundstellen: §11.1(a)–(e) und sektorspezifische Ausnahmen(f)–(p); §11.2; §11.3(b)(4),(5),(6),(7),(9); §11.10(a)–(k); §11.30; §§11.50,11.70,11.100,11.200,11.300
- FDA: Part 11 — Scope and Application, Original-PDFOriginaldeckblatt August 2003, Pharmaceutical CGMPs; Contains Nonbinding Recommendations. Aktuell über FDA als Final gelistet. Fundstellen: I.Introduction, gedruckte S.1–2; III.A, S.4; III.B.1–2, S.5–6; III.C.1–5, S.6–8
Zuletzt fachlich geprüft am 07.10.2026.
Daniel Herrmann Consulting
Anwendbarkeit und Nachweise gezielt bearbeiten
Daniel Herrmann Consulting unterstützt Sie bei der Einordnung Ihres konkreten Prozesses und der passenden Nachweisarbeit. Umfang und Verantwortlichkeiten werden am tatsächlichen Bedarf ausgerichtet.
- IT-GxP-Audit →
Anforderungen, vorhandene Nachweise und relevante Lücken beurteilen.
- IT-GxP-Consulting →
Vereinbarte Bewertungs-, Dokumentations- und Testarbeit im Projekt bearbeiten.
- IT-GxP-Coaching →
Ihr Team bei konkreten Entscheidungen und der Anwendung eigener Verfahren begleiten.
- IT-GxP-Compliance-Programm →
Passende interne Verfahren, Vorlagen und Schulung aufbauen.