¶ Schnittstellen zu ISMS und DSGVO
Steuerungsregel: Gemeinsame Stammdaten und operative Ereignisse werden möglichst einmal erfasst und über eindeutige Referenzen genutzt. NIS2-, ISMS- und DSGVO-Bewertungen bleiben dennoch getrennte Entscheidungen mit eigenen Kriterien, Verantwortlichkeiten, Fristen, Freigaben und Nachweisen.
¶ NIS2, Informationssicherheit und Datenschutz integriert steuern
NIS2/BSIG, ein Informationssicherheitsmanagementsystem und die DSGVO betreffen häufig dieselben Prozesse, Systeme, Lieferanten und Sicherheitsvorfälle. Trotzdem verfolgen sie unterschiedliche Bewertungsziele: Das ISMS steuert Informationssicherheitsrisiken im festgelegten Geltungsbereich, NIS2/BSIG konzentriert sich auf die Sicherheit und Kontinuität relevanter Dienste einer betroffenen Einrichtung, und die DSGVO schützt die Rechte und Freiheiten natürlicher Personen bei der Verarbeitung personenbezogener Daten.
Eine gute Schnittstellenorganisation vermeidet doppelte Inventare, widersprüchliche Risikoeinstufungen und unklare Meldewege. Sie versucht aber nicht, alle Anforderungen in einem einzigen Register oder einer einzigen Bewertung aufzulösen. Stattdessen werden gemeinsame Fakten – etwa System, Standort, Dienst, Lieferant, Sicherheitsvorfall oder Maßnahme – über stabile IDs verbunden. Die jeweilige Rechts- und Fachbewertung bleibt im zuständigen Verfahren dokumentiert.
Diese Seite zeigt, welche Informationen gemeinsam genutzt werden können, wo bewusste Trennungen notwendig sind und wie Übergaben zwischen Informationssicherheit, NIS2-Governance, Datenschutz, Recht/Compliance, IT und Geschäftsleitung nachweisbar gestaltet werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-MAP-00-06 |
| Dokumentenart | Schnittstellen-, Daten- und Führungsmodell |
| Wiki.js-Pfad | /NIS2/00-Start-und-Navigation/Schnittstellen-zu-ISMS-und-DSGVO |
| Status | Entwurf – führende Systeme, Rollen und Übergaben nicht organisationsbezogen freigegeben |
| Version / Stand | 0.2 / 09.08.2026 |
| Schutzklasse | Intern; Fall-, Personen- und Nachweisdetails geschützt |
| Rechtsbezug | Insbesondere §§ 30 und 32 BSIG sowie Artikel 24, 25, 28, 30, 32 bis 35 DSGVO |
| Verantwortlich | Zu benennen – koordinierende ISMS-/NIS2-Funktion gemeinsam mit Datenschutz, Recht/Compliance und Prozessverantwortlichen |
Gemeinsame Fakten konsistent nutzen und rechtliche Bewertungen dennoch klar getrennt dokumentieren. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Abgrenzung der drei Steuerungsebenen
| Ebene | Bewertungsobjekt | Typische Leitfrage |
|---|---|---|
| ISMS / ISO 27001 | Informationen, Prozesse, Assets und Risiken innerhalb des freigegebenen ISMS-Geltungsbereichs | Sind Informationssicherheitsrisiken angemessen behandelt und die Kontrollen wirksam? |
| NIS2 / BSIG | betroffene Einrichtung, relevante Dienste sowie die hierfür genutzten Systeme, Komponenten und Prozesse | Können erhebliche Störungen vermieden, Auswirkungen begrenzt und gesetzliche Pflichten nachweisbar erfüllt werden? |
| DSGVO | Verarbeitung personenbezogener Daten und Risiken für die Rechte und Freiheiten natürlicher Personen | Ist die Verarbeitung rechtmäßig, transparent, zweckgebunden und durch angemessene Maßnahmen geschützt? |
Ein Dienst kann NIS2-relevant sein, ohne personenbezogene Daten zu verarbeiten. Umgekehrt kann eine Verarbeitung DSGVO-relevant sein, obwohl sie außerhalb des NIS2-Scope liegt. Ein System kann wiederum im ISMS erfasst sein, aber weder einen relevanten Dienst tragen noch personenbezogene Daten enthalten. Diese Unterschiede müssen in den Registern sichtbar bleiben.
¶ 2. Grundsätze des Schnittstellenmodells
¶ Ein Sachverhalt – mehrere Fachbewertungen
Ein neu eingeführter Cloud-Dienst wird beispielsweise einmal als Dienst und technisches Asset identifiziert. Danach folgen getrennte Prüfungen: ISMS-Risikobewertung, Zuordnung zu NIS2-relevanten Diensten, Lieferketten- und Kontinuitätsprüfung, Datenschutzrolle, Verarbeitungstätigkeit, Auftragsverarbeitung, Drittlandtransfer und gegebenenfalls DSFA-Screening.
¶ Führende Quelle statt Kopierregister
Jede Information erhält eine festgelegte führende Quelle. Andere Register speichern möglichst nur die Referenz-ID, den benötigten Status und den Zeitpunkt des letzten Abgleichs. So bleibt beispielsweise die technische Systembezeichnung im Asset-Inventar führend, während das VVT auf die System-ID verweist.
¶ Getrennte Entscheidung und Freigabe
Ein gemeinsamer technischer Maßnahmenkatalog bedeutet nicht, dass eine Maßnahme automatisch in allen drei Regelwerken genügt. ISMS-Control-Owner, NIS2-Dienstverantwortliche und datenschutzrechtlich Verantwortliche prüfen Scope, Zweck und Wirksamkeit aus ihrer jeweiligen Perspektive.
¶ Datenminimierung und Need-to-know
Register dürfen miteinander verknüpft werden, ohne sämtliche Inhalte gegenseitig offenzulegen. Personenbezogene Einzelfalldaten, Sicherheitslücken, Zugangsdaten, forensische Artefakte oder Behördenkommunikation gehören in geschützte Fachakten. Das öffentliche Muster-Wiki enthält nur Prozessbeschreibungen und Beispieldaten.
¶ 3. Führende Informationen und Register
| Information | Führende Stelle | Nutzung an der Schnittstelle |
|---|---|---|
| juristische Personen, Standorte und Organisationseinheiten | Organisationsstamm / dokumentierter Scope | Betroffenheitsprüfung, ISMS-Geltungsbereich, Datenschutzrollen und Behördenzuständigkeit |
| Prozesse, relevante Dienste und Abhängigkeiten | Prozess- und NIS2-Diensteregister | Kritikalität, Wiederanlauf, Auswirkungen und Dienstverantwortung |
| Hardware, Software, Netze, Cloud-Dienste und Informationswerte | ISMS-Asset- und Systeminventar | NIS2-Systemscope, technische Maßnahmen, VVT-Systemreferenzen und Vorfallanalyse |
| Verarbeitungstätigkeiten, Zwecke, Rechtsgrundlagen und Datenkategorien | DSGVO-Verzeichnis von Verarbeitungstätigkeiten | Datenschutzprüfung bei Projekten, Lieferanten, Veränderungen und Vorfällen |
| Lieferanten, Diensteanbieter und Unterauftragnehmer | abgestimmter Lieferantenstamm | NIS2-Lieferkette, ISMS-Risiko, Auftragsverarbeitung und Drittlandtransfer |
| Informationssicherheits- und Cyberrisiken | ISMS- beziehungsweise NIS2-Risikoregister | Maßnahmensteuerung, Restrisiken und Managementberichte |
| Datenschutzrisiken und DSFA-Entscheidungen | Datenschutz-Risikoregister und DSFA-Prüfregister | Risiken für Betroffene, Abhilfemaßnahmen und datenschutzrechtliche Freigabe |
| Sicherheitsvorfälle | zentrales Incident-Register | gemeinsame Faktenbasis für Wiederherstellung und getrennte Meldeentscheidungen |
| NIS2-Meldungen | NIS2-Melderegister | Fristen, Meldestufen, BSI-/Behördenreferenzen und Freigaben |
| Datenschutzverletzungen | Datenschutzverletzungsregister | Artikel-33-/34-Entscheidungen, Aufsichtsbehörden- und Betroffenenkommunikation |
| technische und organisatorische Maßnahmen | Control- und Maßnahmenregister | Zuordnung zu ISMS, NIS2 und DSGVO mit eigenem Scope- und Wirksamkeitsstatus |
| Nachweise | geschütztes Nachweisregister mit kontrollierter Originalablage | gemeinsame Referenz, Schutzklasse, Aufbewahrung, Prüfergebnis und Gültigkeit |
¶ 4. Referenz- und Datenmodell
Die Verknüpfung sollte über stabile Kennungen erfolgen. Dateinamen oder Freitextbezeichnungen allein sind zu fehleranfällig.
| Objekt | Beispiel-ID | Wichtige Verknüpfungen |
|---|---|---|
| relevanter Dienst | NIS2-DST-001 |
Prozesse, Systeme, Standorte, Dienstverantwortliche, Lieferanten |
| Asset oder System | ISMS-AST-0042 |
Dienst, Schutzbedarf, Verarbeitungstätigkeit, Risiken, Maßnahmen |
| Verarbeitungstätigkeit | DSGVO-VVT-017 |
Zweck, Rechtsgrundlage, Betroffene, Datenkategorien, Systeme, Empfänger |
| Lieferant | SUP-0028 |
Vertrag, Dienst, Systeme, AVV, Unterauftragnehmer, Exit und Risiko |
| Risiko | NIS2-RSK-014 oder DS-RSK-009 |
Bewertungsmethodik, betroffene Objekte, Maßnahmen und Restrisiko |
| Sicherheitsvorfall | INC-2026-004 |
Systeme, Dienste, personenbezogene Daten, Meldungen, Maßnahmen und Nachweise |
| Maßnahme | MSN-0081 |
Rechtsanforderung, Risiko, Control Owner, Termin und Wirksamkeitsprüfung |
| Nachweis | NW-2026-0118 |
Maßnahme, Scope, Schutzklasse, Prüfer, Ablageort und Aufbewahrung |
¶ Mindestfelder jeder Schnittstellenreferenz
- Quellregister und Objekt-ID,
- verantwortliche und vertretende Rolle,
- Status und Schutzklasse,
- Gültigkeits- oder Reviewdatum,
- betroffene Gesellschaft, Standorte und Scope,
- abhängige Register oder Entscheidungen,
- Zeitpunkt und Ergebnis des letzten Abgleichs,
- offene Abweichung oder Synchronisationsbedarf.
¶ 5. Scope-Abgleich
Vor einer gemeinsamen Nutzung ist zu klären, ob die betrachteten Objekte tatsächlich deckungsgleich sind.
- Organisation: Sind dieselbe juristische Person und dieselben Organisationseinheiten gemeint?
- Standorte: Deckt der ISMS-Scope alle Standorte ab, an denen der relevante Dienst erbracht oder unterstützt wird?
- Dienste und Prozesse: Welche Prozesse sind für NIS2 relevant, welche nur Teil des allgemeinen ISMS?
- Systeme und Informationen: Welche Netz- und Informationssysteme tragen den Dienst, welche enthalten personenbezogene Daten?
- Lieferkette: Welche unmittelbaren Anbieter unterstützen den Dienst und welche sind zugleich Auftragsverarbeiter oder gemeinsame Verantwortliche?
- Schutzobjekte: Geht es um Verfügbarkeit und Resilienz eines Dienstes, um Informationssicherheit oder um Risiken für natürliche Personen – oder um mehrere Perspektiven zugleich?
Freigaberegel: Eine bestehende Richtlinie, Maßnahme oder Prüfung darf nur dann mehrfach angerechnet werden, wenn der jeweils benötigte Scope und die konkrete Wirksamkeit belegt sind.
¶ 6. Gemeinsame Änderungs- und Projektauslöser
Mindestens folgende Ereignisse müssen eine Schnittstellenprüfung auslösen:
- neuer oder wesentlich geänderter Dienst, Prozess, Standort oder Geschäftsbereich,
- Einführung, Migration oder Stilllegung eines IT-Systems oder Cloud-Dienstes,
- neue Verarbeitung personenbezogener Daten oder wesentliche Änderung von Zweck, Datenkategorien oder Empfängern,
- neuer Lieferant, Unterauftragnehmer, Drittlandbezug oder geänderter Vertrag,
- Akquisition, Ausgliederung, Outsourcing oder Änderung des Unternehmensverbunds,
- neue Schwachstelle, Bedrohung, Abhängigkeit oder fehlgeschlagener Sicherheits- beziehungsweise Wiederanlauftest,
- Sicherheitsvorfall oder Datenschutzverletzung,
- neue oder geänderte Rechts-, Behörden-, Norm- oder Kundenanforderung,
- Auditfeststellung, Risikoakzeptanz oder wesentliche Managemententscheidung.
¶ Übergabe im Projekt- und Änderungsprozess
| Phase | Gemeinsame Aktivität | Getrennte Fachentscheidung |
|---|---|---|
| Bedarf und Planung | Dienst, Zweck, Owner, Datenflüsse, Systeme und Lieferanten erfassen | NIS2-Relevanz, ISMS-Scope und Datenschutzrolle bestimmen |
| Bewertung | Bedrohungen, Abhängigkeiten und geplante Maßnahmen zusammentragen | Sicherheitsrisiko, Dienst-/NIS2-Risiko, Datenschutzrisiko und DSFA-Screening getrennt bewerten |
| Beschaffung und Vertrag | Sicherheits-, Audit-, Melde-, Lösch-, Exit- und Mitwirkungspflichten abstimmen | NIS2-Lieferkettenanforderungen, ISMS-Anforderungen und Artikel-28-/Drittlandprüfung freigeben |
| Umsetzung und Test | technische Kontrollen, Berechtigungen, Protokollierung, Backup und Notfallverfahren testen | Abnahme je Fachperspektive und Dokumentation der Restlücken |
| Inbetriebnahme | IDs, Register, Ansprechpartner und Nachweise verknüpfen | produktive Freigaben durch die zuständigen Rollen |
| Betrieb und Änderung | Kennzahlen, Vorfälle, Schwachstellen, Lieferanten- und Berechtigungsreviews | regelmäßige Wirksamkeits- und Rechtsprüfung |
| Stilllegung | Abschaltung, Datenexport, Rückgabe, Löschung und Nachweise koordinieren | NIS2-Abhängigkeit beenden, Assets ausmustern, Datenschutzaufbewahrung und Löschung freigeben |
¶ 7. Lieferanten- und Dienstleister-Schnittstelle
Ein Lieferant kann gleichzeitig unmittelbarer Anbieter eines NIS2-relevanten Dienstes, ISMS-kritischer Dienstleister und Auftragsverarbeiter nach Artikel 28 DSGVO sein. Die Bewertungen dürfen einen gemeinsamen Lieferantenstamm nutzen, benötigen aber eigene Kriterien.
¶ Gemeinsamer Datensatz
- Rechtsträger, Vertrag, Leistung und Dienstverantwortlicher,
- unterstützte relevante Dienste, Prozesse, Systeme und Standorte,
- Kritikalität, Konzentrations- und Substitutionsrisiko,
- Sicherheitskontakt, Vorfall- und Eskalationswege,
- Unterauftragnehmer und wesentliche technische Abhängigkeiten,
- Prüf-, Audit-, Informations-, Mitwirkungs- und Exit-Rechte,
- letzte Bewertung, offene Maßnahmen und nächste Überwachung.
¶ Datenschutzspezifische Ergänzungen
Datenschutzrolle, Gegenstand und Dauer der Verarbeitung, Weisungsbindung, Datenkategorien, Betroffenengruppen, technische und organisatorische Maßnahmen, Löschung/Rückgabe, Unterauftragsverarbeiter, Drittlandtransfer und Unterstützung bei Betroffenenrechten oder Datenschutzverletzungen werden zusätzlich geprüft. Ein positiver ISMS-Sicherheitsstatus ersetzt diese rechtliche Prüfung nicht.
¶ 8. Sicherheitsvorfall: ein Ereignis, drei Entscheidungsstränge
Ein Sicherheitsvorfall wird zunächst technisch und organisatorisch im zentralen Incident-Prozess behandelt. Danach laufen die notwendigen Fachentscheidungen parallel. Die Teams teilen eine konsistente Faktenbasis, aber nicht automatisch dieselbe Risikobewertung oder Meldeentscheidung.
| Entscheidungsstrang | Leitfragen | Ergebnis und Nachweis |
|---|---|---|
| ISMS / Incident Response | Was ist passiert, welche Systeme und Informationen sind betroffen, wie wird eingedämmt und wiederhergestellt? | Incident-Ticket, Zeitleiste, technische Analyse, Maßnahmen und Lessons Learned |
| NIS2 / BSIG | Ist ein NIS2-relevanter Dienst betroffen und liegt ein erheblicher Sicherheitsvorfall vor? | dokumentierte Erheblichkeitsentscheidung, frühe Erstmeldung, 72-Stunden-Meldung, Zwischen- und Abschlussmeldung soweit erforderlich |
| DSGVO | Liegt eine Verletzung des Schutzes personenbezogener Daten vor und besteht ein Risiko beziehungsweise hohes Risiko für Betroffene? | Artikel-33-Entscheidung, Behördenmeldung oder Negativentscheidung; gegebenenfalls Benachrichtigung nach Artikel 34 |
| weitere Pflichten | Bestehen sektorale, vertragliche, versicherungs-, arbeits- oder strafrechtliche Pflichten? | eigene Entscheidung, Freigabe und Kommunikationsnachweis |
¶ Gemeinsame Ereignisdaten
Zeitpunkt der Entdeckung und Kenntniserlangung, Melder, betroffene Systeme und Dienste, Ursache, Angriffsindikatoren, Dauer, Auswirkung, grenzüberschreitender Bezug, Eindämmung, Wiederherstellung und Kommunikationsstatus werden konsistent referenziert. Änderungen an diesen Fakten müssen in alle noch offenen Bewertungen einfließen.
¶ Unterschiedliche Fristen bewusst steuern
- Nach § 32 BSIG sind bei einem erheblichen Sicherheitsvorfall grundsätzlich eine unverzügliche frühe Erstmeldung spätestens innerhalb von 24 Stunden, eine Meldung spätestens innerhalb von 72 Stunden und eine Abschlussmeldung grundsätzlich spätestens einen Monat nach der 72-Stunden-Meldung vorgesehen. Zwischen- oder Fortschrittsmeldungen können hinzukommen; die gesetzliche Übergangsregel zum eingerichteten Meldeweg ist zu beachten.
- Nach Artikel 33 DSGVO meldet der Verantwortliche eine Datenschutzverletzung unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde, sofern die Verletzung voraussichtlich zu einem Risiko für Rechte und Freiheiten führt. Auch eine begründete Nichtmeldung wird dokumentiert.
- Bei voraussichtlich hohem Risiko werden betroffene Personen nach Artikel 34 DSGVO grundsätzlich unverzüglich informiert, soweit keine gesetzliche Ausnahme greift.
Wichtig: Eine NIS2-Meldung ersetzt keine DSGVO-Meldung und umgekehrt. Die 72-Stunden-Angaben haben unterschiedliche Tatbestände, Adressaten und Inhalte.
¶ 9. Getrennte Risikobewertungen mit gemeinsamen Fakten
| Bewertung | Schutzperspektive | Typische Auswirkungen |
|---|---|---|
| ISMS-Risikobewertung | Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Assets | Betriebs-, Kunden-, Vermögens-, Compliance- und Reputationsschäden |
| NIS2-Risikobewertung | Erbringung relevanter Dienste und Cyberresilienz der betroffenen Einrichtung | Dienstunterbrechung, gesellschaftliche und wirtschaftliche Folgen, grenzüberschreitende Auswirkungen |
| Datenschutz-Risikobewertung | Rechte und Freiheiten natürlicher Personen | Identitätsdiebstahl, Diskriminierung, Kontrollverlust, finanzielle oder immaterielle Schäden |
| Datenschutz-Folgenabschätzung | Verarbeitung mit voraussichtlich hohem Risiko | systematische Prüfung von Notwendigkeit, Verhältnismäßigkeit, Risiken und Abhilfemaßnahmen |
Bedrohung, Schwachstelle, System, Eintrittsszenario und vorhandene technische Maßnahme können gemeinsam genutzt werden. Bewertungsskalen, Risikoeigner, Akzeptanzbefugnis und Freigabe bleiben jedoch methodenspezifisch. Eine „niedrige“ Betriebswirkung kann trotzdem ein hohes Datenschutzrisiko darstellen; umgekehrt kann ein Dienst aus NIS2-Sicht hochkritisch sein, ohne personenbezogene Daten zu enthalten.
¶ 10. Rollen und Entscheidungsbefugnisse
| Rolle | Kernaufgabe an der Schnittstelle |
|---|---|
| Geschäftsleitung | NIS2-Maßnahmen billigen und überwachen, Ressourcen entscheiden, wesentliche Risiken und Zielkonflikte behandeln |
| NIS2-/ISMS-Koordination | relevante Dienste, Sicherheitsrisiken, Maßnahmen, Vorfälle und Nachweise koordinieren |
| Verantwortlicher im Sinne der DSGVO | Zwecke und Mittel der Verarbeitung sowie datenschutzrechtliche Entscheidungen verantworten |
| Datenschutzbeauftragte Funktion | beraten, überwachen und frühzeitig einbezogen werden; keine unzulässige Übernahme konfliktbehafteter Entscheidungsverantwortung |
| Recht / Compliance | Betroffenheit, Rechtsgrundlagen, Meldepflichten, Verträge und Behördenkommunikation bewerten |
| Dienst- und Prozessverantwortliche | Fachauswirkungen, Kritikalität, Anforderungen und operative Umsetzung bestätigen |
| IT-/System- und Control Owner | technische Fakten, Maßnahmen, Betriebsnachweise und Wiederherstellung liefern |
| Einkauf / Lieferantenmanagement | Sicherheits- und Datenschutzanforderungen vertraglich und im Lieferantenlebenszyklus steuern |
| Kommunikation / Krisenorganisation | freigegebene interne und externe Kommunikation vorbereiten und dokumentieren |
Vertretungen, Erreichbarkeit außerhalb der Regelarbeitszeit und Freigabebefugnisse müssen vor einem Vorfall feststehen. Ein Organigramm allein ist dafür nicht ausreichend.
¶ 11. Nachweise und geschützte Ablage
Gemeinsame Nachweise können beispielsweise freigegebene Richtlinien, Vertragsklauseln, technische Konfigurationen, Schulungsnachweise, Testprotokolle, Auditberichte oder Maßnahmenabschlüsse sein. Das Nachweisregister speichert nur die für Suche und Steuerung erforderlichen Metadaten:
- Nachweis-ID und Titel,
- zugeordnete Anforderungen, Risiken, Dienste, Systeme und Maßnahmen,
- Scope und betrachteter Zeitraum,
- Owner, Prüfer und Freigabestatus,
- Schutzklasse und kontrollierter Ablageort des Originals,
- Erstell-, Prüf-, Ablauf- und Aufbewahrungsdatum,
- Ergebnis, Abweichung und Folgemaßnahme.
Forensische Daten, personenbezogene Einzelfallinformationen, Schwachstellendetails, Behördenmeldungen und vertrauliche Auditfeststellungen werden nicht frei im Wiki veröffentlicht. Die Fachseite enthält nur Referenz, Status und Zugriffspfad für berechtigte Rollen.
¶ 12. Muster eines Schnittstellenfalls
| Feld | Musterwert |
|---|---|
| Fall-ID | IF-2026-003 |
| Auslöser | geplanter neuer externer Plattformdienst |
| betroffener Dienst | NIS2-DST-001 – Musterbezeichnung |
| Systeme | ISMS-AST-0042, ISMS-AST-0043 |
| Verarbeitung | DSGVO-VVT-017 |
| Lieferant | SUP-0028 |
| gemeinsame Maßnahme | MFA, Protokollierung, Backup, Incident-Kontakt und getesteter Exit |
| NIS2-Entscheidung | Zuordnung und Lieferkettenprüfung offen |
| ISMS-Entscheidung | Risikobewertung und technische Abnahme offen |
| DSGVO-Entscheidung | AVV-, Drittland- und DSFA-Screening offen |
| Freigabe | keine Produktivfreigabe, solange Pflichtprüfungen offen sind |
Die Angaben sind reine Musterdaten. Sie belegen weder Umsetzung noch Freigabe in einer realen Organisation.
¶ 13. Kennzahlen und Überwachung
Geeignete Kennzahlen für die Schnittstellensteuerung sind beispielsweise:
- Anteil relevanter Dienste mit vollständiger Asset-, Lieferanten- und VVT-Verknüpfung,
- offene oder überfällige Schnittstellenprüfungen aus Projekten und Changes,
- Differenzen zwischen Asset-Inventar, Diensteregister, Lieferantenstamm und VVT,
- Zeit von Incident-Erkennung bis zur Einbindung der NIS2-, Datenschutz- und Rechtsrollen,
- Anteil der Vorfälle mit vollständig dokumentierten Fachentscheidungen,
- offene Maßnahmen nach Ursache, Kritikalität, Owner und Überfälligkeit,
- Nachweise mit abgelaufener Gültigkeit oder unklarem Scope,
- wiederkehrende Feststellungen aus Audits, Übungen und Lessons Learned.
Kennzahlen werden nicht nur gezählt, sondern mit Schwellenwert, Datenquelle, Verantwortlichem, Trend, Ursache und erforderlicher Entscheidung dargestellt.
¶ 14. Qualitätskontrolle vor Freigabe
- Führende Register und verantwortliche Rollen sind eindeutig festgelegt.
- Gemeinsame Objekte besitzen stabile IDs und dokumentierte Verknüpfungen.
- NIS2-, ISMS- und DSGVO-Scope sind getrennt beschrieben und miteinander abgeglichen.
- Projekt-, Change-, Lieferanten- und Stilllegungsprozesse enthalten verbindliche Übergabepunkte.
- Der zentrale Incident-Prozess stößt NIS2-, DSGVO- und weitere Fachentscheidungen parallel an.
- Kenntniserlangung, Fristbeginn, Entscheidung, Freigabe und Meldung werden nachvollziehbar protokolliert.
- Datenschutzbeauftragte, Recht/Compliance und Geschäftsleitung werden entsprechend ihrer Rolle rechtzeitig beteiligt.
- Gemeinsame Maßnahmen wurden je Regelwerk auf Scope, Angemessenheit und Wirksamkeit geprüft.
- Vertrauliche Originale und personenbezogene Falldaten liegen ausschließlich in geschützten Systemen.
- Offene Punkte besitzen Risiko, Owner, Termin und Abnahmekriterium.
¶ 15. Verknüpfte Arbeitsseiten
¶ NIS2
- Geltungsbereich und relevante Dienste
- NIS2–ISO-27001–TISAX-Mapping
- Rollen und Verantwortlichkeiten
- NIS2-Risikoregister
- Asset- und Systeminventar
- Meldeweg erhebliche Sicherheitsvorfälle
¶ ISMS
- ISMS-Startseite
- Asset-Inventar
- Lieferanten und Dienstleister
- Informationssicherheit im Projektmanagement
- Incident Response
- Nachweisregister
¶ DSGVO
- DSGVO-Startseite
- Verzeichnis von Verarbeitungstätigkeiten
- Auftragsverarbeiterregister
- Technische und organisatorische Maßnahmen
- DSFA-Prüfregister
- Bewertung von Datenschutzverletzungen
- Datenschutzverletzungsregister
¶ 16. Offizielle Grundlagen
- § 30 BSIG – Risikomanagementmaßnahmen
- § 32 BSIG – Meldepflichten
- Richtlinie (EU) 2022/2555 – NIS-2-Richtlinie
- Datenschutz-Grundverordnung – insbesondere Artikel 24, 25, 28, 30 und 32 bis 35
¶ 17. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei der integrierten Steuerung von NIS2, Informationssicherheit und Datenschutz mit klaren Rollen und prüffähigen Nachweisen
- Datenschutz und Informationssicherheit integriert betrachten
- NIS2-Beratung und dokumentierte Umsetzung
- Datenschutzberatung und externe Datenschutzunterstützung
- Informationssicherheit und ISO 27001
¶ 18. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.2 | 09.08.2026 | SEO- und Facheinleitung, Abgrenzung, Grundsätze, Register- und Referenzmodell, Scope-Abgleich, Projekt-, Lieferanten- und Vorfallschnittstellen, Risikobewertungen, Rollen, Nachweise, Musterfall, Kennzahlen, Qualitätskontrolle und Links ergänzt | Ausstehend |
| 0.1 | 08.08.2026 | Schnittstellenmodell für führende Daten, Auslöser und getrennte Entscheidungen erstellt | Ausstehend |