Bedrohungsmodellierung für ISO 27001, NIS2 und DORA

Anya, CISO eines schnell wachsenden Fintech-Unternehmens, sollte den Launch-Plan für eine neue B2B-Plattform zur Bewertung von Zahlungsrisiken freigeben. Das Leitungsorgan wollte den Markteintritt noch vor Quartalsende. Der Vertrieb hatte bereits Bankkunden in Aussicht. Die Entwicklung hatte eine cloud-native Architektur mit Identitätsattributen, Gerätesignalen, Transaktionsmetadaten, verhaltensbasierten Risikowerten, einer verwalteten Datenbank und einem Drittanbieter für Analysen skizziert.

Auf dem Papier sah die Plattform wie ein kommerzieller Durchbruch aus. Für Anya sah sie nach fünf Compliance-Diskussionen aus, die gleichzeitig auf das Unternehmen zukamen.

Als Finanztechnologieanbieter stand das Unternehmen unter DORA-Druck. Als Cloud-Service- und Digitalplattformanbieter musste es seine NIS2-Exponierung verstehen. Da die Plattform personenbezogene Daten von Personen in der EU verarbeitete, galt GDPR. Unternehmenskunden erwarteten eine ISO/IEC 27001:2022-Zertifizierung. Würde der Service Teil eines vernetzten Softwareprodukts, kämen Anforderungen des Cyber Resilience Act an Security-by-Design-Produktnachweise hinzu.

Das Entwicklungsteam schlug den üblichen Sicherheitsplan vor: Abhängigkeiten scannen, einen Schwachstellenscan durchführen, einen Penetrationstest beauftragen und kritische Feststellungen vor der Produktivsetzung beheben. Anya wusste, dass das nicht ausreichte. Diese Aktivitäten testen, was bereits gebaut wurde. Sie belegen nicht, dass die Architektur von Beginn an sicher entworfen wurde, dass Vertrauensgrenzen verstanden wurden, dass Datenflüsse personenbezogener Daten minimiert wurden, dass Lieferantenannahmen überprüft wurden oder dass Szenarien für Serviceunterbrechungen vor dem Launch berücksichtigt wurden.

Deshalb bremste sie das Meeting mit vier Fragen:

1. Wo liegen die Vertrauensgrenzen?
2. Welche Missbrauchsszenarien könnten zu Betrug, Datenexposition oder Serviceunterbrechungen führen?
3. Welche Designentscheidungen reduzieren das Risiko, bevor Code geschrieben wird?
4. Welche Nachweise werden Prüfer für ISO 27001, NIS2, DORA, CRA und GDPR in sechs Monaten akzeptieren?

An dieser vierten Frage scheitern viele Organisationen. Bedrohungsmodellierung wird häufig als hilfreicher Engineering-Workshop behandelt und anschließend in einer Wiki-Seite vergraben. Im Jahr 2026 reicht das nicht mehr aus. Für SaaS-Anbieter, Fintechs, Cloud-Plattformen, MSPs, MSSPs, Betreiber digitaler Infrastruktur und Softwarehersteller ist Bedrohungsmodellierung zu einem Motor für Compliance-Nachweise geworden.

Ein ausgereifter Prozess zur Bedrohungsmodellierung überführt STRIDE-Feststellungen, Missbrauchsszenarien und Architekturentscheidungen in Einträge im Risikoregister, Sicherheitsanforderungen, Behandlungspläne, Testfälle, Aufgaben zur Lieferantensicherung, Nachweise für Datenschutz durch Technikgestaltung und Nachvollziehbarkeit in der Anwendbarkeitserklärung (SoA).

Warum Security-by-Design-Nachweise jetzt wichtig sind

Moderne Vorschriften nähern sich derselben Erwartung an: Organisationen müssen Sicherheits- und Datenschutzrisiken frühzeitig identifizieren, Verantwortlichkeiten zuweisen, angemessene Kontrollen umsetzen und Nachweise aufbewahren.

