C5, SOC 2 und GxP: Tragweite von Cloud-Nachweisen
C5-Testat, SOC-2-Bericht und ISO-27001-Zertifikat belegen Sicherheits- und Betriebskontrollen des Cloud-Anbieters, keine GxP-Validierung. Die Tragweite für Pharma-Unternehmen entscheidet sich beim Auswerten: Scope, Prüfzeitraum, Ausnahmen, Subservice-Organisationen und die im Bericht definierten Kundenpflichten. Der Beitrag ordnet die drei Nachweisformate in Shared Responsibility, Lieferantenqualifizierung und Validierungsstrategie ein und liefert eine Prüfmatrix mit acht Nachweistypen.
Cloud-Nachweise sind Testate, Prüfberichte und Zertifikate, mit denen ein Cloud-Anbieter die Sicherheits- und Betriebskontrollen seiner Dienste gegenüber Kunden belegt. In Anbieterpaketen für Pharma-Kunden stehen drei Formate im Mittelpunkt: das Testat nach dem BSI-Kriterienkatalog C5, der SOC-2-Bericht nach den Trust Services Criteria und das Zertifikat nach ISO/IEC 27001. Alle drei sind für die Lieferantenqualifizierung brauchbar. Keines belegt eine GxP-Validierung.
Dieser Beitrag vertieft die Evidenz-Seite des Grundlagenartikels zur Shared-Responsibility-Matrix für die GxP-Cloud. Dort steht der Verantwortungsschnitt zwischen Anbieter und Anwender im Vordergrund. Hier geht es um die Nachweise selbst: ihre Aussagekraft, ihre Grenzen und die Einordnung in Lieferantenqualifizierung und Validierungsstrategie.
Reichweite der Kontrollnachweise
C5, SOC 2 und ISO 27001 beantworten dieselbe Grundfrage aus drei Richtungen: Der Anbieter muss eine kontrollierte, sichere Umgebung betreiben. Geprüft werden Zugriffskontrollen, Betriebsprozesse, physische Sicherheit, Incident-Handling und die organisatorische Steuerung des Anbieters.
Ungeprüft bleibt alles, was den regulierten Einsatz ausmacht: der Intended Use des Systems, die Konfiguration von Workflows und Rollen, die Datenmigration, die Schnittstellen und der GxP-Prozess, in dem das System arbeitet. Ein SaaS-eQMS kann ein makelloses C5-Testat tragen und trotzdem einen fehlerhaft konfigurierten Freigabe-Workflow ausführen.
Für Audits folgt daraus eine zweistufige Erwartung. Erstens müssen Nachweise vorliegen, aktuell sein und den genutzten Dienst abdecken. Zweitens muss aus ihnen eine dokumentierte Entscheidung über übernommene Anbieterkontrollen und eigene Anwenderkontrollen abgeleitet werden. Die zweite Stufe ist der Teil, den kein Anbieterdokument ersetzt.
C5: Kriterienkatalog mit Kundenpflichten
C5 (Cloud Computing Compliance Criteria Catalogue) ist der Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik (BSI) für Cloud-Sicherheit. Die Fassung C5:2020 umfasst 125 Kriterien in 17 Themenbereichen, unterteilt in Basiskriterien für normalen Schutzbedarf und Zusatzkriterien für erhöhte Anforderungen.
Das Ergebnis ist kein Zertifikat, sondern ein C5-Testat: eine Prüfung durch einen Wirtschaftsprüfer nach dem internationalen Prüfungsstandard ISAE 3000 (Revised). Ein Typ-1-Bericht bestätigt die Angemessenheit der Kontrollen zu einem Stichtag, ein Typ-2-Bericht zusätzlich deren Wirksamkeit über einen Prüfzeitraum. Für die Lieferantenbewertung zählt der Typ-2-Bericht, weil er den laufenden Betrieb abdeckt.
Zwei Eigenschaften machen C5 wertvoller als ein reines Siegel. Zum einen verlangt der Katalog Transparenzangaben in der Systembeschreibung, darunter Datenlokation, Gerichtsstand, Subdienstleister und Offenlegungspflichten gegenüber staatlichen Stellen. Zum anderen definiert C5:2020 korrespondierende Kriterien: Kontrollen, die der Cloud-Kunde an der Schnittstelle zum Dienst selbst erfüllen muss, etwa im Identitäts- und Berechtigungsmanagement. Diese Kundenpflichten sind der direkte Rohstoff für die Shared-Responsibility-Matrix, sie müssen ausgewertet und internen Ownern zugewiesen werden.
Beim Lesen eines C5-Berichts zählen vier Prüffelder: genutzte Dienste, Regionen und Plattformkomponenten im Prüfgegenstand; geprüfter Zeitraum; Behandlung von Subservice-Organisationen; Kriterien mit Einschränkungen im Testat.
Zum Versionsstand: Dieser Beitrag bezieht sich auf C5:2020 (Redaktionsstand März 2026). Das BSI hat am 14.07.2025 einen Community Draft der Nachfolgefassung unter dem Arbeitstitel C5:2025 zur Kommentierung gestellt (Frist 15.09.2025) und die finale Fassung angekündigt. Laufende Testate nach C5:2020 bleiben davon zunächst unberührt. Bei neuen Verträgen lohnt die Frage, wann der Anbieter auf die Nachfolgefassung umstellt.
SOC 2: Prüfbericht statt Siegel
SOC 2 ist ein Attestierungsbericht nach den Prüfungsstandards des US-Wirtschaftsprüferverbands AICPA (American Institute of Certified Public Accountants). Kriterienbasis sind die Trust Services Criteria in der Fassung von 2017 mit überarbeiteten Points of Focus von 2022. Der Katalog gliedert sich in fünf Kategorien: Security als Pflichtteil (Common Criteria CC1 bis CC9) sowie Availability, Processing Integrity, Confidentiality und Privacy als wählbare Ergänzungen. Der Anbieter bestimmt den Scope selbst. Ein Bericht, der nur Security abdeckt, sagt nichts über Verfügbarkeitszusagen oder Vertraulichkeitskontrollen.
Wie bei C5 gilt die Typ-Logik: SOC 2 Typ I beschreibt das Kontrolldesign zu einem Stichtag, Typ II die Wirksamkeit über einen definierten Zeitraum.
Der Wert liegt im Berichtstext, nicht im Ergebnis-Etikett. Ein SOC-2-Typ-II-Bericht enthält die Systembeschreibung, die einzelnen Kontrollen, die Prüfungshandlungen des Auditors und die Ergebnisse einschließlich Ausnahmen (Exceptions). Daneben listet er Complementary User Entity Controls (CUECs): Kontrollen, deren Wirksamkeit der Bericht ausdrücklich beim Kunden voraussetzt, zum Beispiel die Pflege von Benutzerkonten oder die Konfiguration von Sicherheitsoptionen. Ein Anbieterbericht mit 30 CUECs verschiebt 30 Kontrollpflichten in die eigene Organisation. Wer sie nicht auswertet, übernimmt sie unbemerkt.
Die dritte Lesestelle ist die Behandlung von Subservice-Organisationen. Bei der Carve-out-Methode klammert der Bericht die Kontrollen des darunterliegenden Hyperscalers aus. Dessen Nachweise (AWS, Azure, Google Cloud) müssen dann separat beschafft und bewertet werden. Grenzen des Formats: SOC 2 ist eine US-Attestation ohne GxP-Bezug, die Berichte werden gegen Vertraulichkeitsvereinbarung herausgegeben, und die Kriterien sind generisch formuliert, nicht auf regulierte Prozesse zugeschnitten.
ISO 27001 und ergänzende Nachweise
ISO/IEC 27001 zertifiziert ein Informationssicherheits-Managementsystem (ISMS). Aktuell ist die Fassung ISO/IEC 27001:2022 einschließlich Amendment 1 vom Februar 2024. Zertifikate nach der Vorgängerfassung von 2013 sind seit dem 01.11.2025 ungültig, die Übergangsfrist der Akkreditierungsregelung IAF MD 26 endete am 31.10.2025. Ein 2013er-Zertifikat in der Lieferantenakte ist damit ein konkreter Prüfbefund, kein Detail.
Das Zertifikat selbst ist eine Seite Papier. Aussagekraft entsteht erst aus zwei Zusatzinformationen: dem Geltungsbereich, der auf dem Zertifikat steht und den genutzten Dienst tatsächlich umfassen muss, und der Statement of Applicability (SoA), der Übersicht umgesetzter und begründet ausgeschlossener Referenzmaßnahmen aus Anhang A. Ohne Scope-Prüfung und SoA-Einblick bleibt ISO 27001 ein Rahmennachweis: Der Anbieter managt Informationssicherheit systematisch, mehr nicht.
Darüber hinaus gehören ergänzende Unterlagen in die Bewertung: Penetrationstest-Zusammenfassungen mit Angaben zur Behandlung der Findings, Kennzahlen zum Vulnerability Management, Backup- und Disaster-Recovery-Konzepte einschließlich dokumentierter Restore-Tests, Angaben zu Data Residency und Subprozessoren sowie Change- und Incident-Management-Prozesse. Diese Unterlagen durchlaufen keine unabhängige Prüfung wie ein Testat. Gerade deshalb gehören sie mit konkreten Fragen unterlegt, die Prüfmatrix unten liefert dafür die Struktur.
Von der Evidenz zur Lieferantenqualifizierung
Die GxP-Einordnung beginnt bei Annex 11. Abschnitt 3 (Suppliers and Service Providers) verlangt formale Vereinbarungen mit Dienstleistern und macht deren Kompetenz und Zuverlässigkeit zum Auswahlkriterium; Informationen aus Lieferantenaudits müssen verfügbar sein. C5-Testat, SOC-2-Bericht und ISO-Zertifikat sind in dieser Logik Eingangsunterlagen der Lieferantenqualifizierung: Ein Audit-Urteil ersetzen sie nicht, aber sie fokussieren es. Ein belastbares Testat kann die Prüftiefe eines eigenen Lieferantenaudits reduzieren, wenn die Entscheidung dokumentiert und risikobasiert begründet ist.
GAMP 5 Second Edition (2022) beschreibt dafür den Rahmen: Anbieterdokumentation und Anbietertests dürfen genutzt werden, wenn die Lieferantenbewertung deren Verlässlichkeit belegt. Denselben Gedanken trägt der risikobasierte Assurance-Ansatz aus Computer Software Assurance: Anbieter-Evidenz zählt, wenn ihre Herkunft und Qualität bewertet wurden. Für GCP-Systeme formuliert die EMA-Guideline zu computergestützten Systemen und elektronischen Daten in klinischen Prüfungen (März 2023, anzuwenden seit September 2023) diese Erwartung ausdrücklich auch für Cloud-Dienste.
Die Revision von Annex 11 dürfte diese Richtung verstärken. Der Konsultations-Draft vom 07.07.2025 (Kommentierungsfrist 07.10.2025) behandelt Dienstleister und Cloud-Dienste deutlich ausführlicher als die Fassung von 2011; der Umfang wächst von 5 auf 19 Seiten. Zum Redaktionsstand dieses Beitrags liegt die finale Fassung nicht vor, die Stoßrichtung ist aber erkennbar: mehr explizite Anforderungen an Verträge, Audits und die Kontrolle ausgelagerter Aktivitäten.
Unverändert beim regulierten Unternehmen bleiben Intended Use, Konfiguration, Rollenmodell, Workflows, Schnittstellen, Datenmigration und der Review des Audit Trails. Konfigurationsentscheidungen unterscheiden sich von Plattform zu Plattform; die Zertifikatslage der Anbieter beantwortet keine dieser Konfigurationsfragen.
Prüfmatrix für Anbieter-Nachweise
Die Matrix fasst acht Nachweistypen aus Anbieterpaketen für Pharma-SaaS zusammen. Als Arbeitsstruktur für die Lieferantenbewertung wird sie pro System ausgefüllt; Lücken gehen als Fragen an den Anbieter, Ergebnisse in Qualifizierungsakte und Shared-Responsibility-Matrix.
| Nachweis | Aussagekraft | Typische Lücke | Frage an Anbieter | Relevanz für QA/IT |
|---|---|---|---|---|
| C5-Testat (Typ 2) | Wirksamkeit der Cloud-Kontrollen über den Prüfzeitraum, inklusive Transparenzangaben | Korrespondierende Kriterien bleiben unausgewertet; Scope deckt genutzte Dienste nicht | Prüfgegenstand deckt alle genutzten Dienste, Regionen und Komponenten ab. | Kernnachweis der Lieferantenbewertung im DACH-Raum |
| SOC 2 Typ II | Kontrollwirksamkeit über einen Zeitraum nach Trust Services Criteria | Nur Security beauftragt; Ausnahmen und CUECs ungelesen | Kategorien im Scope und Ausnahmen im Bericht sind ausgewertet. | Betriebs- und Sicherheitskontrollen, international vergleichbar |
| ISO-27001-Zertifikat | ISMS vorhanden und unabhängig auditiert | Geltungsbereich eng formuliert; SoA nicht eingesehen | Geltungsbereich umfasst den genutzten Dienst; SoA liegt vor. | Rahmennachweis, Basis für Vertrags- und Risikofragen |
| Penetrationstest-Zusammenfassung | Technischer Sicherheitsstand zum Testzeitpunkt | Nur Management Summary; Behandlung der Findings fehlt | Testdatum und Behandlung kritischer Findings sind dokumentiert. | IT-Security, Eingang für die Risikobewertung |
| Business-Continuity-/DR-Nachweis | Wiederanlauffähigkeit und Verfügbarkeitszusagen | RTO/RPO ohne dokumentierten Restore-Test | Der letzte Restore-Test ist durchgeführt und protokolliert. | Verfügbarkeit und Lesbarkeit regulierter Records |
| Data-Residency-Angaben | Speicher- und Verarbeitungsorte, Subprozessoren | Supportzugriffe aus Drittstaaten fehlen in der Betrachtung | Länder mit privilegiertem Zugriff und Protokollierung sind benannt. | Datenintegrität, Datenschutz, Vertragsgestaltung |
| Validierungspaket des Anbieters | Entwicklungs-, Test- und Release-Modell der Standardsoftware | Beschreibt Standardfunktionen, nicht die Kundenkonfiguration | Testabdeckung pro Release und Kommunikation von Known Issues sind beschrieben. | Kernbaustein für die Übernahme in das eigene Dossier |
| Release Notes und Release Policy | Änderungen am Dienst im laufenden Betrieb | Vorlauf zu kurz für ein Impact Assessment; keine GxP-Kennzeichnung | Vorlaufzeiten, Testumgebung und Impact-Informationen sind geregelt. | Change Control und Continued Verification |
Die acht Zeilen folgen einem Muster: Jeder Nachweis beantwortet eine Betriebsfrage des Anbieters und öffnet zugleich eine Anschlussfrage beim Anwender. Die Qualifizierung ist abgeschlossen, wenn beide Seiten dokumentiert sind, nicht wenn die Zertifikate abgelegt sind.
Empfehlung für die nächsten 90 Tage
- Nachweisinventar anlegen. Pro GxP-Cloud-System vorliegende Testate, Berichte und Zertifikate mit Version, Prüfzeitraum und Ablaufdatum dokumentieren.
- Berichte auswerten. Scope, Prüfzeitraum, Ausnahmen, Subservice-Behandlung, korrespondierende Kriterien und CUECs pro Bericht bewerten und die Bewertung ablegen.
- Kundenpflichten zuweisen. Jede korrespondierende Kontrolle und jede CUEC in die Shared-Responsibility-Matrix übertragen und einem internen Owner zuordnen.
- Lücken adressieren. Fehlende Unterlagen mit den Fragen aus der Prüfmatrix beim Anbieter anfordern; Wiedervorlagen an Zertifikats- und Testatslaufzeiten koppeln.
- Strategie synchronisieren. Lieferantenqualifizierung und Validierungsstrategie so verbinden, dass übernommene Anbieteraktivitäten mit Herkunftsnachweis im Dossier stehen.