Auditbereite ISO 27001-Risikobeurteilung für NIS2 und DORA

Der Kaffee auf Sarahs Schreibtisch war kalt.

Als CISO eines schnell wachsenden Fintech-Unternehmens war sie Druck gewohnt. Das Unternehmen hatte gerade einen großen Bankpartner gewonnen, und der Due-Diligence-Fragebogen auf ihrem Bildschirm hätte eine reine Formsache sein sollen. Die ersten Fragen waren vertraut: ISO/IEC 27001:2022-Anwendbarkeitserklärung (SoA) bereitstellen, das aktuelle Risikoregister teilen, die Methodik der Risikobeurteilung erläutern.

Dann änderte sich der Fragebogen.

Weisen Sie nach, wie Ihr Risikomanagementprogramm DORA adressiert. Erläutern Sie Ihre Vorbereitung auf die NIS2-Richtlinie, einschließlich Rechenschaftspflicht des Managements und Maßnahmen zu Lieferkettenrisiken. Stellen Sie Nachweise bereit, dass kritische IKT-Lieferanten bewertet, überwacht und in Pläne zur Vorfallsreaktion sowie zur Geschäftskontinuität einbezogen werden.

Am Montagmorgen stand dasselbe Thema auf der Agenda des Risikoausschusses des Leitungsorgans. ISO 27001-Zertifizierungsaudit in acht Wochen. DORA-Druck von Kunden aus dem Finanzsektor. NIS2-Klassifizierungsfragen für einen cloudgehosteten Servicebereich, der in die EU expandiert. Der Einkauf sagte, Lieferantenprüfungen existierten, die Nachweise seien jedoch über E-Mails, Vertragsordner und eine Lieferantentabelle verteilt. Die Rechtsabteilung sagte, die regulatorische Zuordnung sei noch in Arbeit. Engineering sagte, das Risikoregister sei im Wesentlichen fertig.

Das Leitungsorgan stellte die einzige Frage, die zählte:

Können wir nachweisen, dass unsere Risikobeurteilung und unser Risikobehandlungsplan ausreichen?

Das ist das eigentliche Problem für SaaS-, Fintech-, Managed-Service-, Cloud- und digitale Plattformunternehmen. Nicht, ob ein Risikoregister existiert. Nicht, ob Annex A-Kontrollen in eine Tabelle kopiert wurden. Entscheidend ist, ob die Organisation unter Audit- und Kundendruck nachweisen kann, dass ihr ISO 27001-Risikobeurteilungsprozess wiederholbar, risikobasiert, von Risikoverantwortlichen genehmigt, mit Risikobehandlungsmaßnahmen verknüpft, auf rechtliche Verpflichtungen abgebildet und operativ wirksam ist.

Richtig umgesetzt, können eine ISO 27001-Risikobeurteilung und ein Risikobehandlungsplan die ISO/IEC 27001:2022-Zertifizierung, NIS2 Article 21-Maßnahmen zum Cybersicherheitsrisikomanagement, DORA-Anforderungen an das IKT-Risikomanagement, GDPR-Rechenschaftspflicht, Lieferantensicherheit, Vorfallsbereitschaft und Berichterstattung an das Leitungsorgan unterstützen.

Schlecht umgesetzt, wird daraus eine Tabelle, die Auditoren in dreißig Minuten zerlegen.

Dieser Leitfaden zeigt, wie Clarysec auditbereite Nachweise für ISO 27001-Risikobeurteilung und Risikobehandlung mit der Zenith Blueprint: 30-Schritte-Roadmap eines Auditors, Clarysec-Richtlinien und Zenith Controls: Der Cross-Compliance-Leitfaden aufbaut.

Warum die ISO 27001-Risikobeurteilung jetzt zum Compliance-Drehkreuz wird

Die regulatorische Landschaft der EU konvergiert um ein einfaches Prinzip: Cybersicherheitsrisiken müssen gesteuert, dokumentiert, getestet und verantwortet werden.

ISO/IEC 27001:2022 funktioniert bereits nach dieser Logik. Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext, interessierte Parteien, den Anwendungsbereich des ISMS und Prozessinteraktionen versteht, bevor sie Risiken beurteilt. Die Abschnitte 6.1.2 und 6.1.3 verlangen einen definierten Prozess zur Informationssicherheitsrisikobeurteilung und -behandlung. Die Abschnitte 8.2 und 8.3 verlangen, dass die Organisation Risikobeurteilungen durchführt und den Risikobehandlungsplan umsetzt, während dokumentierte Informationen aufbewahrt werden.