ISO/IEC 27001:2022 verlangt ein risikobasiertes Informationssicherheitsmanagementsystem. Die Abschnitte 6.1.2 und 6.1.3 verlangen Informationssicherheitsrisikobeurteilung und Risikobehandlung. Abschnitt 8.1 verlangt operative Planung und Steuerung. Anhang A stellt Controls bereit, die über die Anwendbarkeitserklärung auf Grundlage von Risiko, rechtlichen Anforderungen und geschäftlichen Anforderungen auszuwählen sind.

NIS2 überträgt dasselbe Prinzip auf die Cybersicherheits-Governance. Article 20 verlangt, dass Leitungsorgane Cybersicherheits-Risikomanagementmaßnahmen genehmigen und deren Umsetzung überwachen. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, darunter Risikoanalyse, Verfahren zum Umgang mit Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, Sicherheit bei Beschaffung, Entwicklung und Wartung, Umgang mit Schwachstellen, Cyberhygiene, Verschlüsselung, Zugriffskontrolle, Asset-Management und, soweit angemessen, MFA.

DORA betrachtet dies ab dem 17. Januar 2025 durch die Brille der digitalen operationalen Resilienz im Finanzsektor. Die Verordnung verlangt von erfassten Finanzunternehmen, ein solides, umfassendes und dokumentiertes Rahmenwerk für das Management von IKT-Risiken zu unterhalten, IKT-Assets und Abhängigkeiten zu identifizieren, Schutz- und Präventionsmaßnahmen anzuwenden, anomale Aktivitäten zu erkennen, die digitale operationale Resilienz zu testen, IKT-Drittparteienrisiken zu steuern und Fähigkeiten für Reaktion und Wiederherstellung vorzubereiten. Für erfasste Finanzunternehmen ist DORA der sektorspezifische Rechtsakt der Union für sich überschneidende NIS2-Verpflichtungen.

GDPR ergänzt Rechenschaftspflicht sowie Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Jedes System, das personenbezogene Daten verarbeitet, muss rechtmäßige, faire, transparente, zweckgebundene, minimierte, speicherbegrenzte und sichere Verarbeitung nachweisen können. Ein Bedrohungsmodell, das Datenflüsse personenbezogener Daten, Zugriffspfade, Protokolle, Aufbewahrung, Löschung und Übermittlungen an Drittparteien abbildet, ist unmittelbar relevant für GDPR Articles 5, 25, 32 und 35.

Der Cyber Resilience Act erhöht den Druck auf Produkte mit digitalen Elementen. Produktteams benötigen Nachweise über den gesamten Lebenszyklus hinweg, dass Cybersicherheitsrisiken, vorhersehbare Fehlverwendung, Schnittstellen, Aktualisierungsmechanismen, Authentifizierungsabläufe und Annahmen zum Umgang mit Schwachstellen frühzeitig berücksichtigt wurden.

Die Lehre ist klar: Wenn eine Architekturprüfung nicht auf Risiken, Controls, Verantwortliche, Risikominderungsmaßnahmen und Tests zurückgeführt werden kann, wird sie in einem Audit oder einer regulatorischen Prüfung im Jahr 2026 schwer zu verteidigen sein.

Das Clarysec-Modell: ein Bedrohungsmodell, viele Ergebnisse

Der Ansatz von Clarysec beginnt mit einem praktischen Grundsatz: Ein Bedrohungsmodell ist erst vollständig, wenn es auditierbare Entscheidungen erzeugt.

In Zenith Blueprint: 30-Schritte-Roadmap eines Auditors [ZB] gibt Schritt 9 in der Phase Risikomanagement Teams ein einfaches Format, um technische Beobachtungen in Risikosprache zu überführen:

