Map once, comply everywhere: So funktioniert das Control-Mapping über mehrere Frameworks

Die meisten Unternehmen beschließen nicht, fünf Compliance-Frameworks zu betreiben. Es passiert ihnen. Zuerst verlangt ein großer Kunde ISO 27001, also lässt sich das Unternehmen zertifizieren. Zwei Jahre später möchte ein Interessent aus den USA einen SOC-2-Bericht. Dann wächst das Unternehmen über eine Größenschwelle und fällt unter NIS2. Ein Kunde aus der Automobilbranche fragt nach einem TISAX®-Label. Und weil das Produkt inzwischen KI nutzt, fragt jemand aus der Rechtsabteilung nach dem EU AI Act.

Jede dieser Anfragen kommt als eigenes Projekt, oft mit eigener Beratung, eigener Tabelle und eigenem Auditkalender. Nach ein paar Jahren beantwortet dasselbe Sicherheitsteam dieselben Fragen fünfmal, in fünf Formaten, für fünf Auditoren. Niemand hat das so geplant. Es hat sich einfach angesammelt.

„Map once, comply everywhere“ ist der Ausweg. Die Idee ist einfach: Sie beschreiben Ihr Unternehmen einmal, bauen ein Control-Set auf, erheben jeden Nachweis einmal und verknüpfen alles mit jedem Framework, das es braucht. Dieser Leitfaden erklärt, wie das in der Praxis funktioniert, wo es am meisten Arbeit spart und wo es gar nicht hilft.

Warum sich die Frameworks so stark überschneiden

Sicherheits-Frameworks werden von verschiedenen Organisationen für verschiedene Zielgruppen geschrieben. ISO schreibt für Zertifizierungsstellen, das AICPA für US-Auditoren, die EU für nationale Behörden, die deutsche Automobilindustrie für ihre Zulieferer. Die Sprache unterscheidet sich, der Aufbau unterscheidet sich, und die Audits unterscheiden sich.

Darunter stellen aber alle eine kurze Liste derselben Fragen. Wer hat Zugriff worauf, und stimmt das noch? Sind Ihre Systeme sicher konfiguriert und aktuell? Sind Daten bei der Übertragung, im Ruhezustand und in Backups geschützt? Bemerken Sie Vorfälle und reagieren Sie darauf? Steuern Sie die Risiken, die von Ihren Lieferanten ausgehen? Und für jede dieser Fragen: Gibt es eine schriftliche Regel, eine verantwortliche Person und einen Nachweis, dass die Regel eingehalten wird?

Weil die Fragen dieselben sind, sind es auch die Antworten weitgehend. NIS2 nennt in Artikel 21 zehn Bereiche von Risikomanagementmaßnahmen, von der Bewältigung von Sicherheitsvorfällen über die Sicherheit der Lieferkette bis zu Zugriffskontrolle und Multi-Faktor-Authentifizierung. Fast jeder davon hat eine Entsprechung in Annex A der ISO 27001. Für Anbieter digitaler Dienste beschreibt die NIS2-Durchführungsverordnung der EU vom Oktober 2024 diese Maßnahmen so, dass sie sich sehr nah an Controls der ISO 27001 lesen. Ein Unternehmen mit einem ausgereiften ISO-27001-Programm hat den Großteil der technischen Arbeit, die NIS2 verlangt, bereits erledigt. Was meist fehlt, ist das Mapping, das es belegt.

Die Arbeit fehlt selten. Was fehlt, ist die Verbindung zwischen der Arbeit, die Sie schon tun, und der Anforderung, die vor Ihnen liegt.

Beginnen Sie mit Ihrem Unternehmen, nicht mit einem Framework

Der häufigste Fehler ist, mit dem Framework zu beginnen: die Liste der Anforderungen öffnen und von oben nach unten abarbeiten. Das ergibt Antworten, die zum Framework passen, aber nicht unbedingt zu Ihrem Unternehmen.

Der bessere Ausgangspunkt ist eine Beschreibung des Unternehmens selbst. Welche Gesellschaften haben Sie, und wo? Welche Produkte und Leistungen bieten Sie an? Welche Systeme betreiben Sie, und wo laufen sie? Welche Daten verarbeiten Sie, und von wem? Wer sind Ihre Lieferanten, und welche davon sind kritisch? Wie nutzen Sie KI?

Diese Beschreibung, Ihr Unternehmensmodell, erfüllt zwei Aufgaben. Erstens zeigt sie, welche Frameworks und Regulierungen überhaupt gelten. Ein Unternehmen, das vernetzte Geräte an Kunden in der EU liefert, fällt unter den Cyber Resilience Act; eines, das das nicht tut, fällt nicht darunter. Zweitens zeigt sie, welche Anforderungen innerhalb eines Frameworks relevant sind. Ein Unternehmen ohne eigenes Rechenzentrum braucht keine Controls für dessen physische Sicherheit.

