ISO 27001-ISMS-Geltungsbereich für NIS2, DORA und GDPR

Maria, CISO eines schnell wachsenden europäischen Fintechs, war überzeugt, dass das ISO 27001-Überwachungsaudit unter Kontrolle war.

Das Zertifikat war neu. Die Anwendbarkeitserklärung wirkte ausgereift. Die Geltungsbereichserklärung umfasste „das unternehmensweite Informationssicherheitsmanagementsystem zur Unterstützung des Betriebs der SaaS-Plattform“. Die produktive Cloud-Umgebung war dokumentiert. Das Incident-Response-Verfahren existierte. Das Risikoregister enthielt Verantwortliche, Termine und Bewertungen des Restrisikos.

Dann stellte der Auditor eine einfache Frage:

„Welche Teile dieser SaaS-Plattform liegen auch im Geltungsbereich der NIS2-Registrierung, welche ausgelagerten Dienstleistungen unterstützen kritische oder wichtige Funktionen nach DORA für Ihre Finanzkunden, und wo genau werden personenbezogene Daten im Sinne der GDPR verarbeitet?“

Im Raum wurde es still.

Die Rechtsabteilung öffnete eine Tabelle mit regulatorischen Verpflichtungen. Das Produktmanagement öffnete ein Architekturdiagramm. Der Datenschutzbeauftragte öffnete das Verzeichnis von Verarbeitungstätigkeiten. Der Einkauf öffnete die Lieferantenliste. Der Betrieb öffnete den Disaster-Recovery-Plan. Nichts davon passte zusammen.

Der ISMS-Geltungsbereich sagte „SaaS-Plattform“. Die NIS2-Bewertung identifizierte digitale Infrastrukturdienste in mehreren Mitgliedstaaten. Kundenverträge beschrieben die Plattform als Unterstützung regulierter Finanzprozesse. Die GDPR-Aufzeichnungen umfassten Identitätsdaten, Telemetriedaten, IP-Adressen, Zahlungsmetadaten, Support-Tickets und ausgelagerte Analysedienste. Der Disaster-Recovery-Plan deckte die Produktion ab, nicht jedoch die Kundensupport-Plattform, die für die Kommunikation bei Datenschutzverletzungen genutzt wurde. Die Lieferanten-Due-Diligence deckte den Hosting-Anbieter ab, nicht jedoch den Managed-Detection-Service, der mit Produktionsprotokollen verbunden war.

Das ist das ISMS-Scoping-Problem des Jahres 2026. Eine ISO 27001-Zertifizierung bleibt wertvoll, doch ein enger „minimal tragfähiger Geltungsbereich“ kann zu einer Haftungs- und Steuerungslücke werden, wenn Aufsichtsbehörden, Kunden und Auditoren erwarten, dass dasselbe Managementsystem wesentliche Dienste nach NIS2, kritische oder wichtige Funktionen nach DORA und Verarbeitungsgrenzen nach GDPR erklären kann.

Für ISO/IEC 27001:2022, NIS2, DORA und GDPR ist ein schwacher Geltungsbereich kein administrativer Mangel. Er ist der erste Dominostein. Ist der Geltungsbereich falsch, ist die Risikobeurteilung unvollständig, die Anwendbarkeitserklärung irreführend, Lieferantenkontrollen erfassen kritische Anbieter nicht, Meldefristen für Vorfälle werden unsicher, und die Verantwortlichkeit im Datenschutz zerfällt zwischen Teams.

Warum der ISO 27001-ISMS-Geltungsbereich heute eine regulatorische Grenze ist

ISO/IEC 27001:2022 Abschnitt 4.3 verlangt, dass eine Organisation die Grenzen und die Anwendbarkeit des ISMS bestimmt und dabei interne und externe Themen, Anforderungen interessierter Parteien sowie Schnittstellen und Abhängigkeiten zu anderen Organisationen berücksichtigt ISO/IEC 27001:2022.

Diese Formulierung ist 2026 wichtiger als in früheren Zertifizierungszyklen. NIS2, DORA, GDPR, Cloud-Outsourcing, Kundenverträge, konzernweite Technologiedienste und Managed Service Provider sind keine Randnotizen. Sie sind Eingangsgrößen für die ISMS-Grenze.