„Kombinieren Sie nun Asset + Bedrohung + Schwachstelle zu einer prägnanten Beschreibung des Risikoszenarios. Beschreiben Sie im Kern den potenziellen Vorfall. Dies wird später ein Eintrag in Ihrem Risikoregister. Verwenden Sie ein einfaches Format: ‚[Bedrohung] nutzt [Schwachstelle] auf [Asset] aus, was zu [Auswirkung] führt.‘“

Dieser Satz ist die Brücke zwischen Engineering und Compliance.

Eine Whiteboard-Notiz wie „Spoofing-Risiko bei Partner-API“ wird zu:

„Ein Angreifer nutzt schwache Partner-API-Authentifizierung auf der API für Transaktionsrisiken aus, was zu unbefugtem Zugriff auf Zahlungsrisikoentscheidungen und zur Exposition personenbezogener Daten führt.“

Damit hat die Feststellung ein Asset, eine Bedrohung, eine Schwachstelle und eine Auswirkung. Sie kann bewertet, zugewiesen, behandelt, getestet und akzeptiert werden.

Die Richtlinienebene macht dies wiederholbar. Die P24 – Richtlinie für sichere Softwareentwicklung [P24] legt fest:

„Alle neuen Anwendungen und wesentlichen Änderungen müssen vor Entwicklungsbeginn einer Sicherheitsarchitekturprüfung und Bedrohungsmodellierung unterzogen werden.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.

Sie verlangt außerdem:

„Designprüfungen müssen Datenflussdiagramme, Vertrauensgrenzen und Risikominderungsmaßnahmen für identifizierte Risiken dokumentieren.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.2.

Diese beiden Klauseln sind starke Audit-Anker. Sie zeigen, dass Bedrohungsmodellierung nicht optional ist und dass Designnachweise Diagramme, Grenzen und Entscheidungen zur Risikominderung enthalten müssen.

Die P06 – Risikomanagement-Richtlinie [P06] verbindet Bedrohungsmodellierung mit unternehmensweitem Risikomanagement:

„Alle Geschäftsbereiche müssen Risiken proaktiv mit strukturierten Techniken identifizieren, die aus ISO/IEC 27005:2024 abgeleitet sind, einschließlich Bedrohungsmodellierung, Asset-Abhängigkeitskartierung und szenariobasierter Identifizierung.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.

Sie legt außerdem fest:

„Identifizierte Risiken müssen mit Bezug auf den Asset-Verantwortlichen, den Bedrohungsakteur, die Schwachstelle und die potenziellen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit (CIA) dokumentiert werden.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.4.

Dies ist die Nachweiskette, die Auditoren sehen wollen: Richtlinienanforderung, Designtätigkeit, Risikoszenario, Control-Auswahl, Umsetzung, Test und Genehmigung.

STRIDE macht Abdeckung systematisch, Missbrauchsszenarien machen sie realistisch

STRIDE bleibt eine der nützlichsten Methoden für Bedrohungsmodellierung in der Entwurfsphase, weil sie Teams zwingt, sechs häufige Fehlermodi zu betrachten:

• Spoofing
• Manipulation
• Abstreitbarkeit
• Offenlegung von Informationen
• Denial-of-Service
• Rechteerweiterung

Für Anyas Plattform zur Bewertung von Zahlungsrisiken nutzte das Team STRIDE für jede Komponente, jeden Datenfluss und jede Vertrauensgrenze.

Spoofing warf die Frage auf, ob ein Partner-API-Client einen Bankkunden imitieren könnte, wenn gegenseitige Authentifizierung schwach ist. Manipulation legte das Risiko offen, dass Gerätesignale oder Transaktionsbeträge vor der Aufnahme manipuliert werden könnten. Abstreitbarkeit machte den Bedarf an Administrator- und Transaktions-Audit-Protokollen deutlich. Die Offenlegung von Informationen konzentrierte sich auf Abfluss über Protokolle, Analyseexporte, Support-Werkzeuge und Reporting-APIs. Denial-of-Service zwang das Team, Spitzenfenster bei Transaktionen und Flooding mit fehlerhaften Anfragen zu betrachten. Rechteerweiterung machte Risiken in Support-Rollen, Sitzungstoken und administrativen Funktionen sichtbar.

