ISO 27001-Erklärung zur Anwendbarkeit für NIS2- und DORA-Bereitschaft

Es ist Montag, 08:30 Uhr. Elena, CISO eines schnell wachsenden B2B-FinTech-SaaS-Anbieters, öffnet eine als dringend markierte Anfrage des Leitungsorgans. Das Unternehmen hat gerade die ISO/IEC 27001:2022-Zertifizierung erreicht, doch eine große EU-Bank als Interessentin stellt deutlich anspruchsvollere Fragen als in einem üblichen Sicherheitsfragebogen.

Gefragt wird nicht nur, ob das Unternehmen Daten verschlüsselt, MFA einsetzt oder einen Penetrationstestbericht vorlegen kann. Der Interessent möchte wissen, ob die SaaS-Plattform seine DORA-Verpflichtungen unterstützt, ob der Anbieter als IKT-Dienst oder als Abhängigkeit digitaler Infrastruktur in den NIS2-Geltungsbereich fallen könnte und ob die ISO 27001-Erklärung zur Anwendbarkeit jede einbezogene Maßnahme, jede ausgeschlossene Maßnahme und jeden Nachweis begründen kann.

Das Leitungsorgan stellt die Frage, die CISOs, Compliance Manager und SaaS-Gründer immer häufiger hören:

Kann unsere ISO 27001-SoA die NIS2- und DORA-Bereitschaft nachweisen?

Elena weiß: Die falsche Antwort wäre, drei separate Compliance-Programme aufzusetzen – eines für ISO 27001, eines für NIS2 und eines für DORA. Das würde doppelte Nachweise, widersprüchliche Maßnahmenverantwortliche und hektische Vorbereitung vor jeder Kundenbewertung erzeugen. Der bessere Ansatz ist, das bestehende ISMS als Betriebssystem für Compliance zu nutzen – mit der Erklärung zur Anwendbarkeit, also der SoA, als zentralem Dokument für Nachvollziehbarkeit.

Die SoA ist nicht nur eine Tabelle für die ISO-Zertifizierung. In einem europäischen Umfeld für Cybersicherheit und operationelle Resilienz weist eine Organisation darin nach, warum Maßnahmen bestehen, warum Ausschlüsse vertretbar sind, wer für jede Maßnahme verantwortlich ist, welche Nachweise die Umsetzung stützen und wie das Maßnahmenpaket NIS2, DORA, GDPR, Kundenverträge und die interne Risikobehandlung adressiert.

Clarysec’s Enterprise Informationssicherheitsleitlinie Informationssicherheitsleitlinie legt fest:

Das ISMS muss definierte Grenzen des Geltungsbereichs, eine Methodik zur Risikobeurteilung, messbare Ziele und dokumentierte Maßnahmen enthalten, die in der Erklärung zur Anwendbarkeit (SoA) begründet sind.

Diese Anforderung aus Richtlinienklausel 6.1.2 der Informationssicherheitsleitlinie bildet die Grundlage für einen auditbereiten Ansatz. Die SoA muss zur Brücke zwischen Verpflichtungen, Risiken, Maßnahmen, Nachweisen und Managemententscheidungen werden.

Warum NIS2 und DORA die Bedeutung von „anwendbar“ verändert haben

Eine klassische ISO/IEC 27001:2022-SoA beginnt häufig mit einer einfachen Frage: „Welche Annex A-Maßnahmen gelten für unseren Risikobehandlungsplan?“ Das ist weiterhin richtig, reicht aber für SaaS-, Cloud-, Managed-Service-, FinTech-, Finanztechnologie- und kritische Lieferkettenanbieter nicht mehr aus.

