ISO 27001 und SOC 2: Reicht das für GxP-Software?

Einordnung und Geltungsbereich

ISO/IEC 27001 betrifft ein Informationssicherheitsmanagementsystem. SOC 2 ist ein Berichts- und Prüfungsansatz zu Kontrollen einer Dienstleistungsorganisation. Beide sind nach ihrem tatsächlichen Umfang zu bewerten, statt sie als allgemeines GxP-Gütesiegel zu behandeln.

Quellen: [1] [2]

Fragen Sie nach der Aussage hinter dem Logo

Ein ausführlicher Bericht kann Kontrollen, Prüfungen und Einschränkungen verständlicher machen als eine Verkaufsfolie. Entscheidend bleibt, ob diese Kontrollen zu Ihren relevanten Fragen passen: beispielsweise Zugriffsschutz, Wiederherstellung oder Änderungssteuerung. Ausnahmen und beim Kunden vorausgesetzte Maßnahmen verdienen besondere Aufmerksamkeit.

Ergänzen Sie die Anbieterinformationen um die Prüfung Ihres Einsatzes. Rollen, Schnittstellen, fachliche Berechnungen und Freigaben entstehen häufig erst durch Ihre Konfiguration. Ein Sicherheitsnachweis des Anbieters bestätigt nicht automatisch deren fachliche Richtigkeit.

Quellen: [1] [2] [3]

Was die Nachweise jeweils betrachten

ISO/IEC 27001 behandelt ein Informationssicherheitsmanagementsystem. Ein Zertifikat bezieht sich auf einen bezeichneten Geltungsbereich. SOC-Berichte behandeln bestimmte Kontrollen einer Organisation oder Dienstleistung im jeweiligen Prüfrahmen. Beide können wertvolle Informationen für die Lieferantenbewertung liefern, sind aber keine pauschale Bestätigung Ihrer eigenen GxP-Anwendung.

Prüfen Sie zuerst, ob die tatsächlich beauftragte Leistung abgedeckt ist. Ein Zertifikat eines Konzerns muss nicht jeden Standort oder Dienst einschließen. Ein Bericht zu einer Plattform kann andere Komponenten als Ihre konkrete Lösung betrachten. Der Name des Anbieters allein schafft diesen Bezug nicht.

Unterscheiden Sie Nachweisexistenz und Nachweisinhalt. Ein Logo in einer Präsentation zeigt wenig über Umfang, Zeitraum, Ausnahmen oder Kundenaufgaben. Fordern Sie geeignete Informationen im zulässigen Rahmen an und bewerten Sie deren Relevanz. Vertrauliche Berichte dürfen dabei nicht unberechtigt weitergegeben werden.

Quellen: [1] [2] [3]

Eine Evidenzmatrix für die Lieferantenbewertung erstellen

Verknüpfen Sie jede eigene Anforderung mit dem verfügbaren Nachweis und dessen Grenze. Ein Bericht kann beispielsweise bestimmte Betriebs- oder Zugriffskontrollen unterstützen. Die richtige Konfiguration Ihrer Rollen, Berechnungen oder Qualitätsprozesse bleibt dadurch nicht automatisch bestätigt. Die Matrix macht diese verbleibenden Aufgaben sichtbar.

Ein fehlender Bezug kann zusätzliche Fragen oder Prüfungen erfordern. Bewerten Sie nicht nur, ob ein Dokument aktuell aussieht. Ein neuer Bericht über eine andere Dienstleistung kann weniger nützlich sein als ein älterer, klar passender Nachweis mit erklärter Aktualisierung. Die Entscheidung braucht Inhalt und Kontext.

Quellen: [1] [2] [3]

Beispiel: zertifizierter Anbieter, ungeprüfte Kundenschnittstelle

Das Szenario ist konstruiert. Ein SaaS-Anbieter besitzt ein passendes Sicherheitszertifikat. Der Kunde richtet eine Schnittstelle ein, die Ergebniswerte mit einem eigenen Mapping übernimmt. Das Mapping vertauscht zwei Einheiten. Der Sicherheitsnachweis des Anbieters beantwortet diese kundenspezifische Verarbeitung nicht.

Die Lieferantenbewertung kann geeignete Sicherheits- und Betriebsinformationen verwenden. Zusätzlich werden Mapping, Rechte, Fehlerwege und fachliche Zielverwendung geprüft. Diese Aufgaben ergänzen sich. Die Aussage „Der Anbieter ist zertifiziert“ darf nicht als Ersatz für den eigenen End-to-End-Nachweis verwendet werden.

Prüfen Sie auch genannte Kundenaufgaben. Wenn ein Bericht voraussetzt, dass der Kunde Benutzerzugriffe selbst angemessen verwaltet, gehört diese Aufgabe in Ihr Betriebsmodell. Eine Kontrolle, die nur im Bericht steht, aber intern niemand übernimmt, bleibt eine Lücke. Verknüpfen Sie Verantwortung und tatsächlichen Nachweis.

Quellen: [1] [2] [3]

Zeitbezug und Änderungen nachvollziehbar behandeln