Missbrauchsszenarien überführten diese Kategorien in realistische Geschichten:

• Ein Betrüger lädt manipulierte Gerätesignale hoch, um einen Risikowert zu beeinflussen.
• Eine kompromittierte Partner-Zugangsdatenkennung überflutet die API mit betrügerischen Anfragen.
• Ein Entwickler verwendet personenbezogene Produktivdaten in einer Testumgebung.
• Ein böswilliger Insider exportiert Kundenkennungen und Scoring-Logik.
• Ein Ausfall eines Cloud-Analytics-Lieferanten blockiert Risikoentscheidungen während eines Zahlungsfensters.
• Eine fehlerhafte Speicherkonfiguration legt hochgeladene Identitätsdokumente offen.
• Ein Lösch-Workflow entfernt den Anwendungsdatensatz, belässt aber Backups und Lieferantenkopien.

Jedes Missbrauchsszenario wurde zu einem Datensatz zu Designrisiken mit betroffenem Asset, Bedrohungsakteur, Schwachstelle, Auswirkung, bestehenden Annahmen, erforderlicher Risikominderung, Verantwortlichem für das Restrisiko, Testnachweis und regulatorischer Relevanz.

Diese Struktur verhindert vage Feststellungen wie „API-Sicherheitsrisiko“. Sie erzeugt risikotaugliche Aussagen auf Nachweisniveau, etwa:

„Ein Angreifer nutzt gestohlene Partner-Zugangsdaten, um betrügerische Scoring-Anfragen über die API für Transaktionsrisiken einzureichen, was zu einer Beeinträchtigung der Integrität von Risikoentscheidungen, möglichen finanziellen Verlusten für Kunden und unbefugter Verarbeitung personenbezogener Daten führt.“

Zuordnung von Bedrohungsmodellierung zu ISO/IEC 27001:2022 und ISO/IEC 27002:2022

ISO/IEC 27001:2022 verlangt Bedrohungsmodellierung nicht ausdrücklich. Die Norm verlangt konsistente, dokumentierte Risikobeurteilung und Risikobehandlung. Bedrohungsmodellierung ist eine der stärksten Methoden, um diese Nachweise in Software-, Cloud- und Produktumgebungen zu erzeugen.

Entscheidend ist Nachvollziehbarkeit. In ZB empfiehlt Schritt 13 der Phase Risikomanagement, Controls Risiken und Klauseln zuzuordnen, einschließlich Verweisen auf Anhang A in Behandlungsplänen und Hinweisen, wo Controls GDPR, NIS2 oder DORA unterstützen.

Zenith Controls: Der Cross-Compliance-Leitfaden [ZC] unterstützt die Strukturierung dieser Nachvollziehbarkeit, indem ISO/IEC 27002:2022-Controls verwandten Controls, Auditerwartungen und externen Rahmenwerken zugeordnet werden.

Für Bedrohungsmodellierung ist ISO/IEC 27002:2022 control 5.8, Informationssicherheit im Projektmanagement, der Anker für Projekt-Governance. Er zeigt, dass Sicherheit in Projektinitiierung, Planung, Umsetzung und Abnahme integriert ist.

Control 8.25, sicherer Entwicklungslebenszyklus, ist der SDLC-Anker. ZC verbindet 8.25 mit unterstützenden Controls wie 8.26 Sicherheitsanforderungen für Anwendungen, 8.27 sichere Systemarchitektur und Engineering-Grundsätze, 8.28 sichere Programmierung, 8.29 Sicherheitsprüfung in Entwicklung und Abnahme, 8.30 ausgelagerte Entwicklung und 8.31 Trennung von Entwicklungs-, Test- und Produktivumgebungen.