NIS2 hebt die Mindestanforderungen an das Cybersicherheitsrisikomanagement für wesentliche und wichtige Einrichtungen in der EU an. Erfasst werden Sektoren wie digitale Infrastruktur, Cloud-Computing-Dienste, Rechenzentrumsdienste, Content Delivery Networks, Managed Service Provider, Managed Security Service Provider, Banken und Finanzmarktinfrastrukturen. Die Mitgliedstaaten müssen wesentliche und wichtige Einrichtungen sowie Diensteanbieter für die Registrierung von Domänennamen identifizieren. Viele Technologieanbieter, die Cybersicherheitsregulierung bisher als Kundenangelegenheit behandelt haben, fallen nun entweder direkt in den Geltungsbereich oder sind über vertragliche Weitergabepflichten betroffen.

NIS2 Article 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen in den Bereichen Risikoanalyse, Sicherheitsleitlinien, Umgang mit Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Bewertung der Kontrollwirksamkeit, Cyberhygiene, Schulung, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management und – soweit angemessen – Authentifizierung. NIS2 Article 23 ergänzt gestufte Erwartungen an die Meldung von Sicherheitsvorfällen, einschließlich Frühwarnung, Meldung, Aktualisierungen und Abschlussmeldung für erhebliche Sicherheitsvorfälle.

DORA, der Digital Operational Resilience Act, gilt ab dem 17. Januar 2025 und fokussiert Finanzunternehmen und deren IKT-Risikoökosystem. DORA umfasst das Management von IKT-Risiken, die Meldung IKT-bezogener Vorfälle, die Meldung operationeller oder sicherheitsbezogener Zahlungsvorfälle für bestimmte Unternehmen, Tests der digitalen operationellen Resilienz, den Austausch von Cyberbedrohungsinformationen, das Management von IKT-Drittparteienrisiken, vertragliche Vereinbarungen sowie die Aufsicht über kritische IKT-Drittdienstleister.

Für Finanzunternehmen, die zugleich wesentliche oder wichtige Einrichtungen nach NIS2 sind, wirkt DORA als sektorspezifisches Regime für gleichwertige Verpflichtungen zum Management von IKT-Risiken und zur Meldung von Sicherheitsvorfällen. Für SaaS-Anbieter, Cloud-Anbieter, MSPs und MDR-Anbieter, die Finanzkunden bedienen, kommen DORA-Erwartungen in der Praxis jedoch über Beschaffung, Verträge, Auditrechte, Verpflichtungen zur Unterstützung bei Vorfällen, Exit-Planung, Transparenz zu Subunternehmern und Resilienznachweise an.

Damit verändert sich die SoA-Diskussion. Die Frage lautet nicht mehr: „Enthält Annex A diese Maßnahme?“ Die bessere Frage lautet:

Können wir nachweisen, dass die Maßnahmenselektion risikobasiert, verpflichtungsbewusst, verhältnismäßig, verantwortet, umgesetzt, überwacht, nachgewiesen und genehmigt ist?

ISO 27001 ist der universelle Übersetzer für NIS2 und DORA

ISO/IEC 27001:2022 ist wertvoll, weil es sich um eine Managementsystemnorm handelt – nicht um eine enge Checkliste. Sie verlangt, dass das ISMS in die Prozesse der Organisation integriert und an die Bedürfnisse der Organisation angepasst wird. Dadurch wird sie zu einem wirksamen universellen Übersetzer für überlappende Compliance-Anforderungen.

Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext versteht, interessierte Parteien identifiziert, relevante Anforderungen bestimmt und den ISMS-Geltungsbereich definiert. Für einen FinTech-SaaS-Anbieter wie Elenas Unternehmen können diese Anforderungen interessierter Parteien EU-Kunden, von DORA betroffene Finanzkunden, NIS2-Sektorbetroffenheit, GDPR-Verpflichtungen von Verantwortlichen und Auftragsverarbeitern, ausgelagerte Cloud-Abhängigkeiten, Lieferantenschnittstellen und Erwartungen des Leitungsorgans umfassen.

