Common Criteria und der COSO-Bezug: das Kontrollfundament von SOC 2

Problem in der Praxis

Viele Security-Teams gehen an SOC 2 wie an eine Technik-Checkliste heran: Verschlüsselung, Zugriffskontrolle, Logging, Patch-Management. Das ist richtig, greift aber zu kurz. Im SOC-2-Bericht zählt nicht nur, ob eine Maßnahme existiert, sondern ob sie aus einem geordneten Kontrollumfeld heraus betrieben, überwacht und verbessert wird.

Daraus entstehen typische Überraschungen: Ein Unternehmen hat moderne Sicherheitstechnik, scheitert aber an der Frage, wie das Management Verantwortung wahrnimmt, wie Risiken bewertet und wie Kontrollwirksamkeit überwacht wird. Genau diese Governance- und Steuerungsebene adressieren die Common Criteria. Wer sie als reine IT-Anforderung missversteht, baut Nachweise an der falschen Stelle auf. Hinzu kommt eine Begriffsfalle: "Common Criteria" hat hier nichts mit dem gleichnamigen ISO/IEC-Standard für IT-Produktsicherheit zu tun.

CISO-Einordnung

Der Schlüssel ist die Herkunft. COSO beschreibt interne Kontrolle als Zusammenspiel mehrerer Komponenten: Kontrollumfeld, Risikobewertung, Kontrollaktivitäten, Information und Kommunikation sowie laufende Überwachung. Die Common Criteria übernehmen diese Denkweise und übersetzen sie in den Kontext von Informations- und Systemsicherheit.

Auf diesem Fundament ergänzen sie sicherheits- und technologiespezifische Themenbereiche. Konzeptionell gehören dazu der logische und physische Zugriffsschutz, der sichere Systembetrieb, das Change Management und die Risikominderung. Diese Bereiche sind als Konzept zu verstehen, nicht als abzuhakende Nummernliste. Die Botschaft für den CISO: SOC 2 belegt nicht primär gute Technik, sondern gute Steuerung von Sicherheit. Hier liegt auch die Brücke zum ISMS, das die Steuerungslogik der Common Criteria weitgehend aus dem Betrieb heraus liefert.

Umsetzungsperspektive

Aus CISO-Sicht lohnt es sich, die Common Criteria in zwei Schichten zu denken. Die Steuerungsschicht folgt der COSO-Logik: Wer im Management trägt erkennbar Verantwortung für Sicherheit? Wie werden Risiken systematisch bewertet? Wie werden Erwartungen kommuniziert, intern wie zu Dienstleistern? Wie wird überwacht, ob Kontrollen wirken? Diese Fragen beantwortet keine Technik, sondern Prozesse, Verantwortlichkeiten und nachvollziehbare Entscheidungen.

Die Kontrollschicht ist sicherheitsbezogen: Zugriffsschutz, Systembetrieb, Change Management und Umgang mit Risiken. Hier liegt die operative Stärke vieler Teams ohnehin; die Kunst besteht darin, diese Kontrollen sichtbar an die Steuerungsschicht anzubinden. Praktisch bewährt sich, je Kontrollbereich vier Dinge zu klären: das adressierte Risiko, die verantwortliche Rolle, die konkrete Kontrolle und den Nachweis aus dem Betrieb. Genau diese Verkettung will eine spätere Type-II-Prüfung über den Beobachtungszeitraum hinweg sehen.

Typische Fehler

1. Die Common Criteria werden als reine IT-Sicherheits-Checkliste verstanden und die COSO-Steuerungsschicht wird vernachlässigt.
2. Kontrollumfeld und Management-Verantwortung werden nicht belegbar gemacht, weil sie als "weich" gelten.
3. Sicherheitskontrollen existieren technisch, sind aber nicht nachvollziehbar an Risikobewertung und Überwachung angebunden.
4. "Common Criteria" wird mit dem ISO/IEC-Produktsicherheitsstandard gleichen Namens verwechselt.
5. Es wird versucht, Kriterienwortlaut zu reproduzieren, statt eigene Kontrollen zu beschreiben und auf die Originalpublikation zu verweisen.

Risiken und Trade-offs

Ein zu technikzentrierter Aufbau erzeugt einen Bericht, der oberflächlich beeindruckt, bei der Steuerungslogik aber schwach bleibt. Ein zu governance-lastiger Aufbau ohne belastbare operative Kontrollen erzeugt das umgekehrte Problem: viel Dokumentation, wenig wirksame Sicherheit. Die Common Criteria geben zudem nur Struktur vor, keine fertige Implementierung; zu generische Kontrollen wirken aufgesetzt, zu kleinteilige werden im Betrieb nicht durchgehalten.

Hinzu kommt ein Lizenzrisiko in der Kommunikation selbst: Kriterienwortlaut, Common-Criteria-Nummerierung und Points of Focus sind AICPA-urheberrechtlich und dürfen nicht reproduziert werden. Interne Beschreibungen folgen den eigenen Kontrollen.

Entscheidungspunkte

• Behandeln wir SOC 2 als Steuerungsnachweis oder nur als Technikbeleg, und passt unsere interne Kommunikation dazu?
• Ist die COSO-Steuerungsschicht (Verantwortung, Risikobewertung, Kommunikation, Überwachung) belegbar vorhanden oder nur informell gelebt?
• Nutzen wir ein bestehendes ISMS als Fundament für die Steuerungsschicht der Common Criteria?
• Wie verbinden wir operative Sicherheitskontrollen nachvollziehbar mit Risiko und Überwachung?

Praktische Empfehlungen

1. Erklären Sie intern früh, dass die Common Criteria ein internes Kontrollsystem in COSO-Logik abbilden, nicht nur Technik.
2. Bauen Sie zuerst die Steuerungsschicht belegbar auf: Verantwortung, Risikobewertung, Kommunikation und Überwachung der Wirksamkeit.
3. Verankern Sie jede wesentliche Sicherheitskontrolle an Risiko, Owner und Nachweis, sodass der Zusammenhang sichtbar wird.
4. Nutzen Sie ein vorhandenes ISMS als Steuerungsgerüst, statt eine parallele SOC-2-Welt aufzubauen.
5. Verwenden Sie eigene Kontrollformulierungen und verweisen Sie für verbindliche Kriterien auf TSP Section 100; reproduzieren Sie keine Kriterienlisten, Nummern oder Points of Focus.

Relevante Normreferenzen

• AICPA, Trust Services Criteria, TSP Section 100: maßgebliche Originalpublikation für die Kategorien und die Common Criteria. Verbindlicher Wortlaut, Nummerierung und Points of Focus ausschließlich dort; den aktuellen Versionsstand vor verbindlicher Aussage in der Originalpublikation prüfen.
• COSO, Internal Control, Integrated Framework: Referenzrahmen für interne Kontrolle, an den die Common Criteria angelehnt sind.
• ISO/IEC 27001: allgemeine Referenz für ein zertifizierbares Informationssicherheits-Managementsystem (Abgrenzung zur Attestierungslogik von SOC 2).