Diese Zuordnung hilft, aus einem Design-Workshop Nachweise für die Anwendbarkeitserklärung zu machen. Sie unterstützt außerdem die Abschnitte 4 bis 6 von ISO/IEC 27001:2022, weil Anforderungen interessierter Parteien, ISMS-Geltungsbereich, Verpflichtungen der Leitung und Entscheidungen zur Risikobehandlung sichtbar werden.

Eine Cross-Compliance-Übersicht für NIS2, DORA, CRA, GDPR und NIST CSF

Ein gut durchgeführtes Bedrohungsmodell sollte nicht fünf voneinander getrennte Compliance-Arbeitsstränge erzeugen. Es sollte ein Nachweispaket zu Designrisiken erzeugen, das über Rahmenwerke hinweg wiederverwendet werden kann.

NIST CSF 2.0 ist besonders nützlich für die Kommunikation mit der Geschäftsleitung. Seine GOVERN-Funktion unterstützt rechtliche, regulatorische, vertragliche und datenschutzbezogene Verpflichtungen, während die Ergebnisse zur Lieferkette helfen, Kritikalität von Lieferanten, vertragliche Anforderungen, Due Diligence, Überwachung und Vorfallsplanung mit denselben Nachweisen aus dem Bedrohungsmodell zu verbinden.

GDPR erfordert besondere Aufmerksamkeit, weil Bedrohungsmodellierung und DSFA-Arbeit einander verstärken sollten. Die P17 – Richtlinie zu Datenschutz und Privatsphäre [P17] legt fest:

„Bedrohungsmodellierung und Datenschutz-Folgenabschätzungen (DPIAs) sind für Verarbeitungssysteme mit hohem Risiko verpflichtend.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.4.

Für kleinere Teams legt die P17S – Richtlinie zu Datenschutz und Privatsphäre - SME [P17S] fest:

„Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen muss in allen neuen Systemen und Services durchgesetzt werden.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.1.

Das Ergebnis ist ein praktikables Betriebsmodell: Nutzen Sie dieselben Datenflussdiagramme, Vertrauensgrenzen und Missbrauchsszenarien für Sicherheitsrisiken, Datenschutzrisiken, Lieferantenprüfung und regulatorische Nachweise.

Ein 90-minütiger Designrisiko-Sprint für risikobehaftete Funktionen

Bedrohungsmodellierung muss nicht als schwergewichtiges Programm beginnen. Für eine neue Zahlungs-API, einen Onboarding-Workflow, eine KI-gestützte Funktion, einen Identitätsdienst, eine Cloud-Migration oder eine externe Integration kann ein 90-minütiger Designrisiko-Sprint wertvolle Nachweise erzeugen.

1. Einen Projektsicherheits-Checkpoint eröffnen

Nutzen Sie P24 Klausel 6.1.1 als Auslöser. Erstellen Sie für jede neue Anwendung oder wesentliche Änderung einen Nachweisordner mit:

• Architekturdiagramm
• Datenflussdiagramm
• Übersicht der Vertrauensgrenzen
• Asset-Liste
• Notizen zu personenbezogenen Daten
• Liste der Lieferanten- und IKT-Abhängigkeiten
• Erste Sicherheitsanforderungen
• Arbeitsblatt zum Bedrohungsmodell
• Einträge im Risikoregister
• Nachvollziehbarkeit von Risikominderung und Tests
• Genehmigungsaufzeichnung

Für kleinere Organisationen unterstützt die P24S – Richtlinie für sichere Softwareentwicklung - SME [P24S] dieselbe Disziplin, indem sie sichere Entwicklungsprozesse mit Entwickler-Zugriffskontrolle, Tests, Bedrohungsmodellierung und Dokumentation verknüpft. Sie verlangt außerdem die zentrale Aufbewahrung von Checklisten, Prüfgenehmigungen, Testberichten und Komponentenverzeichnissen für Auditzwecke. Klausel 11.3.1 verweist auf SA-3 bis SA-15, um sichere Entwicklungsprozesse einschließlich Bedrohungsmodellierung zu definieren.