Die Klauseln 6.1.1 bis 6.1.3 verlangen die Planung von Risiken und Chancen, einen wiederholbaren Prozess zur Informationssicherheitsrisikobeurteilung, einen Risikobehandlungsprozess, den Abgleich mit Annex A sowie eine Erklärung zur Anwendbarkeit, die einbezogene Maßnahmen, Umsetzungsstatus und Begründungen für Ausschlüsse identifiziert.

An dieser Stelle wird die SoA zum Entscheidungsnachweis für Maßnahmen. Eine Maßnahme kann einbezogen werden, weil sie ein Risiko behandelt, eine rechtliche Anforderung erfüllt, einen Kundenvertrag bedient, ein Geschäftsziel unterstützt oder grundlegende Sicherheitshygiene abbildet. Eine Maßnahme darf nur ausgeschlossen werden, nachdem die Organisation sie bewusst bewertet, als für den ISMS-Geltungsbereich nicht relevant eingestuft, die Begründung dokumentiert und eine angemessene Genehmigung eingeholt hat.

Clarysec’s Enterprise Risikomanagement-Richtlinie Risikomanagement-Richtlinie legt fest:

Eine Erklärung zur Anwendbarkeit (SoA) muss alle Behandlungsentscheidungen abbilden und aktualisiert werden, wenn sich die Maßnahmenabdeckung ändert.

Diese Anforderung aus Richtlinienklausel 5.4 der Risikomanagement-Richtlinie ist für die NIS2- und DORA-Bereitschaft entscheidend. Ein neuer regulierter Kunde, eine neue Cloud-Abhängigkeit, eine neue Pflicht zur Meldung von Sicherheitsvorfällen oder ein neues Konzentrationsrisiko bei Lieferanten kann die Anwendbarkeit von Maßnahmen verändern.

Mit dem Compliance-Register beginnen, nicht mit der Maßnahmenliste

Eine schwache SoA beginnt mit Annex A und fragt: „Welche Maßnahmen haben wir bereits?“ Eine starke SoA beginnt mit der tatsächlichen Betriebsrealität der Organisation und fragt: „Welche Verpflichtungen, Services, Risiken, Daten, Lieferanten und Kunden muss das ISMS adressieren?“

ISO/IEC 27005:2022 unterstützt diesen Ansatz, indem sie Anforderungen interessierter Parteien, Risikokriterien und die Notwendigkeit betont, Normen, interne Regeln, Gesetze, Vorschriften, Verträge und bestehende Kontrollen zu berücksichtigen. Außerdem hebt sie hervor, dass Nichtanwendbarkeit oder Nichteinhaltung erläutert und begründet werden sollte.

Clarysec’s SME Richtlinie zur rechtlichen und regulatorischen Compliance-sme Richtlinie zur rechtlichen und regulatorischen Compliance-sme - KMU beschreibt dasselbe operative Prinzip:

Der GM muss ein einfaches, strukturiertes Compliance-Register führen, das Folgendes auflistet:

Diese Anforderung stammt aus Klausel 5.1.1 der Richtlinie zur rechtlichen und regulatorischen Compliance-sme. Für eine kleinere Organisation kann das Register einfach gehalten sein. Für ein Unternehmen sollte es detaillierter sein. Die Logik bleibt gleich: Verpflichtungen müssen sichtbar sein, bevor sie zugeordnet werden können.

Clarysec’s Enterprise Richtlinie zur rechtlichen und regulatorischen Compliance Richtlinie zur rechtlichen und regulatorischen Compliance ist eindeutig:

Alle rechtlichen und regulatorischen Verpflichtungen müssen im Informationssicherheits-Managementsystem (ISMS) konkreten Richtlinien, Maßnahmen und Verantwortlichen zugeordnet werden.

Das ist Richtlinienklausel 6.2.1 der Richtlinie zur rechtlichen und regulatorischen Compliance. Sie bildet das Governance-Rückgrat für die Nutzung einer ISO 27001-Erklärung zur Anwendbarkeit zur Compliance-Bereitschaft gegenüber NIS2 und DORA.

Risikokriterien auf Resilienz, Datenschutz, Lieferanten und Regulierung ausrichten

