¶ Geltungsbereich und relevante Dienste
Zweck: Diese Seite beschreibt, wie eine als besonders wichtig oder wichtig eingestufte Einrichtung ihren NIS2-Geltungsbereich nachvollziehbar festlegt. Der Scope verbindet die gesetzlich erfasste Tätigkeit mit den tatsächlich dafür genutzten Diensten, Prozessen, Netz- und Informationssystemen sowie internen und externen Abhängigkeiten.
Muster und Aussagegrenze: Die Seite bestätigt weder eine NIS2-Betroffenheit noch einen realen Unternehmens-Scope. Organisationsbezogene Einträge, Freigaben und technische Detailnachweise sind ausstehend.
Grundsatz: Der Geltungsbereich darf weder pauschal mit der gesamten Unternehmens-IT gleichgesetzt noch aus Bequemlichkeit auf wenige Produktionssysteme begrenzt werden. Entscheidend ist, was für die Erbringung der erfassten Dienste tatsächlich genutzt wird oder deren Sicherheit wesentlich beeinflusst.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-SCOPE-00-03 |
| Dokumentenart | Verfahren und Registerstruktur für den NIS2-Geltungsbereich |
| Wiki.js-Pfad | /NIS2/00-Start-und-Navigation/Geltungsbereich-und-relevante-Dienste |
| Verantwortlich | Geschäftsführung / NIS2-Koordination / Dienst- und Prozessverantwortliche |
| Fachlich geprüft durch | Recht/Compliance und Informationssicherheitsfunktion – ausstehend |
| Freigabe durch | Geschäftsführung – ausstehend |
| Status | Entwurf – keine realen Dienste, Systeme oder Ausschlüsse freigegeben |
| Version / Stand | 0.2 / 09.08.2026 |
| Schutzklasse | Intern; technische Detailinventare regelmäßig vertraulich oder höher |
| Rechtsbezug | Insbesondere §§ 28 bis 32 BSIG; Artikel 21 NIS-2-Richtlinie |
Relevante Dienste Ende-zu-Ende abgrenzen und alle notwendigen Abhängigkeiten nachvollziehbar einbeziehen. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Betroffenheit und Geltungsbereich sind zwei verschiedene Entscheidungen
Die Betroffenheits- und Einstufungsprüfung beantwortet, ob und aufgrund welcher Tätigkeit ein Rechtsträger erfasst ist. Die Scope-Festlegung beantwortet anschließend, welche Dienste, Prozesse, Systeme und Abhängigkeiten für diese Tätigkeit geschützt und gesteuert werden müssen.
| Entscheidung | Leitfrage | Typisches Ergebnis |
|---|---|---|
| Betroffenheit | Welcher Rechtsträger erfüllt welchen Tatbestand des § 28 oder § 29 BSIG? | Einstufung, Einrichtungsart und Rechtsgrundlage |
| Geltungsbereich | Welche Dienste und Ressourcen werden für die erfasste Tätigkeit genutzt? | freigegebenes Scope-Statement und Scope-Register |
| Risikomanagement | Welche Risiken bestehen im festgelegten Scope und welche Maßnahmen sind angemessen? | Risikoregister, Behandlungsplan und Maßnahmenstatus |
| Nachweisführung | Woran lässt sich Umsetzung und Wirksamkeit belegen? | kontrollierte Referenzen, Prüfungen, Tests und Berichte |
Eine ISO-27001-Zertifizierungsgrenze oder ein TISAX-Prüfscope kann als Ausgangspunkt dienen, ist aber nicht automatisch mit dem gesetzlichen NIS2-Geltungsbereich identisch. Abweichungen werden bewusst festgestellt und begründet.
¶ 2. Gesetzlicher Ausgangspunkt
§ 30 Absatz 1 BSIG bezieht die Risikomanagementpflichten auf die informationstechnischen Systeme, Komponenten und Prozesse, welche die Einrichtung für die Erbringung ihrer Dienste nutzt. Die Maßnahmen müssen geeignet, verhältnismäßig, wirksam und dokumentiert sein.
Daraus folgen für die Scope-Festlegung drei praktische Regeln:
- Dienstebezug: Ausgangspunkt ist nicht die Geräteliste, sondern die gesetzlich erfasste Tätigkeit und der daraus erbrachte Dienst.
- Ende-zu-Ende-Sicht: Direkte Leistungssysteme, Querschnittsdienste, manuelle Abläufe, externe Provider und Wiederanlaufmittel werden gemeinsam betrachtet.
- Nachweisbare Grenze: Jede Ein- oder Ausgrenzung benötigt Tatsachen, Verantwortlichkeit, Begründung und einen aktuellen technischen Bezug.
Für bestimmte digitale Einrichtungsarten – unter anderem DNS, TLD, Cloud, Rechenzentrum, CDN, MSP, MSSP, Online-Marktplätze, Online-Suchmaschinen, soziale Netzwerke und Vertrauensdienste – sind zusätzlich die vorrangigen technischen und methodischen Anforderungen der Durchführungsverordnung (EU) 2024/2690 zu prüfen.
¶ 3. Vier Ebenen des NIS2-Geltungsbereichs
Ein belastbarer Scope wird auf vier miteinander verbundenen Ebenen beschrieben.
| Ebene | Festzulegende Inhalte | Kernfrage |
|---|---|---|
| 1. Einrichtung | Rechtsträger, Einrichtungsart, Niederlassungen, organisatorische Einheiten und Beteiligungsbezug | Wer trägt die gesetzliche Verantwortung? |
| 2. Relevante Dienste | Leistung, Empfänger, Region, Betriebszeit, Verpflichtungen und Dienstgrenze | Welche erfasste Leistung wird erbracht? |
| 3. Prozesse und Ressourcen | Kern- und Unterstützungsprozesse, Informationen, Personal, Systeme, Standorte und Versorgung | Was ist für die Leistung erforderlich? |
| 4. Externe Abhängigkeiten | Cloud, Provider, Hersteller, Wartung, Logistik, Unterauftragnehmer und gemeinsame Plattformen | Welche Dritten oder Konzernleistungen sind Teil der Dienstekette? |
Die Ebenen werden nicht getrennt freigegeben. Ein Dienst ohne zugeordnete Systeme ist ebenso unvollständig wie ein Asset-Inventar ohne Dienstebezug.
¶ 4. Was ist ein relevanter Dienst?
Ein relevanter Dienst ist eine abgrenzbare Leistung, die der erfassten Einrichtungsart entspricht oder für deren Erbringung erforderlich ist. Die Beschreibung erfolgt aus Sicht der Empfänger und des Geschäftsergebnisses – nicht allein aus Sicht einer IT-Anwendung.
¶ Mindestbeschreibung
| Merkmal | Leitfrage |
|---|---|
| Dienst-ID und Bezeichnung | Wie wird die Leistung eindeutig referenziert? |
| Rechtsbezug | Welche Einrichtungsart, Anlage und Tätigkeit begründet die Relevanz? |
| Leistung und Ergebnis | Was wird tatsächlich bereitgestellt, betrieben, hergestellt oder ermöglicht? |
| Empfänger | Wer erhält oder nutzt den Dienst – Kunden, Partner, Öffentlichkeit oder interne Einheiten? |
| Region und Standorte | Wo wird der Dienst erbracht, betrieben oder technisch unterstützt? |
| Betriebszeit | Wann muss der Dienst verfügbar sein und welche Unterbrechungen sind zulässig? |
| Dienstgrenze | Wo beginnt und endet die eigene Verantwortung? |
| Owner | Wer verantwortet Leistung, Scope, Kritikalität und Änderungen? |
| Verpflichtungen | Welche gesetzlichen, behördlichen, vertraglichen oder internen Anforderungen gelten? |
Ein Produktname oder eine Abteilung ist noch kein hinreichend beschriebener Dienst. Ebenso wenig darf ein technisch klingender Begriff wie „ERP“ oder „Cloud“ die fachliche Leistungsbeschreibung ersetzen.
¶ 5. Top-down- und Bottom-up-Abgrenzung
Die Scope-Festlegung verwendet zwei Blickrichtungen, die am Ende übereinstimmen müssen.
¶ Top-down: vom Dienst zu seinen Abhängigkeiten
- erfasste Tätigkeit und relevanten Dienst beschreiben;
- fachliche Kernprozesse und Leistungsversprechen bestimmen;
- Unterstützungs-, Steuerungs-, Sicherheits-, Incident- und Notfallprozesse ergänzen;
- benötigte Informationen, Rollen, Systeme und Standorte zuordnen;
- Lieferanten, Konzernleistungen und Unterauftragnehmer einbeziehen;
- Ausfallfolgen, Mindestbetriebsniveau und Wiederanlaufziele festlegen.
¶ Bottom-up: vom Inventar zurück zum Dienst
- Anwendungen, Plattformen, Netze, Endpunkte und OT-Komponenten prüfen;
- Identitäts-, Verzeichnis-, DNS-, Zeit-, Zertifikats- und Kommunikationsdienste erfassen;
- Sicherheits-, Protokollierungs-, Monitoring-, Backup- und Wiederherstellungssysteme ergänzen;
- externe Verbindungen, Fernwartung, Cloud und Providerleistungen zuordnen;
- jedes Objekt mindestens einem Dienst, Prozess oder begründeten Querschnittszweck zuweisen;
- nicht zuordenbare, unbekannte oder verwaiste Objekte untersuchen.
Abweichungen zwischen beiden Sichten sind ein Qualitätsbefund. Sie können auf vergessene Abhängigkeiten, veraltete Inventare oder einen zu eng beschriebenen Dienst hinweisen.
¶ 6. Einbeziehungsregeln
Eine Ressource wird grundsätzlich in den Geltungsbereich aufgenommen, wenn mindestens eines der folgenden Kriterien zutrifft:
- sie verarbeitet, speichert oder überträgt Informationen des relevanten Dienstes;
- sie steuert, überwacht oder ermöglicht einen wesentlichen Prozessschritt;
- ihr Ausfall kann Verfügbarkeit, Integrität oder Vertraulichkeit des Dienstes erheblich beeinträchtigen;
- sie stellt Identitäten, Berechtigungen, Netzwerk, Kommunikation, Zeit, Schlüssel oder Zertifikate bereit;
- sie wird für Administration, Fernwartung, Protokollierung oder Angriffserkennung genutzt;
- sie ist für Backup, Wiederherstellung, Notbetrieb oder Krisenkommunikation erforderlich;
- sie verbindet den Dienst mit Kunden, Lieferanten, Partnern, Cloud- oder Konzernsystemen;
- eine Kompromittierung ermöglicht einen relevanten Angriffspfad in den Scope;
- sie ist notwendig, um Sicherheitsvorfälle zu erkennen, zu bewerten, einzudämmen oder zu melden.
¶ Häufig übersehene Querschnittsdienste
| Querschnitt | Warum regelmäßig relevant |
|---|---|
| Identitäts- und Verzeichnisdienste | steuern Benutzer-, Service- und Administrationszugriffe |
| Netzwerk, DNS und Zeitdienste | ermöglichen Kommunikation, Namensauflösung und verlässliche Protokollierung |
| E-Mail, Kollaboration und Notfallkommunikation | unterstützen Betrieb, Eskalation und Krisenreaktion |
| Backup und Wiederherstellung | bestimmen die tatsächliche Wiederanlauffähigkeit |
| Monitoring, SIEM und Alarmierung | ermöglichen Erkennung und Reaktion |
| Administrations- und Fernwartungswege | besitzen häufig weitreichende technische Berechtigungen |
| Softwareverteilung, Patch- und Schwachstellenwerkzeuge | beeinflussen Integrität und Sicherheitszustand zahlreicher Systeme |
| gemeinsame Cloud-, Virtualisierungs- und Speicherplattformen | bündeln Dienste und erzeugen Konzentrationsrisiken |
Ein Querschnittsdienst muss nicht vollständig einbezogen werden, wenn eine technisch und organisatorisch nachvollziehbare Teilabgrenzung möglich ist. Die verbleibenden gemeinsamen Abhängigkeiten bleiben jedoch sichtbar.
¶ 7. Outsourcing, Cloud und Lieferkette
Auslagerung verlagert die Leistungserbringung, beseitigt aber nicht die Verantwortung der Einrichtung für eine angemessene Risikosteuerung. Externe Ressourcen werden daher nicht mit der Begründung „liegt beim Provider“ ausgeschlossen.
Für externe Leistungen werden mindestens dokumentiert:
| Feldgruppe | Mindestinhalt |
|---|---|
| Leistung | bezogener Dienst, funktionale Grenze und betroffene NIS2-Dienste |
| Verantwortungsmodell | Aufgaben der Einrichtung, des Anbieters und gegebenenfalls des Unterauftragnehmers |
| Standorte und Regionen | Leistungserbringung, Datenverarbeitung, Support und Wiederherstellung |
| Zugänge | administrative, technische und Notfallzugänge einschließlich Freigabe und Überwachung |
| Abhängigkeiten | weitere Provider, Plattformen, Netze, Identitäten und gemeinsame Ressourcen |
| Sicherheit | Anforderungen, Nachweise, Meldewege, Schwachstellen- und Änderungsmanagement |
| Resilienz | Redundanz, Backup, Wiederherstellung, Notbetrieb, Exit und getestete Alternativen |
| Steuerung | Owner, Vertrag, Review, offene Risiken und Eskalation |
Berichte und Zertifikate des Anbieters sind wichtige Nachweise, ersetzen aber nicht die Bewertung des konkret bezogenen Dienstes, des eigenen Konfigurationsanteils und der Schnittstellen.
¶ 8. Standorte und physische Abhängigkeiten
Zum Scope gehören nicht nur Serverräume. Zu prüfen sind alle Orte und Versorgungsleistungen, die den relevanten Dienst ermöglichen oder wiederherstellen.
- Betriebs-, Produktions-, Logistik- und Verwaltungsstandorte;
- Rechenzentren, Colocation- und Cloud-Regionen;
- Leitstellen, Werkstätten, Labore und OT-Umgebungen;
- Homeoffice- und mobile Betriebsmodelle, soweit sie für den Dienst wesentlich sind;
- Ausweich-, Notbetriebs- und Wiederherstellungsstandorte;
- Energie, Klima, Zutritt, Kommunikation und technische Versorgung;
- gemeinsam genutzte Gebäude, Netze oder Sicherheitsdienste.
Die Aufnahme eines Standorts bedeutet nicht, dass jede dort vorhandene Ressource automatisch relevant ist. Umgekehrt darf ein externer oder selten genutzter Standort nicht ausgeschlossen werden, wenn er für Administration, Wiederherstellung oder Notbetrieb notwendig ist.
¶ 9. Ausschlüsse und Teilabgrenzungen
Ein Ausschluss ist nur belastbar, wenn die Ressource weder für den relevanten Dienst genutzt wird noch dessen Sicherheit wesentlich beeinflussen kann. Die Beweislast liegt bei der dokumentierten Scope-Entscheidung.
¶ Mindestprüfung eines Ausschlusses
| Prüffrage | Erwarteter Nachweis |
|---|---|
| Kein Dienstebezug? | Prozess-, Daten- und Nutzungsanalyse |
| Keine technische Abhängigkeit? | Architektur, Schnittstellen und gemeinsame Plattformen |
| Kein relevanter Angriffspfad? | Netzwerk-, Identitäts- und Administrationsgrenzen |
| Keine Notfallfunktion? | Notbetrieb, Wiederherstellung und Kommunikationswege |
| Keine gemeinsame externe Abhängigkeit? | Provider-, Vertrags- und Unterauftragnehmeranalyse |
| Keine erhebliche Auswirkung? | Risiko- und Ausfallfolgenbewertung |
| Dauerhaft kontrollierbar? | Owner, Überwachung, Änderungsprozess und Reviewtermin |
Ein Ausschluss erhält eine ID, Beschreibung, Begründung, verantwortliche Rolle, Risiko, technische Grenze, Freigabe und Wiedervorlage. Formulierungen wie „nicht kritisch“, „Büro-IT“ oder „extern betrieben“ reichen allein nicht aus.
¶ Typische unzulässige Verkürzungen
- nur Produktionsserver aufnehmen, aber Identitäts- und Administrationssysteme auslassen;
- Cloud- oder Providerleistungen vollständig außerhalb des Scopes behandeln;
- Büro-IT pauschal ausgrenzen, obwohl sie für Konstruktion, Steuerung, Meldung oder Wiederanlauf verwendet wird;
- Konzernplattformen auslassen, weil sie nicht vom geprüften Rechtsträger betrieben werden;
- Backup-Systeme berücksichtigen, aber Wiederherstellungszugänge, Schlüssel oder Netze vergessen;
- nur Normalbetrieb betrachten und Notfallkommunikation oder manuelle Ersatzverfahren auslassen.
¶ 10. Scope-Register
Das Scope-Register ist die führende Übersicht. Detailinformationen verbleiben in den zuständigen Inventaren und werden über stabile IDs referenziert.
| Feldgruppe | Mindestinhalt |
|---|---|
| Scope-Identität | Scope-ID, Bezeichnung, Version, Status und Gültigkeitsdatum |
| Rechtsbezug | Einrichtung, Einrichtungsart, Einstufungsentscheidung und relevante Tätigkeit |
| Dienste | Dienst-IDs, Leistung, Empfänger, Regionen und Betriebszeiten |
| Prozesse | Kern-, Unterstützungs-, Incident-, Notfall- und Wiederanlaufprozesse |
| Informationen | wesentliche Informationsarten, Flüsse, Schnittstellen und Schutzbedarf |
| Technik | Anwendungen, Plattformen, Netze, Endpunkte, Identitäten, Sicherheits- und Backup-Dienste |
| Standorte | eigene, externe, Cloud-, Rechenzentrums-, Ausweich- und Notbetriebsstandorte |
| Dritte | Anbieter, Unterauftragnehmer, Konzernleistungen, Verantwortungsgrenzen und Exit |
| Kritikalität | Ausfallfolgen, Toleranzen, Mindestbetriebsniveau, RTO/RPO und Single Points of Failure |
| Grenzen | Ein- und Ausschlüsse, Annahmen, technische Trennung, Risiken und offene Punkte |
| Nachweise | Inventare, Diagramme, Verträge, Tests, Freigaben und geschützte Ablagereferenzen |
| Governance | Owner, prüfende Rollen, Freigabe, Änderungen und nächster Review |
¶ 11. Formulierung eines Scope-Statements
Das Scope-Statement ist kurz genug für Entscheidungen, aber präzise genug, um die Registergrenzen eindeutig zu verstehen.
Musterformulierung – nicht freigegeben: Der NIS2-Geltungsbereich umfasst den Rechtsträger
[Firma, Rechtsform]mit der Einrichtungsart[Anlage/Nummer]und den relevanten Diensten[Dienst-IDs und Bezeichnungen]an den Standorten[Referenzen]. Einbezogen sind alle hierfür genutzten Kern-, Unterstützungs-, Sicherheits-, Incident-, Notfall- und Wiederanlaufprozesse sowie die in den führenden Inventaren referenzierten Systeme, Informationen, Identitäten, Netze, Cloud- und Lieferantenleistungen. Ausschlüsse sind ausschließlich im Ausschlussregister[Referenz]mit technischer Grenze, Risiko, Freigabe und Review dokumentiert. Das Statement gilt ab[Datum]in Version[Version].
Zusätzlich können Geltungsbereichsdiagramm, Dienstekatalog und Abhängigkeitsmodell beigefügt werden. Das Statement allein ersetzt diese Nachweise nicht.
¶ 12. Vereinfachtes Praxisbeispiel
Musterfall: Ein Maschinenbauunternehmen ist aufgrund seiner Tätigkeit nach Anlage 2 und seiner Größe als wichtige Einrichtung eingestuft. Die Angaben dienen nur der Veranschaulichung.
| Scope-Baustein | Beispielhafte Zuordnung |
|---|---|
| Relevanter Dienst | Konstruktion, Herstellung und termingerechte Bereitstellung der erfassten Maschinenbauprodukte |
| Kernprozesse | Entwicklung/Konstruktion, Produktionsplanung, Fertigung, Qualitätsprüfung und Versand |
| Direkte Systeme | CAD/PDM, ERP, MES, Produktions-/OT-Systeme, Qualitäts- und Lageranwendungen |
| Querschnittssysteme | Identitäten, Netzwerk, DNS/Zeit, Virtualisierung, Speicher, E-Mail, Backup, Monitoring und Fernwartung |
| Informationen | Konstruktionsdaten, Stücklisten, Produktionsaufträge, Qualitäts- und Lieferdaten |
| Standorte | Werk, Rechenzentrum/Cloud-Region, Lager sowie Ausweich- und Wiederherstellungsort |
| Externe Abhängigkeiten | Cloud-Anbieter, Herstellerwartung, Internet-/Netzprovider, Logistik und gegebenenfalls Konzern-IT |
| Notbetrieb | priorisierte Fertigungsaufträge, manuelle Freigaben, Ersatzkommunikation und Wiederanlaufreihenfolge |
| Möglicher Ausschluss | isoliertes Besucherinformationssystem ohne gemeinsame Identitäten, Netze, Daten oder Notfallfunktion – technische Begründung erforderlich |
Das Beispiel zeigt, warum eine reine Liste „ERP und Produktionsnetz“ zu kurz greift. Ohne Identitäten, Kommunikation, Backup, Administration und Lieferanten ist die tatsächliche Dienstekette nicht vollständig.
¶ 13. Rollen und Freigabe
| Rolle | Verantwortung |
|---|---|
| Geschäftsleitung | Scope-Grundsätze, wesentliche Grenzen, Ressourcen und verbleibende Risiken freigeben |
| NIS2-Koordination | Gesamtverfahren, Konsistenz, Status, offene Punkte und Review steuern |
| Recht/Compliance | Verbindung zwischen Einrichtungsart, Tätigkeit und Geltungsbereich prüfen |
| Dienst-Owner | Leistung, Empfänger, Dienstgrenze, Kritikalität und Änderungen bestätigen |
| Prozess-Owner | tatsächliche Abläufe, Übergaben, manuelle Schritte und Ressourcen pflegen |
| System-/Service-Owner | technische Zuordnung, Betrieb, Lebenszyklus, Wiederherstellung und Nachweise verantworten |
| Information Owner | Informationsarten, Flüsse, Schutzbedarf und zulässige Nutzung bestätigen |
| Einkauf/Lieferantenmanagement | Anbieter, Unterauftragnehmer, Verträge, Nachweise und Exit-Abhängigkeiten pflegen |
| BCM-/Incident-Verantwortung | Ausfallfolgen, Notbetrieb, Meldefähigkeit und Wiederanlauf abstimmen |
| Informationssicherheit/Audit | Vollständigkeit, Risikobezug, Wirksamkeitsnachweise und Stichproben prüfen |
Die Freigabe bestätigt die Abgrenzung und die zugrunde liegenden Annahmen. Sie bestätigt nicht automatisch, dass sämtliche Maßnahmen umgesetzt oder wirksam sind.
¶ 14. Qualitätsprüfung vor Freigabe
| Prüffrage | Status im Muster |
|---|---|
| Ist die Betroffenheitsentscheidung eindeutig referenziert? | Offen |
| Sind alle relevanten Dienste mit Rechts- und Tätigkeitsbezug beschrieben? | Offen |
| Stimmen Top-down-Dienstesicht und Bottom-up-Inventarsicht überein? | Offen |
| Sind Kern-, Unterstützungs-, Sicherheits-, Incident- und Notfallprozesse erfasst? | Offen |
| Sind Identitäten, Netze, Administration, Monitoring, Backup und Wiederherstellung berücksichtigt? | Offen |
| Sind Standorte, Cloud, Provider, Konzernleistungen und Unterauftragnehmer abgebildet? | Offen |
| Sind Ausfallfolgen, Mindestbetriebsniveau und Wiederanlaufziele bestätigt? | Offen |
| Sind Ausschlüsse technisch begründet, risikobewertet und freigegeben? | Offen |
| Lassen sich Risiken, Maßnahmen und Nachweise eindeutig dem Scope zuordnen? | Offen |
| Sind Owner, Änderungsmonitoring und Reviewtermin festgelegt? | Offen |
Eine Freigabe trotz offener Punkte ist nur als ausdrücklich befristeter vorläufiger Scope mit Verantwortlichen und Terminen zulässig.
¶ 15. Änderung und Review
Der Geltungsbereich wird mindestens jährlich sowie bei wesentlichen Änderungen überprüft. Ein außerplanmäßiger Review erfolgt insbesondere bei:
- neuer oder geänderter Tätigkeit, Leistung, Region oder Empfängergruppe;
- Fusion, Erwerb, Verkauf, Umstrukturierung oder Änderung des Rechtsträgers;
- neuer Anwendung, Plattform, Schnittstelle, Cloud- oder Providerleistung;
- wesentlicher Architektur-, Netzwerk-, Identitäts- oder Administrationsänderung;
- Standortverlagerung oder neuem Ausweich- und Notbetriebsverfahren;
- neuem Unterauftragnehmer oder geänderter Lieferkette;
- Sicherheitsvorfall, erheblicher Störung oder fehlgeschlagenem Wiederanlauftest;
- Änderung von Rechtslage, Behördenvorgabe oder Einrichtungsart;
- Widersprüchen zwischen Scope-Register, Dienstekatalog, Prozesslandkarte und Inventaren.
Jede Änderung erhält Referenz, Anlass, Auswirkungsanalyse, betroffene Scope-Objekte, verantwortliche Rolle, Freigabe, Nachweisplan und Nachkontrolle.
¶ 16. Nachweise und geschützte Ablage
| Nachweis | Zweck |
|---|---|
| Betroffenheitsentscheidung | rechtlicher Ausgangspunkt und Einrichtungsart |
| freigegebenes Scope-Statement | verständliche Gesamtgrenze und Gültigkeitsstand |
| Dienstekatalog | Leistungen, Empfänger, Owner und Dienstgrenzen |
| Prozess- und Abhängigkeitsmodelle | tatsächliche Ende-zu-Ende-Diensteketten |
| Asset-, System- und Informationsinventare | technische und informationsbezogene Zuordnung |
| Architektur- und Datenflussdiagramme | Zonen, Schnittstellen, Vertrauens- und Verantwortungsgrenzen |
| Standort- und Lieferantenregister | physische und externe Abhängigkeiten |
| Ausschlussregister | begründete Grenzen, Risiken, Freigaben und Reviews |
| Risiko- und Maßnahmenreferenzen | risikobasierte Behandlung innerhalb des Scopes |
| Test-, Übungs- und Wirksamkeitsnachweise | bestätigte Betriebs-, Erkennungs- und Wiederherstellungsfähigkeit |
Das öffentliche Wiki enthält keine realen Netzpläne, IP-Adressen, Schwachstellen, Zugangsdaten, vertraulichen Verträge oder personenbezogenen Detaildaten. Es führt nur die Steuerungslogik, den Status und kontrollierte Referenzen auf geschützte Originale.
¶ 17. Verknüpfte Arbeitsseiten
- Betroffenheits- und Einstufungsprüfung – rechtlicher Ausgangspunkt
- Relevante Dienste und Prozesse – Dienstekatalog und Prozesszuordnung
- Asset- und Systeminventar – technische und organisatorische Ressourcen
- Netz- und Informationssysteme – Architektur und technische Grenzen
- Daten- und Informationsflüsse – Schnittstellen und Informationswege
- Standorte und Infrastruktur – physische und Versorgungsabhängigkeiten
- Externe Dienste und Cloud – Provider- und Cloud-Steuerung
- Kritikalität und Abhängigkeiten – Ausfallfolgen und Konzentrationsrisiken
- NIS2-Risikoregister – dienstbezogene Risiken
- NIS2-Nachweisregister – kontrollierte Nachweisreferenzen
- ISMS-Prozesslandkarte – vorhandene Prozesssicht
- ISMS-Asset-Inventar – vorhandene Asset-Daten
¶ 18. Offizielle Grundlagen
- BSI-Gesetz – geltende Fassung
- § 30 BSIG – Risikomanagementmaßnahmen
- NIS-2-Richtlinie – Artikel 21 und Erwägungsgrund 83
- Durchführungsverordnung (EU) 2024/2690 für bestimmte digitale Einrichtungsarten
¶ 19. Weiterführende Unterstützung durch SMCT MANAGEMENT
Unterstützung bei NIS2-Scope, Dienstekatalog, Abhängigkeitsanalyse und prüffähigen Nachweisen
NIS2-Beratung auf smct-management.de öffnen
¶ 20. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.2 | 09.08.2026 | Scope-Ebenen, Dienstedefinition, Top-down-/Bottom-up-Methode, Einbeziehungs- und Ausschlussregeln, Cloud/Lieferkette, Scope-Statement, Praxisbeispiel und Nachweise ergänzt | Ausstehend |
| 0.1 | 08.08.2026 | Musterverfahren und Scope-Register erstellt | Ausstehend |