SOC 2 und ISO 27001: Mapping und Doppelnutzung

Problem in der Praxis

In vielen Organisationen entstehen die beiden Welten getrennt und zu unterschiedlichen Zeitpunkten. Im EU-Geschäft fragen Kunden, Ausschreibungen oder regulatorische Erwartungen nach ISO 27001. Sobald ein US- oder SaaS-Kunde im Vendor-Assessment einen SOC-2-Bericht verlangt, wird parallel ein zweites Projekt gestartet, oft mit eigenem Dienstleister, eigenem Tool und eigener Evidenzsammlung.

Das Ergebnis sind zwei Programme, die dasselbe Sicherheitsfundament beschreiben, aber nicht miteinander sprechen. Dieselben Zugriffs-, Change- und Betriebskontrollen werden zweimal dokumentiert, belegt und geprüft. Teams empfinden das als Doppelbelastung, das Management sieht steigende Kosten ohne Mehrwert, und niemand kann zuverlässig sagen, wo sich die Nachweise decken und wo nicht. Verschärft wird das durch ein verbreitetes Missverständnis: Eine ISO-27001-Zertifizierung wird dem US-Kunden als gleichwertiger SOC-2-Ersatz angeboten, oder umgekehrt soll ein SOC-2-Bericht die ISO-Zertifizierung ersetzen. Beides trägt nur teilweise.

CISO-Einordnung

Der Kern des Unterschieds liegt in drei Dimensionen: Was wird geprüft, was kommt heraus, und für wen.

Was geprüft wird. ISO 27001 prüft ein Managementsystem, also ob die Organisation Informationssicherheit systematisch plant, betreibt, überwacht und verbessert, einschließlich Führungsverantwortung, Risikomanagement, internem Audit und Managementbewertung. SOC 2 prüft Kontrollen gegen die Trust Services Criteria. Die Sicherheitskategorie (Common Criteria) ist immer enthalten; weitere Kategorien wie Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Schutz personenbezogener Daten kommen nach Relevanz und Kundenanforderung hinzu. Die Common Criteria sind konzeptionell am COSO-Rahmenwerk für interne Kontrolle orientiert. Der verbindliche Wortlaut der Kriterien gehört urheberrechtlich der AICPA; maßgeblich ist deren Originalpublikation (TSP Section 100, "2017 Trust Services Criteria" mit revidierten Points of Focus 2022).

Was herauskommt. ISO 27001 führt zu einem Zertifikat einer akkreditierten Zertifizierungsstelle. SOC 2 führt zu einem Attestierungsbericht einer CPA-Firma, entweder als Type I (Eignung der Kontrollgestaltung zu einem Stichtag) oder als Type II (zusätzlich betriebliche Wirksamkeit über einen Zeitraum, typischerweise 6 bis 12 Monate). Ein Zertifikat ist ein knappes Konformitätssiegel; ein SOC-2-Bericht ist ein umfangreiches Dokument mit Systembeschreibung, Kontrollen und Prüfergebnissen.

Für wen. Das ISO-Zertifikat ist frei vorzeigbar. Der SOC-2-Bericht ist für einen eingeschränkten Empfängerkreis gedacht (restricted use), typischerweise Kunden, deren Prüfer und Interessenten unter Vertraulichkeit; für die breite Öffentlichkeit ist SOC 3 vorgesehen. Marktseitig ist ISO 27001 im EU- und regulierten Umfeld etabliert, SOC 2 im US- und SaaS-B2B-Geschäft.

Die hohe Überschneidung entsteht, weil beide auf denselben anerkannten Kontrollfeldern aufsetzen: Zugriffssteuerung, Change Management, Systembetrieb, Risikobewertung, Lieferantensteuerung, Incident Response und Monitoring. Genau das macht Doppelnutzung möglich.

Umsetzungsperspektive

Der tragende Gedanke lautet: eine Kontrollbasis, einmal mappen, mehrfach nutzen. Aus CISO-Sicht lässt sich das in wenige Schritte gliedern.

• Gemeinsames Fundament: Ein belastbares ISMS dient als Betriebssystem für beide Nachweise. Risikobewertung, Kontrollset, Verantwortlichkeiten und Evidenzhaltung werden einmal aufgebaut.
• Mapping: Die vorhandenen Kontrollen werden den ISO-Sicherheitsmaßnahmen und den SOC-2-Kategorien zugeordnet, sodass sichtbar wird, welche Kontrolle welche Anforderung bedient und wo Lücken bleiben.
• Scope bewusst trennen: Der ISO-Scope beschreibt die Grenzen des Managementsystems, der SOC-2-Scope das konkrete System beziehungsweise den Service und die einbezogenen Kategorien. Beide müssen nicht deckungsgleich sein.
• Evidenz im Regelbetrieb: Type II verlangt Wirksamkeit über einen Zeitraum. Nachweise sollten laufend entstehen und zugleich internes Audit und Überwachung der ISO-Welt speisen.
• Reihenfolge nach Marktbedarf: Viele EU-Organisationen starten mit ISO 27001 und setzen SOC 2 für den US-Markt darauf auf; der umgekehrte Weg ist ebenso möglich. Entscheidend ist der Kundenbedarf, nicht eine Rangordnung der Frameworks.