Viele SoA-Begründungen scheitern, weil das Risiko-Scoring-Modell zu eng ist. Es misst technische Eintrittswahrscheinlichkeit und Auswirkung, erfasst aber nicht regulatorische Exponierung, Kritikalität des Services, Kundenschäden, Lieferantenabhängigkeit, Datenschutzfolgen oder systemische operative Störungen.

NIS2 betrifft nicht nur Vertraulichkeit. Der Fokus liegt darauf, Auswirkungen von Vorfällen auf Services und Serviceempfänger zu verhindern und zu minimieren. DORA definiert kritische oder wichtige Funktionen danach, ob eine Störung die finanzielle Leistung, die Servicekontinuität oder die regulatorische Compliance wesentlich beeinträchtigen würde. GDPR ergänzt Rechenschaftspflicht, Integrität, Vertraulichkeit, Bereitschaft bei Datenschutzverletzungen und Schäden für betroffene Personen.

Clarysec’s SME Risikomanagement-Richtlinie-sme Risikomanagement-Richtlinie-sme - KMU gibt ein praktisches Mindestmaß vor:

Jeder Risikoeintrag muss Folgendes enthalten: Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlicher und Behandlungsplan.

Dies ist Klausel 5.1.2 der Risikomanagement-Richtlinie-sme. Für die NIS2- und DORA-Bereitschaft erweitert Clarysec dieses Mindestmaß um Felder wie Verpflichtungsquelle, betroffenen Service, Datenkategorie, Lieferantenabhängigkeit, Geschäftsverantwortlichen, regulatorische Auswirkung, Restrisiko, Behandlungsstatus und Nachweisquelle.

Achten Sie auf die Sprache. Eine starke Begründung sagt nicht nur „umgesetzt“. Sie erklärt, warum die Maßnahme im geschäftlichen, regulatorischen und risikobezogenen Kontext der Organisation anwendbar ist.

NIS2- und DORA-Domänen ISO 27001:2022-Maßnahmen zuordnen

Sobald Compliance-Register und Risikokriterien etabliert sind, besteht die praktische Arbeit darin, regulatorische Domänen den Annex A-Maßnahmen zuzuordnen. Diese Zuordnung weist Compliance nicht für sich allein nach, bietet Auditoren und Kunden aber einen klaren Index für die Prüfung von Nachweisen.

Für Elena veränderte diese Zuordnung die Diskussion im Leitungsorgan. Statt NIS2 und DORA als getrennte Projekte darzustellen, konnte sie die Überschneidungen zeigen: Governance, Risikomanagement, Sicherheitsvorfälle, Kontinuität, Lieferanten, Tests, Zugriffskontrolle und Kryptografie.

Die drei ISO-Maßnahmen, von denen jede NIS2- und DORA-SoA abhängt

In Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt Clarysec drei ISO/IEC 27002:2022-Maßnahmen als zentral für eine auditbereite SoA-Governance zu NIS2 und DORA. Es handelt sich um ISO-Maßnahmen, die im Leitfaden Zenith Controls um Cross-Compliance-Attribute erweitert werden.

Diese Maßnahmen stehen nicht isoliert. Sie sind direkt mit den Maßnahmen zu Lieferantenbeziehungen A.5.19 bis A.5.23, den Maßnahmen zum Incident Management A.5.24 bis A.5.28, den Kontinuitätsmaßnahmen A.5.29 und A.5.30, der Datenschutzmaßnahme A.5.34, dem Schwachstellenmanagement A.8.8, dem Konfigurationsmanagement A.8.9, der Informationssicherung A.8.13, der Protokollierung A.8.15, den Überwachungstätigkeiten A.8.16, der Kryptografie A.8.24, den Maßnahmen zur sicheren Entwicklung A.8.25 bis A.8.29 und dem Änderungsmanagement A.8.32 verbunden.