2. Den minimal tragfähigen Datenfluss zeichnen

Beginnen Sie nicht mit einem ausgearbeiteten Diagramm. Beginnen Sie mit den Flüssen, die Risiko erzeugen:

• Benutzer laden Identitätsdokumente oder Transaktionsdaten hoch.
• Die Webanwendung sendet Anfragen an die API.
• Die API schreibt in verwalteten Speicher oder eine Datenbank.
• Der Lieferant erhält Verifikations- oder Analysedaten.
• Das interne Analystenportal zeigt Ergebnisse an.
• Das Kundensystem ruft Statusinformationen oder Entscheidungen ab.
• Protokolle, Monitoring-Werkzeuge und Backups erhalten Kopien.

Kennzeichnen Sie jede Vertrauensgrenze: Internet zu Anwendung, Anwendung zu API, interner Service zu Lieferant, Produktivsystem zu Analyseplattform, Administrator zu privilegierter Funktion und Produktivumgebung zu Nicht-Produktivumgebung.

3. STRIDE und Missbrauchsszenarien gemeinsam durchführen

Stellen Sie für jede Grenze die STRIDE-Fragen und formulieren Sie Missbrauchsszenarien in klarer Geschäftssprache. Ziel ist nicht, jeden denkbaren Angriff aufzulisten. Ziel ist, plausible, wesentliche Szenarien zu identifizieren, die Vertraulichkeit, Integrität, Verfügbarkeit, Datenschutz, Resilienz oder Betriebssicherheit betreffen.

4. Feststellungen in Risikoszenarien überführen

Nutzen Sie die Formel aus ZB Schritt 9:

„[Bedrohung] nutzt [Schwachstelle] auf [Asset] aus, was zu [Auswirkung] führt.“

Zum Beispiel:

„Ein Angreifer nutzt schwache Zugriffskontrollen für Objektspeicher auf dem Repository für Identitätsdokumente aus, was zu unbefugter Offenlegung personenbezogener Daten und regulatorischer Meldeexponierung führt.“

Ergänzen Sie anschließend Verantwortlichen, Eintrittswahrscheinlichkeit, Auswirkung, inhärentes Risiko, Behandlungsoption, Ziel-Control, Restrisiko und Nachweise.

5. Anforderungen und Tests ableiten

Ein Bedrohungsmodell ist nicht abgeschlossen, wenn Risiken aufgelistet sind. Es ist abgeschlossen, wenn Risikominderungsmaßnahmen umgesetzt, getestet oder formal akzeptiert sind.

Die Änderungsmanagement-Richtlinie - SME liefert einen praktischen Auslöser:

„Wenn eine Änderung sensitive Daten, Systemzugriffsrechte oder externe Integrationen betrifft, ist eine Prüfung der Sicherheitsauswirkungen erforderlich. Der benannte Sicherheits- oder Compliance-Kontakt muss bewerten, ob die Änderung zusätzliche Risiken einführt, und zusätzliche Schutzmaßnahmen empfehlen.“
Aus dem Abschnitt „Risikobehandlung und Ausnahmen“, Richtlinienklausel 7.5.1.

Sensitive Daten, Zugriffsrechte und externe Integrationen sind genau die Änderungen, die eine Designrisiko-Prüfung verlangen.

Was unterschiedliche Auditoren fragen werden

Ein ISO/IEC 27001:2022-Auditor wird fragen, ob Bedrohungsmodellierung Teil eines definierten Risikobeurteilungsprozesses ist, ob Kriterien konsistent sind, ob Risikoverantwortliche Restrisiken genehmigt haben, ob Behandlungspläne mit der SoA verknüpft sind und ob Nachweise aufbewahrt werden. Er wird auf Wiederholbarkeit, Versionshistorie, Sichtbarkeit in der Managementbewertung und Abdeckung durch interne Audits achten.