NIS2 erhöht die Governance-Anforderungen für wesentliche und wichtige Einrichtungen. Leitungsorgane müssen Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und Schulungen erhalten. NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Incident-Management, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sicherer Beschaffung und Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management und, soweit angemessen, Multifaktor-Authentifizierung.

DORA verändert die Geltungsbereichsdiskussion für Finanzunternehmen. DORA gilt seit dem 17. Januar 2025 und legt einheitliche Anforderungen an das Management von IKT-Risiken, die Meldung IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, Informationsaustausch und das Management von IKT-Drittparteirisiken fest. DORA Article 6 verlangt ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken. DORA Article 8 verlangt die Identifizierung, Klassifizierung und Dokumentation IKT-unterstützter Geschäftsfunktionen, Informations-Assets und IKT-Assets einschließlich Abhängigkeiten. DORA Article 28 verlangt das Management von IKT-Drittparteirisiken.

GDPR ergänzt die Achse personenbezogener Daten. Sie gilt für automatisierte oder strukturierte Verarbeitung personenbezogener Daten, einschließlich der Verarbeitung durch EU-Niederlassungen sowie durch bestimmte nicht in der EU ansässige Verantwortliche oder Auftragsverarbeiter, die Personen in der Union Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten. GDPR Article 30 verlangt ein Verzeichnis von Verarbeitungstätigkeiten, Article 32 verlangt die Sicherheit der Verarbeitung, und Article 33 legt Erwartungen an die Meldung von Datenschutzverletzungen fest.

Ein belastbarer ISMS-Geltungsbereich wird daher nicht um Abteilungen herum formuliert. Er wird entlang regulierter Dienste, kritischer oder wichtiger Funktionen, Verarbeitung personenbezogener Daten, unterstützender Assets und Abhängigkeiten von Drittparteien definiert.

Der Fehler: ISO 27001, NIS2, DORA und GDPR als getrennte Programme behandeln

In vielen Organisationen zeigt sich ein typisches Muster:

• Security entwirft den ISO 27001-Geltungsbereich.
• Legal bewertet die Anwendbarkeit von NIS2.
• Risiko oder Compliance verwaltet DORA-Verpflichtungen.
• Privacy pflegt das GDPR-Verzeichnis von Verarbeitungstätigkeiten.
• Der Einkauf verantwortet die Lieferantenliste.
• Der Betrieb verantwortet Business Continuity und Disaster Recovery.

Jedes Team kann dabei solide Arbeit leisten. Das Problem ist, dass regulierte Realität quer durch alle diese Bereiche verläuft.

Ein in der Cloud gehosteter Kundenidentitätsdienst kann gleichzeitig die NIS2-Diensterbringung, DORA-regulierte Kundenprozesse und die Verarbeitung personenbezogener Daten nach GDPR unterstützen. Ein Managed-Detection-Anbieter kann Sicherheitslieferant, Incident-Response-Abhängigkeit, Auftragsverarbeiter oder Unterauftragsverarbeiter von Protokolldaten und eine zentrale Eingangsquelle für regulatorische Meldeentscheidungen sein. Eine Support-Plattform kann als „Nicht-Produktion“ gelten und dennoch Kommunikation zu Datenschutzverletzungen sowie Kundenanfragen nach Nachweisen verarbeiten.

Das ISMS ist der beste Ort, um diese Verpflichtungen zusammenzuführen, weil ISO 27001 eine disziplinierte Frage erzwingt: Was liegt innerhalb der Grenze, was liegt außerhalb, und warum?

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt dies in der Phase ISMS Foundation & Leadership, Schritt 2: Anforderungen interessierter Parteien und ISMS-Geltungsbereich:

„Sobald der Kontext verstanden und die Anforderungen der Interessenträger identifiziert sind, verlangt Clause 4.3, dass Sie die Grenzen und die Anwendbarkeit des ISMS bestimmen, um dessen Geltungsbereich festzulegen. Der ISMS-Geltungsbereich ist eine zentrale Definition, die festlegt, was unter Ihr Sicherheitsmanagementprogramm fällt und was nicht.“

Der Zenith Blueprint hebt außerdem einen Punkt hervor, der in vielen Geltungsbereichserklärungen weiterhin fehlt:

„Wenn Sie Ihre IT-Infrastruktur an einen Cloud-Anbieter auslagern, wird sie dadurch nicht aus dem Geltungsbereich ausgeschlossen; vielmehr beziehen Sie das Management dieser Beziehung und die Cloud-Assets als Teil des Geltungsbereichs ein.“

Outsourcing verlagert die Ausführung. Es beseitigt nicht die Rechenschaftspflicht.

Das Vier-Grenzen-Modell für den ISO 27001-Geltungsbereich 2026

Für Organisationen, die von NIS2, DORA und GDPR betroffen sind, empfiehlt Clarysec, den ISO 27001-ISMS-Geltungsbereich über vier miteinander verbundene Grenzen zu definieren.

Eine schwache Geltungsbereichserklärung sagt lediglich „die SaaS-Plattform“. Eine stärkere Erklärung benennt, welche Geschäftsdienste, Systeme, Umgebungen, Standorte, Datenverarbeitungstätigkeiten, Personengruppen, Lieferantenbeziehungen und Managementprozesse einbezogen sind.

Eine belastbarere Fassung könnte lauten:

„Das ISMS umfasst Governance, Risikomanagement, Betrieb und kontinuierliche Verbesserung der Informationssicherheit für die EU-SaaS-Plattform des Unternehmens für Zahlungsanalysen, einschließlich produktiver und nicht produktiver Cloud-Umgebungen, Kundenidentitätsdienste, administrativer Schnittstellen, Support-Aktivitäten, Protokollierungs- und Überwachungsplattformen, Incident Response, Aufrechterhaltung des Geschäftsbetriebs, Lieferantenmanagement und sämtlicher Verarbeitungstätigkeiten für personenbezogene Daten, die den Service unterstützen. Das ISMS umfasst das Management des ausgelagerten Cloud-Hostings, von Managed Detection und von Kundensupport-Werkzeugen, die für Leistungserbringung, Resilienz, Sicherheitsüberwachung oder GDPR-bezogene Kommunikation genutzt werden.“

Dieser Geltungsbereich ist nicht nur länger. Er ist besser auditierbar, weil er Services, Assets, Verarbeitung und Abhängigkeiten verbindet.

Wie Clarysec-Richtlinien den Geltungsbereich in Governance-Sprache übersetzen

Der Geltungsbereich darf nicht nur in einem Einzeldokument stehen. Er muss mit Informationssicherheitsleitlinie, rechtlicher und regulatorischer Compliance, Risikomanagement, Datenschutz, Lieferanten-Governance, Auditkriterien und Kontinuitätsplanung abgestimmt sein.

Die Enterprise-Informationssicherheitsleitlinie Informationssicherheitsleitlinie verhindert Unklarheiten bei Ausschlüssen:

„Alle Ausschlüsse oder Einschränkungen dieses Geltungsbereichs müssen in der ISMS-Geltungsbereichserklärung dokumentiert und mit formaler Genehmigung der obersten Leitung begründet werden.“

Diese Klausel ist relevant, wenn ein Geschäftsbereich argumentiert, dass Kundensupport außerhalb der Plattform liegt, obwohl Support-Mitarbeitende auf Kundenkennungen zugreifen und Kommunikation zu Datenschutzverletzungen bearbeiten. Ein Ausschluss ist nur möglich, wenn er dokumentiert, begründet und genehmigt ist.

Die Enterprise-Richtlinie zur rechtlichen und regulatorischen Compliance Richtlinie zur rechtlichen und regulatorischen Compliance macht die rechtliche Zuordnung operational:

„Alle gesetzlichen und regulatorischen Verpflichtungen müssen konkreten Richtlinien, Kontrollen und Verantwortlichen innerhalb des Informationssicherheitsmanagementsystems (ISMS) zugeordnet werden.“

Das ist die Brücke zwischen rechtlicher Anwendbarkeit und Anwendbarkeitserklärung. NIS2 Article 21 darf nicht in einem Rechtsvermerk verbleiben. DORA-Verpflichtungen zu IKT-Drittparteien dürfen nicht nur in Beschaffungsleitlinien stehen. Verpflichtungen aus GDPR Article 30 und Article 32 dürfen nicht nur im Datenschutzregister liegen. Sie benötigen zugeordnete Verantwortliche, Kontrollen und Nachweise.

