Der gemeinsame Kern: Sicherheitsanforderungen aller Frameworks
Setzt man elf Sicherheits-Frameworks zueinander in Beziehung, zeigt sich in jedem von ihnen ein kleiner gemeinsamer Kern. Wer ein Programm aufsetzt oder mehrere Frameworks parallel bedient, sollte dort beginnen.
Dieser Beitrag behandelt die 11 Frameworks, die ControlMapping zum Zeitpunkt der Erstellung zugeordnet hatte. Seitdem wurden DORA, CPS 234, Cyber Essentials am 2026-10-27 hinzugefügt; ihre Seiten und die Abdeckungsmatrix enthalten sie.

Organisationen müssen selten nur einem Sicherheits-Framework genügen. Ein Softwareunternehmen verkauft an US-Kunden, die einen SOC 2-Bericht verlangen, und an europäische Kunden, die ISO 27001 erwarten; ein Zahlungsdienstleister kommt PCI DSS hinzu; ein digitaler Anbieter aus der EU fällt nun unter NIS2. Jedes Framework bringt eigene Struktur, Nummerierung und Begrifflichkeit mit, und man schließt leicht, dass jedes ein eigenes Programm erfordert.
Das ist nicht der Fall. Unter der unterschiedlichen Nummerierung liegt viel gemeinsamer Boden, und ein kleiner Teil davon wird von jedem Framework geteilt, das wir abbilden. Wir haben nach den Themen gesucht, zu denen es in allen elf eine zugeordnete Anforderung gibt: NIST CSF 2.0, NIST SP 800-53, ISO 27001, CIS Controls, SOC 2, PCI DSS, CMMC Level 2, die HIPAA Security Rule, DSGVO (GDPR), NIS2 und die Essential Eight der ASD.
Die fünf Themen in jedem Framework
5 von 50 Themen haben in allen 11 Frameworks eine zugeordnete Anforderung. Jede Themenseite listet die Anforderungs-IDs jedes Frameworks und die Belege für jede Verknüpfung.
Das ist der gemeinsame Kern: Asset Management, Schwachstellenmanagement, Backup und Wiederherstellung, Incident Response und Meldung von Sicherheitsvorfällen. Jedes der elf Frameworks enthält mindestens eine Anforderung zu jedem dieser Themen, selbst die DSGVO, ein Datenschutzgesetz, und die Essential Eight, eine kurze Liste technischer Maßnahmen.
Die Liste ist bewusst kurz. Viele andere Themen, etwa Zugriffskontrolle, Protokollierung und Verschlüsselung, werden von zehn der elf abgedeckt, und die meisten Frameworks teilen weit mehr als fünf Themen. Doch diese fünf sind die, die kein Framework auslässt.
Warum genau diese fünf
Sie folgen dem Lebenszyklus eines Vorfalls. Man kann nicht schützen, was man nicht kennt (Asset Management). Die meisten Angriffe nutzen nach wie vor bekannte Schwachstellen aus (Schwachstellenmanagement). Wenn etwas schiefgeht, müssen Systeme und Daten wiederhergestellt werden (Backup und Wiederherstellung), der Vorfall bearbeitet werden (Incident Response) und die richtigen Personen informiert werden: Geschäftsleitung, Kunden, Aufsichtsbehörden (Meldung von Sicherheitsvorfällen).
Bei allem Übrigen sind sich die Frameworks uneinig: ob Governance ein Managementsystem oder eine Menge von Ergebnissen ist, wie präskriptiv technische Maßnahmen sein sollten und wie oft Dinge geschehen müssen. Bei diesen fünf Themen herrscht Einigkeit, weil der Rest ohne sie nicht funktioniert.
Gleiches Thema, unterschiedliche Tiefe
Ein gemeinsames Thema bedeutet nicht identische Anforderungen. Nehmen wir das Schwachstellenmanagement:
| Framework | Schwachstellenmanagement | Verknüpfung |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01ID.RA-08 | Themendefinition |
| ISO 27001 | A.8.8 | Crosswalk |
| CIS v8.1 | CIS 7.1CIS 7.2CIS 7.5CIS 7.6CIS 7.7CIS 16.6CIS 18.1CIS 18.2CIS 18.3CIS 18.4CIS 18.5 | Crosswalk |
| SOC 2 | CC7.1 | Redaktionell |
| PCI DSS | 6.3.111.3.111.3.2 | Crosswalk |
| CMMC | RA.L2-3.11.2RA.L2-3.11.3 | Crosswalk |
| 800-53 | RA-5CA-8 | Crosswalk |
| HIPAA | §164.308(a)(1)(ii)(A)§164.308(a)(1)(ii)(B)§164.308(a)(8) | Crosswalk |
| GDPR | Art.32(1)(d) | Redaktionell |
| NIS2 | 6.56.10 | Crosswalk |
| Essential Eight | ISM-1807ISM-1808ISM-1698ISM-1699ISM-1701ISM-1702 | Redaktionell |
Vollständige Details und die Begründung für jede Verknüpfung: Schwachstellenmanagement über Frameworks hinweg →
Die Anforderung A.8.8 von ISO 27001 verlangt, Informationen über technische Schwachstellen einzuholen, die eigene Exposition zu bewerten und angemessene Maßnahmen zu ergreifen; den Zeitpunkt überlässt sie Ihrer Risikobewertung. PCI DSS verlangt interne Scans alle drei Monate und nach wesentlichen Änderungen (11.3.1), externe Scans durch einen Approved Scanning Vendor (11.3.2) sowie das Patchen kritischer und hochriskanter Schwachstellen innerhalb eines Monats nach Veröffentlichung (6.3.3). Die Essential Eight setzt Patchfristen, die auf jeder Reifegradstufe enger werden. HIPAA erfasst das Thema über seine Anforderungen an Risikoanalyse und Risikomanagement statt über eine eigene Vorgabe zu Schwachstellen.
Der gemeinsame Kern sagt also, was jedes Framework von Ihnen erwartet, nicht wie viel. Wenn Sie eine Maßnahme entwerfen, gestalten Sie sie nach dem strengsten Framework, dem Sie verpflichtet sind; die anderen folgen meist.
So sieht es in der Praxis aus
- Asset Management: ein Inventar aller Hardware, Software, Cloud-Dienste und Datenspeicher mit Verantwortlichen, das durch Discovery-Tools aktuell gehalten wird und nicht nur durch Tabellenkalkulationen.
- Schwachstellenmanagement: geplante Scans (intern und extern), eine Schweregradbewertung, Behebungsfristen je Schweregrad und Nachweise, dass die Fristen eingehalten werden.
- Backup und Wiederherstellung: Sicherungen von Daten, Software und Konfiguration, vor Änderung und Löschung geschützt, mit regelmäßig getesteten Wiederherstellungen.
- Incident Response: ein schriftlicher Plan mit Rollen, Schweregradstufen und Eskalationswegen, der mindestens einmal jährlich geübt wird.
- Meldung von Sicherheitsvorfällen: ein Verfahren, das festlegt, wer wem innerhalb welcher Frist Meldung machen muss: interne Geschäftsleitung, vertraglich verbundene Kunden und Aufsichtsbehörden (zum Beispiel die Frühwarnung nach NIS2 innerhalb von 24 Stunden oder die Meldung der DSGVO an die Aufsichtsbehörde innerhalb von 72 Stunden).
Warum der Kern wichtig ist
Wenn Sie ein Sicherheitsprogramm aufbauen, setzen Sie zuerst diese fünf um. Es sind die Anforderungen, denen Sie in jedem Framework begegnen, das Sie später möglicherweise einführen, sodass die Arbeit nie verloren geht.
Wenn Sie bereits mehrere Frameworks parallel bedienen, nutzen Sie den Kern als Rückgrat eines gemeinsamen Maßnahmenkatalogs: eine Maßnahme je Thema, zugeordnet zu jedem Framework, dem Sie verpflichtet sind, mit Nachweisen, die nur einmal erhoben werden. Dieselbe Idee lässt sich auf Themen ausweiten, die zehn, neun oder acht Frameworks gemeinsam haben. Unsere Abdeckungsmatrix zeigt alle fünfzig Themen gegen alle elf Frameworks, und die Lückenanalyse zeigt Anforderung für Anforderung, was zwischen zwei beliebigen Frameworks übertragbar ist.

