ISO 27001-Auditnachweise für NIS2 und DORA

Es ist 08:17 Uhr an einem Dienstag, und der CISO eines schnell wachsenden Fintech-SaaS-Unternehmens hat drei Nachrichten vorliegen.
Die erste stammt von einem großen Bankkunden: „Bitte senden Sie uns Ihren aktuellen Bericht zum internen Audit, die Sitzungsprotokolle der Managementbewertung, den Status der Korrekturmaßnahmen, das Verfahren zur Vorfallmeldung, das Lieferantenregister und Nachweise zur Aufsicht durch das Leitungsorgan.“
Die zweite kommt vom CFO: „Fallen wir in den Geltungsbereich von NIS2 oder DORA, und welche Nachweise haben wir bereits?“
Die dritte stammt vom CEO: „Können wir sagen, dass wir auditbereit sind?“
Die unbequeme Antwort in vielen Organisationen lautet nicht, dass nichts passiert. Es ist schlimmer. Sicherheitsarbeit findet überall statt, aber belastbare Nachweise sind nirgends verfügbar. Es gibt Kontrollen, aber keinen Prüfpfad. Es gibt Tickets, aber keine klare Verknüpfung mit Risiken. Es gibt Updates an die Leitung, aber keine formalen Ergebnisse der Managementbewertung. Es gibt Gespräche mit Lieferanten, aber kein belastbares Lieferantenregister, keine Vertragsprüfung und keine Exit-Strategie.
Genau an dieser Lücke werden internes Audit und Managementbewertung nach ISO/IEC 27001:2022 zu mehr als Zertifizierungsaktivitäten. Sie werden zum operativen Taktgeber für NIS2, DORA, GDPR, Kundenvertrauen, Cyberversicherung und die Rechenschaftspflicht des Leitungsorgans.
SaaS-, Cloud-, MSP-, MSSP- und Fintech-Teams scheitern selten daran, dass Sicherheitsaktivitäten fehlen. Sie scheitern daran, dass Aktivitäten über Slack, Jira, Tabellen, Lieferantenportale, SOC-Tickets, Beschaffungsunterlagen und Unterlagen für das Leitungsorgan verstreut sind. Eine Aufsichtsbehörde, ein externer Auditor oder ein Unternehmenskunde erwartet keine heldenhafte Erklärung. Er erwartet objektive Nachweise.
Die praktische Lösung besteht nicht darin, für jedes Rahmenwerk ein separates Auditprogramm zu betreiben. Sie besteht darin, das ISMS nach ISO 27001 als zentrale Nachweisplattform zu nutzen und diese Nachweise anschließend für NIS2, DORA, GDPR und vertragliche Anforderungen zu kennzeichnen. Gut umgesetzt kann ein Zyklus aus internem Audit und Managementbewertung viele Compliance-Fragen beantworten.
Von Rahmenwerksmüdigkeit zu einem einheitlichen ISMS-Nachweismodell
Viele CISOs kennen eine Variante von Marias Problem. Maria leitet die Informationssicherheit in einem B2B-SaaS-Unternehmen mit Kunden aus dem Finanzsektor. Ihr Team hat vor sechs Monaten ein Zertifizierungsaudit nach ISO/IEC 27001:2022 bestanden. Das ISMS wird reifer, Richtlinien werden befolgt, und Kontrollverantwortliche verstehen ihre Zuständigkeiten. Dann leitet der CEO zwei Artikel weiter, einen zur NIS2-Richtlinie und einen zu DORA, mit der kurzen Frage: „Sind wir abgedeckt?“
Die Antwort hängt von Geltungsbereich, Services, Kunden und juristischen Personen ab. Die operative Antwort ist jedoch klar: Wenn Maria NIS2 und DORA als separate Compliance-Projekte behandelt, entstehen Doppelarbeit, inkonsistente Nachweise und zunehmende Auditmüdigkeit. Wenn sie diese Anforderungen als Anforderungen interessierter Parteien innerhalb des ISMS behandelt, kann sie ISO 27001 nutzen, um die Anforderungen aufzunehmen, zu prüfen und die Vorbereitung nachzuweisen.
ISO/IEC 27001:2022 ist genau dafür ausgelegt. Abschnitt 4 verlangt, dass die Organisation ihren Kontext und die Anforderungen interessierter Parteien versteht, einschließlich gesetzlicher, regulatorischer, vertraglicher und abhängigkeitsbezogener Verpflichtungen. Abschnitt 5 verlangt Führung und Integration in Geschäftsprozesse. Abschnitt 6 verlangt Risikobeurteilung und Risikobehandlung. Abschnitt 9 verlangt Leistungsbewertung durch Überwachung, internes Audit und Managementbewertung. Abschnitt 10 verlangt Verbesserung und Korrekturmaßnahmen.
NIS2 und DORA fügen sich nahtlos in diese Struktur ein.
NIS2 verlangt von wesentlichen und wichtigen Einrichtungen die Umsetzung geeigneter und verhältnismäßiger technischer, operativer und organisatorischer Maßnahmen zum Cybersicherheitsrisikomanagement. Die Richtlinie weist Leitungsorganen außerdem die Verantwortung zu, diese Maßnahmen zu genehmigen, ihre Umsetzung zu überwachen und bei Verstößen haftbar gemacht werden zu können. Die Mindestmaßnahmen umfassen Risikoanalyse, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Geschäftskontinuität, Sicherheit der Lieferkette, sichere Entwicklung, Schwachstellenmanagement, Wirksamkeitsbewertung, Schulung, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management und, soweit angemessen, Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung.
DORA gilt ab dem 17. Januar 2025 und schafft ein sektorspezifisches Regime für digitale operationale Resilienz für Finanzunternehmen. DORA verlangt die Verantwortung des Leitungsorgans für das Management von IKT-Risiken, ein dokumentiertes Rahmenwerk für das IKT-Risikomanagement, eine Strategie für digitale operationale Resilienz, IKT-Kontinuitäts- und Wiederherstellungspläne, Resilienztests, Governance für IKT-Vorfälle und das Management von IKT-Drittparteienrisiken. Für SaaS- und Cloud-Anbieter, die Finanzunternehmen bedienen, kann DORA über vertragliche Verpflichtungen, Kundenaudits und Erwartungen an das Management von IKT-Drittparteienrisiken relevant werden, auch wenn der Anbieter selbst kein Finanzunternehmen ist.
GDPR ergänzt die Rechenschaftsebene. Werden personenbezogene Daten im Geltungsbereich von GDPR verarbeitet, müssen Organisationen die Einhaltung der Datenschutzgrundsätze sowie geeigneter technischer und organisatorischer Maßnahmen nachweisen können.
ISO 27001 ist kein magisches Compliance-Zertifikat für diese Verpflichtungen. Es ist das Managementsystem, das diese Verpflichtungen strukturieren, nachweisen und verbessern kann.
Die Geltungsbereichsfrage: Was weisen Sie nach, und für wen?
Bevor ein auditbereites Nachweispaket aufgebaut wird, muss die Leitung eine grundlegende Frage beantworten: Welche Verpflichtungen liegen im Geltungsbereich?
Für SaaS- und Cloud-Unternehmen kann der NIS2-Geltungsbereich breiter sein als erwartet. NIS2 gilt für öffentliche oder private Einrichtungen in aufgeführten Sektoren, die Größenschwellen erfüllen, sowie für bestimmte Einrichtungen mit hoher Auswirkung unabhängig von ihrer Größe. Relevante Sektoren können digitale Infrastruktur, Cloud-Computing-Provider, Rechenzentrumsanbieter, Content Delivery Networks, Vertrauensdiensteanbieter, Anbieter öffentlicher elektronischer Kommunikationsdienste sowie B2B-Anbieter für das IKT-Servicemanagement umfassen, etwa Managed Service Provider und Managed Security Service Provider. SaaS-Anbieter sollten besonders darauf achten, wie Services erbracht werden, welche Sektoren sie unterstützen und ob sie bedarfsgesteuerte Administration sowie breiten Fernzugriff auf skalierbare, gemeinsam genutzte Rechenressourcen ermöglichen.
Für Fintech- und Finanzsektor-Dienstleister muss DORA separat analysiert werden. DORA erfasst unmittelbar eine breite Palette von Finanzunternehmen, darunter Kreditinstitute, Zahlungsinstitute, Kontoinformationsdienstleister, E-Geld-Institute, Wertpapierfirmen, Anbieter von Kryptowerte-Dienstleistungen, Handelsplätze, Fondsmanager, Versicherungs- und Rückversicherungsunternehmen sowie Crowdfunding-Dienstleister. IKT-Drittdienstleister sind ebenfalls Teil des DORA-Ökosystems, weil Finanzunternehmen ihre IKT-Abhängigkeiten steuern, Register vertraglicher Vereinbarungen führen und spezifische Vertragsbestimmungen für IKT-Dienste aufnehmen müssen, die kritische oder wichtige Funktionen unterstützen.
NIS2 und DORA greifen zudem ineinander. Wenn ein sektorspezifischer EU-Rechtsakt gleichwertige Anforderungen an das Cybersicherheitsrisikomanagement oder die Meldung von Vorfällen auferlegt, können die entsprechenden NIS2-Bestimmungen für diese Einrichtungen in diesen Bereichen nicht gelten. DORA ist das sektorspezifische Regime für operationale Resilienz von Finanzunternehmen. Das macht NIS2 für alle umliegenden Anbieter nicht irrelevant. Es bedeutet, dass das Nachweismodell unterscheiden muss, ob die Organisation ein Finanzunternehmen ist, das DORA unmittelbar unterliegt, ein IKT-Drittdienstleister, der Finanzunternehmen unterstützt, ein SaaS-Anbieter im NIS2-Geltungsbereich oder eine Gruppe mit mehreren juristischen Personen und Servicelinien.
Diese Geltungsbereichsanalyse gehört in den ISMS-Kontext und in das Register interessierter Parteien. Ohne sie prüft der Auditplan die falschen Themen.
Ein Prüfpfad, viele Compliance-Fragen
Ein häufiger Fehler besteht darin, separate Nachweispakete für ISO 27001, NIS2, DORA, GDPR, Cyberversicherung und Kundenaudits zu erstellen. Dieser Ansatz erzeugt Doppelarbeit und widersprüchliche Antworten. Besser ist ein Nachweismodell mit mehreren Perspektiven.
Im Zentrum steht das ISMS. Darum herum liegen fünf Nachweisfamilien.
| Nachweisfamilie | Was sie nachweist | Typische Aufzeichnungen |
|---|---|---|
| Governance-Nachweise | Die Leitung hat das ISMS genehmigt, mit Ressourcen ausgestattet und überprüft | Informationssicherheitsleitlinie, Rollen, Auditplan, Sitzungsprotokolle der Managementbewertung, Berichterstattung an das Leitungsorgan |
| Risikonachweise | Risiken wurden identifiziert, bewertet, verantwortet und behandelt | Risikokriterien, Risikoregister, Risikobehandlungsplan, Anwendbarkeitserklärung (SoA), Genehmigungen von Restrisiken |
| Kontrollnachweise | Kontrollen funktionieren wie vorgesehen | Berechtigungsüberprüfung, Wiederherstellungstests, Monitoring-Warnmeldungen, Schwachstellenberichte, Lieferanten-Due-Diligence, Aufzeichnungen zur sicheren Entwicklung |
| Prüfungs- und Bestätigungsnachweise | Unabhängige oder interne Prüfungen haben Lücken festgestellt und Konformität verifiziert | Interner Auditplan, Audit-Checkliste, Auditbericht, Nichtkonformitätsprotokoll, CAPA-Protokoll |
| Verbesserungsnachweise | Feststellungen führten zu Korrektur, Ursachenanalyse und kontinuierlicher Verbesserung | Korrekturmaßnahmenpläne, Lessons Learned, Managemententscheidungen, aktualisierte Richtlinien, Aufzeichnungen zu Wiederholungsprüfungen |
Diese Struktur ist auf Zenith Blueprint: Roadmap in 30 Schritten für Auditoren Zenith Blueprint ausgerichtet. In der Phase Audit, Überprüfung und Verbesserung konzentriert sich Schritt 25 auf das Programm für interne Audits, Schritt 26 auf die Auditdurchführung, Schritt 28 auf die Managementbewertung und Schritt 29 auf die kontinuierliche Verbesserung.
Die Anleitung in Schritt 25 des Blueprints ist bewusst praxisnah:
„Entwickeln Sie einen Zeitplan, der darlegt, wann Audits stattfinden und was sie abdecken.“
„Verwenden Sie die Vorlage für den internen Auditplan, sofern bereitgestellt; dies kann ein einfaches Dokument oder eine Tabelle sein, in der Auditdaten, Geltungsbereich und zugewiesene Auditoren aufgeführt sind.“
Aus Zenith Blueprint, Phase Audit, Überprüfung und Verbesserung, Schritt 25: Programm für interne Audits Zenith Blueprint
Dieser einfache Auditplan wird wirkungsvoll, wenn er risikobasiert ist und NIS2-, DORA- und GDPR-Verpflichtungen zugeordnet wird.
ISO 27001-Kontrollen, die Auditbereitschaft verankern
Für die Auditbereitschaft sind drei Kontrollen aus ISO/IEC 27002:2022 besonders wichtig, wenn sie über Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls interpretiert werden:
- 5.4 Verantwortlichkeiten des Managements
- 5.35 Unabhängige Überprüfung der Informationssicherheit
- 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit
Dies sind keine separaten „Zenith-Kontrollen“. Es handelt sich um Kontrollen nach ISO/IEC 27002:2022, die Zenith Controls dabei unterstützt, rahmenwerksübergreifend zuzuordnen, zu auditieren und zu interpretieren.
Kontrolle 5.4 fragt, ob Verantwortlichkeiten für Informationssicherheit zugewiesen und verstanden sind. Kontrolle 5.35 fragt, ob Informationssicherheit unabhängig überprüft wird. Kontrolle 5.36 fragt, ob die Organisation ihre Richtlinien, Regeln und Standards einhält.
Zenith Controls klassifiziert Kontrolle 5.35 assurance-orientiert:
ISO/IEC 27002:2022-Kontrolle 5.35, „Unabhängige Überprüfung der Informationssicherheit“, wird in Zenith Controls als „präventiv, korrektiv“ behandelt. Sie unterstützt Vertraulichkeit, Integrität und Verfügbarkeit über die Cybersicherheitskonzepte „Identifizieren“ und „Schützen“ mit operativer Fähigkeit in „Sicherstellung der Informationssicherheit“. Zenith Controls
Das ist wichtig, weil das interne Audit sowohl präventiv als auch korrektiv wirkt. Es verhindert blinde Flecken, indem es das ISMS vor externer Prüfung testet, und es korrigiert Schwächen durch dokumentierte Maßnahmen.
Die breitere Zuordnung beginnt bei den Anforderungen aus NIS2 und DORA und identifiziert anschließend die ISO 27001-Nachweise, mit denen sie belegt werden können.
| Regulatorisches Thema | Nachweise nach ISO/IEC 27001:2022 und ISO/IEC 27002:2022 | Praktischer Auditschwerpunkt |
|---|---|---|
| Rechenschaftspflicht des Managements | Abschnitte 5, 9.3 und Kontrollen 5.2, 5.4, 5.35, 5.36 | Genehmigungen durch die Leitung, Sitzungsprotokolle der Managementbewertung, Rollenzuweisungen, CAPA-Entscheidungen |
| Risikoanalyse und Sicherheitsrichtlinien | Abschnitte 4, 6.1, 6.2 und Kontrollen 5.1, 5.7, 5.9, 5.31 | Risikokriterien, Risikoregister, Richtlinienfreigaben, gesetzliche und vertragliche Anforderungen |
| Umgang mit Informationssicherheitsvorfällen | Kontrollen 5.24, 5.25, 5.26, 5.27, 5.28 | Klassifizierung, Eskalation, Reaktionsaufzeichnungen, Lessons Learned, Sicherung von Beweismitteln |
| Geschäftskontinuität und Wiederherstellung | Kontrollen 5.29, 5.30, 8.13 | Kontinuitätspläne, IKT-Bereitschaft, Backup-Wiederherstellungstests, Wiederherstellungskennzahlen |
| Lieferanten- und Cloud-Risiken | Kontrollen 5.19, 5.20, 5.21, 5.22, 5.23 | Lieferanten-Due-Diligence, Verträge, Überwachung, Cloud-Exit-Pläne, Konzentrationsrisiko |
| Sichere Entwicklung und Schwachstellen | Kontrollen 8.8, 8.25, 8.26, 8.27, 8.28, 8.29 | Schwachstellen-SLAs, Aufzeichnungen zum sicheren SDLC, Änderungsgenehmigungen, Sicherheitsprüfungen |
| Zugriff, Personal und Schulung | Kontrollen 5.15, 5.16, 5.17, 5.18, 6.1, 6.2, 6.3, 6.5, 6.6, 6.7 | Berechtigungsüberprüfung, Stichproben zu Eintritts-, Wechsel- und Austrittsprozessen, Sensibilisierungsnachweise, Kontrollen für Remote-Arbeit |
| Protokollierung, Überwachung und Kryptografie | Kontrollen 8.15, 8.16, 8.17, 8.24 | Protokollaufbewahrung, Prüfung von Warnmeldungen, Zeitsynchronisierung, Verschlüsselungsstandards |
| Datenschutz und rechtliche Compliance | Kontrollen 5.31, 5.34, 5.36 | Compliance-Register, Datenschutzkontrollen, Nachweise zu Auftragsverarbeitern, Compliance-Überprüfungen |
Kontrollzuordnung ist nur dann nützlich, wenn die Nachweise belastbar sind. Ist der Datensatz schwach, hilft keine Crosswalk-Zuordnung. Ist der Datensatz vollständig, kann derselbe Nachweis Fragen nach ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 und COBIT 2019 beantworten.
Richtliniennachweise, deren Aufbewahrung Clarysec erwartet
Die Richtlinien von Clarysec übersetzen ISMS-Theorie in konkrete Nachweiserwartungen.
Für KMU verlangt Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme Genehmigung durch die Leitung und eine systematische Auditsteuerung:
„Der General Manager (GM) muss einen jährlichen Auditplan genehmigen.“
Aus Audit and Compliance Monitoring Policy-sme, Governance-Anforderungen, Abschnitt 5.1.1 Audit and Compliance Monitoring Policy-sme
Sie legt außerdem eine Mindestfrequenz fest:
„Interne Audits oder Compliance-Überprüfungen müssen mindestens jährlich durchgeführt werden.“
Aus Audit and Compliance Monitoring Policy-sme, Governance-Anforderungen, Abschnitt 5.2.1
Und sie verknüpft Feststellungen mit Korrektur und Managementbewertung:
„Der GM muss einen Korrekturmaßnahmenplan genehmigen und dessen Umsetzung nachverfolgen.“
Aus Audit and Compliance Monitoring Policy-sme, Governance-Anforderungen, Abschnitt 5.4.2
„Auditfeststellungen und Statusaktualisierungen müssen in den ISMS-Managementbewertungsprozess aufgenommen werden.“
Aus Audit and Compliance Monitoring Policy-sme, Governance-Anforderungen, Abschnitt 5.4.3
Auch die Nachweisaufbewahrung ist ausdrücklich geregelt:
„Nachweise müssen mindestens zwei Jahre aufbewahrt werden oder länger, wenn dies durch Zertifizierungs- oder Kundenvereinbarungen erforderlich ist.“
Aus Audit and Compliance Monitoring Policy-sme, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.2.4
Für größere Organisationen erweitert Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, in einigen Clarysec-Materialien auch als P33 Audit and Compliance Monitoring Policy bezeichnet, die Struktur:
„Ein risikobasierter Auditplan ist jährlich zu entwickeln und zu genehmigen; dabei ist Folgendes zu berücksichtigen:“
Aus Audit and Compliance Monitoring Policy, Governance-Anforderungen, Abschnitt 5.2 Audit and Compliance Monitoring Policy
„Die Organisation hat ein Auditregister zu führen, das Folgendes enthält:“
Aus Audit and Compliance Monitoring Policy, Governance-Anforderungen, Abschnitt 5.4
„Interne Audits haben einem dokumentierten Verfahren zu folgen, das Folgendes umfasst:“
Aus Audit and Compliance Monitoring Policy, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.1.1
„Alle Feststellungen müssen zu einer dokumentierten CAPA führen, die Folgendes enthält:“
Aus Audit and Compliance Monitoring Policy, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.2.1
Die Managementbewertung ist in der Information Security Policy Information Security Policy verankert, die in einigen Clarysec-Materialien auch als P01 Information Security Policy bezeichnet wird:
„Tätigkeiten der Managementbewertung (gemäß ISO/IEC 27001 Abschnitt 9.3) sind mindestens jährlich durchzuführen und müssen Folgendes umfassen:“
Aus Information Security Policy, Governance-Anforderungen, Abschnitt 5.3 Information Security Policy
Diese Anforderungen schaffen die Nachweiskette, die Auditoren erwarten: genehmigter Plan, definiertes Verfahren, Auditregister, Feststellungen, CAPA, Aufbewahrung und Überprüfung durch die Leitung.
Aufbau des auditbereiten Nachweispakets
Ein auditbereites Nachweispaket ist kein riesiger Ordner, der zwei Tage vor dem Audit erstellt wird. Es ist eine lebende Struktur, die während des gesamten Jahres gepflegt wird.
| Nachweiselement | Zweck nach ISO 27001 | Relevanz für NIS2 und DORA |
|---|---|---|
| ISMS-Geltungsbereich und Register interessierter Parteien | Zeigt, dass gesetzliche, vertragliche und abhängigkeitsbezogene Anforderungen identifiziert sind | Unterstützt den NIS2-Entitätsumfang, die DORA-Rollenanalyse und die Rechenschaftspflicht nach GDPR |
| Risikokriterien und Risikoregister | Zeigt konsistente Risikobeurteilung und Verantwortlichkeit | Unterstützt NIS2-Maßnahmen zum Risikomanagement und das DORA-Rahmenwerk für IKT-Risikomanagement |
| Anwendbarkeitserklärung (SoA) | Zeigt ausgewählte Kontrollen, Begründung und Umsetzungsstatus | Schafft eine konsolidierte Kontrollbasis für rahmenwerksübergreifende Compliance |
| Jährlicher interner Auditplan | Zeigt geplante Prüfungs- und Assurance-Aktivitäten | Unterstützt Managementaufsicht und DORA-IKT-Auditplanung |
| Checkliste für das interne Audit | Zeigt Auditkriterien und Stichprobenmethode | Weist nach, wie Anforderungen aus NIS2, DORA und GDPR geprüft wurden |
| Auditbericht und Feststellungsprotokoll | Zeigt objektive Nachweise und Nichtkonformitäten | Unterstützt Wirksamkeitsbewertung und regulatorische Assurance |
| CAPA-Protokoll | Zeigt Ursache, Verantwortlichen, Fälligkeitstermin und Abschluss | Unterstützt Korrekturmaßnahmen nach NIS2 und Mängelbehebung nach DORA |
| Paket für die Managementbewertung | Zeigt die Überprüfung von Leistung, Vorfällen, Risiken und Ressourcen durch die Leitung | Unterstützt die Rechenschaftspflicht des Leitungsorgans nach NIS2 und DORA |
| Lieferantenregister und Vertragsnachweise | Zeigt Kontrolle von Drittparteienrisiken | Unterstützt die Sicherheit der Lieferkette nach NIS2 und das Management von IKT-Drittparteienrisiken nach DORA |
| Aufzeichnungen zur Vorfallmeldung und zu Lessons Learned | Zeigt Reaktion und Verbesserung | Unterstützt gestufte NIS2-Meldungen und DORA-Governance für Vorfälle |
Das Nachweispaket sollte den Abschnitten von ISO/IEC 27001:2022 und den Annex A-Kontrollen zugeordnet, aber zusätzlich nach regulatorischer Relevanz gekennzeichnet werden. Ein Lieferantenauditdatensatz kann beispielsweise Annex A-Lieferantenkontrollen, NIS2-Sicherheit der Lieferkette und das Management von IKT-Drittparteienrisiken nach DORA unterstützen. Ein Tabletop-Protokoll zu einem Vorfall kann das ISO 27001-Vorfallmanagement, die Bereitschaft für gestufte NIS2-Meldungen und die DORA-Governance für schwerwiegende IKT-bezogene Vorfälle unterstützen.
Durchführung des integrierten internen Audits
Schritt 26 von Zenith Blueprint betont objektive Nachweise:
„Führen Sie das Audit durch, indem Sie objektive Nachweise für jeden Punkt Ihrer Checkliste sammeln.“
„Befragen Sie relevantes Personal.“
„Überprüfen Sie Dokumentation.“
„Beobachten Sie Praktiken.“
„Nehmen Sie Stichproben und führen Sie Stichprobenprüfungen durch.“
Aus Zenith Blueprint, Phase Audit, Überprüfung und Verbesserung, Schritt 26: Auditdurchführung Zenith Blueprint
Genau das verlangen die Vorbereitung auf NIS2 und DORA. Aufsichtsbehörden und Kunden akzeptieren kein „wir glauben, dass es funktioniert“. Sie werden fragen, woher Sie das wissen.
Ein gut durchgeführtes Audit prüft vier Nachweisdimensionen.
| Nachweisdimension | Beispiel für eine Auditprüfung | Gute Nachweise |
|---|---|---|
| Design | Definiert die Richtlinie oder der Prozess die Anforderung? | Genehmigte Richtlinie, Verfahren, Standard, Workflow |
| Umsetzung | Wurde der Prozess ausgerollt? | Tickets, Konfigurationen, Schulungsnachweise, Lieferantenaufzeichnungen |
| Operative Wirksamkeit | Hat der Prozess über die Zeit funktioniert? | Stichproben über mehrere Monate, Warnmeldungen, Prüfprotokolle, Testergebnisse |
| Governance-Eskalation | Hat das Management Ergebnisse gesehen und darauf reagiert? | CAPA-Genehmigung, Sitzungsprotokolle der Managementbewertung, Budgetentscheidung |
Betrachten Sie ein simuliertes Ransomware-Ereignis auf einem Staging-Server. Der Auditor prüft, ob der Incident-Response-Prozess Anforderungen aus ISO 27001, Erwartungen an gestufte NIS2-Meldungen und DORA-bezogene Kundenverpflichtungen erfüllen kann.
| Gesammelter Nachweis | Relevanz für ISO 27001 | Relevanz für NIS2 | Relevanz für DORA |
|---|---|---|---|
| Vorfallsprotokoll mit erster Klassifizierung und Zeitstempel | Kontrolle 5.26 Reaktion auf Informationssicherheitsvorfälle | Legt den Zeitpunkt der Kenntnisnahme für Meldefristen fest | Unterstützt Identifizierung und Protokollierung IKT-bezogener Vorfälle |
| Eskalation an CSIRT und Rechtsabteilung | Kontrolle 5.25 Bewertung und Entscheidung zu Informationssicherheitsereignissen | Unterstützt die Entscheidungsfindung zur Meldung erheblicher Vorfälle | Unterstützt interne Kommunikation und Eskalationsverfahren |
| Entwurf einer Vorlage für Frühwarnmeldungen | Kontrolle 5.24 Planung und Vorbereitung des Vorfallmanagements | Unterstützt die Fähigkeit, die 24-Stunden-Frühwarnanforderung einzuhalten | Kann die Bereitschaft für vertragliche Kommunikation unterstützen |
| Entscheidungsaufzeichnung zur Backup-Wiederherstellung | Kontrollen 5.29, 5.30 und 8.13 | Unterstützt Nachweise zu Geschäftskontinuität und Disaster Recovery | Unterstützt Erwartungen an Reaktion, Wiederherstellung und Backup-Wiederherstellung |
| Kundenkommunikationsaufzeichnung | Kontrollen 5.20 und 5.22 Lieferantenvereinbarungen und Überwachung von Lieferantenservices | Kann vertragliche Kommunikation und Kommunikation zur Lieferkette unterstützen | Unterstützt Drittparteienrisikoverpflichtungen von Finanzkunden |
NIS2 sieht für erhebliche Vorfälle eine gestufte Meldestruktur vor, einschließlich Frühwarnung innerhalb von 24 Stunden nach Kenntnisnahme, Vorfallmeldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats nach der Vorfallmeldung. DORA verfügt über ein eigenes Klassifizierungs- und Melderahmenwerk für IKT-bezogene Vorfälle bei Finanzunternehmen. Das interne Audit sollte verifizieren, dass Playbooks Zeitpunkt der Kenntnisnahme, Schweregradkriterien, betroffene Services, Indikatoren einer Kompromittierung (IOCs), Risikominderungsmaßnahmen, Ursache, Kundenbenachrichtigungspflichten und Daten für den Abschlussbericht erfassen.
Eine Auditfeststellung in NIS2- und DORA-Nachweise überführen
Eine realistische Lieferantenfeststellung zeigt, wie Nachweise fließen sollten.
Während des internen Audits nimmt der Auditor Stichproben bei fünf kritischen Lieferanten. Ein Cloud-Protokollierungsanbieter unterstützt Betrugsüberwachung und Sicherheitsalarmierung für die Fintech-Plattform. Der Lieferant ist im Inventar aufgeführt, aber es gibt keinen dokumentierten Exit-Plan, keinen Nachweis einer jährlichen Sicherheitsüberprüfung und keine Bestätigung, dass der Vertrag Unterstützung bei Vorfällen oder Auditrechte enthält.
Der Auditor erfasst eine Nichtkonformität zu Anforderungen an Lieferantensicherheit und Cloud-Exit. Eine schwache Reaktion würde lauten: „Lieferantenprüfung fehlt.“ Eine starke Reaktion schafft eine rahmenwerksübergreifende Nachweiskette:
- Erfassen Sie die Feststellung im Auditbericht, einschließlich Stichprobengröße, Lieferantenname, Vertragsreferenz und fehlender Nachweise.
- Ergänzen Sie einen CAPA-Eintrag mit Ursache, zum Beispiel: „Die Lieferanten-Onboarding-Checkliste enthielt keine Kritikalitätsklassifizierung und keinen Auslöser für Exit-Pläne.“
- Weisen Sie den Lieferantenverantwortlichen und den Risikoverantwortlichen zu.
- Aktualisieren Sie das Lieferantenregister, um den Service als unterstützend für eine kritische oder wichtige Funktion zu kennzeichnen.
- Führen Sie eine Risikobeurteilung durch, die Serviceunterbrechung, Datenzugriff, Konzentrationsrisiko, Abhängigkeit bei Vorfallmeldungen und vertragliche Lücken abdeckt.
- Aktualisieren Sie den Risikobehandlungsplan und die Anwendbarkeitserklärung (SoA), soweit relevant.
- Beschaffen Sie einen aktualisierten Vertragsnachtrag oder eine dokumentierte Risikoakzeptanz.
- Erstellen oder testen Sie einen Exit-Plan.
- Auditieren Sie die Lieferantennachweise nach der Mängelbehebung erneut.
- Berichten Sie Feststellung, Risiko und Ressourcenbedarf in der Managementbewertung.
Diese einzelne Kette unterstützt mehrere Verpflichtungen. NIS2 erwartet Sicherheit der Lieferkette und die Berücksichtigung von Schwachstellen bei Lieferanten, Cybersicherheitspraktiken und sicheren Entwicklungsverfahren. DORA verlangt von Finanzunternehmen das Management von IKT-Drittparteienrisiken, die Führung von Registern vertraglicher Vereinbarungen, die Bewertung von Anbietern vor Vertragsabschluss, die Aufnahme von Audit- und Inspektionsrechten, soweit angemessen, die Aufrechterhaltung von Kündigungsrechten und die Dokumentation von Exit-Strategien für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen. GDPR kann ebenfalls relevant sein, wenn der Lieferant personenbezogene Daten verarbeitet.
Der Auditdatensatz ist dann nicht mehr nur ein Compliance-Nachweis. Er ist ein Nachweis der Resilienz.
Managementbewertung: wo Nachweise zu Rechenschaftspflicht werden
Das interne Audit stellt die Fakten fest. Die Managementbewertung entscheidet, was damit geschieht.
Schritt 28 von Zenith Blueprint beschreibt das Eingabepaket für die Managementbewertung:
„ISO 27001 nennt mehrere erforderliche Eingaben für die Managementbewertung. Bereiten Sie einen kurzen Bericht oder eine Präsentation vor, die diese Punkte abdeckt.“
Der Blueprint nennt den Status früherer Maßnahmen, Änderungen externer und interner Themen, ISMS-Leistung und -Wirksamkeit, Vorfälle oder Nichtkonformitäten, Verbesserungsmöglichkeiten und Ressourcenbedarf.
Aus Zenith Blueprint, Phase Audit, Überprüfung und Verbesserung, Schritt 28: Managementbewertung Zenith Blueprint
Für NIS2 und DORA wird in der Managementbewertung Rechenschaftspflicht auf Ebene des Leitungsorgans sichtbar. Die Bewertung sollte nicht nur festhalten, dass „Sicherheit besprochen wurde“. Sie sollte zeigen, dass die Leitung Folgendes geprüft hat:
- Änderungen bei Anforderungen aus NIS2, DORA, GDPR, Kunden und Verträgen.
- Änderungen des Geltungsbereichs, einschließlich neuer Länder, Produkte, regulierter Kunden oder IKT-Abhängigkeiten.
- Ergebnisse interner Audits, einschließlich wesentlicher und geringfügiger Nichtkonformitäten.
- Status von CAPAs und überfälligen Maßnahmen.
- Sicherheitsziele und Kennzahlen.
- Sicherheitsvorfalltrends, Beinahe-Vorfälle und Lessons Learned.
- Lieferanten- und Cloud-Konzentrationsrisiken.
- Ergebnisse von Tests zur Geschäftskontinuität und zu Backups.
- Leistung im Schwachstellen- und Patch-Management.
- Ressourcenbedarf, einschließlich Personal, Werkzeuge, Schulung und Budget.
- Restrisiken, die eine formale Akzeptanz erfordern.
- Verbesserungsentscheidungen und verantwortliche Eigentümer.
Hier kann Maria einen technischen Bericht in strategische Assurance überführen. Statt zu sagen: „Wir haben eine Lücke im Vorfallprozess gefunden“, kann sie sagen: „Das Audit hat eine geringfügige Nichtkonformität in unseren NIS2-Entscheidungskriterien für Vorfallmeldungen identifiziert. Die CAPA aktualisiert das Verfahren, ergänzt eine Entscheidungsmatrix und verlangt eine Tabletop-Übung innerhalb von 30 Tagen. Wir benötigen die Genehmigung des Managements für rechtliche Prüfung und Schulungszeit.“
Das ist die Art von Aufzeichnung, die Governance, Aufsicht und belastbare Entscheidungsfindung unterstützt.
Korrekturmaßnahmen: der Unterschied zwischen einer Feststellung und Reifegrad
Ein internes Audit ohne Korrekturmaßnahmen ist nur eine Diagnose.
Schritt 29 von Zenith Blueprint weist Organisationen an, ein CAPA-Protokoll zu verwenden:
„Füllen Sie es mit jedem Thema: Beschreibung des Problems, Ursache, Korrekturmaßnahme, verantwortlicher Eigentümer, Zieldatum für den Abschluss, Status.“
Aus Zenith Blueprint, Phase Audit, Überprüfung und Verbesserung, Schritt 29: Kontinuierliche Verbesserung Zenith Blueprint
Er macht außerdem eine wichtige Unterscheidung:
„In Auditterminologie: Korrektur behebt das Symptom, Korrekturmaßnahme behebt die Ursache. Beides ist wichtig.“
Aus Zenith Blueprint, Phase Audit, Überprüfung und Verbesserung, Schritt 29: Kontinuierliche Verbesserung
Wenn Nachweise für Backup-Wiederherstellungen fehlen, kann die Korrektur darin bestehen, diese Woche einen Wiederherstellungstest durchzuführen und zu dokumentieren. Die Korrekturmaßnahme besteht darin, das Backup-Verfahren so zu ändern, dass Wiederherstellungstests quartalsweise geplant, automatisch als Ticket erstellt, durch den Serviceverantwortlichen geprüft und in die Kennzahlen der Managementbewertung aufgenommen werden.
Auditoren achten auf diesen Reifegrad. Ein ISO 27001-Auditor prüft die Konformität mit dem ISMS und den ausgewählten Kontrollen. Ein NIS2-Prüfer fragt, ob Risikomanagementmaßnahmen wirksam sind und überwacht werden. Ein DORA-Prüfer achtet auf Integration in das IKT-Risikomanagementrahmenwerk, Resilienztests, Management von Drittparteienabhängigkeiten und Mängelbehebung. Ein Prüfer nach dem NIST Cybersecurity Framework 2.0 kann fragen, ob Ergebnisse in den Bereichen Governance, Identify, Protect, Detect, Respond und Recover operativ funktionieren. Ein COBIT 2019-Auditor kann sich auf Governance-Ziele, Verantwortlichkeit, Leistungsindikatoren und Assurance konzentrieren.
Derselbe CAPA-Datensatz kann diese Perspektiven bedienen, wenn er Ursache, Verantwortlichen, Risikoauswirkung, Korrekturmaßnahme, Fälligkeitstermin, Umsetzungsnachweis, Wirksamkeitsüberprüfung und Sichtbarkeit für das Management enthält.
Die verschiedenen Perspektiven des Auditors
Unterschiedliche Auditoren lesen dieselben Nachweise unterschiedlich. Zenith Controls hilft, diese Fragen vorwegzunehmen, indem es als Cross-Compliance-Leitfaden für Kontrollen nach ISO/IEC 27002:2022 und verwandte Rahmenwerke dient.
| Auditperspektive | Was der Auditor voraussichtlich fragen wird | Nachweise, die überzeugend antworten |
|---|---|---|
| ISO 27001-Auditor | Ist das ISMS gemäß den Anforderungen von ISO/IEC 27001:2022 geplant, umgesetzt, bewertet und verbessert? | Geltungsbereich, Risikobeurteilung, Anwendbarkeitserklärung (SoA), interner Auditplan, Auditbericht, Ergebnisse der Managementbewertung, CAPA |
| NIS2-Prüfer | Hat das Management geeignete Risikomanagementmaßnahmen genehmigt und überwacht, und kann die Einrichtung Wirksamkeit und Korrekturmaßnahmen nachweisen? | Sitzungsprotokolle des Leitungsorgans oder der Managementbewertung, Risikobehandlungsplan, Vorfall-Playbooks, Lieferantenüberprüfungen, Schulungsnachweise, Wirksamkeitskennzahlen |
| DORA-Prüfer | Ist das IKT-Risikomanagement in Governance, Resilienzstrategie, Tests, Drittparteienrisiken und Mängelbehebung integriert? | IKT-Risikomanagementrahmenwerk, Auditplan, Nachweise zu Resilienztests, Drittparteienregister, Zuordnung kritischer Funktionen, Aufzeichnungen zur Mängelbehebung |
| GDPR-Prüfer | Kann die Organisation Rechenschaftspflicht für die Verarbeitung und Sicherheit personenbezogener Daten nachweisen? | Dateninventar, Aufzeichnungen zu Rechtsgrundlagen, Auftragsverarbeitungsverträge, Protokolle zu Datenschutzverletzungen, Zugriffskontrollen, Nachweise zur Aufbewahrung, Sicherheitsmaßnahmen |
| NIST CSF 2.0-Prüfer | Funktionieren Ergebnisse in Governance, Risiko, Schutz, Erkennung, Reaktion und Wiederherstellung wirksam? | Den Ergebnissen zugeordnete Kontrollnachweise, Protokolle, Überwachung, Vorfallsaufzeichnungen, Wiederherstellungstests, Verbesserungsmaßnahmen |
| COBIT 2019-Auditor | Sind Governance-Ziele, Verantwortlichkeit, Leistungsmanagement und Assurance-Aktivitäten definiert und überwacht? | RACI, Richtlinien, KPIs, Auditregister, Vorgangsmanagement, Managementberichterstattung, Entscheidungsaufzeichnungen |
Kontrolle 5.36 ist ein gutes Beispiel. Der ISO 27001-Auditor kann sich darauf konzentrieren, ob Compliance-Überprüfungen stattfinden und in Korrekturmaßnahmen einfließen. Der NIS2-Prüfer kann fragen, ob diese Überprüfungen gesetzliche Cybersicherheitsmaßnahmen prüfen und nicht nur interne Regeln. Der DORA-Prüfer kann darauf achten, ob Compliance-Überprüfungen kritische IKT-Anbieter und vertragliche Durchsetzungsmaßnahmen einschließen.
Deshalb müssen Nachweise von Anfang an für mehrere Leser konzipiert werden.
Ein praktischer 30-Tage-Sprint zur Auditbereitschaft
Wenn der CEO fragt, ob die Organisation in 30 Tagen auditbereit sein kann, lautet die ehrliche Antwort: Sie können eine glaubwürdige Nachweisbasis schaffen, wenn die Leitung den Sprint unterstützt und der Geltungsbereich realistisch ist.
| Tage | Aktivität | Ergebnis |
|---|---|---|
| 1 bis 3 | ISMS-Geltungsbereich, regulierte Services, interessierte Parteien und Verpflichtungen bestätigen | Geltungsbereichserklärung, Anwendbarkeitsnotiz zu NIS2, DORA und GDPR |
| 4 bis 7 | Risikokriterien, Risikoregister und zentrale Risikoverantwortliche aktualisieren | Aktualisiertes Risikoregister und Prioritäten der Risikobehandlung |
| 8 bis 10 | Risikobasierten internen Auditplan erstellen | Genehmigter Auditplan und Audit-Checkliste |
| 11 bis 17 | Auditinterviews, Stichproben und Nachweisprüfung durchführen | Nachweisprotokoll, Feststellungen, positive Beobachtungen |
| 18 bis 20 | Feststellungen mit Verantwortlichen validieren und Schweregrad klassifizieren | Auditbericht und Nichtkonformitätsregister |
| 21 bis 24 | CAPA-Protokoll mit Ursachen, Verantwortlichen und Fälligkeitsterminen erstellen | Genehmigter Korrekturmaßnahmenplan |
| 25 bis 27 | Paket für die Managementbewertung vorbereiten | Bewertungspräsentation oder Bericht mit Kennzahlen, Risiken, Vorfällen und Ressourcen |
| 28 bis 30 | Managementbewertung durchführen und Entscheidungen dokumentieren | Sitzungsprotokoll, Maßnahmenprotokoll, Risikoakzeptanzen, Ressourcenentscheidungen |
Dieser Sprint ersetzt keinen langfristigen Reifegrad. Er schafft eine belastbare operative Basislinie. Der eigentliche Wert entsteht, wenn die Organisation den Zyklus quartalsweise oder halbjährlich wiederholt, nicht nur einmal pro Jahr.
Häufige Nachweismängel, die Clarysec feststellt
Dieselben Schwächen treten in SaaS-, Cloud- und Fintech-Audits immer wieder auf:
- Der Auditplan existiert, ist aber nicht risikobasiert.
- Die Audit-Checkliste prüft ISO-Abschnitte, ignoriert aber NIS2, DORA, GDPR und Kundenverpflichtungen.
- Sitzungsprotokolle der Managementbewertung existieren, zeigen aber keine Entscheidungen, Ressourcenzuweisung oder Risikoakzeptanz.
- CAPA-Aufzeichnungen listen Maßnahmen auf, aber keine Ursache.
- Feststellungen werden ohne Wirksamkeitsprüfung geschlossen.
- Lieferantenüberprüfungen werden durchgeführt, aber kritische Lieferanten werden nicht von Lieferanten mit geringem Risiko unterschieden.
- Vorfall-Playbooks existieren, aber niemand kann nachweisen, dass der 24- oder 72-Stunden-Meldeworkflow funktionieren würde.
- Backup-Jobs sind grün, aber Wiederherstellungstests sind nicht nachgewiesen.
- Berechtigungsüberprüfungen werden exportiert, aber Ausnahmen werden nicht bis zum Abschluss nachverfolgt.
- Protokolle werden gesammelt, aber niemand kann Überwachung, Eskalation oder Reaktion nachweisen.
- Nachweise werden in persönlichen Ordnern statt in einem kontrollierten Repository gespeichert.
- Aufbewahrungsanforderungen sind unklar oder nicht mit Kundenverträgen konsistent.
Diese Mängel sind behebbar. Sie erfordern eine strukturierte ISMS-Nachweisarchitektur, keine Dokumentenjagd in letzter Minute.
Wie gute Praxis für das Leitungsorgan aussieht
Wenn der CISO zum CEO und CFO zurückkehrt, lautet die stärkste Antwort nicht: „Wir haben eine Audit-Checkliste bestanden.“ Sie lautet:
„Wir haben einen genehmigten Auditplan. Wir haben ein risikobasiertes internes Audit durchgeführt. Wir haben Feststellungen mit objektiven Nachweisen identifiziert. Wir haben CAPAs mit Verantwortlichen und Fälligkeitsterminen genehmigt. Wir haben wesentliche Risiken, Vorfälle, Lieferantenabhängigkeiten und Ressourcenbedarf in die Managementbewertung eskaliert. Wir haben Nachweise ISO/IEC 27001:2022, NIS2, DORA und GDPR zugeordnet. Wir können den Prüfpfad nachweisen.“
Diese Antwort verändert das Gespräch. Sie gibt dem CEO Sicherheit gegenüber Kunden. Sie gibt dem CFO Klarheit zur regulatorischen Exponierung. Sie gibt dem Leitungsorgan eine belastbare Aufsichtsaufzeichnung. Sie gibt dem CISO eine priorisierte Roadmap statt eines Stapels unverbundener Anforderungen.
Vor allem führt sie die Organisation von Compliance-Theater zu operationaler Resilienz.
Nächste Schritte mit Clarysec
Ihr nächstes Audit sollte kein Kraftakt sein. Es sollte ein sichtbarer Nachweis dafür sein, dass Ihr ISMS funktioniert, die Leitung eingebunden ist und die Organisation für ISO 27001, NIS2, DORA, GDPR und Kundenvertrauen bereit ist.
Clarysec kann Sie dabei unterstützen:
- Erstellen Sie einen risikobasierten internen Auditplan mit Zenith Blueprint: Roadmap in 30 Schritten für Auditoren Zenith Blueprint.
- Ordnen Sie Auditnachweise mit Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls zu.
- Setzen Sie Audit-Governance für KMU oder Unternehmen mit Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme oder Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy um.
- Bereiten Sie Pakete für die Managementbewertung vor, die auf Information Security Policy Information Security Policy und die Erwartungen aus ISO/IEC 27001:2022 Abschnitt 9.3 ausgerichtet sind.
- Überführen Sie Feststellungen in CAPA-Aufzeichnungen, Managemententscheidungen und messbare Verbesserung.
Laden Sie die Clarysec-Toolkits herunter, buchen Sie eine Bereitschaftsbewertung oder fordern Sie eine Demo an, um Ihr nächstes internes Audit in belastbare Nachweise für ISO 27001, NIS2, DORA und darüber hinaus zu verwandeln, die dem Leitungsorgan vorgelegt werden können.
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