Die Enterprise-Risikomanagement-Richtlinie Risikomanagement-Richtlinie erweitert den Geltungsbereich auf Dritte:

„Diese Richtlinie gilt für alle Organisationseinheiten, Geschäftsprozesse, Systeme, Mitarbeitenden und Drittparteienbeziehungen, die an der Handhabung, Entwicklung, Speicherung oder Verwaltung von Informations-Assets beteiligt sind.“

Diese Formulierung steht im Einklang mit der NIS2-Sicherheit der Lieferkette, DORA-IKT-Drittparteirisiken und der Rechenschaftspflicht von Verantwortlichen oder Auftragsverarbeitern nach GDPR.

Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre Richtlinie zu Datenschutz und Privatsphäre verankert den Datenschutzgeltungsbereich an der Verarbeitung:

„Diese Richtlinie gilt für alle Organisationseinheiten, Mitarbeitenden und Systeme, die an der Verarbeitung personenbezogener Informationen (PII) beteiligt sind, einschließlich:“

Das Prinzip ist entscheidend. Wenn ein System PII verarbeitet, kann es für das ISMS nicht unsichtbar sein, nur weil es „nur Support“, „Nicht-Produktion“ oder „marketingeigen“ ist.

Die Enterprise-Richtlinie zur Aufrechterhaltung des Geschäftsbetriebs und Disaster Recovery Richtlinie zur Aufrechterhaltung des Geschäftsbetriebs und Disaster Recovery verknüpft den Geltungsbereich mit BIA-Ergebnissen:

„Diese Richtlinie gilt für alle Organisationseinheiten, Informationssysteme, Geschäftsprozesse, Mitarbeitenden und Drittparteidienste, die auf Grundlage der Ergebnisse der Business Impact Analysis (BIA) als kritisch oder wesentlich klassifiziert wurden.“

Diese Klausel passt unmittelbar zu kritischen oder wichtigen Funktionen nach DORA und zur Servicekontinuität nach NIS2.

Für kleinere Organisationen halten Clarysecs SME-Richtlinien die Formulierung knapp und bewahren dieselbe Logik. Die SME-Richtlinie zur Audit- und Compliance-Überwachung SME-Richtlinie zur Audit- und Compliance-Überwachung definiert die Auditabdeckung als:

„Alle Kontrollen und Systeme innerhalb des Geltungsbereichs des Informationssicherheitsmanagementsystems (ISMS)“

Die SME-Richtlinie zu Datenschutz und Privatsphäre SME-Richtlinie zu Datenschutz und Privatsphäre definiert den Datenschutzgeltungsbereich als:

„Jedes System, jede Anwendung oder jeder Standort, in dem personenbezogene Daten gespeichert oder übertragen werden“

Die SME-Risikomanagement-Richtlinie SME-Risikomanagement-Richtlinie hält ausgelagerte Dienste sichtbar:

„Alle Informationen, Dienste und Assets, die intern oder durch Dritte verwaltet werden“

Kurze Klauseln wie diese sind wirksam, weil sie verhindern, dass eine Zertifizierungsgrenze regulierte Daten, Cloud-Services oder von Lieferanten verwaltete Assets ausschließt.

Das Asset-Inventar macht den Geltungsbereich real

Eine Geltungsbereichserklärung ist nur glaubwürdig, wenn sie auf Assets, Verantwortliche, Lieferanten, Datenflüsse und Nachweise zurückgeführt werden kann.

Der Zenith Blueprint weist Organisationen in der Risikomanagementphase, Schritt 9: Assets, Bedrohungen und Schwachstellen identifizieren, an, Assets im ISMS-Geltungsbereich aufzulisten und Verantwortliche, Standort und Klassifizierung zu erfassen. Er gibt ein praktisches Beispiel:

„Kundendatenbank – im Eigentum der IT-Abteilung – gehostet auf AWS – enthält personenbezogene und Finanzdaten (hohe Sensitivität).“

Derselbe Schritt ergänzt einen Scoping-Hinweis, der unmittelbar für NIS2 und GDPR relevant ist:

„Stellen Sie sicher, dass Assets mit personenbezogenen Daten gekennzeichnet werden (für GDPR-Relevanz) und kritische Service-Assets vermerkt sind (für eine mögliche NIS2-Anwendbarkeit, wenn Sie in einem regulierten Sektor tätig sind).“

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt ISO/IEC 27002:2022 Maßnahme 5.9, Inventory of information and other associated assets, als grundlegende Cross-Compliance-Kontrolle. Die Attribute klassifizieren die Kontrolle als präventiv, unterstützend für Vertraulichkeit, Integrität und Verfügbarkeit, ausgerichtet am Cybersicherheitskonzept Identify, an der operativen Fähigkeit Asset-Management sowie an den Domänen Governance, Ökosystem und Schutz.

Zenith Controls erklärt die Relevanz für GDPR und NIS2 klar:

„Ohne ein genaues und aktuelles Asset-Inventar können Organisationen angemessene Schutzmaßnahmen weder bewerten noch umsetzen.“

Für NIS2 unterstützt das Asset-Inventar die Identifizierung kritischer Systeme und Komponenten, die wesentliche oder wichtige Dienste tragen. Für DORA macht DORA Article 8 die Identifizierung von IKT-Assets und Informations-Assets zu einem Kern der operationalen Resilienz. Für GDPR unterstützt das Asset-Inventar die Datenflussabbildung, die Qualität des RoPA und die Reaktion auf Datenschutzverletzungen.

Unterstützende ISO-Standards bekräftigen dieselbe Logik. ISO/IEC 27005:2024 stärkt die Asset-Identifizierung in der Informationssicherheitsrisikobeurteilung. ISO 22301:2019 unterstützt die Identifizierung von Ressourcen, die für die Aufrechterhaltung des Geschäftsbetriebs benötigt werden. ISO/IEC 19770-1:2017 unterstützt den Reifegrad des IT-Asset-Managements. ISO/IEC 27017:2015 und ISO/IEC 27018:2019 unterstützen Cloud-spezifische Kontrollen und den Schutz von PII in öffentlichen Clouds. ISO/IEC 27701:2019 erweitert das Management von Datenschutzinformationen. ISO/IEC 29100:2011 trägt Datenschutzgrundsätze wie Transparenz, Minimierung und Sicherheitsmaßnahmen bei.

Eine praktische Scoping-Übung für SaaS- und Fintech-Teams

Beginnen Sie mit einem regulierten Dienst, nicht mit dem gesamten Unternehmen. Beispiel: „EU-Zahlungsanalyse-SaaS für Finanzinstitute“.

Erstellen Sie anschließend eine Service-Asset-Verarbeitungs-Zuordnung.

Ein detaillierteres Asset-Beispiel könnte so aussehen.

Nutzen Sie anschließend Zenith Blueprint Schritt 13: Risikobehandlungsplanung und Anwendbarkeitserklärung. Der Leitfaden weist Nutzer an, die Anwendbarkeitserklärung mithilfe der Vorlage zu erstellen, die alle Annex A-Kontrollen auflistet, und die Anwendbarkeit auf Grundlage der Risikobehandlung, gesetzlicher oder vertraglicher Anforderungen, Geltungsbereichsrelevanz und des Organisationskontexts zu entscheiden. Er formuliert:

„Entscheiden Sie für jede Kontrolle (Zeile) im SoA-Blatt, ob sie auf Ihr ISMS anwendbar ist.“

Für das obige Beispiel sollte die Anwendbarkeitserklärung Kontrollen für Lieferantensicherheit, Cloud-Services, Vorfallmanagement, Kontinuität, gesetzliche und regulatorische Anforderungen, Datenschutz, Schwachstellenmanagement, Backups, Protokollierung, Überwachung, Kryptografie, sichere Entwicklung, Sicherheitsprüfung und Änderungsmanagement berücksichtigen.

Ein praktischer Ablauf ist:

1. Erstellen Sie im Risikoregister und SoA Builder einen Reiter „ISMS Scope Mapping“.
2. Fügen Sie eine Zeile je reguliertem Dienst oder je Produktlinie hinzu.
3. Verknüpfen Sie jeden Dienst mit Assets, Datentypen, Lieferanten, Standorten und Geschäftsverantwortlichen.
4. Kennzeichnen Sie NIS2-Relevanz, DORA-Relevanz und GDPR-Verarbeitungsrelevanz.
5. Ergänzen Sie Risikoszenarien für Nichtverfügbarkeit des Dienstes, Datenschutzverletzung, Lieferantenausfall, Cloud-Fehlkonfiguration, kritische Schwachstelle und Fehler bei der Vorfallmeldung.
6. Wählen Sie SoA-Kontrollen auf Grundlage dieser Risiken und Verpflichtungen aus.
7. Dokumentieren Sie Ausschlüsse, kompensierende Kontrollen und Risikoakzeptanz.
8. Holen Sie die Genehmigung der obersten Leitung für die finalen Grenzen und Ausschlüsse ein.
9. Überführen Sie die finale Grenze in internes Audit, Managementbewertung und Lieferantenüberwachung.

Das Ergebnis ist nicht nur eine bessere Geltungsbereichserklärung. Es ist eine belastbare Kette vom regulierten Dienst zu Asset, Lieferant, Daten, Kontrolle, Verantwortlichem und Nachweis.

Cross-Compliance-Zuordnung: ein Geltungsbereich, viele Verpflichtungen

Ein sauber abgegrenztes ISO 27001-ISMS wird zur Betriebsebene, auf der Anforderungen aus NIS2, DORA, GDPR, NIST CSF und COBIT miteinander in Einklang gebracht werden können.

Für ISO/IEC 27002:2022 Maßnahme 5.31, Legal, statutory, regulatory and contractual requirements, verknüpft Zenith Controls Compliance-Verpflichtungen mit Datenschutz, PII-Schutz, Aufbewahrung von Aufzeichnungen, unabhängiger Überprüfung und interner Richtlinieneinhaltung. Dies lässt sich unmittelbar auf GDPR-Rechenschaftspflicht, NIS2-Compliance in der Lieferkette, DORA-Management von IKT-Risiken und Compliance, NIST CSF-Governance sowie COBIT 2019-Überwachung externer Anforderungen abbilden.

Für ISO/IEC 27002:2022 Maßnahme 5.34, Privacy and protection of PII, verbindet Zenith Controls Datenschutz mit Asset-Inventar, Cloud-Services, Klassifizierung, Informationsübertragung, Zugriffskontrolle, Identitätsmanagement und Prüfungen von Projektänderungen. Die GDPR-Zuordnung deckt Sicherheit der Verarbeitung und Datenschutz durch Technikgestaltung ab. Die DORA-Zuordnung unterstützt Datenintegrität, Sicherheit und Vertraulichkeit, einschließlich personenbezogener Daten, die in IKT-Diensten verarbeitet werden.

Das Prinzip ist einfach: Erstellen Sie nicht vier voneinander getrennte Compliance-Programme. Schaffen Sie ein ISMS mit klar definiertem Geltungsbereich, das erklären kann, wie Verpflichtungen erfüllt, nachgewiesen und auditiert werden.

Geltungsbereich der Vorfallmeldung: wo Grenzen regulatorische Fristen beeinflussen

Ein falscher Geltungsbereich wird bei Vorfällen schmerzhaft sichtbar.

NIS2 Article 23 verlangt eine gestufte Meldung erheblicher Vorfälle, einschließlich einer Frühwarnung innerhalb von 24 Stunden, einer Vorfallmeldung innerhalb von 72 Stunden, Zwischenberichten auf Anforderung und eines Abschlussberichts innerhalb eines Monats. Auch eine Kommunikation an betroffene Empfänger kann erforderlich sein.

DORA verlangt von Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle anhand von Kriterien wie betroffenen Kunden oder Gegenparteien, Dauer, Ausfallzeit, geografischer Ausbreitung, Datenverlusten, Kritikalität der betroffenen Dienste und wirtschaftlicher Auswirkung zu erkennen, zu steuern, zu klassifizieren und zu melden. Kunden müssen unverzüglich informiert werden, wenn ein schwerwiegender IKT-Vorfall ihre finanziellen Interessen beeinträchtigt.

Die Meldung einer Verletzung personenbezogener Daten nach GDPR hängt davon ab, ob eine Verletzung zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung personenbezogener Daten oder zum unbefugten Zugriff darauf führt.

Wenn Support-Plattform, Protokollumgebung, Identitätsdienst, Kundenbenachrichtigungskanal oder Managed-Detection-Anbieter außerhalb des ISMS-Geltungsbereichs liegen, wissen Incident-Teams möglicherweise nicht, ob ein Ereignis NIS2, DORA, GDPR, Kundenvertragsmeldungen oder alle zusammen auslöst. Diese Unsicherheit verbraucht Meldefristen.