Jedes Framework wird dann gegen dasselbe Modell gelesen. Ändert sich das Unternehmen, mit einem neuen Produkt, einem neuen Cloud-Anbieter oder einem neuen Markt, erfassen Sie die Änderung einmal, und jedes Framework sieht sie.

Ein Control-Set, in Ihren eigenen Worten

Das Herzstück des Ansatzes ist ein einziges Control-Set. Ein Control ist etwas, das Ihr Unternehmen tatsächlich tut, in einfacher Sprache beschrieben: „Alle Mitarbeiter und Administratoren melden sich mit Multi-Faktor-Authentifizierung an“ statt „A.8.5“. Jedes Control hat eine verantwortliche Person, eine kurze Beschreibung, wie es umgesetzt wird, und den Nachweis, dass es umgesetzt wird.

Dann wird jede Anforderung aus jedem Framework mit den Controls verknüpft, die sie erfüllen. Die Richtung ist wichtig: Sie gehen von der Anforderung zum Control. Ein Control kann viele Anforderungen bedienen, und eine Anforderung kann mehrere Controls brauchen.

Multi-Faktor-Authentifizierung ist das einfachste Beispiel. Dasselbe Control beantwortet ISO 27001:2022 A.8.5 zur sicheren Authentifizierung, SOC 2 CC6.1 zum logischen Zugriff, NIS2 Artikel 21 Absatz 2 Buchstabe j zur Multi-Faktor-Authentifizierung und DORA Artikel 9 Absatz 4 Buchstabe d zur starken Authentifizierung, und es stützt Artikel 32 DSGVO zur Sicherheit der Verarbeitung. Ein wöchentlicher Bericht aus Ihrem Identity-Provider, der zeigt, dass jedes Konto einen zweiten Faktor nutzt, ist der Nachweis für alle fünf. Sie erheben ihn einmal, halten ihn einmal aktuell, und jedes Framework sieht ihn.

Seien Sie ehrlich bei teilweisen Treffern

Nicht jede Verbindung zwischen einer Anforderung und einem Control passt perfekt. Es hilft, jede klar zu kennzeichnen:

• Vollständig: Das Control erfüllt die Anforderung ganz.
• Teilweise: Das Control deckt einen Teil ab, es braucht etwas zusätzlich.
• Keine: Die Anforderung ist neu und braucht ein eigenes Control.

Aus teilweisen Treffern entstehen die meisten Feststellungen im Audit. Ein allgemeiner Prozess zur Reaktion auf Sicherheitsvorfälle deckt Erkennung, Analyse und Wiederherstellung ab und sieht deshalb wie ein Treffer für NIS2 aus. NIS2 ergänzt aber feste Fristen: eine Frühwarnung an die Behörde innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. Enthält Ihr Prozess diese Schritte nicht, ist der Treffer nur teilweise, und ihn als vollständig zu behandeln, ist der klassische Fehler von Programmen mit mehreren Frameworks.

Ein durchgerechnetes Beispiel: NIS2 zu ISO 27001 hinzufügen

Begleiten wir ein Unternehmen dabei. Acme ist ein Softwareunternehmen mit rund 300 Mitarbeitern und seit zwei Jahren nach ISO 27001 zertifiziert. Im Frühjahr erfährt es, dass es wegen seiner Größe und Branche eine wichtige Einrichtung nach NIS2 ist.

Ohne ein abgebildetes Control-Set würde Acme tun, was viele Unternehmen tun: eine Beratung beauftragen, eine NIS2-Gap-Analyse von Grund auf durchführen und ein zweites Programm starten. Mit einem abgebildeten Control-Set sieht die Arbeit ganz anders aus.

Erstens liest Acme NIS2 gegen sein Unternehmensmodell. Es bestätigt, dass es in den Anwendungsbereich fällt und eine wichtige statt einer wesentlichen Einrichtung ist. Das wirkt sich auf die Aufsicht aus, nicht auf die Kernmaßnahmen.

Zweitens bildet es die NIS2-Maßnahmen auf seine bestehenden Controls ab. Die meisten technischen Maßnahmen sind bereits abgedeckt: Zugriffskontrolle, Backups, Verschlüsselung, Umgang mit Schwachstellen, Lieferantensicherheit. Sie gibt es wegen ISO 27001.

