Inhaltsverzeichnis
Was ist das NIST Cybersecurity Framework?
Das NIST Cybersecurity Framework (CSF) wurde vom National Institute of Standards and Technology (NIST) der USA entwickelt und erstmals 2014 veröffentlicht. Es entstand auf Basis einer Executive Order von Präsident Obama, der nach einer Reihe kritischer Infrastrukturangriffe einen gemeinsamen, branchenübergreifenden Sicherheitsstandard forderte. In den darauffolgenden Jahren avancierte das CSF zum meistgenutzten Cybersecurity-Framework weltweit — nicht nur in den USA, sondern auch in Europa, Asien und Lateinamerika.
Der entscheidende Vorteil des NIST CSF gegenüber anderen Frameworks ist sein risikobasierter, nicht-präskriptiver Ansatz. Es schreibt Organisationen nicht vor, welche konkreten Technologien einzusetzen oder welche exakten Kontrollen zu implementieren sind. Stattdessen bietet es eine strukturierte Sprache und einen methodischen Rahmen, mit dem Organisationen ihren aktuellen Sicherheitsstand beschreiben, Zielzustände definieren und die Lücke dazwischen systematisch schließen können. Dieser Ansatz macht das Framework flexibel genug für ein 50-Mann-KMU ebenso wie für einen DAX-Konzern.
Version 1.0 (2014) und die erste große Aktualisierung auf Version 1.1 (2018) etablierten fünf Kernfunktionen: Identify, Protect, Detect, Respond und Recover. Dieses Modell bewährte sich in der Praxis, zeigte aber mit zunehmender Reife der Cybersecurity-Landschaft Lücken — insbesondere in den Bereichen Governance, Supply-Chain-Sicherheit und der Unterstützung kleinerer Organisationen ohne dedizierte Sicherheitsteams.
Nach einem mehrjährigen, öffentlichen Überarbeitungsprozess mit Tausenden von Kommentaren aus Industrie, Behörden und Wissenschaft veröffentlichte NIST im Februar 2024 Version 2.0. Die neue Version ist mehr als ein Update — sie ist eine strategische Neuausrichtung, die Cybersecurity explizit als Unternehmensstrategie und Chefsache verankert. CSF 2.0 gilt nun offiziell für alle Organisationstypen und -größen, nicht mehr nur für kritische Infrastrukturen.
Was ist neu in CSF 2.0?
Die wichtigste strukturelle Neuerung in NIST CSF 2.0 ist die Einführung der sechsten Kernfunktion GOVERN (GV). Diese Funktion adressiert einen blinden Fleck der Vorgängerversionen: Cybersecurity-Entscheidungen wurden bisher oft isoliert in der IT-Abteilung getroffen, ohne ausreichende Einbindung von Unternehmensführung, Vorstand und Aufsichtsrat. GOVERN verankert Cybersecurity-Strategie, Rollen, Verantwortlichkeiten und Risikotoleranz als explizite Managementaufgabe.
Ein weiterer zentraler Schwerpunkt von CSF 2.0 ist die erheblich ausgeweitete Behandlung der Lieferkettensicherheit (Supply Chain Risk Management, SCRM). Während CSF 1.1 Supply-Chain-Risiken nur peripher erwähnte, enthält Version 2.0 eine dedizierte Kategorie mit konkreten Subcategories für die Bewertung von Drittanbieter-Risiken, Vertragsklauseln, Software-Bills of Materials (SBOM) und die Überwachung kritischer Lieferanten. Nach den prominenten Supply-Chain-Angriffen der letzten Jahre (SolarWinds, Log4Shell, XZ Utils) ist dieser Schritt überfällig und praktisch notwendig.
CSF 2.0 bietet erstmals umfangreiche Implementierungsbeispiele und Profile, die auf spezifische Branchen, Unternehmensgrößen und Reifegrade zugeschnitten sind. NIST stellt auf seiner Website einen wachsenden Katalog von Community Profiles bereit, darunter spezifische Guidance für kleine Unternehmen ohne dediziertes Sicherheitsteam. Damit wird das Framework deutlich zugänglicher für den breiten Mittelstand, der bisher durch die Komplexität des Frameworks abgeschreckt wurde.
Die Verknüpfung zu anderen Standards und Frameworks wurde systematisch ausgebaut. CSF 2.0 enthält offizielle Mappings zu ISO/IEC 27001, COBIT 2019, der ISA/IEC 62443-Serie und den CIS Controls. Für die Governance-Einordnung von COBIT im Verhältnis zum Service-Management-Framework ITIL hilft unser Vergleich COBIT vs. ITIL. Für europäische Unternehmen besonders relevant: Die Überschneidungen mit den Anforderungen der NIS2-Richtlinie und dem Digital Operational Resilience Act (DORA) werden zunehmend in der Praxis genutzt, um Compliance-Aufwände zu konsolidieren.
Die wichtigste Neuerung: Die neue GOVERN-Funktion macht Cybersecurity zur Chefsache — Strategie, Risikotoleranz und Verantwortlichkeiten gehören ab sofort auf die Agenda des Vorstands.
Die 6 Kernfunktionen des CSF 2.0
Das NIST CSF 2.0 strukturiert Cybersecurity-Aktivitäten in sechs Kernfunktionen (Functions), die jeweils in Kategorien (Categories) und Subcategories unterteilt sind. Insgesamt umfasst das Framework 22 Kategorien und 106 Subcategories. Die Funktionen sind nicht als sequenzieller Prozess zu verstehen, sondern als gleichzeitig aktive, sich gegenseitig verstärkende Aktivitätsbereiche.
GOVERN (GV) — Steuerung und Strategie
GOVERN ist die neue sechste Funktion und konzeptuell zentral: Sie überspannt alle anderen fünf Funktionen und stellt sicher, dass Cybersecurity-Aktivitäten strategisch gesteuert, organisatorisch verankert und kontinuierlich überwacht werden. Ohne eine funktionierende GOVERN-Funktion bleiben die operativen Maßnahmen der anderen Funktionen fragmentiert und ineffektiv.
Die Kategorien unter GOVERN umfassen: Organizational Context (GV.OC) — Verstehen des regulatorischen und strategischen Rahmens der Organisation; Risk Management Strategy (GV.RM) — Festlegen von Risikotoleranz, Risikoappetit und Priorisierungsprinzipien; Cybersecurity Supply Chain Risk Management (GV.SC) — Strategie für Drittanbieter-Risiken; Roles, Responsibilities, and Authorities (GV.RR) — klare Verantwortlichkeiten auf allen Ebenen; Policies, Processes, and Procedures (GV.PO) — dokumentierte und kommunizierte Richtlinien; sowie Oversight (GV.OV) — kontinuierliche Überprüfung der Effektivität der Cybersecurity-Maßnahmen durch das Management.
Ein reifes GOVERN erkennt man daran, dass der Vorstand regelmäßig über Cybersecurity-Risiken informiert wird (nicht nur nach Vorfällen), dass es eine dokumentierte Risikotoleranz gibt und dass Cybersecurity-Ziele in die Unternehmensplanung integriert sind.
IDENTIFY (ID) — Verstehen und Inventarisieren
IDENTIFY bildet die Grundlage aller weiteren Sicherheitsmaßnahmen. Eine Organisation kann nichts schützen, was sie nicht kennt. Die Funktion umfasst das vollständige Asset Management (ID.AM) — Hardware, Software, Daten, Netzwerke, Systeme und Geschäftsprozesse — sowie die Bewertung von Risiken (ID.RA), die Analyse des Threat-Umfelds und die Identifikation von Schwachstellen.
Besonders praxisrelevant ist die Subcategory ID.AM-7 (Software Bill of Materials), die in CSF 2.0 neu aufgenommen wurde. SBOMs ermöglichen es Organisationen, schnell zu bewerten, ob sie von neu entdeckten Schwachstellen in Open-Source-Komponenten betroffen sind — ein Thema, das nach Log4Shell (2021) massiv an Bedeutung gewonnen hat.
Im Assessment-Kontext ist IDENTIFY oft die größte Schwachstelle: Viele Unternehmen haben kein vollständiges, aktuelles Asset-Inventar. Shadow IT, Cloud-Ressourcen außerhalb des offiziellen Procurement-Prozesses und veraltete CMDB-Einträge sind typische Probleme, die im Assessment ans Licht kommen.
PROTECT (PR) — Schutzmaßnahmen implementieren
PROTECT umfasst die präventiven Kontrollen, die sicherstellen, dass bekannte Risiken aktiv reduziert werden. Die Kernkategorien sind: Identity Management, Authentication, and Access Control (PR.AA) — das Fundament jeder Zero-Trust-Strategie; Awareness and Training (PR.AT) — Schulung von Mitarbeitern, Partnern und privilegierten Nutzern; Data Security (PR.DS) — Verschlüsselung, Daten-Klassifizierung, Data Loss Prevention; Platform Security (PR.PS) — Hardening von Hardware, Software und Diensten; und Technology Infrastructure Resilience (PR.IR) — Hochverfügbarkeit, Redundanz und Kapazitätsmanagement.
Identity Management (PR.AA) gewinnt mit der Verbreitung von Cloud-Diensten und Remote-Arbeit exponentiell an Bedeutung. CSF 2.0 betont Multifaktor-Authentifizierung, Least-Privilege-Prinzip und kontinuierliche Authentifizierung als Grundlage für moderne Schutzmaßnahmen.
Ein häufiger Befund im Assessment: PROTECT-Maßnahmen werden zwar implementiert, aber nicht konsequent auf alle Assets angewendet. Patching-Prozesse haben Ausnahmen, MFA-Rollouts stoppen bei der Führungsebene, und das Hardening von Legacy-Systemen bleibt liegen.
DETECT (DE) — Angriffe erkennen
DETECT fokussiert auf die Fähigkeit, Anomalien, Angriffe und Kompromittierungen zeitnah zu erkennen. Die zwei Kernkategorien sind: Continuous Monitoring (DE.CM) — kontinuierliche Überwachung von Netzwerken, Systemen, Identitäten, Anwendungsaktivitäten, externen Bedrohungen und Supply-Chain-Aktivitäten; sowie Adverse Event Analysis (DE.AE) — systematische Analyse erkannter Ereignisse, Korrelation von Indicators of Compromise (IoC) und Einschätzung des potenziellen Impacts.
Die Mean Time to Detect (MTTD) ist eine der wichtigsten Kennzahlen im Cybersecurity-Bereich. Laut dem IBM Cost of a Data Breach Report 2024 beträgt die durchschnittliche Zeit bis zur Entdeckung einer Kompromittierung noch immer über 194 Tage. Organisationen mit ausgereiften DETECT-Fähigkeiten (SIEM, EDR, UEBA) erkennen Angriffe in Stunden oder Tagen — ein entscheidender Unterschied für das Schadensausmaß.
Im Assessment wird DETECT oft als ausreichend eingestuft, wenn ein SIEM vorhanden ist. Die Qualität der Detection-Regeln, der Abdeckungsgrad des Monitorings und vor allem die tatsächliche Reaktionsfähigkeit auf Alerts werden dabei zu wenig hinterfragt.
RESPOND (RS) — Auf Vorfälle reagieren
RESPOND definiert die Fähigkeit einer Organisation, auf erkannte Cybersecurity-Vorfälle strukturiert und effektiv zu reagieren. Die Kategorien umfassen: Incident Management (RS.MA) — Triage, Eskalation und Aktivierung von Response-Prozessen; Incident Analysis (RS.AN) — forensische Analyse, Root-Cause-Identifikation und Impact-Bewertung; Incident Response Reporting and Communication (RS.CO) — interne und externe Kommunikation inklusive regulatorischer Meldepflichten; Incident Mitigation (RS.MI) — Eindämmung des Schadens und Beseitigung der Ursache.
Die Meldepflichten unter NIS2 machen einen ausgereiften RESPOND-Prozess zur regulatorischen Pflicht. NIS2 schreibt vor, dass wesentliche und wichtige Einrichtungen signifikante Vorfälle innerhalb von 24 Stunden an die zuständige Behörde melden müssen (Early Warning), gefolgt von einer detaillierten Meldung innerhalb von 72 Stunden. Ohne dokumentierte Response-Prozesse und klare Verantwortlichkeiten ist diese Anforderung in der Praxis nicht erfüllbar.
Tabletop-Übungen und Incident-Response-Simulationen sind ein wichtiger Indikator für die Reife der RESPOND-Funktion. Eine Organisation, die seit mehr als zwei Jahren kein Incident-Response-Training durchgeführt hat, hat typischerweise eine schlechtere RESPOND-Reife als ihr Incident-Response-Plan suggeriert.
RECOVER (RC) — Wiederherstellung sicherstellen
RECOVER beschreibt die Fähigkeit, nach einem Cybersecurity-Vorfall den Normalbetrieb zeitnah wiederherzustellen und aus dem Vorfall zu lernen. Die Kategorien sind: Incident Recovery Plan Execution (RC.RP) — Ausführung und kontinuierliche Verbesserung von Recovery-Plänen; Incident Recovery Communication (RC.CO) — Kommunikation mit internen und externen Stakeholdern während der Wiederherstellung.
Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind die zentralen Kennzahlen der RECOVER-Funktion. Sie müssen für kritische Systeme und Geschäftsprozesse definiert, regelmäßig getestet und mit der tatsächlichen Backup- und Redundanzinfrastruktur abgeglichen werden. Ein RTO von 4 Stunden ist wertlos, wenn das letzte Restore-Testing 18 Monate zurückliegt.
Die RECOVER-Funktion schließt den Kreislauf, indem sie auch die Verbesserungsschleife adressiert: Nach jedem Vorfall sollten Lessons Learned systematisch dokumentiert und in die Verbesserung von IDENTIFY, PROTECT, DETECT und RESPOND eingeflossen werden.
Die 4 Implementation Tiers
Die Implementation Tiers des NIST CSF beschreiben den Reifegrad, mit dem eine Organisation Cybersecurity-Risikomanagement in ihre Prozesse und Kultur integriert hat. Wichtig: Die Tiers sind keine Compliance-Levels und keine direkten Messgrößen für die Sicherheitslage. Sie beschreiben vielmehr, wie systematisch und strategisch eine Organisation an Cybersecurity herangeht.
Die Tiers helfen bei zwei Dingen: erstens beim Verstehen des Status quo (Current Profile), zweitens beim Definieren realistischer Verbesserungsziele (Target Profile). Nicht jede Organisation muss Tier 4 (Adaptive) anstreben — für viele mittelständische Unternehmen ist Tier 3 (Repeatable) ein angemessenes und erreichbares Ziel.
| Tier | Bezeichnung | Merkmale |
|---|---|---|
| Tier 1 | Partial | Kein formales Risikomanagement; reaktive Maßnahmen; kein unternehmensweites Bewusstsein für Cybersecurity-Risiken; keine Integration in Geschäftsstrategie. |
| Tier 2 | Risk Informed | Risikomanagement-Praktiken vorhanden, aber nicht formalisiert; Awareness auf Management-Ebene, aber uneinheitliche Umsetzung; informelle Koordination mit Lieferanten. |
| Tier 3 | Repeatable | Formalisierte, dokumentierte Risikomanagement-Prozesse; regelmäßige Überprüfung und Anpassung; Cybersecurity als Teil der Unternehmenspolitik; strukturiertes Lieferantenmanagement. |
| Tier 4 | Adaptive | Kontinuierliche Anpassung basierend auf aktuellen Bedrohungen; proaktives Threat Intelligence; Cybersecurity vollständig in Unternehmensstrategie integriert; geteilte Erkenntnisse mit Industrie-Partnern. |
CSF 2.0 Assessment durchführen
Ein NIST CSF 2.0 Assessment folgt einer strukturierten Methodik, die auf den Konzepten Current Profile, Target Profile und Gap-Analyse basiert. Der Prozess ist iterativ — das erste Assessment legt die Baseline, jedes Folge-Assessment misst den Fortschritt.
Erfahrungsgemäß sollten Sie für ein erstes vollständiges CSF 2.0 Assessment eines mittelgroßen Unternehmens (500–2.000 Mitarbeiter, 3–5 kritische IT-Systeme) vier bis sechs Wochen einplanen. Der größte Zeitaufwand entsteht nicht bei der Erhebung des Status quo, sondern bei der Diskussion und Abstimmung der Bewertungen zwischen IT, Management und Fachabteilungen.
- 1Scope definieren: Legen Sie fest, welche Organisationseinheiten, Systeme und Geschäftsprozesse in das Assessment einbezogen werden. Ein zu breiter Scope erhöht die Komplexität und reduziert die Tiefe; beginnen Sie bei kritischen Systemen und erweitern iterativ.
- 2Current Profile erstellen: Bewerten Sie für jede der 106 Subcategories den aktuellen Implementierungsgrad auf einer Skala (z.B. 0 = nicht vorhanden, 1 = partiell, 2 = implementiert, 3 = gemessen/optimiert). Nutzen Sie Interviews, Dokumentenanalyse und technische Tests als Evidenzquellen.
- 3Target Profile definieren: Definieren Sie gemeinsam mit dem Management, welchen Zielzustand Sie für welche Subcategories in welchem Zeitraum erreichen wollen. Der Target Profile muss mit der Risikotoleranz, dem Budget und den regulatorischen Anforderungen abgestimmt sein.
- 4Gap-Analyse durchführen: Vergleichen Sie Current und Target Profile systematisch. Identifizieren Sie für jede Lücke den potenziellen Risiko-Impact (hoch/mittel/niedrig) und den ungefähren Aufwand zur Schließung.
- 5Maßnahmen priorisieren: Nutzen Sie eine Impact-vs-Effort-Matrix, um die wichtigsten Quick Wins (hoher Impact, geringer Aufwand) von den strategischen Langzeit-Investitionen zu trennen. Nicht alle Lücken müssen sofort geschlossen werden.
- 6Action Plan erstellen: Übersetzen Sie die priorisierten Maßnahmen in konkrete Projekte mit Verantwortlichen, Budgets, Meilensteinen und Erfolgskennzahlen. Der Action Plan ist das Deliverable des Assessments für das Management.
- 7Kommunizieren und berichten: Präsentieren Sie Ergebnisse sowohl für technische als auch nicht-technische Stakeholder. Das Executive Summary sollte Risiken in Geschäftssprache kommunizieren, nicht in technischen Detailbeschreibungen.
- 8Fortschritt messen und re-assessieren: Führen Sie halbjährliche oder jährliche Folge-Assessments durch, um den Fortschritt zu messen und das Current Profile zu aktualisieren. CSF ist ein kontinuierlicher Verbesserungszyklus, kein einmaliges Projekt.
NIST CSF 2.0 und regulatorische Compliance
Für europäische Unternehmen ist die Frage zentral, wie NIST CSF 2.0 zu den EU-Regularien NIS2, DSGVO, ISO 27001 und DORA passt. Die gute Nachricht: CSF 2.0 ist komplementär zu allen genannten Frameworks und kann als übergreifende Struktur dienen, um Compliance-Aktivitäten zu konsolidieren, statt sie redundant zu betreiben.
Die NIS2-Richtlinie (EU 2022/2555), die in Deutschland durch das NIS2UmsuCG in nationales Recht überführt wird, definiert Mindestsicherheitsanforderungen für wesentliche und wichtige Einrichtungen. Die NIS2-Anforderungen (Artikel 21) lassen sich nahezu vollständig auf CSF 2.0 Kategorien mappen. Unternehmen, die ein CSF 2.0 Assessment durchführen und Tier 3 erreichen, decken dabei den Großteil der NIS2-Anforderungen ab — eine vollständige Kongruenz ist nicht gegeben, aber der Überlapp ist substanziell.
Der Digital Operational Resilience Act (DORA), der seit Januar 2025 für Finanzunternehmen und ihre IT-Dienstleister in der EU gilt, legt besonderen Wert auf ICT-Risikomanagement, Incident Reporting und Supply-Chain-Resilienz — alles Bereiche, die CSF 2.0 in GOVERN, IDENTIFY, RESPOND und RECOVER direkt adressiert.
| Regulation | CSF-Funktion | Abdeckung |
|---|---|---|
| NIS2 — Risikomanagement (Art. 21) | GOVERN, IDENTIFY | Sehr hoch — GV.RM und ID.RA decken NIS2 Risikomanagement-Anforderungen direkt ab |
| NIS2 — Incident Reporting (Art. 23) | DETECT, RESPOND | Hoch — DE.AE und RS.CO strukturieren Erkennungs- und Meldeprozesse |
| NIS2 — Supply Chain Security (Art. 21) | GOVERN (GV.SC) | Sehr hoch — GV.SC ist die dedizierte Supply-Chain-Kategorie in CSF 2.0 |
| DORA — ICT Risk Management | IDENTIFY, PROTECT | Hoch — ID.AM und PR.AA/PR.DS decken die DORA ICT-Risikoanforderungen ab |
| DORA — Operational Resilience | RESPOND, RECOVER | Hoch — RS.MA und RC.RP adressieren DORA Business Continuity Requirements |
| ISO 27001:2022 | Alle 6 Funktionen | Sehr hoch — offizielles NIST-Mapping verfügbar; CSF 2.0 ist weitgehend kompatibel mit Annex A Controls |
| DSGVO — Technische Maßnahmen (Art. 32) | PROTECT, DETECT | Mittel — PR.DS (Datensicherheit) deckt Art. 32 ab; spezifische Datenschutz-Anforderungen erfordern ergänzende Maßnahmen |
Typische Schwachstellen im Assessment
In der Praxis zeigen CSF 2.0 Assessments über Branchen und Unternehmensgrößen hinweg ein konsistentes Muster wiederkehrender Schwachstellen. Die Kenntnis dieser häufigen Findings ermöglicht es, das Assessment gezielt auf diese Bereiche zu fokussieren und Ressourcen effizient einzusetzen.
- 1Kein vollständiges Asset-Inventar (ID.AM): Die meisten Unternehmen unterschätzen die Anzahl ihrer IT-Assets erheblich. Shadow IT, Cloud-Ressourcen außerhalb des offiziellen Procurement-Prozesses und veraltete CMDB-Einträge führen dazu, dass ein substanzieller Teil der IT-Infrastruktur im Assessment-Prozess nicht berücksichtigt wird.
- 2Fehlende Dokumentation der Risikotoleranz (GV.RM): Viele Organisationen haben keine explizit dokumentierte Risikotoleranz für Cybersecurity. Damit fehlt die strategische Grundlage für priorisierte Investitionsentscheidungen — jede Sicherheitsmaßnahme wird reaktiv statt strategisch begründet.
- 3MFA-Ausnahmen auf privilegierten Konten (PR.AA): Multi-Faktor-Authentifizierung ist zwar häufig eingeführt, aber selten lückenlos. Privilegierte Konten (Administratoren, Service-Accounts), Legacy-Systeme und Ausnahmeregelungen für "wichtige" Nutzer sind typische Schwachstellen.
- 4Ungetestete Backup- und Recovery-Prozesse (RC.RP): Backups existieren, aber Restore-Tests werden selten oder gar nicht durchgeführt. Organisationen entdecken Backup-Defizite oft erst im Ernstfall — ein inakzeptables Risiko, das durch einfache Maßnahmen behebbar ist.
- 5Mangelhafte Lieferantenbewertung (GV.SC): Third-Party-Risk-Management ist in vielen Organisationen rudimentär. Sicherheitsanforderungen in Verträgen sind unspezifisch, Lieferanten-Assessments werden nicht regelmäßig durchgeführt, und kritische IT-Abhängigkeiten von Einzellieferanten werden nicht als Risiko dokumentiert.
- 6Alert-Fatigue im Security Monitoring (DE.AE): SIEM-Systeme generieren eine Flut von Alarmen, von denen ein Großteil unbearbeitet bleibt. Ohne Tuning, Priorisierung und ausreichend Analysekapazität ist selbst ein technisch gutes SIEM in der Praxis ineffektiv.
- 7Fehlende Incident-Response-Übungen (RS.MA): Incident-Response-Pläne existieren auf dem Papier, werden aber nicht regelmäßig geübt. Ohne Tabletop-Übungen und realistische Simulationen wissen die Beteiligten im Ernstfall nicht, welche Schritte wann zu unternehmen sind.
- 8Keine Integration von Cybersecurity in den SDLC (PR.PS): Sicherheitsanforderungen werden bei der Software-Entwicklung oft als nachgelagerter Schritt behandelt. Security by Design, Static Application Security Testing (SAST) und Dependency-Scanning sind häufig unzureichend oder inkonsistent implementiert.
Quick-Start: In 5 Schritten zum CSF 2.0 Assessment
Wenn Sie noch kein strukturiertes Cybersecurity-Assessment durchgeführt haben oder nach einer Methodik für ein schnelles erstes Screening suchen, bietet dieser Quick-Start-Ansatz eine praktikable Grundlage. Er kann in zwei bis vier Wochen mit einem kleinen Team durchgeführt werden und liefert ausreichend Erkenntnisse für erste priorisierte Maßnahmen.
- 1Stakeholder identifizieren und einbinden: Laden Sie IT-Leitung, CISO (falls vorhanden), Datenschutzbeauftragten, Vertreter kritischer Fachabteilungen und idealerweise die Geschäftsführung ein. Cybersecurity ist kein reines IT-Thema — ohne Management-Commitment führt das Assessment zu einem Bericht, der in der Schublade verschwindet.
- 2Fokus-Scope festlegen: Beginnen Sie mit Ihren 5–10 kritischsten IT-Systemen und Geschäftsprozessen (diejenigen, deren Ausfall den größten Schaden verursachen würde). Ein vollständiges Assessment kommt später — ein fokussiertes Quick-Assessment in 2 Wochen ist mehr wert als ein umfassendes, das nie fertig wird.
- 3Self-Assessment mit CSF 2.0 Kurzfragebogen: Nutzen Sie die offizielle NIST CSF 2.0 Quick Start Guide oder einen der verfügbaren Quickcheck-Kataloge. Bewerten Sie für jede Kernfunktion den Status auf drei Stufen: Nicht vorhanden (0), Partiell implementiert (1), Vollständig implementiert (2). Dieser erste Durchlauf dauert typischerweise einen halben Tag.
- 4Top-3-Gaps pro Funktion identifizieren: Analysieren Sie die Ergebnisse und identifizieren Sie die drei kritischsten Lücken in jeder der sechs Funktionen. Bewerten Sie jede Lücke nach Risiko-Impact (welchen Schaden kann diese Lücke verursachen?) und Aufwand zur Behebung.
- 5Sofortmaßnahmen und 90-Tage-Plan ableiten: Definieren Sie sofort umsetzbare Quick Wins (typischerweise: MFA auf allen privilegierten Konten, Asset-Inventur anstoßen, Backup-Restore-Test, Incident-Response-Kontaktliste aktualisieren) und einen 90-Tage-Plan für die wichtigsten mittelfristigen Maßnahmen. Präsentieren Sie beides der Geschäftsführung mit konkreten Risikobeschreibungen in Geschäftssprache.
Die wichtigsten Erkenntnisse
- NIST CSF 2.0 (Februar 2024) ist der internationale Standard für strukturierte Cybersecurity-Assessments und gilt jetzt explizit für alle Organisationstypen und -größen — nicht mehr nur für kritische Infrastrukturen.
- Die neue GOVERN-Funktion ist die zentrale Neuerung: Sie verankert Cybersecurity als strategische Managementaufgabe mit klaren Rollen, dokumentierter Risikotoleranz und Vorstandsbeteiligung.
- Die 4 Implementation Tiers beschreiben nicht die Sicherheitslage, sondern den Reifegrad des Risikomanagements. Tier 3 (Repeatable) ist für die meisten mittelständischen Unternehmen ein realistisches und angemessenes Ziel.
- Ein CSF 2.0 Assessment in 5 Schritten (Scope, Current Profile, Target Profile, Gap-Analyse, Action Plan) liefert eine klare Roadmap — typischer Zeitaufwand für ein mittelgroßes Unternehmen: 4–6 Wochen.
- NIST CSF 2.0 bietet starke Überschneidungen mit NIS2, DORA und ISO 27001. Unternehmen können CSF als übergreifende Struktur nutzen, um Compliance-Aufwände zu konsolidieren statt redundant zu betreiben.
Passende Assessment-Templates
Weiterlesen
NIS2-Umsetzungsgesetz: Der Pflichten-Fahrplan für Geschäftsführer
Artikel lesenCyber Resilience Act: Die 24-Stunden-Meldepflicht ab September 2026 — ein SDLC-Fahrplan
Artikel lesenNIS2-Compliance für IT-Teams — Praktischer Governance-Guide 2026
Artikel lesenDORA vs. NIS2 — Welche EU-Resilienzpflicht trifft Sie wirklich?
Artikel lesenHäufig gestellte Fragen
Die Kosten variieren stark je nach Scope und Unternehmensgröße. Ein Self-Assessment mit internen Ressourcen (Zeit + NIST-Dokumentation) ist kostenlos. Ein externer Berater für ein vollständiges Assessment eines mittelständischen Unternehmens (500–2.000 MA) kostet typischerweise zwischen 15.000 und 50.000 Euro, abhängig von der Tiefe der technischen Tests, der Anzahl Standorte und der Komplexität der IT-Landschaft. Für einen initialen Quick-Check (2–3 Beratertage) sollten Sie mit 5.000–10.000 Euro kalkulieren.
Ein fokussiertes Quick-Assessment auf Basis der kritischsten Systeme lässt sich in 2–3 Wochen durchführen. Ein vollständiges, tiefes Assessment inklusive technischer Tests (Penetration Testing, Vulnerability Scanning), Interviews aller relevanten Stakeholder und umfassender Dokumentenanalyse dauert typischerweise 6–12 Wochen für ein mittelgroßes Unternehmen. Die anschließende Erstellung und Präsentation des Assessment-Reports kommt noch hinzu.
Nein — NIST CSF ist kein Zertifizierungs-Framework. Es gibt keine offizielle NIST-Zertifizierung für die Nutzung des CSF. Unternehmen, die eine externe, überprüfbare Zertifizierung anstreben, sollten ISO/IEC 27001 in Betracht ziehen, die von akkreditierten Zertifizierungsstellen ausgestellt wird. NIST CSF und ISO 27001 sind gut kompatibel — ein CSF-Assessment kann als Vorbereitung auf eine ISO-27001-Zertifizierung genutzt werden.
Ein reifes CSF 2.0 Assessment auf Tier 3 deckt den Großteil der NIS2-Anforderungen aus Artikel 21 ab. Allerdings gibt es spezifische NIS2-Anforderungen (z.B. konkrete Meldepflichten an die zuständige nationale Behörde, spezifische Schulungspflichten für Leitungsorgane), die über das CSF hinausgehen. Empfohlen wird ein kombinierter Ansatz: CSF 2.0 als methodische Grundlage, ergänzt durch ein dediziertes NIS2-Gap-Assessment für die EU-spezifischen Anforderungen.
Nein. Das CSF 2.0 ist ausdrücklich nicht als vollständige Checkliste gedacht, die jede Subcategory erfüllen muss. Stattdessen sollen Sie auf Basis Ihrer Risikobewertung, Ihrer Branche und Ihrer Ressourcen einen priorisierten Target Profile definieren. Für kleinere Unternehmen oder erste Assessments empfiehlt NIST sogar explizit, mit einem reduzierten Scope zu beginnen und iterativ zu erweitern.