Ein ausgereifter Geltungsbereich umfasst vorfallsrelevante Abhängigkeiten: Erkennungswerkzeuge, Protokollspeicher, forensische Repositories, Kundenkommunikationskanäle, Support-Werkzeuge, Backup-Umgebungen, Incident Bridges und Lieferanten, die an Triage oder Wiederherstellung beteiligt sind.

Wie Auditoren und Aufsichtsbehörden Ihren ISMS-Geltungsbereich prüfen werden

Ein starker Geltungsbereich hält Stichproben stand. Ein schwacher Geltungsbereich bricht zusammen, wenn Auditoren Dokumente mit der Realität vergleichen.

Zenith Controls liefert nützliche Auditerwartungen für ISO/IEC 27002:2022 Maßnahme 5.9. Auditoren nach ISO/IEC 19011-Stil fordern das Inventar frühzeitig an, um andere Bewertungen abzugrenzen und physische, Software- und Cloud-Assets stichprobenartig zu prüfen. Auditoren nach ISO/IEC 27007-Stil fragen, wie und wann das Inventar aktualisiert wird, und suchen nach Verknüpfungen zu Beschaffung, Änderungsmanagement und Außerbetriebnahme. Auditoren nach NIST SP 800-53A-Stil verifizieren, dass Inventardetails Asset-Typ, Verantwortlichen, Standort, Netzwerkadresse soweit anwendbar und Status enthalten und dass Cloud-, virtuelle und mobile Assets einbezogen sind.

Für Maßnahme 5.31 weist Zenith Controls darauf hin, dass Zertifizierungsauditoren ein Compliance-Register oder eine Liste von Gesetzen und Verträgen erwarten, die in der Anwendbarkeitserklärung und in Risikobehandlungsplänen referenziert wird. COBIT-Auditoren achten auf Verantwortliche für Compliance, Bewertungen und Berichterstattung an die obere Führungsebene. ISACA ITAF-Auditoren nehmen Nachweise stichprobenartig, um zu bestätigen, dass die Organisation ihre Verpflichtungen nicht nur kennt, sondern aktiv sicherstellt, dass sie erfüllt werden.

Für Maßnahme 5.34 prüfen Auditoren Datenschutzrichtlinien, Dateninventare, DPIAs, Schulungsnachweise, Verschlüsselungsnachweise, Zugriffskontrollen, DSAR-Stichproben, Nachweise für Datenschutz durch Technikgestaltung und Vorfallsaufzeichnungen mit PII-Bezug. Eine Geltungsbereichserklärung, die ein System ausschließt, das personenbezogene Daten verarbeitet, wird schnell infrage gestellt.

Die Frage des Leitungsorgans: Was darf nicht ausgeschlossen werden?

Die oberste Leitung fragt häufig, ob ein Geschäftsbereich, Standort, Lieferant oder System außerhalb des ISMS-Geltungsbereichs bleiben kann. Manchmal lautet die Antwort ja. Aber nicht, wenn der Ausschluss verhindert, dass die Organisation gesetzliche, regulatorische, vertragliche oder servicebezogene Sicherheitsverpflichtungen erfüllt.

Nutzen Sie diesen Ausschlusstest, bevor Sie eine Begrenzung des Geltungsbereichs genehmigen:

• Unterstützt die Einheit, das System oder der Lieferant einen NIS2-regulierten Dienst?
• Unterstützt es eine kritische oder wichtige Funktion nach DORA für die Organisation oder ihre regulierten Kunden?
• Erhebt, speichert, überträgt, protokolliert, unterstützt oder löscht es personenbezogene Daten?
• Stellt es Sicherheitsüberwachung, Identität, Backup, Incident Response oder Wiederherstellung für einen Service im Geltungsbereich bereit?
• Liefert es Nachweise, die für die Vorfallklassifizierung oder regulatorische Meldung benötigt werden?
• Verlangt ein Kundenvertrag, dass es vom ISMS abgedeckt ist?
• Würde seine Kompromittierung Vertraulichkeit, Integrität, Verfügbarkeit, rechtliche Compliance oder Servicekontinuität innerhalb des erklärten Geltungsbereichs beeinträchtigen?