NIS2 und DORA machen dieselbe risikobasierte Logik dringlicher.

NIS2 Article 20 verlangt von den Leitungsorganen wesentlicher und wichtiger Einrichtungen, Maßnahmen des Cybersicherheitsrisikomanagements zu genehmigen, deren Umsetzung zu überwachen und Cybersicherheitsschulungen zu absolvieren. Article 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen zur Steuerung von Risiken für Netz- und Informationssysteme. Diese Maßnahmen umfassen Risikoanalyse, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Geschäftskontinuität, Sicherheit der Lieferkette, sichere Entwicklung, Schwachstellenmanagement, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management sowie Multi-Faktor-Authentifizierung oder sichere Kommunikation, soweit angemessen.

DORA erzeugt ähnlichen Druck auf Finanzunternehmen. Articles 5 and 6 verlangen vom Leitungsorgan, Regelungen zum IKT-Risikomanagement zu definieren, zu genehmigen und zu überwachen sowie dafür verantwortlich zu bleiben. DORA erwartet ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken, das in das übergreifende Risikomanagement integriert ist und durch Richtlinien, Verfahren, Protokolle, Werkzeuge, interne Audits, Abhilfemaßnahmen, Geschäftskontinuität, Tests, Vorfallmanagement und Governance für IKT-Drittparteien unterstützt wird.

Die praktische und unvermeidbare Schlussfolgerung lautet: Das Risikoregister ist kein Arbeitsblatt des technischen Teams mehr. Es ist Governance-Nachweis.

Clarysecs Enterprise-Risikomanagement-Richtlinie macht diese Erwartung ausdrücklich:

Ein formaler Risikomanagementprozess muss gemäß ISO/IEC 27005 und ISO 31000 aufrechterhalten werden und Risikoidentifizierung, Risikoanalyse, Risikobewertung, Risikobehandlung, Risikoüberwachung und Risikokommunikation abdecken.

Aus der Enterprise-Risikomanagement-Richtlinie, Abschnitt „Governance-Anforderungen“, Richtlinienanforderung 5.1.

Dieselbe Richtlinie definiert das auditbereite Ergebnis:

Aufrechterhaltung eines zentralen, versionskontrollierten Risikoregisters und Risikobehandlungsplans, der den aktuellen Risikostatus, die Kontrollabdeckung und den Fortschritt der Risikominderung widerspiegelt.

Aus der Enterprise-Risikomanagement-Richtlinie, Abschnitt „Ziele“, Richtlinienanforderung 3.3.

Diese Formulierung „aktueller Risikostatus, Kontrollabdeckung und Fortschritt der Risikominderung“ ist der Unterschied zwischen einer statischen Compliance-Akte und einem belastbaren Risikoprogramm.

Mit Anwendungsbereich, Verpflichtungen und Risikokriterien beginnen

Viele schwache ISO 27001-Risikobeurteilungen beginnen mit einer Kontrollcheckliste. Das ist die falsche Reihenfolge.

ISO 27001 verlangt, dass die Organisation Kontext, Anforderungen interessierter Parteien, ISMS-Anwendungsbereich, Führungsverantwortung und Risikoplanung bestimmt, bevor sie Kontrollen auswählt. ISO/IEC 27005:2022 verstärkt dies, indem Organisationen empfohlen wird, die grundlegenden Anforderungen interessierter Parteien zu identifizieren, bevor Risiken beurteilt werden. Diese Anforderungen können aus ISO-Normen, branchenspezifischen Vorschriften, nationalen Gesetzen, Kundenverträgen, internen Richtlinien, früheren Risikobehandlungsmaßnahmen und Lieferantenverpflichtungen stammen.

Für ein SaaS- oder Fintech-Unternehmen mit EU-Bezug sollte der Risikoprozess mit einem Inventar der Compliance- und Verpflichtungsanforderungen beginnen.

Für KMU legt Clarysecs Richtlinie zur Einhaltung rechtlicher und regulatorischer Anforderungen – KMU den Ausgangspunkt fest:

Der Geschäftsführer muss ein einfaches, strukturiertes Compliance-Register führen, das Folgendes auflistet:

Aus der KMU-Richtlinie zur Einhaltung rechtlicher und regulatorischer Anforderungen, Abschnitt „Governance-Anforderungen“, Richtlinienanforderung 5.1.1.