Für Anhang A wird er Ihre Nachweise mit 5.8, 8.25, 8.26, 8.27 und 8.29 verbinden. ZB Schritt 21, Controls in der Praxis, hebt sichere Systemarchitektur und Engineering-Grundsätze hervor, indem gefragt wird, welche Prinzipien sichere Architektur leiten. Auditoren können fragen, ob Bedrohungsmodellierung während des Designs mit Methoden wie STRIDE oder Attack Trees durchgeführt wird und ob Architekturentscheidungen vor der Implementierung geprüft werden.

Ein NIS2-Prüfer wird sich auf Governance und Verhältnismäßigkeit konzentrieren. Er kann fragen, ob das Management den Ansatz für Cybersicherheits-Risikomanagement genehmigt hat, ob sichere Beschaffung, Entwicklung und Wartung abgedeckt sind, ob Lieferantenschwachstellen berücksichtigt werden, ob Vorfallszenarien mit Melde-Workflows verbunden sind und ob Szenarien zur Aufrechterhaltung des Geschäftsbetriebs analysiert werden. Die gestufte Meldung erheblicher Vorfälle nach NIS2 Article 23, einschließlich Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats, macht Szenarioklarheit besonders wertvoll.

Ein DORA-Prüfer wird sich auf IKT-Risiko-Governance, kritische Funktionen, IKT-Assets, externe Abhängigkeiten, Resilienztests und IKT-Drittparteidienste konzentrieren. Wenn das System eine kritische oder wichtige Funktion unterstützt, wird er stärkere Nachweise erwarten, die Bedrohungsszenarien mit Asset-Inventaren, Abhängigkeitsübersichten, Testplänen, Drittparteienverträgen und Wiederherstellungsmaßnahmen verbinden.

Ein Datenschutzprüfer wird Datenflüsse untersuchen und fragen, ob die Verarbeitung personenbezogener Daten notwendig, rechtmäßig, minimiert und geschützt ist. Er wird fragen, ob besondere Kategorien personenbezogener Daten beteiligt sind, ob Pseudonymisierung oder Verschlüsselung eingesetzt wird, ob Aufbewahrung begründet ist und ob eine DPIA erforderlich ist. Bedrohungsmodellierung und DPIA sind unterschiedliche Tätigkeiten, sollten aber Diagramme, Szenarien und Risikominderungsmaßnahmen gemeinsam nutzen.

Ein an NIST CSF oder COBIT 2019 orientierter Prüfer wird auf Governance, Prozessverantwortung, Leistung, Rechenschaftspflicht und kontinuierliche Verbesserung achten. Das STRIDE-Arbeitsblatt selbst ist für ihn möglicherweise weniger wichtig als die Frage, ob der Prozess zuverlässig, gemessen, genehmigt und verbessert wird.

Häufige Nachweisfehler bei Bedrohungsmodellierung

Die häufigsten Fehler sind nicht technischer Natur. Es sind Nachweisfehler.

Teams führen Bedrohungsmodellierung zu spät durch, nachdem das System bereits gebaut wurde. Zu diesem Zeitpunkt wird der Workshop zu einem Briefing vor dem Penetrationstest statt zu einer Designkontrolle.

Feststellungen werden nicht in Risikosprache überführt. „Auth hinzufügen“ oder „Logging-Problem“ kann Entwicklungsteams helfen, aber Auditoren benötigen Asset, Bedrohung, Schwachstelle, Auswirkung, Verantwortlichen, Behandlung und Restrisiko.

Datenschutz und Sicherheit werden getrennt. Ein Team dokumentiert Spoofing- und Injektionsrisiken, während ein anderes Aufbewahrung und Rechtsgrundlage dokumentiert. GDPR-Rechenschaftspflicht funktioniert besser, wenn Datenflüsse, Missbrauchsszenarien und DSFA-Auslöser verbunden sind.

