NIS2 Art. 21(2), die CC-Serie von SOC 2 und CRA Anhang I, nebeneinander gelesen: Buchstabe für Buchstabe gemappt, haben acht der zehn Massnahmen zumindest teilweisen Gegentext in den beiden anderen Texten. Das teure Risiko eines neuen Frameworks ist die zweite Kopie einer Kontrolle, die Sie bereits betreiben und die zwischen den Audits driftet — und wo die Texte tatsächlich auseinandergehen, beim Monitoring, fällt eine kopierte Kontrolle durch beide.
Die drei Dokumente hinter diesem Beitrag teilen sich normalerweise keinen Schreibtisch. Die Richtlinie (EU) 2022/2555, NIS2, ist offen zugängliches Recht und formuliert ihre Sicherheitsanforderungen als zehn Massnahmen-Buchstaben. Die AICPA Trust Services Criteria, der Text hinter jedem SOC-2-Bericht, formulieren ihre als nummerierte Kriterien; an eine frei zugängliche Kopie zu kommen, verlangte eine Archivsuche, dazu unten mehr. Und die Verordnung (EU) 2024/2847, die Cyberresilienz-Verordnung (CRA), packt ihre Anforderungen in einen Anhang aus Produktanforderungen und Pflichten zur Behandlung von Schwachstellen.
Der Pitch, jedes Mal wenn eines dieser Regelwerke aufschlägt, lautet «neues Framework, neues Projekt». Ich habe die drei Texte nebeneinander gelesen, und ich kaufe das nicht: Sie verlangen weitgehend dieselben Kontrollen. Die echten Kosten zeigen sich später, in den Parallelkopien einer Kontrolle, die Teams pro Framework betreiben, und in dem, was zwischen den Audits mit diesen Kopien passiert.
Drei Texte, eine Liste von Kontrollen
Art. 21(1) der NIS2 verlangt, dass Einrichtungen «geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen ergreifen, um die Risiken für die Sicherheit der Netz- und Informationssysteme […] zu beherrschen», und Art. 21(2) listet, was diese Massnahmen, die «auf einem gefahrenübergreifenden Ansatz beruhen» müssen, «zumindest» umfassen. Zehn Buchstaben (Wortlaut der amtlichen deutschen Fassung):
- (a) — «Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme»
- (b) — «Bewältigung von Sicherheitsvorfällen»
- (c) — «Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement»
- (d) — «Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern»
- (e) — «Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen»
- (f) — «Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen im Bereich der Cybersicherheit»
- (g) — «grundlegende Verfahren im Bereich der Cyberhygiene und Schulungen im Bereich der Cybersicherheit»
- (h) — «Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung»
- (i) — «Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen»
- (j) — «Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung», dazu gesicherte Sprach-, Video- und Textkommunikation sowie «gegebenenfalls gesicherte Notfallkommunikationssysteme»
Die NIS2-Liste ist das sauberste Rückgrat für eine Dreifach-Lektüre. Die Trust Services Criteria decken dasselbe Terrain als Ein-Satz-Kriterien ab, CC1.1–CC9.2, mit Kategorien-Serien (A für Availability) ausserhalb der Common Criteria; CRA Anhang I deckt es als Produkteigenschaften (Teil I) plus acht Herstellerpflichten zur Behandlung von Schwachstellen (Teil II) ab. Also gehen wir Buchstabe für Buchstabe durch: Gibt es Gegentext in den beiden anderen (abgedeckt, teilweise oder fehlend)?
Das Mapping: wo die Texte konvergieren
Eine Regel vorweg: Dieses Mapping erfasst Abdeckung, es erstellt kein Ranking. Einen Sieger zu küren zwischen einer Richtlinie, einem Testierungs-Framework und einer Produktverordnung wäre ein Kategorienfehler. (Die TSC existieren nur auf Englisch; ihre Zitate bleiben deshalb im Original, die CRA-Anker folgen der amtlichen deutschen Fassung.)
| NIS2 21(2) | SOC 2 TSC-Anker | Befund | CRA Anhang I-Anker | Befund |
|---|
| (a) Risikokonzepte | CC3.2 "identifies risks … and analyzes risks"; CC5.3 | abgedeckt | I(1) «angesichts der Risiken ein angemessenes Cybersicherheitsniveau»; I(2)-Chapeau | abgedeckt |
| (b) Vorfallsbewältigung | CC7.3–CC7.5 "defined incident-response program", Recovery | abgedeckt | I(2)(h) Verfügbarkeit «auch nach einem Sicherheitsvorfall»; I(2)(k) | teilweise |
| (c) Kontinuität, Backup, Krise | CC9.1; A1.2 "data backup processes"; A1.3 | abgedeckt* | kein Gegentext (siehe unten) | fehlend |
| (d) Lieferkette | CC9.2 "vendors and business partners" | abgedeckt | nur Komponenten: II(1) SBOM; II(6) «Komponenten Dritter» | teilweise |
| (e) sichere Entwicklung, Schwachstellenbehandlung | CC8.1 Change-Lifecycle; CC7.1 "newly discovered vulnerabilities" | abgedeckt | I(1); II(2) «unverzüglich»; II(5) «koordinierte Offenlegung von Schwachstellen» | abgedeckt |
| (f) Wirksamkeitsbewertung | CC4.1 "ongoing and/or separate evaluations"; CC4.2 | abgedeckt | II(3) das Produkt «regelmäßig und wirksam testen und überprüfen» | teilweise |
| (g) Hygiene und Schulung | CC1.4 "competent individuals"; Schulung nur in Points of Focus | teilweise | kein Gegentext | fehlend |
| (h) Kryptografie-Konzept | CC6.7; Kryptografie nur in Points of Focus | teilweise | I(2)(e) «Verschlüsselung relevanter Daten», gespeichert oder übermittelt | abgedeckt |
| (i) Personalsicherheit, Zugriffskontrolle, Anlagen | CC6.1–CC6.3 "least privilege"; CC6.5; CC1.4/CC1.5 | abgedeckt | I(2)(d) «Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme» |
* Nur mit der Kategorie Availability im Prüfumfang — A1.2 und A1.3 liegen ausserhalb der CC-Common-Criteria.
Die Zahlen brauchen ihre Definitionen, denn die Definition ändert die Zahl. Gegen SOC 2 allein finden alle zehn Buchstaben zumindest teilweisen Gegentext: sieben abgedeckt, drei teilweise. Gegen CRA Anhang I: drei abgedeckt, fünf teilweise, zwei fehlend. Über alle drei zugleich tauchen acht der zehn Massnahmen in jedem Text zumindest teilweise auf. Aber volle Abdeckung überall ist selten: Nach dieser Tabelle sind nur (a) Risikokonzepte und (e) sichere Entwicklung und Schwachstellenbehandlung in allen dreien abgedeckt. Ich würde sagen: Die gemeinsame Basis ist real und gross, und jeder Überlappungs-Prozentzahl, die ohne ihre Definition zitiert wird, würde ich misstrauen.
Zwei Befunde sind Ermessensentscheide, und ich will sie angreifbar im Protokoll haben:
- (h) CRA «abgedeckt». Anhang I nennt Verschlüsselung, ist aber ergebnisförmig (verschlüssle die Daten), wo NIS2 Konzepte für Kryptografie will. Wer eine Ergebnisanforderung nicht als Abdeckung einer Konzeptanforderung gelten lässt, landet bei teilweise.
- (b) CRA «teilweise». Anhang I liefert Produktresilienz nach einem Sicherheitsvorfall; ein Bewältigungsprozess steht nicht im Anhang, und die Meldepflichten des CRA sitzen in Artikel 14, ausserhalb davon. Wer Artikel 14 mitzählt, verschiebt den Befund.
Die Fehlstellen laufen in beide Richtungen, jede belegt durch eine protokollierte Wortsuche, Synonyme eingeschlossen; die Suchen liefen gegen die englischen Textfassungen. NIS2 verlangt zwei Dinge, die Anhang I nie erwähnt: Hygiene und Schulung (training, awareness, hygiene, personnel, staff, employee: je null Treffer) und Betriebskontinuität (backup, disaster recovery, crisis: je null Treffer). Nur der CRA verlangt eine Software-Stückliste «in einem gängigen maschinenlesbaren Format» (II(1); der Begriff kommt weder in NIS2 noch in den TSC vor), die Bereitstellung «mit einer sicheren Standardkonfiguration» (I(2)(b)) und kostenlose, unverzüglich verbreitete Sicherheitsaktualisierungen (II(8)). Und innerhalb von SOC 2 leben Multi-Faktor-Authentifizierung und Kryptografie nur in Points of Focus (der Guidance-Schicht unter jedem Kriterium und der einzigen Schicht, die die Revision 2022 verändert hat), nie in einem Kriteriumssatz.
Wo die Texte auseinandergehen: Monitoring
Das ist die schärfste Trennlinie in der Tabelle. Hier ist CC7.2 von SOC 2, vollständig und im englischen Original:
"The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events."
Sinngemäss: Die Einrichtung überwacht Systemkomponenten und deren Betrieb auf Anomalien, die auf böswillige Handlungen, Naturkatastrophen und Fehler hindeuten, welche die Fähigkeit der Einrichtung beeinträchtigen, ihre Ziele zu erreichen; Anomalien werden analysiert, um festzustellen, ob sie Sicherheitsereignisse darstellen. Zwei laufende Tätigkeiten in einem Satz: Monitoring, das in Betrieb ist, und Analyse dessen, was es zutage fördert.
Jetzt dieselbe Idee in der NIS2 suchen (auch hier: gegen die englische Textfassung). "Anomal-": null Treffer in der gesamten Richtlinie, Erwägungsgründe eingeschlossen. "Logging": null im verfügenden Teil — der einzige Treffer der Richtlinie ist eine beiläufige Erwähnung in einer Diensteliste in Erwägungsgrund 56. Auf Einrichtungsseite taucht "detect" zweimal in Art. 29(1) auf, einer Bestimmung über freiwillige Vereinbarungen zum Austausch von Cybersicherheitsinformationen, und sonst nur innerhalb einer Definition, Art. 6(8): «‹Bewältigung von Sicherheitsvorfällen› alle Maßnahmen und Verfahren zur Verhütung, Erkennung, Analyse und Eindämmung von Sicherheitsvorfällen oder die Reaktion darauf und die Erholung davon». Die NIS2 faltet Erkennung per Definition in Buchstabe (b) und verlangt in Art. 21(2) an keiner Stelle Monitoring, Logs oder Anomalie-Auswertung.
Der Monitoring-Haken des CRA zeigt auf das Produkt: Nach I(2)(l) müssen Produkte «sicherheitsbezogene Informationen durch Aufzeichnung und/oder Überwachung einschlägiger interner Vorgänge wie Zugang zu Daten, Diensten oder Funktionen und Änderungen daran bereitstellen und den Nutzern einen Opt-out-Mechanismus zur Verfügung stellen». Das ist eine Logging-Fähigkeit, mit der das Produkt ausgeliefert wird, Nutzer-Opt-out eingeschlossen, und kein organisatorischer Analyseprozess. "Anomal-": null Treffer in der gesamten Verordnung.
Hier ist die Drift in Evidenzbegriffen. Ein freigegebenes Verfahren zur Vorfallsbewältigung plus ein gepflegtes Vorfallsregister erfüllt den Wortlaut von 21(2)(b), gelesen mit Art. 6(8): Die Richtlinie verlangt Massnahmen und Verfahren. Derselbe Ordner fällt durch beide Hälften von CC7.2: Nichts zeigt Monitoring im Betrieb, nichts zeigt analysierte Anomalien. Umgekehrt: Ein Alert-Triage-Log aus Ihrem Monitoring-Stack belegt CC7.2, deckt aber weder die Spanne von Verhütung bis Erholung in 21(2)(b) noch CRA I(2)(l) ab, das danach fragt, was das Produkt aufzeichnet und ob die Nutzer sich abmelden können.
ISO 27001 hat seine eigene Monitoring-Kontrolle in Annex A, A.8.16. Ich kann sie benennen. Zitieren kann ich sie nicht, und Sie vermutlich auch nicht.
Das Mapping, das Sie nicht prüfen können
NIS2 und CRA sind offenes Recht auf EUR-Lex: frei zu lesen, frei zu durchsuchen. Die Trust Services Criteria sind offiziell, aber sperrig: Der Download der aktuellen Ausgabe sitzt hinter einem AICPA-Login (das JSON der Seite selbst markiert die Datei als "locked"), und die zitierfähigen Kopien sind ein Redline-PDF auf AICPAs CDN und eine im Wayback-Archiv gesicherte Ausgabe von 2020. Das war die Archivsuche. Gegengeprüft sind die dreissig Kriterientexte hinter diesem Mapping in beiden Ausgaben Wort für Wort identisch.
ISO/IEC 27001:2022 sagt Ihnen auf seiner Katalogseite, dass es existiert — "Published (Edition 3, 2022)" — und dass ein konformes ISMS die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen durch Anwendung eines Risikomanagementprozesses wahrt (im Original: "preserves the confidentiality, integrity and availability of information by applying a risk management process"). Der Text selbst ist eine kostenpflichtige Norm: CHF 155 laut Katalogseite. Wenn Ihnen also ein Anbieter ein Mapping-Sheet mit einer ISO-27001-Spalte reicht: Die NIS2- und CRA-Zeilen können Sie gegen das Gesetz prüfen, SOC 2 teilweise gegen archivierten Text, und keine einzige Annex-A-Behauptung können Sie prüfen, ohne die Norm zu kaufen. Ein Mapping, das Sie nicht prüfen können, ist nicht zwingend falsch; Sie nehmen es auf Treu und Glauben.
Ein Kontrollset, gemappt — und was es Sie kostet
So würde ich es betreiben: ein gepflegtes Kontrollset, mit den NIS2-Buchstaben, TSC-Kriterien und Anhang-I-Punkten pro Kontrolle als Mapping-Notizen festgehalten, und die Divergenz-Zeilen — (b), (g), (h), der CC7.2-Bruch — namentlich nachverfolgt, mit einem Owner. Acht von zehn Buchstaben teilen Boden in allen drei Texten; eine zweite und dritte Kopie dieser Kontrollen schafft vor allem zusätzliche Stellen, an denen Wortlaut und Evidenz aufhören können übereinzustimmen, ohne dass jemand dafür eingeteilt ist, es zu bemerken.
Ein einzelnes Set löst die Divergenz nicht auf; diese Kosten bleiben:
- Ein Evidenzstrom nur für SOC 2 bleibt. CC7.2 will Monitoring-Abdeckung und Aufzeichnungen der Anomalie-Analyse, die nichts im NIS2-Text verlangt; die Mapping-Notiz, die genau das festhält, verhindert, dass dieser Strom «wegvereinfacht» wird.
- CRA-Zeilen brauchen Engineering-Evidenz, keine Policy-Evidenz. SBOM, sichere Standardkonfiguration, Update-Verbreitung, Produkt-Logging mit Opt-out: alles Release-Artefakte. Eine organisatorische Kontrolle kann sie nicht erfüllen.
- Manche Artefakte haben nirgends ein Gegenstück. Anhang I Teil II(4) und II(5) erwarten veröffentlichte Informationen über behobene Schwachstellen und eine Strategie für die koordinierte Offenlegung von Schwachstellen; nichts in SOC 2 oder 21(2) produziert diese.
- Scope-Abhängigkeit auf der SOC-2-Seite. Das «abgedeckt» von Buchstabe (c) stützt sich auf A1.2/A1.3; ein Engagement nur mit der Kategorie Security lässt Kontinuität bei teilweise.
Drei Fragen fallen direkt aus den Mapping-Zeilen:
- An wie vielen Orten lebt Ihr Zugriffskontroll-Konzept gerade? Zeile (i): drei Texte, drei Vokabulare — «Konzepte für die Zugriffskontrolle», "least privilege", «Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme».
- Wenn Ihr SOC-2-Auditor und Ihre NIS2-Aufsicht in derselben Woche Ihre Evidenz zur Vorfallsbewältigung anfordern würden, bekämen sie dasselbe Dokument? Zeile (b): ein ausgeführtes "defined incident-response program", gegen Verfahren über die Spanne von Verhütung bis Erholung, gegen die veröffentlichten Offenlegungen und Update-Aufzeichnungen des CRA.
- Welches Ihrer Frameworks verlangt tatsächlich Anomalie-Analyse, und stammt Ihre Monitoring-Evidenz aus der Kontrollkopie, die dieses Framework auditiert? Die CC7.2-Zeile: Der NIS2-Text fragt nie danach; der Satz von CC7.2 besteht daraus.
Wenn die Antworten «an mehreren», «nein» und «müsste ich nachsehen» lauten, läuft die Drift bereits, und die Mapping-Notizen sind der günstigste Ort, sie einzufangen.
Ein Kontrollset beantwortet, wie man drei Frameworks nebeneinander betreibt; es beantwortet nicht, wo für ein einzelnes davon die Untergrenze liegt. Für den CRA hat diese Frage eine überraschend spezifische Form, und Vadim hat sie am Dienstag gegen ENISAs Reifegradmodell auseinandergenommen: Welches Level in ENISAs KMU-Reifegradmodell ist die tatsächliche CRA-Untergrenze?
devguard hält ein Kontrollset über Frameworks hinweg gemappt, Notizen auf Klauselebene und Divergenz-Zeilen eingeschlossen: devguard.ch.