Der Wert von Zenith Controls liegt darin, dass Teams die SoA nicht als Artefakt für nur eine Norm behandeln. Maßnahme 5.31 unterstützt rechtliche und vertragliche Zuordnungen. Maßnahme 5.35 unterstützt internes Audit, unabhängige Überprüfung und Managementsicherheit. Maßnahme 5.36 unterstützt die operative Einhaltung von Richtlinien, Verfahren, Standards und Maßnahmenanforderungen.

Mit dem Zenith Blueprint die SoA aufbauen, testen und verteidigen

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint verortet Clarysec den Aufbau der SoA in der Risikomanagementphase, Schritt 13: Planung der Risikobehandlung und Erklärung zur Anwendbarkeit. Der Blueprint weist Organisationen an, das SoA-Blatt in der Vorlage „Risk Register and SoA Builder.xlsx“ zu verwenden, für jede der 93 Annex A-Maßnahmen über die Anwendbarkeit zu entscheiden und die Entscheidung auf Risikobehandlung, rechtliche und vertragliche Anforderungen, Relevanz für den Geltungsbereich und organisatorischen Kontext zu stützen.

Der Blueprint formuliert:

Die SoA ist faktisch ein Brückendokument: Sie verknüpft Ihre Risikobeurteilung und Risikobehandlung mit den tatsächlichen Maßnahmen, über die Sie verfügen.

Dieser Satz beschreibt das Betriebsmodell. Die SoA verbindet Verpflichtungen, Risiken, Richtlinien, Maßnahmen, Nachweise und Audit-Schlussfolgerungen.

Der Zenith Blueprint weist Teams außerdem an, Vorschriften in den SoA-Notizen bei Bedarf querzuverweisen. Wird eine Maßnahme für GDPR, NIS2 oder DORA umgesetzt, sollte dies im Risikoregister oder in den SoA-Notizen erscheinen. Später, in Schritt 24, fordert der Blueprint Organisationen auf, die SoA nach der Umsetzung zu aktualisieren und mit dem Risikobehandlungsplan gegenzuprüfen. In Schritt 30, Zertifizierungsvorbereitung, abschließende Überprüfung und Probeaudit, weist der Blueprint Teams an zu bestätigen, dass für jede anwendbare Annex A-Maßnahme Nachweise wie Richtlinie, Verfahren, Bericht, Plan oder Umsetzungsaufzeichnung vorliegen.

Diese Abfolge macht die SoA zu einem lebenden Compliance-Instrument:

1. Schritt 13 baut sie aus Risikobehandlung und Verpflichtungen auf.
2. Schritt 24 prüft sie gegen die tatsächliche Umsetzung.
3. Schritt 30 verteidigt sie durch abschließende Nachweisprüfung und Probeaudit.

Einbeziehungsbegründungen so formulieren, dass Auditoren ihnen folgen können

Eine Maßnahme muss einbezogen werden, wenn mindestens ein belastbarer Treiber vorliegt: Risikobehandlung, rechtliche Anforderung, vertragliche Anforderung, Relevanz für den Geltungsbereich, grundlegende Sicherheitshygiene, Kundenerwartung an Assurance oder ein vom Management genehmigtes Resilienzziel.

Eine hilfreiche Formel lautet:

Anwendbar, weil [Risiko oder Verpflichtung] [Service, Asset, Daten oder Prozess] betrifft und diese Maßnahme [präventive, detektive, korrektive oder resilienzbezogene Wirkung] bereitstellt, nachgewiesen durch [Richtlinie, Aufzeichnung, Test, Bericht oder Systemausgabe].

Für einen FinTech-SaaS-Anbieter könnte eine SoA-Zeile so aussehen:

Das ist auditbereit, weil die Maßnahme mit Kontext, Risiko, Verpflichtung, Umsetzung, Verantwortung und Nachweisen verbunden wird.

Ausschlüsse begründen, ohne Auditrisiken zu erzeugen

Ausschlüsse sind keine Fehler. Schlecht begründete Ausschlüsse sind Fehler.