Dieses einfache Register bildet die Brücke zwischen Compliance und Risikomanagement. Wenn es festhält, dass GDPR anwendbar ist, weil personenbezogene Daten aus der EU verarbeitet werden, NIS2 anwendbar sein kann, weil die Organisation digitale oder Managed Services erbringt, oder DORA über Kunden aus dem Finanzsektor relevant ist, müssen diese Verpflichtungen Risikokriterien und Prioritäten der Risikobehandlung beeinflussen.

Die Zenith Blueprint ist an diesem Punkt in der Risikomanagementphase, Schritt 10, „Festlegung von Risikokriterien und Auswirkungsmatrix“, eindeutig:

Berücksichtigen Sie außerdem rechtliche/regulatorische Anforderungen in Ihren Akzeptanzkriterien. Einige Risiken können aufgrund gesetzlicher Vorgaben unabhängig von ihrer Eintrittswahrscheinlichkeit inakzeptabel sein.

Aus Zenith Blueprint, Risikomanagementphase, Schritt 10.

Sie gibt auch eine praxistaugliche Regel für Workshops vor:

„Jedes Risiko, das zu einer Nichteinhaltung anwendbarer Gesetze (GDPR usw.) führen könnte, ist nicht akzeptabel und muss gemindert werden.“

Aus Zenith Blueprint, Risikomanagementphase, Schritt 10.

Für Sarahs Fintech ändert das das Bewertungsmodell. Eine Schwachstelle in einer Lieferanten-API kann eine geringe Eintrittswahrscheinlichkeit haben; wenn eine Ausnutzung jedoch einen schwerwiegenden DORA-IKT-bezogenen Vorfall, einen erheblichen NIS2-Vorfall, eine GDPR-Bewertung einer Datenschutzverletzung, einen Kunden-SLA-Verstoß oder eine Eskalation auf Ebene des Leitungsorgans auslösen könnte, ist die Auswirkung hoch oder kritisch. Compliance-Exposition wird Teil der Risikologik, nicht eine separate Tabelle.

Ein Risikoregister aufbauen, das Auditoren testen können

Auditoren fragen nicht nur nach den Top-Risiken. Sie prüfen, ob die Methode definiert, wiederholbar, nachvollziehbar und angewendet ist.

Sie werden fragen:

• Wie haben Sie diese Risiken identifiziert?
• Welche Assets, Services, Lieferanten, Datenarten und Prozesse waren im Anwendungsbereich?
• Welche Kriterien wurden für Eintrittswahrscheinlichkeit und Auswirkung verwendet?
• Wer ist für jedes Risiko verantwortlich?
• Welche bestehenden Kontrollen reduzieren das Risiko?
• Warum wurde die Risikobehandlungsentscheidung ausgewählt?
• Wo befindet sich der Nachweis, dass die Behandlung umgesetzt wurde?
• Wer hat das Restrisiko genehmigt?
• Wann wird das Risiko neu bewertet?

Clarysecs Risikomanagement-Richtlinie – KMU beschreibt den minimalen auditbereiten Risikoeintrag:

Jeder Risikoeintrag muss Folgendes enthalten: Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlichen und Risikobehandlungsplan.

Aus der KMU-Risikomanagement-Richtlinie, Abschnitt „Governance-Anforderungen“, Richtlinienanforderung 5.1.2.

Für Enterprise-Programme erweitert die Zenith Blueprint in der Risikomanagementphase, Schritt 11, „Aufbau und Dokumentation des Risikoregisters“, die Struktur. Sie empfiehlt Spalten wie Risiko-ID, Asset, Bedrohung, Schwachstelle, Risikobeschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Risikostufe, aktuelle Kontrollen, Risikoverantwortlicher, Risikobehandlungsentscheidung, Risikobehandlungsplan oder Kontrollen und Status.

Ein belastbarer Risikoeintrag sieht so aus:

Das unterscheidet sich wesentlich von „Drittparteienrisiko, Hoch, mindern“. Die auditbereite Version verknüpft Asset, Bedrohung, Schwachstelle, Folge, aktuelle Kontrollen, Verantwortlichen, Vorschrift, Nachweis und Governance.

Risikobehandlung in einen Nachweisplan überführen

Ein Risikobehandlungsplan muss vier operative Fragen beantworten:

