Leitfaden 2026 für ein Register der Compliance-Verpflichtungen in der Cybersicherheit

Maria, CISO einer schnell wachsenden Fintech-Plattform, hatte noch zwanzig Minuten, bevor das Unterlagenpaket für die vierteljährliche Sitzung des Leitungsorgans finalisiert wurde. Die Nachricht des CEO war kurz und unangenehm:
„Maria, ich brauche eine einzige Folie, die zeigt, dass wir unsere gesetzlichen Cybersicherheitsverpflichtungen für 2026 im Griff haben. Nicht nur ISO 27001. Ich meine alles. NIS2, DORA, GDPR, unsere Kundenverträge. Sind wir konform? Wo ist der Nachweis? Wer ist verantwortlich?“
Um 08:15 gingen drei weitere Anfragen ein. Die Rechtsabteilung wollte wissen, ob das Unternehmen nach den NIS2-Umsetzungsregelungen eines Mitgliedstaats als wichtige Einrichtung einzustufen ist. Der Datenschutzbeauftragte wollte wissen, ob ein verdächtiger Datenbankexport als Verletzung des Schutzes personenbezogener Daten gemäß GDPR, als schwerwiegender IKT-bezogener Vorfall gemäß DORA, als beides oder als keines von beidem zu behandeln ist. Die Beschaffung wollte die Freigabe für einen Anbieter von Betrugsanalysen, der personenbezogene Daten aus der EU verarbeiten, einen kritischen Service unterstützen und einen Cloud-Unterauftragsverarbeiter außerhalb der EU einsetzen würde.
Keine dieser Fragen ist 2026 ungewöhnlich. Gefährlich wird es, wenn die Organisation sie nicht aus einer gepflegten zentralen Informationsquelle beantworten kann.
Die meisten Unternehmen haben Richtlinien. Viele verfügen über Risikoregister, Lieferantenakten, Datenschutzaufzeichnungen, Playbooks für Sicherheitsvorfälle und eine Erklärung zur Anwendbarkeit. Die Lücke wird jedoch sichtbar, wenn ein Mitglied des Leitungsorgans, ein Auditor, eine Aufsichtsbehörde oder ein wichtiger Kunde eine einfache Frage stellt:
„Zeigen Sie mir jede anwendbare gesetzliche, regulatorische und vertragliche Cybersicherheitsverpflichtung, wer dafür verantwortlich ist, wie oft sie überprüft wird, welche Kontrolle sie umsetzt, welcher Nachweis sie belegt und wie Ausnahmen an das Management eskaliert werden.“
Das ist das Register der Compliance-Verpflichtungen in der Cybersicherheit.
Für CISOs, Compliance-Manager, Auditoren und Fachverantwortliche ist dieses Register längst keine administrative Tabelle mehr. Es ist der operative Mechanismus, der nationale Verpflichtungen aus NIS2, Aufsichtserwartungen aus DORA, Rechenschaftspflicht gemäß GDPR, Anforderungen aus ISO/IEC 27001:2022, Kundenverträge und interne Richtlinien zu einem funktionierenden Governance-System verbindet.
Clarysec behandelt das Register als lebendes ISMS-Artefakt, nicht als juristischen Anhang. In der Richtlinie zur rechtlichen und regulatorischen Compliance gilt für die Compliance-Funktion:
„Pflegt das Register der Compliance-Verpflichtungen, in dem alle anwendbaren Gesetze, Standards, Zertifizierungen und vertraglichen Klauseln aufgeführt sind.“
Aus Richtlinie zur rechtlichen und regulatorischen Compliance, Rollen und Verantwortlichkeiten, Klausel 4.2.1.
Das entscheidende Wort ist „pflegt“. Ein Register, das für eine Zertifizierung erstellt und bis zum nächsten Audit ignoriert wird, ist kein Compliance-Mechanismus. Es ist ein Nachweis historischen Optimismus.
Was ein Register der Compliance-Verpflichtungen in der Cybersicherheit 2026 leisten muss
Ein nutzbares Register der Verpflichtungen erfüllt fünf Aufgaben.
Erstens identifiziert es Verpflichtungen. Dazu gehören Gesetze, Vorschriften, Normen, Zertifizierungen und vertragliche Klauseln. Zu den typischen Quellen im Jahr 2026 zählen NIS2 für wesentliche und wichtige Einrichtungen, DORA für erfasste Finanzunternehmen und IKT-Drittdienstleister, GDPR für Verantwortliche und Auftragsverarbeiter, die personenbezogene Daten aus der EU verarbeiten, Anforderungen aus ISO/IEC 27001:2022 an das ISMS, Zusagen zur Cloud-Sicherheit, Klauseln zur Meldung von Sicherheitsvorfällen in Kundenverträgen, Auslagerungsanforderungen und Anforderungen an die Lieferantensicherheit.
Zweitens klassifiziert es die Anwendbarkeit. NIS2 kann anwendbar sein, weil die Organisation in einen Sektor nach Anhang I oder Anhang II fällt, digitale Infrastruktur bereitstellt, als Managed-Service-Provider agiert, Cloud-Computing-Dienste anbietet oder in eine größenunabhängige Kategorie wie DNS, TLD oder Vertrauensdienste fällt. DORA kann anwendbar sein, weil die Organisation ein Finanzunternehmen oder ein IKT-Drittdienstleister ist, der Finanzunternehmen unterstützt. GDPR kann anwendbar sein, weil die Organisation personenbezogene Daten aus der EU verarbeitet, Dienstleistungen für Personen in der EU anbietet oder Verhalten in der EU beobachtet.
Drittens ordnet es Verpflichtungen internen Kontrollen, Richtlinien, Prozessen und Systemen zu. Hier wird das Register operativ. Die Risikomanagementmaßnahmen aus NIS2 Article 21 werden Risikobeurteilung, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Geschäftskontinuität, Sicherheit der Lieferkette, sicherer Entwicklung, Überprüfung der Kontrollwirksamkeit, Schulungen, Kryptografie, Zugriffskontrolle, Asset-Management und gegebenenfalls MFA zugeordnet. DORA wird Rechenschaftspflichten des Leitungsorgans, IKT-Risikomanagement, Vorfallklassifizierung, Resilienztests, Drittparteienregistern und Exit-Strategien zugeordnet. GDPR wird dem Verzeichnis von Verarbeitungstätigkeiten, der Rechtsgrundlage, Datenminimierung, Aufbewahrung, Sicherheit der Verarbeitung, Bewertung von Datenschutzverletzungen und Nachweisen der Rechenschaftspflicht zugeordnet.
Viertens weist es Verantwortliche und Überprüfungsintervalle zu. Ohne Verantwortlichkeit wird Compliance zum Besprechungspunkt. Mit Verantwortlichkeit wird sie zu einem gesteuerten Prozess.
Fünftens definiert es Nachweise. Das Register sollte beantworten, welches Artefakt belegt, dass diese Verpflichtung heute erfüllt ist. Nachweise können Protokolle des Leitungsorgans, Aufzeichnungen zu Risikobeurteilungen, Vorfalltickets, Lieferanten-Due-Diligence, Vertragsklauseln, Verschlüsselungskonfigurationen, Schwachstellenberichte, Berechtigungsüberprüfungen, Aufzeichnungen zu Backup-Tests, Datenschutzhinweise, Datenschutz-Folgenabschätzungen, Bewertungen von Datenschutzverletzungen und interne Auditfeststellungen umfassen.
Die Richtlinie von Clarysec macht diese Nachvollziehbarkeit ausdrücklich:
„Alle gesetzlichen und regulatorischen Verpflichtungen müssen bestimmten Richtlinien, Kontrollen und Verantwortlichen innerhalb des Informationssicherheits-Managementsystems (ISMS) zugeordnet werden.“
Aus Richtlinie zur rechtlichen und regulatorischen Compliance, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.1.
Sie definiert auch Nachweise als Teil desselben Mechanismus:
„Erforderliche Artefakte oder Aufzeichnungen zum Nachweis der Einhaltung (z. B. Audit-Protokolle, Verschlüsselungseinstellungen, Einwilligungsdokumentation)“
Aus Richtlinie zur rechtlichen und regulatorischen Compliance, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.2.3.
Das ist der Unterschied zwischen Compliance-Bewusstsein und belastbarer Sicherstellung der Kontrollwirksamkeit.
Warum ISO/IEC 27001:2022 das Rückgrat bildet
ISO/IEC 27001:2022 wird häufig als Zertifizierungsziel betrachtet, doch für das Management von Verpflichtungen ist ihr Nutzen größer. Sie gibt dem Register einen Platz im Managementsystem.
Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen versteht, interessierte Parteien identifiziert und gesetzliche, regulatorische sowie vertragliche Anforderungen bestimmt, die für das ISMS relevant sind. Die Klauseln 5.1 bis 5.3 verlangen Führungsverpflichtung, Ausrichtung der Richtlinien, Ressourcen und zugewiesene Verantwortlichkeiten. Die Klauseln 6.1 bis 6.2 verlangen Risikobeurteilung, Risikobehandlung, die Erklärung zur Anwendbarkeit und messbare Ziele, die durch anwendbare Anforderungen geprägt sind. Die Klauseln 8, 9 und 10 schaffen den Betriebszyklus: Kontrollen umsetzen, Risiken neu bewerten, Leistung überwachen, interne Audits durchführen, auf Managementebene bewerten und Nichtkonformitäten korrigieren.
In Zenith Blueprint: 30-Schritte-Roadmap für Auditoren verortet Clarysec dies früh in der Phase ISMS-Grundlagen und Führung, Schritt 2: Anforderungen interessierter Parteien und ISMS-Geltungsbereich. Der Blueprint empfiehlt Teams, Anforderungen interessierter Parteien zu identifizieren, indem gesetzliche und regulatorische Anforderungen überprüft, vertragliche Sicherheitsklauseln extrahiert, Stakeholder befragt und von Partnern erwartete Branchenstandards berücksichtigt werden.
„Klausel 4.2 verlangt kein bestimmtes Dokument, in der Praxis ist es jedoch sinnvoll, eine Stakeholder-Analyse-Tabelle zu erstellen. Dies kann eine einfache Tabelle mit den Spalten sein: Interessierte Partei, Anforderungen/Erwartungen, Wie wir sie adressieren.“
Aus Zenith Blueprint, Phase ISMS-Grundlagen und Führung, Schritt 2.
Diese Stakeholder-Analyse wird zum vorgelagerten Input für das Register der Verpflichtungen. Das Register wird anschließend zur Brücke in die Risikobehandlung.
In der Phase Risikomanagement, Schritt 13, weist Zenith Blueprint Teams an, Kontrollen Risiken, Klauseln und externen Vorschriften zuzuordnen:
„Vorschriften querverweisen: Wenn bestimmte Kontrollen speziell umgesetzt werden, um GDPR, NIS2 oder DORA einzuhalten, können Sie dies entweder im Risikoregister (als Teil der Begründung der Risikoauswirkung) oder in den SoA-Anmerkungen festhalten.“
Aus Zenith Blueprint, Phase Risikomanagement, Schritt 13: Planung der Risikobehandlung und Erklärung zur Anwendbarkeit.
Das ist die Nachvollziehbarkeit, die Auditoren erwarten. Wenn GDPR Verschlüsselung, Aufbewahrung und Kontrollen zur Bewertung von Datenschutzverletzungen auslöst, benennen Sie dies. Wenn NIS2 Eskalationen zur Vorfallmeldung und Maßnahmen zur Lieferantensicherheit auslöst, benennen Sie dies. Wenn DORA Register für IKT-Drittparteienrisiken und Exit-Tests auslöst, benennen Sie dies.
Die drei Kontrollanker aus ISO/IEC 27002:2022
Die zentrale Maßnahme aus ISO/IEC 27002:2022 für das Management von Verpflichtungen ist 5.31, gesetzliche, behördliche, regulatorische und vertragliche Anforderungen. Clarysecs Zenith Controls: Der Cross-Compliance-Leitfaden klassifiziert 5.31 als vorbeugende Kontrolle mit Bezug zu Vertraulichkeit, Integrität und Verfügbarkeit, ausgerichtet am Cybersicherheitskonzept „Identify“ und verankert in der Fähigkeit Recht und Compliance über Governance-, Ökosystem- und Schutzbereiche hinweg.
Die Darstellung in Zenith Controls ist eindeutig:
„Sicherheit existiert nicht im luftleeren Raum. Sie wirkt innerhalb eines Geflechts von Verpflichtungen, von denen einige gesetzlich, andere vertraglich und wieder andere durch branchenspezifische Regulierung definiert sind.“
Aus Zenith Controls, Behandlung der ISO/IEC 27002:2022 Maßnahme 5.31.
Maßnahme 5.31 wirkt nicht allein. Zwei unterstützende Maßnahmen sind wesentlich.
Maßnahme 5.2, Rollen und Verantwortlichkeiten für Informationssicherheit, stellt sicher, dass Verpflichtungen nicht abstrakt „dem Fachbereich“ oder „der IT“ zugewiesen werden. Die Zuordnung in Zenith Controls verknüpft 5.2 mit Richtlinienverantwortung, Compliance-Überwachung, Vorfallmanagement, Sensibilisierung, unabhängiger Überprüfung, Umgang mit Nachweisen und Governance für privilegierte Zugriffe.
Maßnahme 5.36, Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit, schließt den Regelkreis. Sie stellt sicher, dass dokumentierte Anforderungen befolgt, überwacht, berichtet und korrigiert werden. Die Zuordnung in Zenith Controls verknüpft 5.36 mit Informationssicherheitsleitlinien, Disziplinarverfahren, unabhängiger Überprüfung, Rollen und Verantwortlichkeiten, Ereignisbewertung, Protokollierung, Überwachung und geschützten Aufzeichnungen.
Gemeinsam beantworten diese Maßnahmen die Kernfragen des Auditors.
| Frage des Auditors | ISO/IEC 27002:2022-Anker | Wie gute Nachweise aussehen |
|---|---|---|
| Welche Verpflichtungen gelten? | 5.31, gesetzliche, behördliche, regulatorische und vertragliche Anforderungen | Register der Verpflichtungen, Notizen aus rechtlichen Überprüfungen, Extraktion von Vertragsklauseln, Bewertung der regulatorischen Anwendbarkeit |
| Wer ist für jede Verpflichtung und Kontrolle verantwortlich? | 5.2, Rollen und Verantwortlichkeiten für Informationssicherheit | RACI-Matrix, Stellenbeschreibungen, Bestellungsaufzeichnungen, Governance-Charta, Liste der Kontrollverantwortlichen |
| Woran erkennen Sie, dass Kontrollen befolgt werden? | 5.36, Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit | Compliance-Dashboards, interne Auditberichte, Ausnahmeprotokolle, Aufzeichnungen zu Korrekturmaßnahmen, Protokolle der Managementbewertung |
Für kleinere Organisationen kann dieselbe Struktur schlanker sein. Clarysecs Richtlinie zur rechtlichen und regulatorischen Compliance – KMU stellt fest:
„Die Geschäftsführung muss ein einfaches, strukturiertes Compliance-Register pflegen, das Folgendes aufführt:“
Aus Richtlinie zur rechtlichen und regulatorischen Compliance – KMU, Governance-Anforderungen, Klausel 5.1.1.
Sie verlangt außerdem eine routinemäßige Überprüfung:
„Das Compliance-Register muss vierteljährlich überprüft und aktualisiert werden, wenn:“
Aus Richtlinie zur rechtlichen und regulatorischen Compliance – KMU, Governance-Anforderungen, Klausel 5.1.2.
Für KMU kann das Register einfach beginnen. Es benötigt dennoch Verantwortlichkeit, Taktung und Nachweise.
Das Register an Verpflichtungen ausrichten, nicht an Frameworks
Der häufigste Fehler besteht darin, einen Tracker für NIS2, einen weiteren für DORA, einen weiteren für GDPR, einen weiteren für ISO/IEC 27001:2022 und einen weiteren für Kundenverträge zu erstellen. Das erzeugt doppelte Nachweisanfragen, widersprüchliche Verantwortliche und überlastete Teams.
Der bessere Ansatz ist die Zuordnung von Verpflichtungen zu Kontrollen. Eine Sicherheitsfähigkeit kann mehrere rechtliche Treiber erfüllen, wenn das Register die Unterschiede bei Auslöser, Geltungsbereich, Frist und zuständiger Stelle bewahrt.
Beispielsweise unterstützt die Reaktion auf Sicherheitsvorfälle die Meldung erheblicher Vorfälle gemäß NIS2, die Meldung schwerwiegender IKT-bezogener Vorfälle gemäß DORA und die Bewertung von Verletzungen des Schutzes personenbezogener Daten gemäß GDPR. Lieferanten-Due-Diligence unterstützt die Sicherheit der Lieferkette gemäß NIS2, das IKT-Drittparteienrisiko gemäß DORA und die Auftragsverarbeiter-Governance gemäß GDPR. Protokollierung und Überwachung unterstützen Vorfallerkennung, Kontrollwirksamkeit und Rechenschaftspflicht. Asset- und Dateninventare unterstützen die Risikobeurteilung gemäß NIS2, DORA, GDPR und ISO/IEC 27001:2022.
| Verpflichtungsthema | NIS2-Treiber | DORA-Treiber | GDPR-Treiber | ISO/IEC 27001:2022- und ISO/IEC 27002:2022-Anker | Beispiele für Nachweise |
|---|---|---|---|---|---|
| Management rechtlicher Verpflichtungen | Einrichtungsklassifizierung, nationale Umsetzung, Aufsichtsbefugnisse | Branchenspezifisches Regime für digitale operationale Resilienz | Rechenschaftspflicht und anwendbares Datenschutzrecht | Klausel 4.2, Klausel 6.1, Maßnahme 5.31 | Register der Verpflichtungen, Anwendbarkeitsvermerk, Protokoll gesetzlicher Änderungen |
| Kontrollverantwortung | Genehmigung durch das Leitungsorgan, Aufsicht und Schulung | Rechenschaftspflicht des Leitungsorgans, IKT-Rollen und Verantwortlichkeiten | Rechenschaftspflicht des Verantwortlichen, Aufgaben des Datenschutzbeauftragten, soweit anwendbar | Klausel 5.3, Maßnahme 5.2 | RACI, Rollenbeschreibungen, Bestätigungen der Kontrollverantwortlichen |
| Vorfallmeldung | Article 23 gestufte Meldung erheblicher Vorfälle | Article 19 Meldung schwerwiegender IKT-bezogener Vorfälle | Article 33 Meldung einer Verletzung des Schutzes personenbezogener Daten, soweit anwendbar | Maßnahmen 5.24 bis 5.28, ISO/IEC 27035-1:2023 | Vorfalltickets, Klassifizierungsmatrix, Meldeaufzeichnungen |
| Lieferanten- und Cloud-Risiko | Article 21 Sicherheit der Lieferkette | Article 28 IKT-Drittparteienrisikomanagement | Article 28 Schutzmaßnahmen für Auftragsverarbeiter, Kapitel V Übermittlungskontrollen | Maßnahmen 5.19 bis 5.23, ISO/IEC 27017:2021, ISO/IEC 27018:2020, ISO/IEC 27036-2:2014 | Lieferantenbewertungen, Verträge, Exit-Tests, Überprüfungen von Unterauftragsverarbeitern |
| Überwachung der Einhaltung | Kontrollwirksamkeit, Cyberhygiene und Erwartungen an Zugriffskontrolle | Überprüfung des IKT-Risikomanagementrahmens, internes Audit, Resilienztests | Nachweis der Einhaltung und Überprüfung von Maßnahmen | Klausel 9.1, Klausel 9.2, Maßnahme 5.36 | Auditberichte, Dashboards, Ausnahmen, Korrekturmaßnahmen |
Das Ziel ist nicht, rechtliche Unterschiede zu verdecken. Das Ziel ist, dieselbe Fähigkeit nicht dreimal umzusetzen.
Ein praktisches Registermodell, das Sie diese Woche umsetzen können
Ein Register der Verpflichtungen im Clarysec-Stil sollte einfach genug sein, um gepflegt zu werden, und detailliert genug, um Audit-Stichproben standzuhalten. Die Mindestfelder sind:
- Verpflichtungskennung.
- Quelle, etwa NIS2, DORA, GDPR, ISO/IEC 27001:2022, Kundenvertrag oder interne Richtlinie.
- Konkrete Article-, Klausel- oder Vertragsreferenz.
- Zusammenfassung der Anforderung.
- Begründung der Anwendbarkeit.
- Betroffener Geschäftsprozess oder Service.
- Risikoszenario bei Nichterfüllung.
- Kontrollzuordnung, einschließlich ISO/IEC 27002:2022-Maßnahmen und interner Richtlinienreferenzen.
- Kontrollverantwortlicher.
- Nachweisverantwortlicher.
- Überprüfungsintervall.
- Ablageort der Nachweise.
- Ausnahmen oder offene Lücken.
- Kennzeichen für die Eskalation in die Managementbewertung.
- Datum der letzten und der nächsten Überprüfung.
- Status.
Hier ist ein praktisches Beispiel für einen SaaS-Fintech-Anbieter, der in der EU tätig ist.
| Verpflichtungskennung | Quelle und Anforderung | Interne Zuordnung | Verantwortlicher | Überprüfungsintervall | Nachweis | |—|—|—|—|—| | OBL-001 | NIS2-Anwendbarkeit und Einrichtungsklassifizierung für digitale Infrastruktur oder Managed-Service-Aktivitäten | Richtlinie zur rechtlichen und regulatorischen Compliance, Maßnahme 5.31, ISMS-Geltungsbereich | Compliance-Manager | Vierteljährlich und bei Serviceänderungen | Anwendbarkeitsvermerk, Daten zur Registrierung der Einrichtung, Briefing für das Leitungsorgan | | OBL-002 | DORA IKT-Drittparteienrisikomanagement für kritische oder wichtige IKT-Services | Verfahren zur Lieferantensicherheit, Maßnahmen 5.19 bis 5.23, DORA-Lieferantenregister | Verantwortlicher für Lieferantenrisiken | Vierteljährlich und vor einem neuen kritischen Lieferanten | Lieferantenregister, Due-Diligence, Vertragsklauseln, Exit-Test | | OBL-003 | GDPR Bewertung von Verletzungen des Schutzes personenbezogener Daten und Rechenschaftspflicht | Incident Response Plan, Datenschutzverfahren, Maßnahmen 5.24 bis 5.28 und 5.34 | Datenschutzbeauftragter und Incident Manager | Pro Vorfall, vierteljährliche Trendüberprüfung | Bewertung der Datenschutzverletzung, Vorfallticket, Meldeentscheidung, Lessons Learned | | OBL-004 | ISO/IEC 27001:2022 Überwachung, internes Audit und Managementbewertung | Audit- und Compliance-Überwachungsprozess, Maßnahme 5.36 | ISMS-Manager | Jährlicher Auditplan, vierteljährliche Überwachung | Interner Auditbericht, KPI-Dashboard, Protokoll zu Korrekturmaßnahmen | | OBL-005 | Kundenvertrag verlangt Meldung eines Sicherheitsvorfalls innerhalb von 24 Stunden | Vertragsregister, Playbook für Vorfallkommunikation | Customer Success und Recht | Bei Vertragsänderung und pro Vorfall | Auszug der Vertragsklausel, Aufzeichnung zur Vorfallkommunikation |
Beachten Sie, dass jede Zeile umsetzbar ist. Sie sagt nicht lediglich „DORA einhalten“. Sie identifiziert die Anforderung, die interne Zuordnung, den Verantwortlichen, den Überprüfungsrhythmus und den Nachweis.
Clarysecs Richtlinie zu Governance-Rollen und Verantwortlichkeiten – KMU stärkt diese Verantwortlichkeitsdisziplin:
„Governance-Verantwortlichkeiten (z. B. Richtlinienüberprüfung, Genehmigung von Ausnahmen, Anbieteraufsicht) müssen bestimmten Personen oder Rollen zugewiesen werden.“
Aus Richtlinie zu Governance-Rollen und Verantwortlichkeiten – KMU, Governance-Anforderungen, Klausel 5.3.
Für Unternehmensumgebungen sollte dasselbe Konzept in einer RACI-Matrix, einem Register der Kontrollverantwortung und einem Management-Reporting-Paket abgebildet sein.
Beispiel Vorfallmeldung: ein Playbook, mehrere Verpflichtungen
Ein SaaS-Anbieter stellt fest, dass er in den NIS2-Geltungsbereich fallen könnte, weil er Cloud- oder Managed-Service-Aktivitäten in der EU erbringt und einschlägige Größen- oder Sektorkriterien erfüllt. Die Organisation verfügt bereits über einen Incident Response Plan, hat die NIS2-Meldeanforderungen jedoch noch nicht in die Eskalationsverfahren eingebunden.
Der Registereintrag sollte die Verpflichtung präzise erfassen:
- Quelle: NIS2 Article 23.
- Anforderung: Meldung erheblicher Vorfälle an den CSIRT oder die zuständige Behörde ohne unangemessene Verzögerung, mit Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats.
- Anwendbarkeit: potenziell anwendbar aufgrund der Servicekategorie und der Tätigkeiten in Mitgliedstaaten.
- Risiko bei Nichterfüllung: regulatorischer Verstoß, verzögerte Benachrichtigung von Stakeholdern, Verlust des Kundenvertrauens.
Anschließend wird die Verpflichtung Kontrollen zugeordnet. ISO/IEC 27002:2022 Maßnahmen 5.24 bis 5.28 decken Planung des Vorfallmanagements, Bewertung, Reaktion, Lernen und Beweissicherung ab. Maßnahme 5.31 deckt die Nachverfolgung gesetzlicher Verpflichtungen ab. Maßnahme 5.2 deckt die Rollenzuweisung ab. Maßnahme 5.36 deckt die Überwachung ab, ob der Prozess befolgt wird.
Die Verantwortlichkeit sollte eindeutig sein. Der Incident Manager verantwortet Klassifizierung und Eskalation. Recht oder Compliance verantwortet die regulatorische Auslegung und Freigabe von Meldungen. Kommunikation verantwortet die Kundenkommunikation. Der Nachweisverantwortliche pflegt die Vorfallsakte.
Nachweise sollten den Vorfallklassifizierungsdatensatz, die Zeitachse, den Zeitpunkt der Kenntnisnahme, die Triage-Zeit, die Eskalationszeit, die Meldeentscheidung, die Einreichung bei der Aufsichtsbehörde, soweit anwendbar, die Entscheidung zur Kundenkommunikation, Lessons Learned und Korrekturmaßnahmen umfassen.
Eine Tabletop-Übung macht das Register anschließend real. Verwenden Sie ein Szenario, in dem eine fehlerhafte Cloud-Konfiguration zu potenzieller Exponierung von Kundendaten und Serviceunterbrechung führt. Testen Sie, ob das Team die 24-Stunden-Frist aus NIS2 erkennt, bestimmt, ob eine Bewertung der Datenschutzverletzung gemäß GDPR erforderlich ist, potenzielle DORA-Auswirkungen klassifiziert, wenn Finanzdienstleistungen betroffen sind, und eine vollständige Nachweisakte erstellt.
So wird das Register der Verpflichtungen zu einer Kontrolle. Es verändert operatives Verhalten.
Nachweismanagement ist der Bereich, in dem Audits häufig scheitern
Viele Organisationen können ein Register vorlegen. Weniger können zeigen, dass Nachweise vollständig, aktuell, geschützt und verknüpft sind.
Clarysecs Richtlinie zur Audit- und Compliance-Überwachung – KMU formuliert die Grundanforderung:
„Alle Nachweise müssen in einem zentralen Auditordner gespeichert werden.“
Aus Richtlinie zur Audit- und Compliance-Überwachung – KMU, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.1.
Dieser Satz löst ein häufiges Auditproblem. Nachweise, die über E-Mail, Jira-Tickets, SharePoint-Ordner, Anbieterportale und persönliche Laufwerke verteilt sind, sind nicht auditbereit. Der zentrale Ordner muss nicht zwingend ein einzelner physischer Ordner für jede Datei sein, aber es muss ein kontrolliertes Nachweisrepository oder ein Index existieren, der einem Auditor zeigt, wo das maßgebliche Artefakt liegt.
Für jede Verpflichtung sollten Nachweise konsistent benannt, der Verpflichtungskennung und der Kontrollkennung zugeordnet, einer benannten Person oder Rolle zugewiesen, gegen unbefugte Änderung geschützt, gemäß gesetzlichen und vertraglichen Anforderungen aufbewahrt, in definierten Intervallen überprüft und mit Ausnahmen sowie Korrekturmaßnahmen verknüpft werden.
Die Behandlung von Maßnahme 5.31 in Zenith Controls verknüpft gesetzliche Anforderungen über Maßnahme 5.33 mit der Aufbewahrung von Aufzeichnungen, über Maßnahme 5.34 mit Datenschutz und Schutz von PII, über Maßnahme 5.35 mit unabhängiger Überprüfung und über Maßnahme 5.36 mit interner Einhaltung. Das ist wichtig, weil Nachweise selbst regulierte Informationen enthalten können, etwa personenbezogene Daten, forensische Indikatoren, Protokolle privilegierter Zugriffe oder vertrauliche Kundendaten.
Die Auditperspektive: Wie unterschiedliche Prüfer das Register testen
Ein starkes Register hält mehreren Auditperspektiven stand.
Ein Auditor nach ISO/IEC 27001:2022 beginnt mit Kontext, interessierten Parteien, Geltungsbereich, Risikobehandlung, Erklärung zur Anwendbarkeit, Überwachung, internem Audit und Managementbewertung. Für Maßnahme 5.31 erwartet der Auditor, dass anwendbare gesetzliche und vertragliche Anforderungen identifiziert, aktuell gehalten und in Kontrollen abgebildet sind. Für Maßnahme 5.2 prüft er, ob Verantwortlichkeiten zugewiesen und verstanden sind. Für Maßnahme 5.36 sucht er nach Überwachung, Nichtkonformitäten und Korrekturmaßnahmen.
Ein an NIST ausgerichteter Assessor konzentriert sich auf Governance-Ergebnisse. Das NIST Cybersecurity Framework 2.0 GOVERN enthält GV.OC-03, das erwartet, dass gesetzliche, regulatorische und vertragliche Anforderungen an Cybersicherheit, einschließlich Datenschutz- und Bürgerrechtsverpflichtungen, verstanden und gesteuert werden. Der Assessor kann ein Organisationsprofil, eine Lückenanalyse und einen priorisierten Maßnahmenplan verlangen und anschließend stichprobenartig prüfen, ob Verpflichtungen in Asset-Management, Zugriffskontrolle, Datenschutz, Protokollierung, Reaktion und Wiederherstellung übersetzt werden.
Ein COBIT 2019- oder ISACA-Auditor betrachtet Governance- und Managementziele. MEA03, Managed Compliance With External Requirements, ist besonders relevant. Der Auditor kann prüfen, ob externe Anforderungen über MEA03.01 identifiziert werden, ob Reaktionen über MEA03.02 optimiert werden, ob Einhaltung über MEA03.03 bestätigt wird und ob Assurance über MEA03.04 erlangt wird.
Ein ISACA ITAF-basierter Auditor legt den Schwerpunkt auf ausreichende und angemessene Nachweise. Er kann eine GDPR-Anforderung zur Meldung einer Datenschutzverletzung, eine DORA-Anforderung an ein Lieferantenregister und eine NIS2-Anforderung zur Vorfallmeldung auswählen und dann den durchgängigen Prüfpfad der Nachweise anfordern.
Ein technischer Assessor kann Maßnahme 5.36 anhand von Konfigurationsnachweisen validieren. Wenn das Register besagt, dass NIS2 und Kundenverträge MFA für privilegierten Zugriff verlangen, kann er die Einstellungen des Identitätsanbieters prüfen. Wenn es besagt, dass GDPR und Verträge Verschlüsselung verlangen, kann er Datenbankverschlüsselung, Aufzeichnungen zum Schlüsselmanagement und Datenflussdiagramme prüfen. Wenn DORA Überwachung von IKT-Drittparteiservices verlangt, kann er Serviceüberprüfungen, SLA-Berichte und Aufzeichnungen zu Exit-Tests prüfen.
| Framework oder Prüfer | Was geprüft wird | Hilfreiche Register-Nachweise |
|---|---|---|
| ISO/IEC 27001:2022 | Klauseln 4.2, 6.1, 6.1.3, 9.1, 9.2 und 9.3 | Analyse interessierter Parteien, SoA-Verknüpfungen, Auditplan, Protokolle der Managementbewertung |
| NIST CSF 2.0 | GOVERN-Ergebnisse, insbesondere GV.OC-03 | Inventar rechtlicher Anforderungen, aktuelles Profil und Zielprofil, Maßnahmenplan |
| COBIT 2019 | MEA03 Einhaltung externer Anforderungen | Berichte zur Einhaltung, Aufzeichnungen zur Verantwortlichkeit, Genehmigungen von Ausnahmen |
| NIS2-, DORA- und GDPR-Aufsichtsbehörden | Konkrete gesetzliche Ergebnisse | Zuordnungen auf Article-Ebene, Vorfallaufzeichnungen, Lieferantenakten, Meldeentscheidungen |
| Technischer Assessor | Ob die angegebenen Kontrollen funktionieren | Konfigurationsexporte, Protokolle, Berechtigungsüberprüfungen, Testaufzeichnungen |
Das Register benötigt Governance-Nachweise und technische Nachweise.
Die Managementbewertung schließt den Kreis der Rechenschaftspflicht
Ein Register der Compliance-Verpflichtungen sollte nicht im Stillen von Compliance verwaltet werden. Es muss in die Managementbewertung einfließen, weil NIS2, DORA, GDPR und ISO/IEC 27001:2022 sämtlich auf Rechenschaftspflicht beruhen.
NIS2 verlangt, dass Leitungsorgane Cybersicherheits-Risikomanagementmaßnahmen genehmigen und deren Umsetzung überwachen. DORA legt die letztendliche Rechenschaftspflicht für das IKT-Risikomanagement beim Leitungsorgan fest. GDPR verlangt von Verantwortlichen, die Einhaltung nachzuweisen. ISO/IEC 27001:2022 verlangt, dass die Managementbewertung Änderungen im Kontext, Anforderungen interessierter Parteien, Auditergebnisse, Überwachungsergebnisse, Ergebnisse der Risikobeurteilung, den Status der Behandlung und Verbesserungsmöglichkeiten berücksichtigt.
Clarysecs Informationssicherheitsleitlinie entspricht dieser Erwartung:
„Managementbewertungstätigkeiten (gemäß ISO/IEC 27001 Klausel 9.3) müssen mindestens jährlich durchgeführt werden und Folgendes umfassen:“
Aus Informationssicherheitsleitlinie, Governance-Anforderungen, Klausel 5.3.
Die KMU-Auditrichtlinie ergänzt die operative Verknüpfung:
„Audit-Feststellungen und Statusaktualisierungen müssen in den ISMS-Managementbewertungsprozess aufgenommen werden.“
Aus Richtlinie zur Audit- und Compliance-Überwachung – KMU, Governance-Anforderungen, Klausel 5.4.3.
Die Managementbewertung benötigt nicht jede einzelne Zeile. Sie benötigt Trends, Risikoentscheidungen, Ausnahmen, Ressourcen und Rechenschaftspflicht.
| Thema der Managementbewertung | Beispielkennzahl oder Entscheidung |
|---|---|
| Änderungen der Anwendbarkeit | Neue NIS2-Registrierungsanforderung in einem Mitgliedstaat identifiziert und Verantwortlicher zugewiesen |
| Offene Compliance-Lücken | DORA-Lieferanten-Exit-Test für zwei kritische IKT-Services überfällig |
| Zustand der Nachweise | 92 Prozent der Verpflichtungen verfügen über aktuelle Nachweise, 8 Prozent sind abgelaufen |
| Ausnahmen | Vorübergehende Abweichung von der Protokollaufbewahrung bis zur Speichererweiterung genehmigt |
| Vorfälle und Meldungen | Zwei Sicherheitsvorfälle bewertet, keine Meldung an Aufsichtsbehörde erforderlich, Begründung dokumentiert |
| Audit-Feststellungen | Drei geringfügige Nichtkonformitäten, Verantwortliche und Fristen für Korrekturmaßnahmen bestätigt |
| Regulatorischer Horizont | Bevorstehende Vertrags- und nationale Umsetzungsänderungen in rechtlicher Prüfung |
Damit wird aus dem Register eine Entscheidungsgrundlage für die Leitungsebene statt einer Compliance-Akte.
Häufige Fehlermuster und wie Sie sie vermeiden
Das erste Fehlermuster: Die Rechtsabteilung besitzt das Gesetz, die Sicherheit besitzt die Kontrollen, und niemand besitzt die Zuordnung. Clarysec verhindert dies, indem Verpflichtungen im ISMS Richtlinien, Kontrollen und Verantwortlichen zugeordnet werden müssen.
Das zweite Fehlermuster ist die Verfolgung von Frameworks statt Verpflichtungen. Ein Registereintrag mit der Aussage „DORA“ ist nicht umsetzbar. Ein Registereintrag mit der Aussage „DORA Article 28 IKT-Drittparteienrisikomanagement verlangt Due-Diligence, vertragliche Bestimmungen, Überwachung und Exit-Strategien“ ist umsetzbar.
Das dritte Fehlermuster ist fehlende Taktung. Eine vierteljährliche Überprüfung ist für viele Organisationen eine praktikable Basis, ergänzt durch anlassbezogene Aktualisierungen bei neuen Services, neuen Ländern, neuen Lieferanten, Vorfällen, Audits und Vertragsänderungen.
Das vierte Fehlermuster sind Nachweise, die existieren, aber nicht auffindbar sind. Das Prinzip des zentralen Auditordners adressiert dies unmittelbar.
Das fünfte Fehlermuster sind informelle Ausnahmen. Wenn eine Kontrolle eine Verpflichtung vorübergehend nicht erfüllen kann, muss die Ausnahme dokumentiert, risikobewertet, genehmigt, zeitlich begrenzt und überprüft werden.
Das sechste Fehlermuster ist eine zeremonielle Managementbewertung. Das Register sollte Entscheidungen über Budget, Personal, Lieferantenabhilfe, Vertragsverhandlungen, Risikoakzeptanz und Korrekturmaßnahmen auslösen.
Wie Clarysec das Register zu einem operativen Mechanismus macht
Der 30-Schritte-Ansatz von Clarysec macht das Management von Verpflichtungen praktikabel.
In Zenith Blueprint identifiziert Schritt 2 Anforderungen interessierter Parteien und anwendbare Anforderungen. Schritt 13 ordnet Kontrollen Risiken, Klauseln und der Erklärung zur Anwendbarkeit zu. Schritt 23 behandelt organisatorische Maßnahmen, einschließlich der Anforderung, ein Register gesetzlicher und regulatorischer Anforderungen aufzubauen und zu pflegen.
Der Blueprint formuliert:
„Arbeiten Sie mit Recht, Compliance oder externen Rechtsberatern zusammen, um ein Register anwendbarer Gesetze, Vorschriften und vertraglicher Verpflichtungen im Zusammenhang mit Informationssicherheit (5.31) aufzubauen. Dies sollte Datenschutzgesetze (z. B. GDPR), branchenspezifische Anforderungen und Zertifizierungspflichten umfassen. Stellen Sie sicher, dass das ISMS-Team weiß, wo dieses Register zu finden ist, und dass Änderungen mindestens vierteljährlich überprüft werden.“
Aus Zenith Blueprint, Phase Kontrollen in der Praxis, Schritt 23.
Clarysec-Richtlinien stellen die Governance-Regeln bereit: Register pflegen, Verantwortlichkeiten zuweisen, Nachweise zentralisieren, Feststellungen überprüfen und Status in die Managementbewertung aufnehmen.
Zenith Controls liefert den Cross-Compliance-Kompass. Für Maßnahme 5.31 ordnet es das Management von Verpflichtungen der Rechenschaftspflicht gemäß GDPR, Cybersicherheitspflichten gemäß NIS2, dem IKT-Risikomanagement gemäß DORA, der NIST CSF Governance, dem NIST SP 800-53 Programmmanagement und kontinuierlicher Überwachung sowie der Überwachung externer Einhaltung nach COBIT 2019 zu. Für Maßnahme 5.2 verbindet es Rollenverantwortung mit GDPR, NIS2, DORA, NIST und COBIT. Für Maßnahme 5.36 verbindet es die Überwachung der Richtlinieneinhaltung mit der Rechenschaftspflicht gemäß GDPR, Cyberhygiene und Zugriffskontrollerwartungen gemäß NIS2, operationaler Resilienz gemäß DORA, kontinuierlicher Überwachung nach NIST und Konformitätsüberwachung nach COBIT.
Der Nutzen ist einfach: ein Register, eine Kontrollarchitektur, viele Compliance-Ergebnisse.
Nächste Schritte: Machen Sie Ihr Register der Verpflichtungen auditbereit
Die Organisationen, die Compliance 2026 gut beherrschen, werden nicht die mit den meisten Tabellen sein. Es werden diejenigen sein, die Nachvollziehbarkeit haben: Verpflichtung zu Verantwortlichem, Verantwortlicher zu Kontrolle, Kontrolle zu Nachweis, Nachweis zu Überprüfung, Überprüfung zu Verbesserung.
Beginnen Sie mit diesen Maßnahmen:
- Erstellen oder aktualisieren Sie Ihr Register der Compliance-Verpflichtungen in der Cybersicherheit.
- Nehmen Sie NIS2, DORA, GDPR, ISO/IEC 27001:2022 und wesentliche vertragliche Kundenverpflichtungen auf.
- Ordnen Sie jede Verpflichtung Richtlinien, ISO/IEC 27002:2022-Maßnahmen, Verantwortlichen, Überprüfungsintervallen und Nachweisen zu.
- Identifizieren Sie Lücken, Ausnahmen und abgelaufene Nachweise.
- Nehmen Sie den Registerstatus in die nächste ISMS-Managementbewertung auf.
- Nutzen Sie Clarysecs Zenith Blueprint, um das Register in die 30-Schritte-ISMS-Roadmap einzuordnen.
- Nutzen Sie Zenith Controls, um Verpflichtungen mit Erwartungen aus ISO, NIST, COBIT, GDPR, NIS2 und DORA quer zuzuordnen.
- Nutzen Sie Clarysecs Richtlinie zur rechtlichen und regulatorischen Compliance, Richtlinie zur rechtlichen und regulatorischen Compliance – KMU, Richtlinie zu Governance-Rollen und Verantwortlichkeiten – KMU, Richtlinie zur Audit- und Compliance-Überwachung – KMU und Informationssicherheitsleitlinie, um Verantwortlichkeit, Überprüfung, Nachweisspeicherung und Rechenschaftspflicht des Managements zu formalisieren.
Clarysec kann Ihnen helfen, diese Nachvollziehbarkeit in Ihr ISMS einzubauen, bevor Auditor, Aufsichtsbehörde, Mitglied des Leitungsorgans oder Kunde danach fragt. Laden Sie die relevanten Clarysec-Richtlinienvorlagen herunter, ordnen Sie diese Woche Ihre ersten zehn Verpflichtungen zu und machen Sie aus Compliance kein Krisenprojekt, sondern ein Betriebssystem.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