ISO/IEC 27001:2022 verlangt, dass die SoA ausgeschlossene Annex A-Maßnahmen begründet. ISO/IEC 27005:2022 bekräftigt, dass Nichtanwendbarkeit erläutert und begründet werden sollte. Clarysec’s Enterprise Informationssicherheitsleitlinie legt fest:

Die Baseline darf angepasst werden; Ausschlüsse müssen jedoch mit formaler Genehmigung und Begründung in der SoA dokumentiert werden.

Dies ist Klausel 7.2.2 der Informationssicherheitsleitlinie.

Clarysec’s Informationssicherheitsleitlinie-sme Informationssicherheitsleitlinie-sme - KMU legt fest:

Jede Abweichung von dieser Richtlinie muss dokumentiert werden; dabei ist klar zu erläutern, warum die Abweichung erforderlich ist, welche alternativen Schutzmaßnahmen bestehen und welches Datum für die erneute Bewertung festgelegt wurde.

Diese Anforderung stammt aus Klausel 7.2.1 der Informationssicherheitsleitlinie-sme.

Für NIS2 und DORA erfordern Ausschlüsse besondere Sorgfalt. Ein SaaS-Unternehmen sollte Protokollierung, Überwachung, Backups, Incident Management, Zugriffskontrolle, Lieferantensicherheit oder Schwachstellenmanagement nur selten ausschließen. Selbst wenn eine Maßnahme nicht mit einem einzelnen spezifischen Risiko verknüpft ist, kann sie als grundlegende Sicherheitsmaßnahme, Kundenerwartung an Assurance, vertragliche Erwartung oder rechtliche Verpflichtung erforderlich sein.

Clarysec’s Risikomanagement-Richtlinie-sme erinnert Teams außerdem daran, wie akzeptierte Risiken zu behandeln sind:

Akzeptieren: Begründen, warum keine weiteren Maßnahmen erforderlich sind, und das Restrisiko dokumentieren.

Diese Klausel, 6.1.1 der Risikomanagement-Richtlinie-sme, beschreibt genau die Haltung, die für Ausschlüsse und Restrisikoentscheidungen erforderlich ist.

Vorfallsmeldung: Workflow nachweisen, nicht nur Richtlinienexistenz

NIS2 Article 23 verlangt eine gestufte Meldung erheblicher Sicherheitsvorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, Meldung innerhalb von 72 Stunden, Aktualisierungen auf Anforderung und Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung. DORA verlangt von Finanzunternehmen, wesentliche IKT-bezogene Vorfälle zu erkennen, zu steuern, zu klassifizieren, zu eskalieren, zu kommunizieren und zu melden, betroffene Kunden soweit erforderlich zu informieren, eine Ursachenanalyse durchzuführen und Kontrollen zu verbessern.

Ein SaaS-Anbieter meldet möglicherweise nicht immer direkt an eine DORA-Behörde, muss aber unter Umständen die Meldefristen seiner Finanzkunden unterstützen. Dadurch werden Vorfallsmaßnahmen in der SoA besonders relevant.

Eine schwache SoA sagt: „Incident-Response-Richtlinie vorhanden.“

Eine starke SoA sagt: „Anwendbar, weil die Organisation Vorfälle erkennen, bewerten, klassifizieren, eskalieren, kommunizieren, Nachweise sichern, regulatorische Meldefristen unterstützen, betroffene Kunden bei vertraglicher Verpflichtung benachrichtigen und aus Vorfällen lernen muss, die Services, Daten oder regulierte Kunden betreffen.“

Nachweise sollten Folgendes umfassen:

• Incident Response Plan und Eskalationsmatrix.
• Kriterien zur Schweregradklassifizierung.
• Workflow zur Kundenbenachrichtigung.
• Entscheidungsbaum für regulatorische Meldungen, soweit anwendbar.
• Vorfalltickets und Zeitachsen.
• Protokolle und Monitoring-Warnmeldungen.
• Aufzeichnungen zu Tabletop-Übungen.
• Nachprüfung nach Vorfällen und Korrekturmaßnahmen.
• Verfahren zur Beweissicherung.