1. Was werden wir tun?
2. Wer ist verantwortlich?
3. Bis wann wird es erledigt?
4. Wie weisen wir nach, dass das Risiko reduziert wurde?

ISO/IEC 27001:2022 Abschnitt 6.1.3 verlangt, dass die Organisation Behandlungsoptionen auswählt, notwendige Kontrollen bestimmt, diese mit Annex A vergleicht, um Auslassungen zu vermeiden, eine Anwendbarkeitserklärung erstellt, einen Behandlungsplan formuliert und die Genehmigung der Risikoverantwortlichen für den Plan und die Restrisiken einholt. Abschnitt 8.3 verlangt anschließend die Umsetzung des Behandlungsplans und die Aufbewahrung dokumentierter Informationen zu den Ergebnissen.

Die Enterprise-Risikomanagement-Richtlinie macht dies operativ greifbar:

Der Risikobeauftragte muss sicherstellen, dass Risikobehandlungen realistisch, terminiert und auf ISO/IEC 27001 Annex A-Kontrollen abgebildet sind.

Aus der Enterprise-Risikomanagement-Richtlinie, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienanforderung 6.4.2.

Die KMU-Richtlinie stellt außerdem klar, dass Akzeptanz keine Abkürzung ist:

Akzeptieren: Begründen Sie, warum keine weitere Maßnahme erforderlich ist, und dokumentieren Sie das Restrisiko.

Aus der KMU-Risikomanagement-Richtlinie, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienanforderung 6.1.1.

Akzeptanz muss anhand von Kriterien begründet, vom richtigen Verantwortlichen genehmigt und überwacht werden. Unter NIS2 und DORA kann ein nicht genehmigtes Restrisiko zu einem Governance-Versagen werden.

Ein vollständiger Behandlungsplan sollte diese Felder enthalten:

Für Sarahs R-042 wird der Behandlungsplan zu einer Cross-Compliance-Maßnahmenliste.

Dieser Plan ist stark, weil er eine direkte Linie von einem Risikoszenario zu ISO 27001-Kontrollen, NIS2-Verpflichtungen, DORA-Artikeln, Verantwortlichen und Nachweisen herstellt.

Die Anwendbarkeitserklärung stärker nutzen

Die Anwendbarkeitserklärung wird häufig als Zertifizierungsartefakt behandelt. Sie sollte mehr sein.

ISO/IEC 27001:2022 Abschnitt 6.1.3 verlangt, dass die SoA notwendige Kontrollen, Begründungen für deren Aufnahme, Umsetzungsstatus und Begründungen für Ausschlüsse enthält. Die Leitlinien in ISO/IEC 27005:2022 verstärken die Notwendigkeit, ausgewählte Kontrollen mit ISO/IEC 27001 Annex A zu vergleichen, um Auslassungen zu vermeiden.

In einem auditbereiten Programm wird die SoA zur Brücke zwischen Risikobehandlung und Cross-Compliance-Nachweisen. Wenn ein Behandlungsplan MFA, Protokollierung, Lieferantenüberwachung, Backup-Wiederherstellung, sichere Entwicklung, Vorfalleskalation oder Planung für den Cloud-Ausstieg verlangt, sollte die SoA zeigen, dass die relevanten Annex A-Kontrollen enthalten, begründet, umgesetzt oder geplant und mit Nachweisen belegt sind.

Das hilft auch, einen häufigen Auditfehler zu vermeiden: Das Risikoregister sagt das eine, der Behandlungsplan etwas anderes, und die SoA schweigt. Wenn diese Artefakte voneinander abweichen, verlieren Auditoren schnell Vertrauen.

ISO 27001-Risikobehandlung auf NIS2, DORA und GDPR abbilden

ISO 27001 ersetzt NIS2, DORA oder GDPR nicht. Sie liefert einen strukturierten Mechanismus, um Nachweise dafür zu erzeugen.

Entscheidend ist, die Zuordnung in den Risikoprozess einzubauen, statt sie später anzuflanschen.

Diese Zuordnung ist besonders wichtig, wenn Vorschriften überlappen. DORA ist für viele Finanzunternehmen das sektorspezifische IKT-Resilienzregime, während NIS2 für bestimmte Anbieter, Koordination oder Einrichtungen außerhalb des DORA-Anwendungsbereichs weiterhin direkt relevant bleiben kann. Ein Fintech benötigt DORA möglicherweise als primäres Rahmenwerk für IKT-Resilienz, während ein Managed Service Provider, der dieses Fintech unterstützt, direkt NIS2-Verpflichtungen unterliegen kann.