Wenn die Antwort ja lautet, braucht der Ausschluss starke Nachweise, kompensierende Governance, Risikoakzeptanz und formale Genehmigung durch die oberste Leitung. In vielen Fällen sollte er nicht ausgeschlossen werden.

Ein moderner ISO 27001-ISMS-Geltungsbereich sollte umfassen:

1. Abgedeckte Geschäftsdienste und Produktlinien.
2. Abgedeckte Rechtsträger, Organisationseinheiten und Standorte.
3. Kundensegmente und Rechtsräume, die Verpflichtungen auslösen.
4. Kritische oder wichtige Funktionen und BIA-basierte wesentliche Dienste.
5. Informations-Assets, IKT-Assets und Cloud-Umgebungen.
6. Verarbeitungstätigkeiten für personenbezogene Daten und PII-Repositories.
7. Entwicklungs-, Test-, Support-, Überwachungs- und Vorfallprozesse.
8. Lieferanten und ausgelagerte Dienstleistungen, die Services im Geltungsbereich unterstützen.
9. Schnittstellen und Abhängigkeiten zu Konzerngesellschaften oder externen Anbietern.
10. Ausdrückliche Ausschlüsse mit Begründung, Risikoakzeptanz und Genehmigung durch die oberste Leitung.

So wird der ISO 27001-Geltungsbereich zu einer Governance-Position auf Ebene des Leitungsorgans, nicht zu einer Abkürzung für die Zertifizierung.

Machen Sie Ihren ISMS-Geltungsbereich auditbereit, bevor der Auditor ihn für Sie definiert

Der schlechteste Zeitpunkt, ein Geltungsbereichsproblem zu entdecken, ist während der Zertifizierung, einer aufsichtlichen Prüfung, der Kunden-Due-Diligence oder eines laufenden Vorfalls.

Ein enges Zertifikat kann ein Beschaffungs-Kontrollkästchen erfüllen, hält jedoch keiner ernsthaften Prüfung stand, wenn es die Services, IKT-Funktionen, Lieferanten und Verarbeitung personenbezogener Daten ausschließt, die regulatorische Exponierung erzeugen. Im Jahr 2026 werden die Organisationen Audits souverän bestehen, die eine konsistente Zuordnung vom regulierten Dienst zu Asset, Lieferant, personenbezogenen Daten, Kontrolle, Verantwortlichem und Nachweis zeigen können.

Beginnen Sie mit drei konkreten Maßnahmen:

1. Nutzen Sie den Zenith Blueprint Zenith Blueprint, Phase: ISMS Foundation & Leadership, Schritt 2, um Ihren ISMS-Geltungsbereich entlang von Services, Funktionen, Verarbeitung und Abhängigkeiten neu zu formulieren.
2. Nutzen Sie Zenith Controls Zenith Controls, um Asset-Inventar, gesetzliche Verpflichtungen und PII-Schutz über die Auditerwartungen aus ISO 27001, NIS2, DORA, GDPR, NIST und COBIT 2019 hinweg zuzuordnen.
3. Stimmen Sie den Richtliniengeltungsbereich mithilfe von Clarysecs Informationssicherheitsleitlinie Informationssicherheitsleitlinie, Richtlinie zur rechtlichen und regulatorischen Compliance Richtlinie zur rechtlichen und regulatorischen Compliance, Risikomanagement-Richtlinie Risikomanagement-Richtlinie, Richtlinie zu Datenschutz und Privatsphäre Richtlinie zu Datenschutz und Privatsphäre und Richtlinie zur Aufrechterhaltung des Geschäftsbetriebs und Disaster Recovery Richtlinie zur Aufrechterhaltung des Geschäftsbetriebs und Disaster Recovery ab.

Wenn Ihr aktueller ISMS-Geltungsbereich noch wie eine Abteilungsbezeichnung klingt, bauen Sie ihn als Compliance-Grenze neu auf. Laden Sie die Clarysec-Toolkits herunter, ordnen Sie einen regulierten Dienst Ende-zu-Ende zu, und machen Sie Ihren ISO 27001-Geltungsbereich zu auditbereiten Nachweisen für NIS2, DORA und GDPR.