Typische Fehler

1. ISO 27001 und SOC 2 werden als getrennte Projekte mit eigenen Tools, Dienstleistern und Evidenzbeständen betrieben.
2. Ein ISO-Zertifikat wird gegenüber US-Kunden als vollwertiger SOC-2-Ersatz dargestellt oder umgekehrt.
3. Das Mapping wird als einmalige Tabelle behandelt statt als gepflegte Zuordnung, die Lücken sichtbar macht.
4. Der SOC-2-Scope wird unreflektiert mit dem ISMS-Scope gleichgesetzt, obwohl beide unterschiedlich abgegrenzt sein sollten.
5. Managementsystem-Elemente wie internes Audit, Managementbewertung und Führungsverantwortung werden vernachlässigt, weil SOC 2 sie nicht in dieser Form verlangt.
6. Optionale SOC-2-Kategorien werden ohne echte Kundenanforderung in den Scope genommen und treiben den Aufwand unnötig.

Risiken und Trade-offs

Das Mapping ist kein Eins-zu-eins. Die Überschneidung der Kontrollen ist groß, aber jedes Framework hat einen Bereich, den das andere nicht voll abdeckt. ISO 27001 verlangt Managementsystem-Elemente, die SOC 2 nicht in gleicher Form fordert; SOC 2 verlangt im Type II den Nachweis betrieblicher Wirksamkeit über einen Zeitraum, wobei im Bericht etwaige festgestellte Ausnahmen (exceptions) ausgewiesen werden. Wer Doppelnutzung plant, muss diese Restbereiche bewusst schließen, statt von vollständiger Äquivalenz auszugehen.

Hinzu kommen die Rollen der Prüfer und die Kostenfrage. Eine akkreditierte Zertifizierungsstelle und eine CPA-Firma sind verschiedene Instanzen; ein Nachweis ersetzt den anderen formal nicht. Ein knapp gewählter SOC-2-Scope kann zudem nach außen mehr suggerieren, als tatsächlich geprüft wurde. Beide Nachweise verursachen laufenden Aufwand, und der Mehrwert der Doppelnutzung entsteht nur, wenn die gemeinsame Kontrollbasis und das Mapping wirklich gepflegt werden; sonst entstehen trotz Mapping zwei Parallelwelten.

Entscheidungspunkte

• Welche Märkte und Kunden verlangen welchen Nachweis, und ist beides zugleich erforderlich?
• Wird mit ISO 27001 oder mit SOC 2 begonnen, und wie wird der zweite Nachweis darauf aufgesetzt?
• Wie werden ISMS-Scope und SOC-2-Scope sinnvoll abgegrenzt, ohne sie unkritisch gleichzusetzen?
• Welche optionalen SOC-2-Kategorien sind durch konkrete Kundenanforderungen begründet?
• Wie wird das Mapping organisatorisch verankert, damit es Lücken laufend sichtbar macht?
• Welche Evidenz kann beide Welten zugleich bedienen, und welche muss spezifisch erzeugt werden?

Praktische Empfehlungen

1. Bauen Sie eine gemeinsame Kontrollbasis auf einem ISMS auf und behandeln Sie SOC 2 und ISO 27001 als zwei Sichten darauf.
2. Pflegen Sie ein lebendes Mapping, das Kontrollen den Anforderungen beider Frameworks zuordnet und Lücken offen ausweist.
3. Grenzen Sie ISO-Scope und SOC-2-Scope bewusst ab und begründen Sie jede einbezogene SOC-2-Kategorie mit echtem Kundenbedarf.
4. Gestalten Sie Nachweise so, dass sie internes Audit, Überwachungsaudit und SOC-2-Beobachtungszeitraum zugleich speisen.
5. Kommunizieren Sie klar, dass Zertifikat und Attestierungsbericht unterschiedliche Ergebnisse sind und einander nicht formal ersetzen.
6. Ziehen Sie für verbindliche Detailfragen die ISO-Originalnorm sowie die AICPA-Originalpublikation und eine qualifizierte CPA-Firma heran.

Relevante Normreferenzen

• ISO/IEC 27001: zertifizierbares Managementsystem für Informationssicherheit; Referenz für die ISMS-Anforderungen und den Zertifizierungsansatz.
• ISO/IEC 27002: Referenz für die ausgestaltenden Sicherheitsmaßnahmen, die im Mapping mit SOC-2-Kontrollen abgeglichen werden.
• AICPA, TSP Section 100 (Trust Services Criteria): maßgebliche Originalquelle für die Kriterien von SOC 2 und SOC 3. Version, Ausgabe und Stand sind vor verbindlicher Aussage gegen die Originalpublikation zu prüfen.
• AICPA, SOC for Service Organizations (System and Organization Controls): Referenzrahmen für den Attestierungsansatz und die SOC-Berichtsfamilie.