Das Risikoregister muss beide Seiten dieser Abhängigkeit zeigen können.

Zenith Controls als Cross-Compliance-Kompass nutzen

Clarysec nutzt Zenith Controls als Cross-Compliance-Leitfaden, um den häufigen Fehler zu verhindern, dass ISO-Kontrollen, regulatorische Artikel und Auditfragen in getrennten Welten leben. Es erstellt kein separates Kontrollrahmenwerk. Es bildet Kontrollbereiche aus ISO/IEC 27001:2022 und ISO/IEC 27002:2022 auf andere Standards, Auditerwartungen und Compliance-Perspektiven ab.

Für ISO 27001-Risikobeurteilung und -behandlung sind diese Referenzen besonders wichtig:

Die Cross-Compliance-Lehre ist einfach. Wenn rechtliche Verpflichtungen nicht in der Risikobeurteilungsmethode enthalten sind, ist Ihre Bewertung unvollständig. Wenn die Bewertung unvollständig ist, können Behandlungsprioritäten falsch sein. Wenn Prioritäten falsch sind, werden SoA und Berichterstattung an das Leitungsorgan unzuverlässig.

Die Zenith Blueprint macht denselben Punkt in der Risikomanagementphase, Schritt 14, „Risikobehandlungsrichtlinien und regulatorische Querverweise“. Sie empfiehlt Organisationen, eine Zuordnungstabelle mit wichtigen regulatorischen Sicherheitsanforderungen und den entsprechenden Kontrollen oder Richtlinien im ISMS zu erstellen. Für die ISO 27001-Zertifizierung ist das nicht verpflichtend, aber es ist sehr hilfreich, um nachzuweisen, dass Sicherheit im rechtlichen und vertraglichen Kontext gesteuert wird.

Was unterschiedliche Auditoren fragen werden

Ein Zertifizierungsauditor, ein NIS2-Prüfer, ein DORA-orientierter Kunde, ein GDPR-Prüfer, ein NIST-Assessor oder ein COBIT-Praktiker kann dieselben Nachweise prüfen, aber unterschiedliche Fragen stellen.

Deshalb ist Nachweisarchitektur wichtig. Derselbe Risikoeintrag sollte vom Geschäftsziel bis zu Asset, Bedrohung, Schwachstelle, Kontrolle, Verantwortlichem, regulatorischem Treiber, Behandlungsmaßnahme, Testergebnis und Managemententscheidung nachvollziehbar sein.

Clarysec-Richtlinien sind darauf ausgelegt, diese Architektur zu unterstützen. Die Enterprise-Risikomanagement-Richtlinie enthält im Abschnitt „Referenzstandards und Rahmenwerke“ die Aussage:

Article 5: Verlangt ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken, das durch die Struktur dieser Richtlinie vollständig abgedeckt ist, einschließlich SoA-Zuordnung und KRIs.

Dadurch wird die Richtlinie von einem statischen Dokument zu einem Auditnachweis, der zeigt, dass IKT-Risikogovernance gezielt mit Blick auf DORA gestaltet wurde.

Häufige Feststellungen, die Risikoprogramme scheitern lassen

Wenn Clarysec Nachweise zu ISO 27001-Risikobeurteilung und Risikobehandlung prüft, treten dieselben Feststellungen immer wieder auf.

Erstens ignorieren Risikokriterien rechtliche, regulatorische, vertragliche, lieferantenbezogene und datenschutzbezogene Auswirkungen. Das führt zu schwacher Bewertung. Eine Datenschutzverletzung oder ein Ausfall eines kritischen Lieferanten kann als Mittel bewertet werden, weil die Eintrittswahrscheinlichkeit gering ist, obwohl GDPR-, NIS2-, DORA- oder Kundenauswirkungen die Einstufung Hoch oder Kritisch rechtfertigen müssten.

Zweitens sind Risikoverantwortliche generisch. „IT“ ist kein Risikoverantwortlicher. Ein Risikoverantwortlicher sollte eine Rolle oder Person sein, die für Behandlungsentscheidungen, Budget, Zeitplanung und Restrisiko rechenschaftspflichtig ist.