Drittens listet es auf, was teilweise erfüllt ist oder fehlt. Für Acme ist das eine kurze Liste: Die NIS2-Meldefristen stehen nicht im Prozess für Sicherheitsvorfälle, die Geschäftsleitung hat die Sicherheitsmaßnahmen nicht formell gebilligt und keine Schulung absolviert, wie Artikel 20 es verlangt, und das Unternehmen hat sich noch nicht bei der nationalen Behörde registriert.

Viertens macht es nur aus diesen Lücken Aufgaben. Acme ergänzt seinen Prozess für Sicherheitsvorfälle um den 24-Stunden-Schritt, plant eine Schulung für die Geschäftsleitung, bereitet die Registrierung vor und aktualisiert zwei Policies. Ein paar Wochen fokussierter Arbeit statt eines zweiten Programms.

Dasselbe Muster funktioniert, wenn SOC 2 zu ISO 27001 hinzukommt, DORA zu NIS2 oder ISO 42001 zu einem bestehenden ISMS.

Was sich nicht abbilden lässt

Mapping beseitigt doppelte Arbeit. Es beseitigt nicht, was jedes Framework besonders macht, und wer so tut, wird im Audit überrascht.

Bei SOC 2 Type II geht es um die Frage, ob ein Control über einen Zeitraum wirksam funktioniert hat, oft sechs bis zwölf Monate. Dass es heute existiert, reicht nicht. Sie brauchen Nachweise über den ganzen Zeitraum, die Nachweiserhebung muss also laufend erfolgen und nicht erst kurz vor dem Audit.

NIS2 ergänzt die persönliche Verantwortung der Geschäftsleitung und feste Meldefristen für Sicherheitsvorfälle, die keine ISO-Norm enthält.

DORA ergänzt ein Informationsregister zu allen vertraglichen Vereinbarungen mit IKT-Drittdienstleistern und besondere Vertragsanforderungen in Artikel 30. Für manche Finanzunternehmen verlangt DORA außerdem bedrohungsorientierte Penetrationstests.

TISAX® arbeitet mit Bewertungsstufen, die der Kunde festlegt, und hat zusätzliche Module, etwa zum Prototypenschutz, die es anderswo nicht gibt.

Der EU AI Act und ISO 42001 ergänzen Pflichten rund um KI-Systeme: wissen, welche KI Sie nutzen, sie nach Risiko einstufen, KI-Kompetenz sicherstellen und bei Hochrisiko-Systemen menschliche Aufsicht.

Ein gutes Mapping macht diese Unterschiede früh sichtbar, damit Sie sie einplanen können und sie nicht erst im Audit entdecken.

Das Mapping lebendig halten

Ein Mapping, das einmal in einer Tabelle gebaut wird, beginnt an dem Tag zu veralten, an dem es fertig ist. Frameworks bekommen neue Versionen, Behörden veröffentlichen Leitlinien und Durchführungsrechtsakte, und Ihr Unternehmen verändert sich jeden Monat. Drei Gewohnheiten halten es aktuell.

Erheben Sie Nachweise nach Zeitplan und verknüpfen Sie jeden mit allen Anforderungen, die er belegt. Dann wird die Aktualität dieses Nachweises einmal verfolgt und nicht fünfmal.

Prüfen Sie die Abdeckung regelmäßig, nicht einmal im Jahr vor dem Audit. Eine Lücke, die Sie im März finden, ist eine Aufgabe. Eine Lücke, die der Auditor im November findet, ist eine Feststellung.

Aktualisieren Sie zuerst das Unternehmensmodell, wenn sich etwas ändert. Ein neues Produkt, ein neuer Lieferant oder ein neues Land kommt in das Modell, und von dort wird die Auswirkung auf Controls und Frameworks sichtbar.

Wo Sie anfangen

Wenn Sie heute mehr als ein Framework betreiben, müssen Sie nicht alles auf einmal neu aufbauen. Beginnen Sie mit dem Framework, das Sie am besten kennen, meist ISO 27001, und behandeln Sie seine Controls als erste Version Ihres gemeinsamen Control-Sets. Formulieren Sie sie wo nötig in Ihren eigenen Worten, weisen Sie Verantwortliche zu und verknüpfen Sie die Nachweise, die Sie bereits erheben.

Nehmen Sie dann das nächste Framework und bilden Sie es auf dieses Set ab, wobei Sie jede Anforderung als vollständig, teilweise oder keine kennzeichnen. Das erste Mapping dauert am längsten. Jedes weitere geht schneller, weil die meisten Controls schon da sind.

Quellen: Richtlinie (EU) 2022/2555 (NIS2), Artikel 20, 21 und 23; Durchführungsverordnung (EU) 2024/2690 der Kommission; Verordnung (EU) 2022/2554 (DORA), Artikel 9, 28 und 30; ISO/IEC 27001:2022; ISO/IEC 42001:2023; AICPA Trust Services Criteria.