Lieferantenannahmen bleiben undokumentiert. NIS2, DORA und NIST CSF erhöhen die Erwartungen an das IKT-Lieferkettenrisiko. Wenn eine Risikominderungsmaßnahme von Verschlüsselung, Protokollierung, Löschung, Resilienz oder Incident Response eines Lieferanten abhängt, müssen die Nachweise erhoben werden.

Tests werden nicht auf Bedrohungen zurückgeführt. Ein Penetrationstestbericht kann nützlich sein, belegt aber möglicherweise nicht, dass die konkreten Designrisiken gemindert wurden. Jede wesentliche Bedrohungsfeststellung sollte Validierungsnachweise haben.

Restrisikoakzeptanz erfolgt informell. „Wir akzeptieren das für das MVP“ reicht nicht aus. ISO/IEC 27001:2022 erwartet Restrisikoakzeptanz durch geeignete Risikoverantwortliche als dokumentierte Information.

Ihr Nachweispaket zur Bedrohungsmodellierung für 2026

Führen Sie für jedes wesentliche System oder jede signifikante Änderung ein standardisiertes Nachweispaket, das ISO 27001, NIS2, DORA, CRA, GDPR und Kundenvertrauen unterstützen kann.

Die Risikomanagement-Richtlinie - SME beschreibt das Betriebsmodell treffend:

„Sie stellt sicher, dass Risikomanagement ein aktiver Bestandteil von Planung, Projektdurchführung, Lieferantenauswahl und Incident Response ist, ausgerichtet an ISO 27001, ISO 31000 und geltenden regulatorischen Anforderungen.“
Aus dem Abschnitt „Zweck“, Richtlinienklausel 1.2.

Das ist das richtige Ziel. Bedrohungsmodellierung sollte Planung, Engineering, Lieferantenauswahl, Incident Response und Auditbereitschaft beeinflussen.

Bedrohungsmodellierung vor Ihrer nächsten Freigabe auditbereit machen

Die Organisationen, die den Compliance-Druck 2026 am besten bewältigen werden, sind nicht diejenigen mit den meisten Diagrammen. Es sind diejenigen, die eine einfache Kette belegen können:

Designrisiko wurde identifiziert. Risiko wurde bewertet. Controls wurden ausgewählt. Risikominderungsmaßnahmen wurden umgesetzt. Tests haben die Risikominderungsmaßnahmen validiert. Restrisiko wurde genehmigt. Nachweise sind den relevanten Rahmenwerken zugeordnet.

Beginnen Sie mit einer risikobehafteten Änderung: einer Zahlungsintegration, einer neuen API, einem KI-gestützten Workflow, einer Identitätsfunktion, einer Cloud-Migration, einem kundenbezogenen Produkt-Release oder einem mit Lieferanten verbundenen Service. Führen Sie einen 90-minütigen Designrisiko-Sprint durch. Nutzen Sie ZB, um Feststellungen in Risikoszenarien, Behandlungspläne und SoA-Nachvollziehbarkeit zu überführen. Nutzen Sie ZC, um ISO/IEC 27002:2022-Controls wie 5.8, 8.25, 8.26, 8.27 und 8.29 unterstützenden Controls, Lieferantenrisiko, Datenschutz, Tests und Auditnachweisen zuzuordnen. Richten Sie P24, P06, P17, P24S und Ihr Änderungsmanagementverfahren so aus, dass Bedrohungsmodellierung verpflichtend, wiederholbar und überprüfbar wird.

Wenn Clarysec Sie unterstützen soll, beginnen Sie mit einer Prüfung Ihrer Nachweise zur Bedrohungsmodellierung. Wir bewerten ein reales Projekt, identifizieren Lücken gegenüber den Erwartungen aus ISO/IEC 27001:2022, NIS2, DORA, CRA und GDPR und liefern Ihnen eine praktikable Roadmap zur Mängelbehebung, die Entwicklungsteams, Auditoren und Leitungsorgan gleichermaßen verstehen.