ENISAs offizielles Mapping verknüpft 48 der 49 Anforderungsüberschriften des Anhangs von 2024/2690 mit Controls aus Annex A der ISO 27001:2022 — hier der vollständige Crosswalk als normalisiertes CSV, der Vorbehalt, den ENISA daran geknüpft hat, und wo die eigentliche Arbeit unterhalb der Überschriftenebene steckt.
ENISAs offizielles Mapping verknüpft 48 der 49 Anforderungsüberschriften des Anhangs von 2024/2690 mit Controls aus Annex A der ISO 27001:2022 — hier der vollständige Crosswalk als normalisiertes CSV, der Vorbehalt, den ENISA daran geknüpft hat, und wo die eigentliche Arbeit unterhalb der Überschriftenebene steckt.
Das »NIS2-Modul« auf dem Verlängerungsangebot eines Unternehmens der digitalen Infrastruktur besteht im Kern aus zwei öffentlichen Dokumenten: der Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 und einer 35 KB grossen Tabelle, die ENISA im Juni 2025 veröffentlicht hat. Die Verordnung überführt die Massnahmenliste in Art. 21(2) NIS2 in ausformulierte technische Anforderungen für elf Klassen von Einrichtungen. Die Tabelle ordnet jede Anforderungsüberschrift den Klausel- und Control-IDs der ISO/IEC 27001:2022 zu. Dieser Beitrag veröffentlicht den Crosswalk zwischen beiden als normalisiertes, maschinenlesbares CSV. Die Kennzahlen, per Skript aus ENISAs Mapping-Tabelle abgeleitet: von ihren 49 Datenzeilen sind 48 mindestens einem Annex-A-Control zugeordnet (98,0 %), eine verweist nur auf Managementsystem-Klauseln, und null sind ohne Zuordnung. Wer ein Zertifikat nach ISO 27001:2022 hält, für den ist die Konkordanzebene des angebotenen Moduls öffentlich und nahezu vollständig. Was bleibt, ist schwieriger als eine Tabelle — und gehört ebenso wenig dem Anbieter.
Artikel 1 benennt den Adressatenkreis der Verordnung genau:
„In dieser Verordnung werden in Bezug auf DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste, Anbieter verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter (im Folgenden „betreffende Einrichtungen") die technischen und methodischen Anforderungen der in Artikel 21 Absatz 2 der Richtlinie (EU) 2022/2555 genannten Maßnahmen festgelegt und die Fälle präzisiert, in denen ein Sicherheitsvorfall gemäß Artikel 23 Absatz 3 der Richtlinie (EU) 2022/2555 als erheblich anzusehen ist."
Elf Klassen von Einrichtungen. Wer nicht auf dieser Liste steht, fällt aus dem Anwendungsbereich von 2024/2690 heraus: Art. 21 NIS2 erreicht wesentliche und wichtige Einrichtungen weiterhin allgemein über nationales Umsetzungsrecht, doch der nachfolgende Anhang bindet nur die aufgeführten Klassen. Die Liste stammt aus Art. 21(5) NIS2, der die Kommission verpflichtete, für genau diese Anbieter bis zum 17. Oktober 2024 Durchführungsrechtsakte zu erlassen; 2024/2690 ist dieser Rechtsakt, erlassen am Tag der Frist.
Artikel 2(1) nimmt die Zuordnung vor:
„Für die betreffenden Einrichtungen sind im Anhang dieser Verordnung die technischen und methodischen Anforderungen der in Artikel 21 Absatz 2 Buchstaben a bis j der Richtlinie (EU) 2022/2555 genannten Risikomanagementmaßnahmen im Bereich der Cybersicherheit festgelegt."
Der Anhang besteht aus 13 nummerierten Abschnitten, deren Überschrift jeweils den umgesetzten Buchstaben aus Art. 21(2) trägt:
Die Zuordnung ist n:m. Zwei Abschnitte setzen Buchstabe a um. Buchstabe i (in den Worten der Richtlinie „Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen") wird von vier Abschnitten bedient: 10, 11, 12 und 13. Abschnitt 11 verweist auf zwei Buchstaben zugleich, Abschnitt 13 auf drei. Dreizehn Abschnitte über zehn Buchstaben, gezählt aus den Klammerzusätzen der Abschnittsüberschriften im Verordnungstext.
Eine strukturelle Tatsache für den Rest dieses Beitrags: unterhalb der Abschnittsebene tragen die Anforderungen x.y-Überschriften (3.2 Überwachung und Protokollierung) und werden dann auf x.y.z-Ebene ausformuliert (3.2.1 bis 3.2.7). Das Mapping, das wir gleich betrachten, endet bei x.y. Die Verordnung nicht.
ENISA veröffentlichte ihre Technical Implementation Guidance zu 2024/2690 am 26. Juni 2025: ein 170-seitiges Guidance-PDF, Version 1.0, dazu eine begleitende Mapping-Tabelle in Excel. Das ISO-Mapping existiert nur in der Excel-Datei. Der Leitfaden sagt es selbst (gedruckte S. 10) — und weil ENISA ausschliesslich auf Englisch publiziert, stehen ENISA-Zitate im Folgenden im englischen Original, jeweils mit einer sinngemässen deutschen Wiedergabe: „The mapping to standards and frameworks is available on the ENISA website in Excel format." Sinngemäss: Das Mapping auf Normen und Frameworks ist auf der ENISA-Website im Excel-Format verfügbar.
Das PDF enthält keine eigene Mapping-Tabelle. Es gibt im gesamten Dokument keine einzige „Table N"-Beschriftung, und jeder Verweis im Text auf eine Mapping-Tabelle ist eine Fussnote. Neun dieser Fussnoten sind Überbleibsel aus dem Konsultationsentwurf: Die Fussnoten (33), (49), (51), (54), (61), (66) und (72) lauten weiterhin „in the mapping table at the end of this section" (sinngemäss: in der Mapping-Tabelle am Ende dieses Abschnitts), und (52) und (56) verweisen auf „the standards in the mapping table" (sinngemäss: die Normen in der Mapping-Tabelle) und zeigen damit auf Tabellen, die keinem Abschnitt der veröffentlichten Datei folgen. Eine Folie, die „die Mapping-Tabelle im ENISA-Leitfaden" zitiert, zitiert eine Tabelle, die nicht existiert; die Quelle ist die Tabelle.
Die Tabelle bewegt sich zudem. Die Datei, auf die die Landing-Page heute verlinkt, ist Mapping table version 1.2, hochgeladen im September 2025; die Juni-Fassung war Version 1.0. Version 1.2 trägt einen Changelog: v1.1 (10. Juli 2025) „Removed references to older version of ISO (A9)in measures 11.1, 11.2, 11.3" (Abstände wie im Druck; sinngemäss: Verweise auf die ältere ISO-Version (A9) in den Massnahmen 11.1, 11.2, 11.3 entfernt), und v1.2 (21. August 2025) korrigierte allein die belgische CyFun-Spalte. Unsere Ableitung auf v1.0 und auf v1.2 erzeugt einen byte-identischen Crosswalk, weil die A9-Referenzen, die v1.1 löschte, dieselben sind, die unsere Validierung bereits ausgeschlossen hatte; mehr dazu bei Zeile 11.1 weiter unten. Eine Datei, die sich unter einer stabilen Landing-Page verändert, ist das Argument dafür, das eigene Artefakt mit einem wiederholbaren Skript abzuleiten, statt es aus der Version abzutippen, die man zufällig heruntergeladen hat.
ENISA sagt auch, was das Mapping nicht ist. Gedruckte S. 10 des Leitfadens:
„The mapping should not be interpreted as a measure of equivalency among different standards or frameworks. It simply refers to relevant requirements in these standards or frameworks without assessing whether these fully cover the requirements of the regulation."
Sinngemäss: Das Mapping sollte nicht als Massstab für Äquivalenz zwischen verschiedenen Normen oder Frameworks verstanden werden. Es verweist lediglich auf relevante Anforderungen in diesen Normen oder Frameworks, ohne zu bewerten, ob diese die Anforderungen der Verordnung vollständig abdecken.
Und gedruckte S. 9, zum Leitfaden als Ganzem: „The guidance, examples of evidence and tips are non-exhaustive. Their partial or complete implementation does not assume compliance or conformity with the requirements of the regulation." (Sinngemäss: Der Leitfaden, die Nachweisbeispiele und die Tipps sind nicht abschliessend. Ihre teilweise oder vollständige Umsetzung setzt keine Einhaltung oder Konformität mit den Anforderungen der Verordnung voraus.) Das Mapping „was done only to horizontal standards and for specific topics" (ebenfalls gedruckte S. 10; sinngemäss: erfolgte nur zu horizontalen Normen und für bestimmte Themen). Zusammengelesen ist der ehrliche Gebrauch des Crosswalks dieser: Er sagt einem zertifizierten Inhaber, welche Nachweise zuerst zu ziehen sind. Er sagt niemandem, dass ein Zertifikat die Verordnung erfüllt.
Dasselbe Blatt mappt auch auf NIST CSF 2.0, ETSI EN 319 401, CEN/TS 18026:2024 und fünf nationale Frameworks; diese Spalten sind hier ausser Betracht.
Unten steht das vollständige Mapping, alle 49 Zeilen, als CSV. Das Schema: point_no und title_2690 stammen aus ENISAs Mapping-Tabelle und entsprechen den Anhangsüberschriften der Verordnung. iso_clauses enthält Verweise auf Managementsystem-Klauseln der ISO/IEC 27001:2022, annex_a_controls enthält Control-IDs aus Annex A (gemäss der Lizenz der Norm: nur IDs, nirgends ISO-Text in diesem Artefakt). evidence_example ist meine eigene Kurzfassung in höchstens zehn Worten des ersten Aufzählungspunkts im Block EXAMPLES OF EVIDENCE des ENISA-Leitfadens zum jeweiligen Punkt; sie leitet sich ausschliesslich aus ENISAs Text ab. Die Feldnamen und Werte des maschinenlesbaren Blocks bleiben aus Gründen der Wiederverwendbarkeit unübersetzt in Englisch.
coverage ist mechanisch: mapped bedeutet mindestens einen Verweis auf ein Annex-A-Control, clauses-only bedeutet Verweise auf Managementsystem-Klauseln und sonst nichts, none bedeutet eine leere ISO-Zelle. Es gibt bewusst keine Klasse namens full, denn eine Klasse namens full würde die Äquivalenz behaupten, die ENISA gerade verneint hat.
Die Zahlen, aus der Mapping-Tabelle v1.2 durch ein Skript abgeleitet, das mit den Quellartefakten dieses Beitrags samt den Rohzellwerten ausgeliefert wird: mapped 48 von 49 (98,0 %), clauses-only 1 von 49 (Zeile 7.1), none 0. Zehn der 49 Zeilen tragen mindestens einen Verweis auf eine Managementsystem-Klausel. Hier gibt es kein 80/20; auf Überschriftenebene landet nahezu alles im Anhang in einem Terrain, für das ein zertifizierter Inhaber bereits Nachweise besitzt.
Anmerkung zur Normalisierung: 13 der 49 Zeilen wurden repariert, bevor die IDs maschinell nutzbar waren. Ein griechisches Grossbuchstaben-Α (U+0391) steht in Referenzen über die Zeilen 2.1 und 11.1 bis 11.7 anstelle des lateinischen A; bei zwei Referenzen fehlt ein Punkt (A5.7, A5.29); fünf tragen verirrte interne Leerzeichen (A.5 .24, A. 5.30, A. 7.11, A. 7.3, A. 7.1). Alle Reparaturen stammen von uns, sind protokolliert und bewahren die Rohwerte; nichts davon ist ENISAs Darstellung. Vier Referenzen wurden markiert und ausgeschlossen statt korrigiert: 5.28 in Zeile 10.4, die in der Ausgabe 2022 keine kanonische Klauselnummer ist und plausibel eine fehlerhaft eingetippte Control-Referenz darstellt (in v1.2 weiterhin vorhanden; ausgelassen bis zu einer menschlichen Entscheidung), sowie A9/A.9 in den Zeilen 11.1 bis 11.3, Kennungen aus der Ausgabe 2013 der Norm, die ENISA selbst in v1.1 entfernt hat.
Eine Zeile sei vor den Daten wiederholt, weil sie neben die Daten gehört: Dieses Mapping „should not be interpreted as a measure of equivalency" (ENISA-Leitfaden, gedruckte S. 10; sinngemäss: sollte nicht als Massstab für Äquivalenz verstanden werden).
Sieben Zeilen zeigen die Textur. Für jede: was der Anhang der Verordnung verlangt, worauf das Mapping zeigt, was ENISA als Nachweis auflistet.
Zeile 1.1: der saubere Treffer. Die Anforderung an das Sicherheitskonzept mappt auf die Klauseln 5.2 und 9.3 sowie die Controls A.5.1, A.5.4 und A.5.36 (Konzepte, Managementverantwortung, Einhaltung von Konzepten; meine Bezeichnungen, nicht die der ISO). Anhangspunkt 1.1.1 führt elf verpflichtende Konzeptelemente auf, (a) bis (k), bis hinunter zu „k) das Datum der förmlichen Genehmigung durch die Leitungsorgane der betreffenden Einrichtungen … enthalten." Punkt 1.1.2: „Das Konzept für die Sicherheit von Netz- und Informationssystemen wird von den Leitungsorganen mindestens jährlich sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken überprüft und – soweit angemessen – aktualisiert. Das Ergebnis der Überprüfung wird dokumentiert." ENISAs erster Nachweispunkt (gedruckte S. 14) ist das „documented policy on the security of network and information systems which contains the elements required by points 1.1.1 (a) to 1.1.1 (k)" (sinngemäss: dokumentiertes Konzept für die Sicherheit von Netz- und Informationssystemen, das die durch die Punkte 1.1.1 (a) bis 1.1.1 (k) geforderten Elemente enthält). Ein zertifizierter Inhaber hat das Konzept und die Überprüfungsnachweise. Die lohnende Prüfung ist die Vollständigkeit von (a) bis (k); ein im Dokument selbst gedrucktes Genehmigungsdatum ist die Art von Element, die ein bestehendes Konzept übersieht.
Zeile 2.1: das Normalisierungsbeispiel. Die rohe ISO-Zelle, identisch in v1.0 und v1.2: 6.1, 6.1.2, 6.1.3, 6.2, 8.2, 8.3, A5.7, Α.5.19, Α.5.20, Α.5.21. Ein fehlender Punkt und drei griechische Grossbuchstaben-Α in einer Zelle. Normalisiert: sechs Klauselverweise plus A.5.7, A.5.19, A.5.20, A.5.21. Die Anforderung (2.1.1): die betreffenden Einrichtungen „führen … einen geeigneten Risikomanagementrahmen ein … und erhalten diesen Rahmen aufrecht", „führen Risikobewertungen durch und dokumentieren diese; auf der Grundlage der Ergebnisse erstellen sie einen Risikobehandlungsplan, setzen diesen um und überwachen ihn", wobei die Ergebnisse und Restrisiken „von den Leitungsorganen … akzeptiert" werden. ENISAs Nachweise (S. 21): dokumentierter Rahmen, dokumentierte Bewertungsergebnisse, Behandlungsplan, Genehmigungsunterlagen. Das ist Kernland des ISMS, und das Mapping ist hier dicht, weil die Überschneidung real ist.
Zeile 3.2: mapped, und enger als der Text. Vier Controls: A.5.28, A.8.15, A.8.16, A.8.17 (Beweissicherung, Protokollierung, Überwachung, Zeitsynchronisation; meine Bezeichnungen). Nun die Verordnung. Punkt 3.2.3 verlangt eine Liste der zu protokollierenden Anlagen und Werte „auf der Grundlage der Ergebnisse der gemäß Nummer 2.1 durchgeführten Risikobewertung" und – soweit angemessen – zwölf Kategorien von Protokollen, von „relevanten ausgehenden und eingehenden Netzverkehr" bis „Aktivierung, Beendigung und Pausieren der verschiedenen Protokolle". Punkt 3.2.6: die Einrichtungen „stellen sicher, dass für die Überwachung und Protokollierung Redundanzsysteme zur Verfügung stehen. Die Verfügbarkeit der Überwachungs- und Protokollierungssysteme wird unabhängig von den von ihnen überwachten Systemen überwacht." ENISAs Nachweisblock (S. 36) beginnt mit „Procedures in place." und „Tools in place." (sinngemäss: Verfahren vorhanden. / Werkzeuge vorhanden.) Die vier Control-IDs sind reale Abdeckung, aber diese Zeile ist eine CSV-Zeile und sieben Unterpunkte Verordnung. Ob Ihre Protokollierungsnachweise für redundante Protokollsysteme und die Überwachung der Überwachung einstehen, lässt sich aus keiner Tabelle auf Überschriftenebene ablesen. So sieht „partiell" aus: durch den Anforderungstext belegt, im Mapping unsichtbar.
Zeile 5.1: neue Artefakte innerhalb einer mapped-Zeile. Controls A.5.19, A.5.20, A.5.21, A.8.30. Punkt 5.1.1: im Konzept für die Sicherheit der Lieferkette „legen die betreffenden Einrichtungen ihre Rolle in der Lieferkette fest und teilen sie ihren direkten Anbietern und Diensteanbietern mit." ENISAs zweiter Nachweispunkt (S. 66) benennt das Artefakt: „Evidence (e.g. email, contract or announcements) of the communication of the role of the entity to the direct suppliers and service providers, where possible." (Sinngemäss: Nachweis (z. B. E-Mail, Vertrag oder Bekanntmachungen) der Mitteilung der Rolle der Einrichtung an die direkten Anbieter und Diensteanbieter, soweit möglich.) Das ist ein spezifischer, datierter Nachweis je Lieferantenbeziehung; ob er in einem zertifizierten ISMS existiert, ist eine Frage Datei für Datei. Punkt 5.1.4 listet dann acht Inhalte für den Vertragsinhalt „– soweit angemessen –", darunter „das Recht auf Prüfung oder das Recht auf Erhalt von Prüfberichten" und die Pflicht der Anbieter zur Meldung von Sicherheitsvorfällen. Und 5.1.2(d) schreibt Kriterien für die Lieferantenauswahl fest, die „die Fähigkeit der betreffenden Einrichtungen, ihre Versorgungsquellen zu diversifizieren und – soweit anwendbar – ihre Abhängigkeit von bestimmten Anbietern zu begrenzen" umfassen. Eine Verordnung, die die Abhängigkeit von einzelnen Anbietern (Lock-in) in das Kalkül der Lieferantenauswahl aufnimmt, ist in einem Beitrag über Verlängerungsangebote bemerkenswert.
Zeile 7.1: die einzige clauses-only-Zeile. ISO-Zelle: 6.2, 9.1, 9.3. Null Annex-A-Controls; das Gegenstück ist die ISMS-Maschinerie (Ziele, Messung, Managementbewertung; meine Bezeichnungen). Die Anforderung: die betreffenden Einrichtungen „legen … ein Konzept und Verfahren fest, setzen sie um und wenden sie an, um zu bewerten, ob die ergriffenen Risikomanagementmaßnahmen im Bereich der Cybersicherheit wirksam umgesetzt und aufrechterhalten werden", wobei Punkt 7.2 verlangt, dass die Einrichtungen bestimmen, was überwacht und gemessen wird, mit welchen Methoden „um gültige Ergebnisse sicherzustellen", wann und durch wen. ENISAs Nachweis (S. 107): ein dokumentiertes Konzept und Verfahren zur Wirksamkeitsbewertung. Für einen zertifizierten Inhaber ist das das Messprogramm in Konzeptform. Es ist die eine Zeile, in der der Crosswalk gar keine Control-ID liefert, und sie beschreibt dennoch etwas, das ein laufendes ISMS hervorbringt.
Zeile 11.1: die A.9-Geschichte. Die rohe Zelle in v1.0: Α.5.15, A.7.2, Α.8.3, Α.8.21, A9. Drei griechische Α, und eine Referenz, A9, die in der ISO/IEC 27001:2022 überhaupt keine Kennung ist: die Annex-A-Familien von 2022 laufen von A.5 bis A.8, und A.9 gehört zur Ausgabe 2013. Die Validierungsschicht unserer Ableitung schloss sie aus, bevor ENISAs Changelog aktenkundig war; der v1.1-Changelog bestätigte die Lesart dann: „Removed references to older version of ISO (A9)in measures 11.1, 11.2, 11.3" (sinngemäss: Verweise auf die ältere ISO-Version (A9) in den Massnahmen 11.1, 11.2, 11.3 entfernt). Die Substanz der Zeile ist sauber: Punkt 11.1.1 verlangt, dass die betreffenden Einrichtungen „Konzepte für die logische und physische Kontrolle des Zugangs zu ihren Netz- und Informationssystemen fest[legen], dokumentieren … und … umsetzen", und ENISAs Nachweis (S. 130) sind die Dokumente des Zugriffskontrollkonzepts. Abschnitt 11 ist zugleich das n:m-Beispiel von vorhin: seine Überschrift verweist auf Art. 21(2) Buchstaben i und j zugleich. Die Geschichte der Zeile ist aber das stärkste Argument in diesem Beitrag dafür, Kennungen gegen das tatsächliche ID-Schema der Norm zu validieren, statt irgendeiner Datei zu vertrauen — auch nicht der des Regulierers.
Zeile 13.1: wo die Arbeit wirklich neu ist. Ein Control: A.7.11 (unterstützende Versorgungsleistungen; meine Bezeichnung). Die Anforderung (13.1.1): die betreffenden Einrichtungen „verhindern Verluste, Schäden oder Beeinträchtigungen von Netz- und Informationssystemen oder Unterbrechungen ihres Betriebs aufgrund des Ausfalls und der Störung unterstützender Versorgungsleistungen." Punkt 13.1.2 präzisiert dann, „– soweit angemessen –": „ihre Betriebsstätten vor Stromausfällen und anderen Störungen schützen, die durch Ausfälle bei unterstützenden Versorgungsunternehmen z. B. für Strom, Telekommunikation, Wasser, Gas, Abwasser, Lüftung und Klimatisierung verursacht werden" und „Verträge über die Notversorgung mit entsprechenden Leistungen abschließen, z. B. für Brennstoff für die Notstromversorgung". ENISAs Nachweis (S. 157): eine Liste unterstützender Versorgungsleistungen mit zugehörigen Risikobewertungen. Für ein SaaS, das auf gemieteter Rechenzentrumskapazität läuft, sind Notfall-Treibstoffverträge der Nachweis eines anderen. Diese Zeile ist der Ort, an dem der Verhältnismässigkeitsmechanismus der Verordnung selbst seinen Wert beweist — behandelt im nächsten Abschnitt.
Der Rest ist keine Menge unzugeordneter Zeilen; die Ableitung fand null davon. Er sitzt an zwei Stellen. Erstens die Granularität: die Mapping-Tabelle endet bei x.y-Überschriften, während die Verordnung auf x.y.z-Ebene bindet. Zeile 3.2 ist eine CSV-Zeile; die Punkte 3.2.1 bis 3.2.7 sind die Pflicht. ENISAs Vorbehalt sagt es wörtlich: das Mapping verweise auf relevante Anforderungen „without assessing whether these fully cover the requirements of the regulation" (sinngemäss: ohne zu bewerten, ob diese die Anforderungen der Verordnung vollständig abdecken). Zweitens Anforderungstext, der die gemappten IDs sichtbar überschreitet, wie oben bei den Zeilen 3.2, 5.1 und 13.1 zitiert. Kein Rest lebt in der Tabelle, also lebt keiner in einem Modul, das auf der Tabelle aufbaut. Es ist Close-Reading-Arbeit gegen die eigenen Nachweise, Punkt für Unterpunkt.
Für Anforderungen, die auf einen Betrieb wirklich nicht passen, schreibt die Verordnung die Handhabung selbst vor. Art. 2(2), dritter Absatz:
„Ist im Anhang dieser Verordnung vorgesehen, dass eine technische oder methodische Anforderung einer Risikomanagementmaßnahmen im Bereich der Cybersicherheit nur anzuwenden ist, soweit dies angemessen, anwendbar oder durchführbar ist, und hält es eine betreffende Einrichtung für nicht angemessen, nicht anwendbar oder nicht durchführbar, bestimmte technische und methodische Anforderungen anzuwenden, so muss die betreffende Einrichtung ihre diesbezügliche Begründung in verständlicher Weise dokumentieren."
Im englischen Verordnungstext erscheint „where appropriate" 48-mal, „where applicable" 13-mal, „to the extent feasible" 4-mal (exakte Zählung der kleingeschriebenen Zeichenfolgen; die satzinitialen grossgeschriebenen Vorkommen fügen 4, 1 bzw. 2 weitere hinzu, alle innerhalb des Anhangs); jedes Vorkommen innerhalb des Anhangs ist eine Stelle, an der diese Dokumentationspflicht greifen kann. Ein zertifizierter Inhaber betreibt diese Disziplin bereits unter anderem Namen: Es ist die Begründung im Statement of Applicability, schriftlich begründete Ausschlüsse. Der Mechanismus ist vertraut, auch wo die Anforderung neu ist. Auch das ist ein Nachweis, den Sie bereits halten, und er sitzt in der Verordnung selbst statt im Mapping.
Ein Argument dafür, bei einem etablierten GRC-Tool zu bleiben, ist, dass ein Wechsel den Verlust der darin konfigurierten Framework-Mappings bedeuten würde. Für dieses Framework-Paar ist die Konkordanzebene zwei öffentliche Dokumente und die 49 CSV-Zeilen von oben, per Skript aus ENISAs Datei in Sekunden neu ableitbar. Was jenseits der Konkordanz sitzt, ist Arbeit, die keinem Anbieter gehört: das x.y.z-Close-Reading, die Nachweisprüfungen Zeile für Zeile, die dokumentierte Nicht-anwendbar-Begründung nach Art. 2(2). Sie gehört zu Ihrem ISMS, und sie bleibt Ihre, wo immer das ISMS betrieben wird.
Bleibt eine Frage, die zu stellen sich lohnt, in Ihrer Stimme, nicht meiner:
Als Ihr Verlängerungsangebot das NIS2-Add-on enthielt — hat Ihnen jemand gezeigt, was darin über das öffentliche Mapping von 2690 auf 27001 hinaus steckt?
Für die Fassung dieses Arguments auf Richtlinienebene, quer über NIS2, SOC 2 und den CRA zugleich, siehe ein Control-Set, drei Regime.
Operativ ist dieser Crosswalk ein einziges Control-Set-Overlay in devguard: die 49 Zeilen laden gegen das bestehende Control-Set der ISO 27001:2022, wobei jede mapped-Zeile auf die bereits an ihre Controls angehängten Nachweise zeigt und Zeile 7.1 sowie die markierten Referenzen ihren eigenen offenen Status tragen statt eines vorgetäuschten Treffers.
[Bild: der Crosswalk 2024/2690, geladen als Control-Set-Overlay in devguard, gefiltert auf Zeile 7.1 und die markierten Referenzen]
Der Crosswalk ist jetzt öffentlich und normalisiert. Ziehen Sie diese Woche die Nachweise der mapped-Zeilen aus Ihrem ISMS, lesen Sie den x.y.z-Text unter den Zeilen, die für Ihren Betrieb zählen, fassen Sie den Rest als echte Arbeit auf und nehmen Sie die obige Frage mit ins Verlängerungsgespräch.
Einen solchen Crosswalk gegen Ihr tatsächliches Control-Set am Leben zu halten, statt im Modul eines Anbieters, dafür ist devguard gebaut.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.