Clarysec’s Enterprise Richtlinie zur Audit- und Compliance-Überwachung Richtlinie zur Audit- und Compliance-Überwachung erklärt, warum dies relevant ist:

Um belastbare Nachweise und einen Audit Trail zur Unterstützung von Anfragen von Aufsichtsbehörden, Gerichtsverfahren oder Kundenanfragen zur Vertrauensbildung zu erzeugen.

Dieses Ziel stammt aus Klausel 3.4 der Richtlinie zur Audit- und Compliance-Überwachung.

Für kleinere Organisationen muss auch die Aufbewahrung von Nachweisen ausdrücklich geregelt sein. Clarysec’s Richtlinie zur Audit- und Compliance-Überwachung-sme Richtlinie zur Audit- und Compliance-Überwachung-sme - KMU legt fest:

Nachweise müssen mindestens zwei Jahre oder länger aufbewahrt werden, soweit dies durch Zertifizierungs- oder Kundenvereinbarungen erforderlich ist.

Das ist Klausel 6.2.4 der Richtlinie zur Audit- und Compliance-Überwachung-sme.

Eine SoA, mehrere Audit-Gespräche

Die beste SoA dupliziert keine Rahmenwerke. Sie schafft eine nachvollziehbare Maßnahmenargumentation, die unterschiedliche Auditoren verstehen können.

Ein ISO 27001-Auditor beginnt in der Regel mit der Klausellogik: Geltungsbereich, interessierte Parteien, Risikobeurteilung, Risikobehandlung, SoA, Ziele, internes Audit, Managementbewertung und Verbesserung. Ein NIS2-orientierter Prüfer fokussiert Verhältnismäßigkeit, Managementverantwortung, Schulung, Lieferkette, Vorfallsfristen und Serviceauswirkungen. Ein DORA-orientierter Kundenassessor konzentriert sich auf IKT-Risiko, kritische oder wichtige Funktionen, wesentliche IKT-Vorfälle, Resilienztests, Vertragsklauseln, Auditrechte, Exit-Pläne, Unterbeauftragung und Konzentrationsrisiko. Ein Datenschutzprüfer fokussiert GDPR-Rechenschaftspflicht und Bereitschaft bei Datenschutzverletzungen. Ein Auditor nach COBIT 2019- oder ISACA-Logik prüft Governance, Kennzahlen, Verantwortlichkeit, Assurance und Korrekturmaßnahmen.

Deshalb darf die SoA nicht nur vom Sicherheitsteam gepflegt werden. Sie benötigt Verantwortung aus Recht, Datenschutz, Beschaffung, Engineering, Betrieb, HR und Geschäftsleitung.

Häufige SoA-Schwächen in NIS2- und DORA-Bereitschaftsprojekten

Clarysec findet in Bereitschaftsprojekten wiederholt dieselben Probleme:

1. Die SoA markiert Maßnahmen als anwendbar, aber es ist kein Risiko, keine Verpflichtung und kein geschäftlicher Grund dokumentiert.
2. NIS2 und DORA werden in Richtlinien erwähnt, aber nicht Maßnahmen, Verantwortlichen oder Nachweisen zugeordnet.
3. Lieferantenmaßnahmen sind als umgesetzt markiert, aber es gibt kein Lieferantenregister, keine Kritikalitätsbewertung, keine Vertragsprüfung und keinen Exit-Plan.
4. Vorfallsmaßnahmen bestehen, aber der Prozess unterstützt keine 24-Stunden-, 72-Stunden-, Kunden- oder Abschlussmelde-Workflows.
5. Managementgenehmigung wird unterstellt, aber es gibt keine Aufzeichnung zur Risikoakzeptanz, SoA-Genehmigung oder Restrisikoentscheidung.
6. Ausschlüsse werden aus einer Vorlage kopiert und passen nicht zum tatsächlichen Cloud-, Remote-, SaaS- oder FinTech-Betriebsmodell.
7. Nachweise liegen in verschiedenen Werkzeugen vor, aber kein Audit Trail verbindet sie mit der SoA.
8. Die Verarbeitung personenbezogener Daten nach GDPR ist nicht mit Sicherheitskontrollen, Reaktion auf Datenschutzverletzungen, Lieferantenverträgen oder Aufbewahrung verknüpft.
9. Internes Audit prüft Dokumente, testet aber nicht, ob die SoA die tatsächliche Umsetzung widerspiegelt.
10. Die SoA wird nur vor der Zertifizierung aktualisiert, nicht nach neuen Kunden, Lieferanten, Vorfällen, Auditfeststellungen oder regulatorischen Änderungen.