So haben wir es gemessen
Jedes Thema in ControlMapping ist über die Ergebnisse von NIST CSF 2.0 definiert und listet die Anforderung jedes Frameworks auf, die es adressiert. Ein Link wird als Crosswalk gekennzeichnet, wenn ein veröffentlichter Crosswalk (von NIST, ENISA, CIS oder PCI SSC) ihn stützt, und als redaktionell, wenn es sich um unser Urteil handelt; die Begründung wird dann angezeigt. Verknüpfungen zu SOC 2, DSGVO und Essential Eight sind immer redaktionell, da für sie kein offen lizenzierter Crosswalk existiert. Die vollständige Methode finden Sie auf der Seite Methodik, und jede oben genannte Zahl stammt aus den Live-Daten und wird aktualisiert, wenn sich die Zuordnungen ändern.
Fragen
Welche Sicherheitsmaßnahmen verlangen alle Frameworks?
In den Daten von ControlMapping haben fünf Themen in allen 11 Frameworks eine zugeordnete Anforderung: Asset Management, Schwachstellenmanagement, Backup und Wiederherstellung, Incident Response sowie Meldung von Sicherheitsvorfällen. Wortlaut und Tiefe unterscheiden sich je nach Framework.
Erfüllt die Umsetzung eines Frameworks automatisch die anderen?
Nicht automatisch. Eine Zuordnung bedeutet, dass die Anforderungen dasselbe Thema adressieren; eine davon kann deutlich konkreter sein (PCI DSS und die Essential Eight setzen Fristen und Häufigkeiten, die ISO 27001 Ihnen überlässt). Prüfen Sie den Text des jeweiligen Frameworks.
Datenstand 2026-10-27: Die Zahlen in diesem Beitrag werden aus dem aktuellen Crosswalk berechnet und aktualisieren sich, sobald dieser geändert wird. Crosswalk eine veröffentlichte Crosswalk (NIST, ENISA, CIS, PCI SSC) stellt die Verbindung her · Redaktionell Einschätzung von ControlMapping, wo kein Crosswalk existiert; die Begründung wird angezeigt · teilt nur ein CSF-2.0-Ergebnis: einer Prüfung wert, aber keine Zuordnung · Keine Zuordnung in unseren Daten In unseren Daten nichts zugeordnet; oft neue Arbeit, aber prüfen Sie die Hinweise zur Abdeckung. Keine Compliance-Beratung.