Ein Bericht beschreibt einen bezeichneten Stand oder Zeitraum. Prüfen Sie, ob seitdem wesentliche Änderungen erfolgt sind. Ein ergänzendes Schreiben kann Informationen liefern, ist aber nicht automatisch dieselbe Art von unabhängiger Prüfung wie der ursprüngliche Bericht. Beschreiben Sie die Quelle und Aussage korrekt.

Bei Unterdienstleistern ist zu beurteilen, welche Komponenten tatsächlich einbezogen sind und welche Informationen fehlen. Ein ausgelagerter Speicher- oder Identitätsdienst kann für Ihre Anwendung relevant sein. Die Lieferantenbewertung sollte die benötigten Abhängigkeiten berücksichtigen, ohne pauschal jede fremde Komponente gleich tief zu prüfen.

Legen Sie einen passenden Aktualisierungsweg fest. Änderungen, neue Erkenntnisse oder relevante Befunde können eine erneute Bewertung auslösen. Eine rein kalendarische Ablage neuer PDFs ohne Inhaltsprüfung ist schwach. Umgekehrt braucht nicht jeder redaktionell geänderte Bericht ein vollständiges neues Audit.

Quellen: [1] [2] [3]

Sicherheitsnachweis und GxP-Verantwortung verbinden

Informationssicherheit unterstützt Vertraulichkeit, Integrität und Verfügbarkeit. GxP-Eignung umfasst zusätzlich den vorgesehenen fachlichen Prozess und geeignete Nachweise für Daten und Entscheidungen. Beide Perspektiven überschneiden sich, sind aber nicht identisch. Eine starke Sicherheitskontrolle bestätigt keine richtige Berechnungsformel.

Benennen Sie Verantwortlichkeiten zwischen Anbieter und Kunde. Wer betreibt Infrastruktur, wer konfiguriert Rollen, wer bewertet Updates und wer prüft die Qualitätsverwendung? Annex 11 behandelt die Zusammenarbeit mit Lieferanten und Dienstleistern. Die konkrete Aufteilung wird in Ihrem Modell beschrieben und durch passende Unterlagen unterstützt.

Ein Zertifikat kann den Umfang eigener Lieferantenprüfungen beeinflussen, wenn seine Eignung nachvollziehbar bewertet ist. Eine automatische Befreiung von jeder weiteren Prüfung folgt daraus nicht. Die Entscheidung sollte Risiko, verfügbare Evidenz und verbleibende Lücken zusammenführen.

Quellen: [1] [2] [3]

Eine kurze, brauchbare Bewertungsakte führen

Die Akte sollte betrachteten Dienst, Nachweise, Grenzen, Kundenaufgaben und Schlussfolgerung verbinden. Vermeiden Sie lange allgemeine Normzusammenfassungen ohne Bezug zur Leistung. Ein späterer Reviewer sollte erkennen, welche konkrete Risikoentscheidung durch welches Dokument unterstützt wurde.

Übergeben Sie verbleibende Aufgaben an die zuständigen Rollen. Eine Lieferantenbewertung, die offene Kundenkontrollen erkennt, ist erst praktisch nützlich, wenn diese Aufgaben im Betrieb ankommen. Verknüpfen Sie sie mit Zugriffs-, Änderungs- oder Wiederherstellungsverfahren, soweit passend. So wird aus einem Zertifikatsarchiv eine verwendbare Entscheidung.

Quellen: [1] [2] [3]

Arbeitsvorlage: einen Lieferantennachweis auf die eigene Anwendung beziehen

Beginnen Sie mit der tatsächlich beauftragten Dienstleistung. Im Beispiel betreibt ein Anbieter eine SaaS-Plattform, während Ihr Unternehmen Rollen und Ergebnisübernahme konfiguriert. Prüfen Sie, welchen Teil ein Zertifikat oder Bericht abdeckt. Die gleiche Unternehmensmarke ist kein ausreichender Scope-Nachweis.

Führen Sie verbleibende Kundenaufgaben in die eigene Umsetzung über. Ein Bericht kann bestimmte Kontrollen beim Nutzer voraussetzen. Diese sollten nicht nur im Lieferantenordner stehen, sondern einen zuständigen Prozess und Nachweis besitzen. Die Matrix verbindet fremde Evidenz mit eigener Verantwortung.

Dokumentieren Sie die Schlussfolgerung mit Grenzen. Ein geeigneter Nachweis kann eigene Prüftiefe beeinflussen, ersetzt aber nicht automatisch sämtliche Aufgaben. Wenn Scope oder Zeitraum unklar sind, werden passende Fragen gestellt. Eine pauschale grüne Bewertung allein wegen eines bekannten Logos wäre zu wenig.

Quellen: [1] [2] [3]

Die nächsten Schritte

• Passenden Originalnachweis und Geltungsbereich anfordern.
• Relevante Kontrollen und Einschränkungen bewerten.
• Verbleibende Anbieter- und Kundenaufgaben zuordnen.
• Eigene Prozess- und Konfigurationsnachweise ergänzen.