Das sind keine Papierprobleme. Es sind Governance-Probleme.

Praktische Checkliste für eine auditbereite ISO 27001-SoA

Nutzen Sie diese Checkliste vor einem ISO 27001-Zertifizierungsaudit, einer NIS2-Bereitschaftsprüfung, einer DORA-Kundenbewertung, einer Sitzung des Leitungsorgans oder einer Due-Diligence-Prüfung durch Investoren.

Die SoA in eine belastbare Brücke für Compliance verwandeln

Elenas Präsentation vor dem Leitungsorgan war erfolgreich, weil sie nicht drei voneinander getrennte Compliance-Projekte präsentierte. Sie präsentierte ein kontrolliertes, nachweisbasiertes Betriebsmodell auf Basis von ISO/IEC 27001:2022 – mit der SoA als Brücke zwischen Regulierung, Risiko, Maßnahmenumsetzung, Nachweisen und Managementaufsicht.

NIS2 und DORA machen ISO 27001 nicht obsolet. Sie machen eine gut aufgebaute ISO 27001-Erklärung zur Anwendbarkeit wertvoller. Die SoA kann der zentrale Ort werden, an dem Ihre Organisation erklärt, warum Maßnahmen bestehen, warum Ausschlüsse vertretbar sind, wie Nachweise aufbewahrt werden, wie Lieferanten gesteuert werden, wie Vorfälle eskaliert werden und wie das Management weiß, dass das ISMS funktioniert.

Ihre unmittelbare Maßnahme ist einfach:

1. Öffnen Sie Ihre aktuelle SoA.
2. Wählen Sie fünf als anwendbar markierte Maßnahmen aus und fragen Sie: „Welches Risiko, welche Verpflichtung oder welcher Vertrag begründet dies?“
3. Wählen Sie fünf Ausschlüsse aus und fragen Sie: „Wäre dies für einen NIS2-, DORA-, GDPR- oder ISO/IEC 27001:2022-Auditor weiterhin nachvollziehbar?“
4. Prüfen Sie, ob jede anwendbare Maßnahme aktuelle Nachweise hat.
5. Bestätigen Sie, dass das Management Restrisiken und SoA-Entscheidungen genehmigt hat.
6. Aktualisieren Sie Compliance-Register, Risikoregister und SoA, wenn sich Services, Lieferanten, Kunden, Vorschriften oder Vorfälle ändern.

Clarysec unterstützt Organisationen dabei mit dem Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, Richtliniensätzen für Unternehmen und KMU, Werkzeugen für Risikoregister, SoA-Vorlagen, Auditvorbereitung und Cross-Compliance-Zuordnung für NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 und Customer Assurance.

Wenn Ihre SoA nicht beantworten kann, warum eine Maßnahme besteht, wem sie gehört, welcher Nachweis sie belegt und welche Verpflichtung sie unterstützt, ist sie noch nicht bereit. Nutzen Sie Clarysec, um sie in eine auditbereite Brücke für Compliance zu verwandeln, bevor eine Aufsichtsbehörde, ein Auditor oder ein Kunde diese Fragen zuerst stellt.