Drittens sind Behandlungspläne nicht terminiert. „Überwachung verbessern“ ist kein Plan. „Warnmeldungen für privilegierte Sitzungen im SIEM für Produktionsadministratorkonten bis zum 30. Juni bereitstellen, verantwortet durch den SOC-Manager, getestet durch simulierte Admin-Anmeldung, mit beigefügtem Alarmnachweis“ ist ein Plan.

Viertens ist die SoA von der Risikobehandlung entkoppelt. Wenn der Behandlungsplan Lieferantenüberwachung, Backup-Tests, Vorfalleskalation, MFA oder Protokollierung verlangt, sollte die SoA die relevanten Kontrollen und deren Umsetzungsstatus abbilden.

Fünftens wird Restrisiko nicht genehmigt. ISO 27001 verlangt die Genehmigung des Behandlungsplans und der Restrisiken durch Risikoverantwortliche. NIS2 und DORA machen dies noch wichtiger, weil die Rechenschaftspflicht des Managements ausdrücklich geregelt ist.

Sechstens wird Lieferantenrisiko als Einkaufsadministration behandelt. Unter NIS2 Article 21(2)(d) und DORA Articles 28 and 30 müssen Lieferanten- und IKT-Drittparteienrisiken Teil des Risikomanagements sein, nicht ein isoliert abgelegter jährlicher Fragebogen.

Siebtens fehlen Nachweise der Wirksamkeit. ISO 27001 Abschnitt 6.1.1 verlangt, dass geplante Maßnahmen auf ihre Wirksamkeit bewertet werden. NIS2 enthält die Wirksamkeitsbewertung in Article 21(2)(f). DORA erwartet Tests und Abhilfemaßnahmen. Eine Kontrolle, die existiert, aber nie getestet wird, ist ein schwacher Nachweis.

Die KMU-Risikomanagement-Richtlinie – KMU formuliert die Erwartung klar:

Der Geschäftsführer und der Risikokoordinator müssen sicherstellen, dass Risikomanagementtätigkeiten auditbereit sind. Das Risikoregister und die zugehörigen Maßnahmen unterliegen internen und externen Audits.

Aus der KMU-Risikomanagement-Richtlinie, Abschnitt „Durchsetzung und Einhaltung“, Richtlinienanforderung 8.2.1.

Berichterstattung an das Leitungsorgan ohne Informationsüberflutung

NIS2, DORA und ISO 27001 zielen alle auf Rechenschaftspflicht des Managements, aber Leitungsorgane benötigen nicht jede einzelne Risikozeile. Sie benötigen entscheidungsrelevante Berichterstattung.

Ein gutes Risikopaket für das Leitungsorgan sollte Folgendes zeigen:

• Hohe und kritische Risiken nach Domäne
• Überfällige Risikobehandlungsmaßnahmen
• Regulatorische Risiken mit Bezug zu NIS2, DORA, GDPR oder Verträgen
• Lieferantenrisiken, die kritische oder wichtige Services betreffen
• Trends zu Vorfällen und Beinahe-Vorfällen
• Restrisiken, die auf Akzeptanz warten
• Ergebnisse von Tests der Kontrollwirksamkeit
• Wesentliche Änderungen an Anwendungsbereich, Lieferanten, Technologie oder Recht
• Interne Auditfeststellungen und Korrekturmaßnahmen

Clarysec empfiehlt in der Regel monatliche operative Risikoüberprüfungen und vierteljährliche Managementbewertungen. Monatliche Überprüfungen konzentrieren sich auf die Umsetzung der Behandlung. Vierteljährliche Überprüfungen konzentrieren sich auf Akzeptanz, Finanzierung, Priorisierung, regulatorische Exposition und strategische Risikoentscheidungen.

Dieser Rhythmus unterstützt auch kontinuierliche Verbesserung. Risikobeurteilungen sollten aktualisiert werden, wenn Vorfälle auftreten, Schwachstellen bekannt werden, neue Assets eingeführt werden, sich Technologie ändert, Lieferanten wechseln, Gesetze sich ändern, Kundenverpflichtungen sich ändern oder die Risikobereitschaft angepasst wird.

Der Clarysec-Implementierungspfad

Ein einheitliches Risikoprogramm vermeidet getrennte Tabellen für ISO, NIS2, DORA, GDPR und Kunden-Assurance. Der praktische Weg lautet:

1. ISMS-Anwendungsbereich, Services, Assets, Lieferanten, Rechtsräume und Kundenverpflichtungen bestätigen.
2. Das Compliance-Register mit der Richtlinie zur Einhaltung rechtlicher und regulatorischer Anforderungen – KMU aufbauen oder aktualisieren, soweit angemessen.
3. Risikomethodik, Akzeptanzkriterien, Skalen für Eintrittswahrscheinlichkeit, Skalen für Auswirkungen und Regeln für regulatorische Auswirkungen definieren.
4. Das Risikoregister anhand der Risikomanagementphase der Zenith Blueprint und des Clarysec-Ansatzes für Risikoregister und SoA Builder aufbauen.
5. Asset-basierte und szenariobasierte Risiken identifizieren, einschließlich Lieferanten-, Cloud-, Datenschutz-, Kontinuitäts-, Vorfalls-, Schwachstellen-, Secure-Development- und Zugriffsszenarien.
6. Risiken anhand von Kriterien bewerten, die rechtliche, regulatorische, vertragliche, operative, datenschutzbezogene, lieferantenbezogene und finanzielle Auswirkungen einbeziehen.
7. Behandlungsoptionen auswählen: mindern, vermeiden, übertragen oder akzeptieren.
8. Notwendige Kontrollen auf ISO/IEC 27001:2022 Annex A und ISO/IEC 27002:2022-Leitlinien abbilden.
9. Die Anwendbarkeitserklärung erstellen oder aktualisieren.
10. Behandlungen auf NIS2 Article 21, DORA-IKT-Risikomanagement und Erwartungen an Drittparteien, GDPR-Rechenschaftspflicht und vertragliche Kundenverpflichtungen abbilden.
11. Nachweise sammeln, Kontrollwirksamkeit validieren und Restrisiko-Genehmigung einholen.
12. Ein Auditpaket vorbereiten, das nach Risiko, Kontrolle, Vorschrift und Nachweisartefakt organisiert ist.
13. Ergebnisse in Managementbewertung, internes Audit, Korrekturmaßnahmen und kontinuierliche Verbesserung überführen.

Das ist keine Dokumentation um ihrer selbst willen. Es ist das Betriebssystem für belastbare Cyber-Governance.

Ein auditbereites Paket zur Risikobehandlung aufbauen

Sarahs Geschichte endet gut, weil sie aufgehört hat, ISO 27001, NIS2 und DORA als getrennte Compliance-Projekte zu behandeln. Sie nutzte die ISO 27001-Risikobeurteilung als zentralen Motor, integrierte regulatorische Verpflichtungen in Risikokriterien, bildete Behandlungsmaßnahmen auf Annex A und EU-Anforderungen ab und sammelte Nachweise, die Kunden, Auditoren und das Leitungsorgan verstehen konnten.

Ihre Organisation kann dasselbe tun.

Nutzen Sie Zenith Blueprint: 30-Schritte-Roadmap eines Auditors, um Risikokriterien zu definieren, das Risikoregister aufzubauen, den Risikobehandlungsplan zu erstellen und regulatorische Anforderungen querzuverweisen.

Nutzen Sie Zenith Controls: Der Cross-Compliance-Leitfaden, um Kontrollbereiche aus ISO/IEC 27001:2022 Annex A mit Governance, rechtlicher Compliance, Assurance und Auditperspektiven zu verbinden.

Nutzen Sie Clarysecs Risikomanagement-Richtlinie, Risikomanagement-Richtlinie – KMU und Richtlinie zur Einhaltung rechtlicher und regulatorischer Anforderungen – KMU, um Verantwortlichkeiten, Register, Risikobehandlungsentscheidungen und auditbereite Nachweise zu standardisieren.

Der schnellste praktische nächste Schritt ist, Ihre zehn wichtigsten Risiken zu nehmen und sie anhand von fünf Fragen zu testen:

1. Ist die regulatorische Auswirkung sichtbar?
2. Ist der Risikobehandlungsplan terminiert und einer verantwortlichen Rolle zugeordnet?
3. Ist jede Behandlung auf Annex A und die SoA abgebildet?
4. Ist die Relevanz für NIS2, DORA, GDPR oder Kunden dokumentiert, soweit anwendbar?
5. Gibt es Nachweise, dass die Kontrolle funktioniert?

Wenn die Antwort nein lautet, kann Clarysec helfen, Ihr Risikoregister in ein belastbares Cross-Compliance-Risikobehandlungsprogramm zu überführen, dem Auditoren, Aufsichtsbehörden, Kunden und Leitungsorgane vertrauen können.