¶ Daten- und Informationsflüsse
Leeres Musterregister: Diese öffentliche Beispielseite enthält keine realen Empfänger, Endpunkte, Netzpfade, IP-Adressen, technischen Konten, Zertifikate, Schlüssel, Dateninhalte, Übertragungsfehler oder Vertragsdetails. Muster-IDs, Farben und Registerzeilen erläutern ausschließlich das vorgesehene Verfahren.
Schnittstelle zu Datenschutz und Informationsschutz: Das Flussregister ersetzt weder das Verzeichnis von Verarbeitungstätigkeiten noch die Informationsklassifizierung, Architektur- oder Netzpläne. Es verbindet diese Sichten über kontrollierte IDs und Referenzen.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-03-05 |
| Dokumentenart | Verfahrensbeschreibung und Registermodell für dienstrelevante Daten- und Informationsflüsse |
| Wiki.js-Pfad | /NIS2/03-Assets-Prozesse-und-Dienste/Daten-und-Informationsfluesse |
| Verantwortlich | Information Owner, Dienst-/Prozess-Owner und System-/Application-Owner |
| Status | Entwurf – keine realen Informationsflüsse erfasst |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Wiki enthält Methodik und anonymisierte Muster; reale Flüsse und technische Details geschützt |
| Rechtsbezug | § 30 Absatz 1 und 2 BSIG; abhängig von der Einrichtungsart Durchführungsverordnung (EU) 2024/2690; bei Personenbezug DSGVO |
| Freigabe | Ausstehend; Datenmodell, Detailtiefe, Rollen, Quellen, Review- und Schutzkonzept festzulegen |
Informationsflüsse von Quelle bis Empfänger einschließlich Schutz, Fehlerbehandlung und Notfallweg nachvollziehbar abbilden. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Fluss-Cockpit – Muster ohne Echtdaten
Das Cockpit zeigt die vorgesehene Steuerungssicht. Ein Gedankenstrich bedeutet: Auf dieser Musterseite liegt kein realer Messwert vor. Er darf nicht als Null, vollständige Erfassung oder bestandene Prüfung interpretiert werden.
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein produktives Cockpit nennt Stichtag, betrachtete Dienste, bekannte Grundgesamtheit, Abdeckung, Datenquellen und Aussagegrenzen. Viele dokumentierte Schnittstellen belegen keine Vollständigkeit, wenn manuelle Exporte, Schatten-Cloud, E-Mail, Notfallwege oder externe Weiterleitungen fehlen.
¶ 2. Zweck und Arbeitsergebnisse
Das Register soll für einen definierten Dienst nachvollziehbar beantworten:
- welche Information aus welcher fachlichen und technischen Quelle stammt,
- warum, wann und durch welchen Auslöser sie übertragen oder bereitgestellt wird,
- welche Systeme, Netze, Standorte, Organisationen und Dienstleister beteiligt sind,
- welche Klassifizierung, Integritäts-, Verfügbarkeits- und Datenschutzanforderungen gelten,
- wie Endpunkte, Identitäten, Transport, Inhalt und Protokolle geschützt werden,
- wie Verlust, Verzögerung, Duplikate, Fehler und Manipulation erkannt und behandelt werden,
- welche Ersatz- und Notfallwege bestehen,
- wo Freigaben, Tests, Verträge und technische Originalnachweise geschützt geführt werden.
Arbeitsergebnisse sind ein abgestimmtes Flussmodell, eindeutige Registereinträge, Datenflussdiagramme, Schnittstellensteckbriefe, Freigaben, Testreferenzen, Reviewentscheidungen und behandelte Abweichungen.
¶ 3. Rechtlicher und fachlicher Rahmen
§ 30 Absatz 1 BSIG verlangt Schutzmaßnahmen für die informationstechnischen Systeme, Komponenten und Prozesse, die eine Einrichtung zur Erbringung ihrer Dienste nutzt. Daten- und Informationsflüsse machen sichtbar, wie diese Objekte tatsächlich zusammenwirken und an welchen Übergängen Risiken entstehen.
§ 30 Absatz 2 BSIG umfasst unter anderem Risikoanalyse, Betriebskontinuität, Lieferkettensicherheit, sichere Entwicklung und Wartung, Kryptografie, Zugriffskontrolle sowie gesicherte Kommunikation. Das Flussregister unterstützt die Zuordnung, ersetzt aber keine technische oder organisatorische Maßnahme.
Für die in § 30 Absatz 3 BSIG genannten digitalen Einrichtungsarten gilt die Durchführungsverordnung (EU) 2024/2690 vorrangig. Sie verlangt unter anderem eine verständliche und aktuelle Dokumentation der Netzarchitektur, die Begrenzung nicht erforderlicher Kommunikation, vertrauenswürdige Kanäle mit geschützten Endpunkten und Kanaldaten, risikobasierte Segmentierung sowie Überwachung und Protokollierung. Für andere Einrichtungsarten wird die Anwendbarkeit dieser Detailvorgaben geprüft.
Bei personenbezogenen Daten wird zusätzlich die DSGVO-Sicht geführt. Artikel 30 DSGVO verlangt im Verzeichnis von Verarbeitungstätigkeiten unter anderem Zwecke, Daten- und Personenkategorien, Empfängerkategorien, gegebenenfalls Drittlandübermittlungen, Löschfristen und eine allgemeine Beschreibung technischer und organisatorischer Maßnahmen.
Diese Musterseite ist keine Rechtsberatung und kein positiver Compliance-Nachweis.
¶ 4. Vier Sichten klar unterscheiden
| Sicht | Kernfrage |
|---|---|
| Daten-/Informationsfluss | Was bewegt sich warum von welcher Quelle über welche Station zu welchem Ziel? |
| Kommunikationsverbindung | Welche Komponenten kommunizieren über welchen technischen Kanal? |
| Verarbeitungstätigkeit | Zu welchem Zweck und unter welcher Verantwortung werden personenbezogene Daten verarbeitet? |
| Datenherkunft / Lineage | Wie entsteht, verändert und verdichtet sich ein konkretes Datenmerkmal? |
Die Sichten werden verknüpft, aber nicht vermischt. Eine technische Verbindung kann mehrere Informationsflüsse tragen; ein fachlicher Fluss kann mehrere technische Verbindungen und Verarbeitungstätigkeiten umfassen.
¶ 5. Ebenen und geeignete Detailtiefe
Das Modell verwendet mehrere Abstraktionsebenen:
- Kontextsicht: relevante Dienste, externe Akteure und wesentliche Ein- und Ausgaben.
- Ende-zu-Ende-Sicht: Quelle, Verarbeitungsschritte, Speicher, Empfänger und Vertrauensgrenzen.
- Schnittstellensicht: konkrete Systeme, Protokolle, technische Identitäten, Formate und Kontrollen.
- Betriebssicht: Monitoring, Fehler, Wiederholung, Abstimmung, Notbetrieb und Nachweise.
Die Detailtiefe folgt Risiko und Steuerungsbedarf. Flüchtige technische Einzelverbindungen können aus geschützten Quellsystemen automatisiert referenziert werden, während kritische oder externe Übergänge einzeln verantwortet werden.
¶ 6. Eindeutige Fluss-ID und Versionierung
Jeder führende Fluss erhält eine dauerhafte ID, beispielsweise DEMO-DF-001. Bezeichnung, Quelle, Ziel oder Protokoll dürfen sich ändern, ohne die Identität des fachlichen Flusses zu verlieren.
Wesentliche Änderungen erzeugen eine neue freizugebende Version. Aufteilung, Zusammenführung und Ablösung von Flüssen werden über Vorgänger- und Nachfolgerbeziehungen nachvollziehbar gehalten. Ein gelöschter Registereintrag darf nicht die Entscheidungshistorie beseitigen.
¶ 7. Flusstypen
| Flusstyp | Beispiele und besondere Fragen |
|---|---|
| synchrone API | Endpunktauthentisierung, Timeouts, Rate Limits und Antwortvalidierung |
| asynchrone Nachricht | Warteschlange, Reihenfolge, Duplikate, Rückstau und Fehlerablage |
| Datei-/Batchtransfer | Vollständigkeit, Prüfsumme, Termin, Wiederholung und Zwischenablage |
| Datenbankzugriff | Berechtigung, Abfragezweck, Replikation und Transaktionsintegrität |
| Ereignis-/Streamingfluss | Reihenfolge, Zeitstempel, Volumen, Verlust und Pufferung |
| E-Mail / Kollaboration | Empfängerprüfung, Klassifizierung, Anhänge und Fehlversand |
| manueller Export / Import | Freigabe, Medium, lokale Kopie, Vier-Augen-Kontrolle und Löschung |
| Fernwartung / Administration | zeitlich begrenzter Zugriff, Aufzeichnung, Provider und Notfallfreigabe |
| physischer Datenträger | Übergabe, Transport, Verschlüsselung, Rückgabe und Vernichtung |
Der Flusstyp bestimmt Pflichtfelder, Risiken, Testmethode und zulässige Kontrollen.
¶ 8. Rollen und Verantwortlichkeiten
| Rolle | Mindestaufgabe |
|---|---|
| Dienst-/Prozess-Owner | Zweck, Erforderlichkeit, Kritikalität, Empfänger und Notbetrieb bestätigen |
| Information Owner | Informationskategorie, Schutzbedarf, Nutzung, Weitergabe und Aufbewahrung festlegen |
| System-/Application-Owner | Quelle, Ziel, Schnittstelle, Abhängigkeiten und technische Nachweise verantworten |
| Architektur-/Integrationsrolle | Vertrauensgrenzen, Muster, Abhängigkeiten und Änderungsfolgen bewerten |
| IT-/OT-Betrieb | Bereitstellung, Monitoring, Fehlerbehandlung, Wiederanlauf und Betriebsnachweise |
| Informationssicherheit | Risiken, Kontrollen, Ausnahmen, Tests und Schutz der Dokumentation plausibilisieren |
| Datenschutz | Personenbezug, Verantwortungsmodell, VVT, Empfänger und Drittlandbezug prüfen |
| Lieferantenmanagement | Vertrag, Provider, Unterauftragnehmer, Region, SLA und Exit referenzieren |
Rollen dürfen kombiniert werden, wenn Verantwortlichkeit, Vertretung und erforderliche Gegenprüfung nachvollziehbar bleiben.
¶ 9. Mindestfelder je Informationsfluss
| Feldgruppe | Mindestinhalt |
|---|---|
| Identität | Fluss-ID, Bezeichnung, Version, Owner, Status und Gültigkeit |
| Dienstbezug | Dienst, Prozess, Auslöser, Zweck und Kritikalität |
| Quelle und Ziel | Systeme, Standorte, Organisationen, Empfänger und Verantwortungen |
| Information | Kategorien, Klassifizierung, Personenbezug und besondere Schutzmerkmale |
| Übertragung | Flusstyp, Kanal, Schnittstelle, Authentisierung, Verschlüsselung und Integrität |
| Verarbeitung | Zwischenstationen, Transformation, Speicherung, Protokollierung und Löschbezug |
| Resilienz | Abhängigkeiten, Grenzwerte, Wiederholung, Ersatz- und Notfallweg |
| Nachweis | Diagramm, Konfiguration, Vertrag, Test, Review und Änderungsreferenz |
Pflichtfelder werden je Flusstyp und Kritikalität konkretisiert. „Über Netzwerk“ oder „Cloud“ ist keine ausreichende technische Beschreibung.
¶ 10. Fachlicher Zweck und Erforderlichkeit
Jeder Fluss erhält einen verständlichen fachlichen Zweck. Er beantwortet, welche Aufgabe oder Entscheidung durch die Information ermöglicht wird und warum Quelle, Empfänger, Frequenz und Umfang erforderlich sind.
Zweckänderungen dürfen nicht stillschweigend über bestehende Schnittstellen erfolgen. Sie lösen eine fachliche, sicherheitsbezogene und bei Personenbezug datenschutzrechtliche Prüfung aus. Nicht mehr erforderliche Flüsse werden stillgelegt.
¶ 11. Informationskategorien und Klassifizierung
Das Register referenziert die führende Informationsklassifizierung. Ergänzend werden Merkmale erfasst, die für Risiko und Betrieb bedeutsam sind:
- personenbezogene oder besondere personenbezogene Daten,
- Geschäfts-, Kunden-, Entwicklungs- oder Sicherheitsinformationen,
- Zugangsdaten, Schlüsselmaterial und privilegierte Verwaltungsdaten,
- Produktions-, Steuerungs-, Telemetrie- oder Protokolldaten,
- hohe Integritäts- oder Aktualitätsanforderungen,
- zeitkritische Zustellung und hoher Verfügbarkeitsbedarf,
- gesetzliche, vertragliche oder branchenspezifische Bindungen.
Eine niedrige Vertraulichkeit bedeutet nicht automatisch niedrige Integritäts- oder Verfügbarkeitsanforderungen.
¶ 12. Quelle, Ziel und Zwischenstationen
Quelle und Ziel werden über Asset- und System-IDs referenziert. Zusätzlich werden Zwischenstationen wie Gateways, Integrationsplattformen, Proxys, Warteschlangen, Speicher, Konverter, Cloud-Dienste und manuelle Bearbeitungsschritte dokumentiert.
Für jeden Übergang ist erkennbar, wer ihn betreibt, in welcher Umgebung und Region er liegt, welcher Vertrauenszone er angehört und ob Daten gespeichert, verändert, gefiltert oder weitergeleitet werden.
¶ 13. Vertrauensgrenzen
Eine Vertrauensgrenze liegt beispielsweise zwischen:
- interner Organisation und externem Provider,
- Büro-IT und Produktion/OT,
- Benutzer-, Server- und Administrationsnetz,
- Entwicklung, Test und Produktion,
- eigenem Mandanten und fremder Cloud-Organisation,
- normalem Betrieb und Notfallumgebung,
- zwei rechtlich oder datenschutzrechtlich verantwortlichen Stellen.
Grenzen werden im Diagramm sichtbar markiert. Dort werden Authentisierung, Autorisierung, Verschlüsselung, Inhaltsprüfung, Protokollierung und Störungsbehandlung besonders geprüft.
¶ 14. Technischer Schnittstellenvertrag
Der Schnittstellensteckbrief enthält mindestens:
- technische Quelle, Ziel und verantwortete Endpunkte,
- Protokoll, Port oder Diensttyp in geschützter Detailtiefe,
- Datenformat, Schema, Version und zulässige Werte,
- technische Identität und Berechtigungsmodell,
- Verschlüsselungs-, Signatur- oder Prüfsummenverfahren,
- Frequenz, erwartetes Volumen, Zeitfenster und Grenzwerte,
- Timeout, Wiederholung, Reihenfolge und Duplikatbehandlung,
- Erfolgsmeldung, Fehlercode, Alarm und Eskalation,
- Aufbewahrung von Nachrichten, Protokollen und Fehlerdaten,
- Test-, Änderungs- und Stilllegungsverfahren.
Der Vertrag beschreibt überprüfbare Eigenschaften, nicht nur Produktnamen.
¶ 15. Authentisierung und technische Identitäten
Endpunkte werden eindeutig identifiziert. Technische Konten, Dienstidentitäten, Zertifikate, Token und Schlüssel besitzen Owner, zulässigen Zweck, geringstmögliche Berechtigung, Ablauf- oder Reviewdatum, sicheren Speicher und geregelte Rotation.
Gemeinsam genutzte oder nicht zuordenbare Identitäten werden vermieden. Notfallidentitäten erhalten besondere Freigabe, Protokollierung, Befristung und Nachkontrolle. Geheimnisse selbst gehören nicht in das Flussregister.
¶ 16. Autorisierung und Empfängerbegrenzung
Die Berechtigung wird sowohl am sendenden als auch am empfangenden System betrachtet. Quelle, Ziel und Zwischenstationen dürfen nur die Informationen und Funktionen erhalten, die für den genehmigten Zweck erforderlich sind.
Empfängergruppen, technische Rollen, Weiterleitung und Exportmöglichkeiten werden geprüft. Ein erfolgreich authentisierter Endpunkt ist nicht automatisch für jede Datenkategorie oder jeden Zweck autorisiert.
¶ 17. Verschlüsselung und Kanalschutz
Schutz bei Übertragung kann durch Transportverschlüsselung, Inhaltsverschlüsselung, Signaturen, vertrauenswürdige private Verbindungen oder geeignete physische Maßnahmen erfolgen. Auswahl und Konfiguration richten sich nach Risiko, Klassifizierung, Endpunkten und Lebenszyklus.
Dokumentiert werden Verfahren, verantwortete Zertifikate oder Schlüsselreferenzen, zulässige Protokollversionen, Erneuerung, Widerruf und Verhalten bei Ablauf oder Fehler. „TLS vorhanden“ ist ohne geprüfte Endpunkte, Konfiguration und Zertifikatssteuerung keine ausreichende Wirksamkeitsaussage.
¶ 18. Integrität, Authentizität und Nachvollziehbarkeit
Je nach Risiko werden Schema- und Plausibilitätsprüfung, Sequenznummern, Zeitstempel, Prüfsummen, Signaturen, Quittungen und unveränderbare Protokolle eingesetzt. Das Verfahren legt fest, wann eine Nachricht als vollständig, unverändert und von der erwarteten Quelle stammend gilt.
Nichtabstreitbarkeit wird nur behauptet, wenn Verfahren, Identitäten, Beweiskette und Aufbewahrung diese Aussage tatsächlich unterstützen.
¶ 19. Vollständigkeit, Reihenfolge und Duplikate
Ein zuverlässiger Fluss definiert:
- die erwartete Grundgesamtheit oder Anzahl,
- eindeutige Nachrichten- oder Datensatzkennungen,
- zulässige Reihenfolge und Zeitfenster,
- Erkennung fehlender, verspäteter oder doppelter Elemente,
- Wiederholungs- und Abstimmverfahren,
- zuständige Rolle bei Differenzen,
- Nachweis des kontrollierten Abschlusses.
Besonders bei Batch, Streaming und asynchronen Nachrichten wird zwischen technischer Zustellung und fachlich korrekter Verarbeitung unterschieden.
¶ 20. Fehlerbehandlung, Wiederholung und Abstimmung
Für Fehler werden vorab Kategorien, automatische Reaktionen und Eskalationsgrenzen festgelegt. Zu betrachten sind technische Nichterreichbarkeit, Authentisierungsfehler, Formatfehler, fachlich unzulässige Inhalte, Integritätsabweichungen, Rückstau und teilweise Verarbeitung.
Wiederholungen müssen Duplikate und unerwünschte Mehrfachwirkung verhindern. Fehlerwarteschlangen, manuelle Korrekturen und erneute Verarbeitung sind berechtigt, protokolliert und abstimmbar. Dauerhafte Fehler können Sicherheitsvorfall, Notfall oder Lieferanteneskalation auslösen.
¶ 21. Verfügbarkeit, Kapazität und zeitliche Anforderungen
Der Fluss erhält erwartete Frequenz, Volumen, Spitzenlast, maximale Verzögerung, zulässigen Rückstand und Wiederanlaufziel. Diese Werte werden mit Dienstekritikalität, RTO und RPO abgestimmt.
Puffer, Warteschlangen, Redundanz und Ersatzwege müssen ausreichende Kapazität besitzen. Abhängigkeiten wie DNS, Zeitdienst, Zertifikatsprüfung, Netzwerk, Cloudregion oder Schlüsselservice werden in Tests einbezogen.
¶ 22. Protokollierung und Korrelation
Protokolle sollen technische Nachvollziehbarkeit ermöglichen, ohne sensible Inhalte unnötig zu vervielfältigen. Geeignete Metadaten sind Zeitpunkt, technische Identität, Fluss-ID, Korrelations-ID, Endpunkt, Ergebnis, Datenmenge, Fehlercode und Bearbeitungsdauer.
Inhalte oder vollständige Datensätze werden nur protokolliert, wenn erforderlich, zulässig, minimiert und angemessen geschützt. Zeitquellen und Zeitzonen werden so gesteuert, dass Ereignisse systemübergreifend korreliert werden können.
¶ 23. Überwachung und Alarmierung
Für kritische Flüsse werden Schwellenwerte und Alarmwege definiert, beispielsweise für:
- vollständigen Ausfall oder lange Verzögerung,
- unerwartetes Volumen oder ungewöhnliche Richtung,
- unbekannten Empfänger oder Endpunkt,
- wiederholte Authentisierungs- und Integritätsfehler,
- wachsende Fehlerwarteschlangen und Abstimmungsdifferenzen,
- Zertifikats- oder Schlüsselablauf,
- unerwartete Region, Provider- oder Konfigurationsänderung.
Alarmregeln werden getestet. Fehlende Daten, falsch positive und falsch negative Ergebnisse werden bei der Wirksamkeitsbewertung berücksichtigt.
¶ 24. Externe Empfänger, Provider und Regionen
Bei externen Übergängen werden Organisation, Rolle, Vertragsbezug, Dienst, Unterauftragnehmer, Region, Support, Sicherheitsnachweise und Exit referenziert. Tatsächliche technische Wege werden mit Vertrag und freigegebenem Architekturmodell abgeglichen.
Providerwechsel, neue Subprozessoren, andere Regionen oder Weiterleitungen lösen eine Prüfung aus. Ein Anbietername allein beschreibt weder den Empfänger noch die vollständige Lieferkette.
¶ 25. Schnittstelle zum Datenschutz
Bei Personenbezug verweist der Fluss auf den zugehörigen VVT-Eintrag und gegebenenfalls auf Auftragsverarbeitung, gemeinsame Verantwortlichkeit, Datenschutz-Folgenabschätzung und Drittlandprüfung. Stabile IDs verhindern widersprüchliche Parallelbeschreibungen.
Das VVT führt den datenschutzrechtlichen Zweck und die Verantwortlichkeit. Die NIS2-Sicht ergänzt Dienstekritikalität, Cyberrisiken, technische Abhängigkeiten, Fehler- und Wiederanlaufbehandlung.
¶ 26. Drittland- und Weiterübermittlungen
Ein technischer Standort außerhalb der Organisation ist nicht automatisch eine DSGVO-Drittlandübermittlung; umgekehrt können Supportzugriffe und Weiterverarbeitungen relevant sein, obwohl Daten primär in der EU gespeichert werden. Bewertung und Rechtsgrundlage erfolgen im Datenschutzverfahren.
Das Flussregister hält Empfänger, Region, technische und organisatorische Zugriffsmöglichkeiten sowie die kontrollierte Datenschutzreferenz aktuell. Es trifft selbst keine pauschale Zulässigkeitsentscheidung.
¶ 27. Manuelle Exporte, E-Mail und Schattenwege
Manuelle Flüsse werden häufig übersehen. Dazu gehören Tabellenexporte, lokale Downloads, E-Mail-Anhänge, Kollaborationslinks, Druck, Telefon, Wechseldatenträger und Ad-hoc-Übermittlungen an Dienstleister.
Für wiederkehrende oder kritische Wege werden Zweck, Freigabe, Empfängerprüfung, Klassifizierung, Schutz, lokale Kopien, Aufbewahrung und Löschung geregelt. Ein technisch nicht zentral überwachter Weg benötigt geeignete organisatorische Kontrollen.
¶ 28. OT-, IoT- und Telemetrieflüsse
OT- und IoT-Flüsse können Steuerbefehle, Messwerte, Fernwartung, Herstellertelemetrie und Cloudanbindungen umfassen. Integrität, Aktualität, Safety-Wirkung und Betriebsverfügbarkeit können wichtiger sein als klassische Vertraulichkeit.
Passive Ermittlung, dokumentierte Herstellerverbindungen und kontrollierte Übergänge zwischen OT, IT und externen Dienstleistern werden bevorzugt. Tests dürfen Produktions- oder Safety-Funktionen nicht gefährden.
¶ 29. Notfall- und Ersatzwege
Ein Ersatzweg wird nicht dadurch sicher, dass er selten genutzt wird. Für manuelle Exporte, Telefon, alternative Plattformen, Offline-Medien oder Notfallkonten werden Auslöser, Freigabe, Empfängerkontrolle, Verschlüsselung, Protokollierung, Rückführung und Beendigung geregelt.
Nach dem Notbetrieb wird geprüft, ob Informationen vollständig in das führende System übernommen, temporäre Kopien entfernt, Berechtigungen zurückgesetzt und Abweichungen dokumentiert wurden.
¶ 30. Lebenszyklus des Informationsflusses
| Phase | Mindestaktivität |
|---|---|
| Idee / Anforderung | Zweck, Dienst, Information, Empfänger und Kritikalität klären |
| Entwurf | Normal-, Fehler- und Notfallweg sowie Vertrauensgrenzen modellieren |
| Risiko- und Datenschutzprüfung | Schutzbedarf, Risiken, VVT-/DSFA- und Lieferantenbezug bewerten |
| Implementierung | Schnittstelle, Identitäten, Kontrollen und Monitoring einrichten |
| Test und Abnahme | Funktion, Sicherheit, Fehler, Wiederanlauf und Aussagegrenzen prüfen |
| Betrieb | überwachen, abstimmen, ändern und regelmäßig bestätigen |
| Stilllegung | Verbindungen, Identitäten, Speicher, Protokolle und Verträge behandeln |
Jede Phase besitzt Owner, Eingangskriterien, Ergebnis und Freigabestatus.
¶ 31. Änderungs- und Reviewauslöser
Ein Review wird mindestens ausgelöst durch Änderungen an Zweck, Quelle, Ziel, Empfänger, Datenkategorie, Format, Protokoll, technischer Identität, Schlüssel, Provider, Region, Volumen, Kritikalität, Fehlerweg oder Notbetrieb.
Weitere Auslöser sind Sicherheitsvorfälle, neue Schwachstellen, wiederkehrende Fehler, Auditfeststellungen, ablaufende Zertifikate, Vertragsänderungen und wesentliche Änderungen des Dienstes. Die Änderung wird vor Umsetzung risikobasiert bewertet und getestet.
¶ 32. Stilllegung
Bei Stilllegung werden Endpunkte, technische Konten, Schlüssel, Zertifikate, Regeln, Warteschlangen, Zwischenspeicher, Exporte, Protokolle, Dashboards und Alarmierungen kontrolliert behandelt. Abhängige Prozesse und Empfänger werden informiert.
Der Registereintrag bleibt für den festgelegten Nachweiszeitraum historisch erhalten. „Kein aktueller Datenverkehr“ ist ohne formalen Rückbau keine bestätigte Stilllegung.
¶ 33. Ermittlung und Vollständigkeitsabgleich
Informationsflüsse werden aus Dienst- und Prozessmodellen, Assetinventar, Netz- und Architekturplänen, API-Gateways, Integrationsplattformen, Cloudprotokollen, Firewall- und Proxyinformationen, Verträgen, VVT, Interviews und Beobachtung manueller Abläufe ermittelt.
Der Abgleich sucht insbesondere unbekannte Verbindungen, Datenübertragungen ohne Owner, abweichende Empfänger, Schatten-Cloud, manuelle Nebenwege und nicht mehr benötigte Flüsse. Technische Beobachtung allein erklärt nicht zuverlässig Zweck und Dateninhalt; fachliche Bestätigung bleibt erforderlich.
¶ 34. Datenflussdiagramme
Ein geeignetes Diagramm zeigt mindestens:
- eindeutige IDs für Flüsse und beteiligte Objekte,
- Quelle, Ziel, Richtung und wesentliche Zwischenstationen,
- Informationskategorie und fachlichen Zweck,
- Organisations-, Netz-, Cloud- und Verantwortungsgrenzen,
- externe Empfänger und Provider,
- Speicher- und Transformationspunkte,
- Normal-, Fehler- und Notfallwege,
- Legende, Version, Scope, Stichtag und Owner.
Das Wiki kann eine bereinigte Steuerungsgrafik zeigen. Technische Detaildiagramme werden geschützt und versioniert geführt.
¶ 35. Risiko- und Bedrohungsfragen
Für jeden kritischen Übergang wird geprüft:
- Kann eine falsche Quelle oder ein falsches Ziel auftreten?
- Können Inhalte unbemerkt verändert, vertauscht oder wiederholt werden?
- Können Informationen an unzulässige Empfänger oder Regionen gelangen?
- Kann der Fluss blockiert, überlastet oder zeitlich manipuliert werden?
- Sind technische Identitäten oder Schlüssel unzureichend geschützt?
- Kann ein kompromittierter Zwischenknoten weitere Systeme erreichen?
- Werden Fehler, Rückstände und Anomalien rechtzeitig erkannt?
- Kann ein manueller oder Notfallweg Kontrollen umgehen?
Bewertungen werden mit Dienst, Asset, Risiko, Maßnahme und Nachweis verknüpft.
¶ 36. Test und Abnahme
Die Abnahme prüft nicht nur, ob Daten ankommen. Je nach Risiko umfasst sie:
- zulässige und unzulässige Identitäten und Empfänger,
- korrekte Verschlüsselung und Zertifikatsprüfung,
- Schema-, Format- und Plausibilitätsfehler,
- Verlust, Duplikat, Reihenfolge, Verzögerung und Rückstau,
- Wiederholung, Fehlerablage und fachliche Abstimmung,
- Monitoring, Alarm und Eskalation,
- Ausfall von Abhängigkeiten und Wiederanlauf,
- Notfallweg und kontrollierte Rückkehr zum Normalbetrieb.
Testdaten enthalten keine unnötigen Echtdaten. Ergebnis, Scope, Einschränkungen und offene Abweichungen werden geschützt referenziert.
¶ 37. Störungen und Sicherheitsvorfälle
Grenzwerte legen fest, wann eine Abweichung als Betriebsstörung, Sicherheitsereignis, möglicher Sicherheitsvorfall oder Notfall bewertet wird. Dabei werden Vertraulichkeit, Integrität, Verfügbarkeit, betroffene Dienste, Empfänger und Dauer betrachtet.
Bei Vorfällen unterstützt die Flussdokumentation Eingrenzung, Abschaltung, Beweissicherung, Kommunikation und Wiederherstellung. Nach der Behandlung werden Ursache, Änderungen und erforderliche Registerkorrekturen nachgeführt.
¶ 38. Status- und Qualitätsampel
| Ampel | Bedeutung | Folge |
|---|---|---|
| Grün | Pflichtfelder, Freigabe, Test und Review im definierten Scope aktuell | regulär überwachen |
| Gelb | nicht kritische Lücke mit Owner und Termin | nachverfolgen |
| Orange | wesentliche Schutz-, Test- oder Aktualitätslücke | priorisiert behandeln |
| Rot | kritischer Fluss ohne Owner, zulässigen Empfänger oder steuerbare Sicherheitsbasis | unverzüglich eskalieren |
| Violett | wegen fehlender Daten, Scope oder Nachweise nicht bewertbar | Datenerhebung und Risikoentscheidung auslösen |
Die Ampel beschreibt Register- und Freigabestatus. Sie ist keine pauschale Aussage, dass die technische Übertragung dauerhaft wirksam geschützt ist.
¶ 39. Fiktiver Musterregistereintrag
| Feld | Fiktiver Musterwert |
|---|---|
| Fluss-ID | DEMO-DF-001 |
| Bezeichnung | Muster-Auftragsstatus |
| Dienst / Zweck | DEMO-SVC-001 / Statusbereitstellung |
| Quelle / Ziel | DEMO-APP-001 → DEMO-APP-002 |
| Flusstyp | asynchrone Nachricht |
| Information | Muster-Geschäftsdaten; Klassifizierung nicht freigegeben |
| Vertrauensgrenze | interner Dienst → Musterprovider |
| Schutz | Verfahren und technische Parameter noch offen |
| Fehler-/Notfallweg | Muster-Warteschlange / manuelle Ersatzmeldung |
| Status | Violett – nicht bewertbar |
| Nachweis | nur geschützte Referenz vorgesehen |
Der Eintrag ist vollständig fiktiv und bestätigt weder einen realen Datenfluss noch eine rechtmäßige Verarbeitung oder wirksame Sicherheitskontrolle.
¶ 40. Arbeitsansichten und Filter
Nützliche Arbeitsansichten sind:
- kritische Flüsse je relevantem Dienst,
- externe Empfänger, Provider und Regionen,
- personenbezogene Flüsse ohne bestätigte VVT-Verknüpfung,
- Flüsse ohne Owner, Zweck oder aktuellen Review,
- manuelle, E-Mail- und Notfallwege,
- technische Identitäten oder Zertifikate mit bevorstehendem Review,
- Flüsse mit wiederkehrenden Fehlern oder Abstimmungsdifferenzen,
- ungeklärte Vertrauensgrenzen und nicht bewertbare Schutzwege,
- seit dem letzten Stichtag neu angelegte oder wesentlich geänderte Flüsse.
Filter verändern nur die Ansicht, nicht den führenden Datensatz oder seine Historie.
¶ 41. Kennzahlen und Managementinformation
| Kennzahl | Aussagegrenze |
|---|---|
| Anteil bestätigter kritischer Flüsse | hängt von einer bekannten Grundgesamtheit ab |
| Flüsse ohne Owner oder Zweck | zeigt Steuerungslücken, nicht automatisch einen Vorfall |
| überfällige Reviews | benötigt risikobasierte Sollintervalle |
| ungeklärte externe Empfänger | Kritikalität und Datenkategorie sind separat zu bewerten |
| wiederkehrende Übertragungsfehler | technische und fachliche Fehler müssen unterschieden werden |
| getestete Notfallwege | Testaktivität ist nicht gleich erfolgreicher und vollständiger Test |
| Flüsse mit ablaufenden Zertifikaten | setzt verlässliche Zertifikatsdaten voraus |
Managementberichte zeigen betroffene Dienste, Trends, Ursachen, Risiken, Maßnahmen, Owner, Termine und Aussagegrenzen.
¶ 42. Nachweise und geschützte Ablage
Typische Nachweise sind:
- freigegebene Datenflussdiagramme und Schnittstellensteckbriefe,
- Architektur- und Risikoentscheidungen,
- API-, Gateway-, Netzwerk- und Konfigurationsreferenzen,
- Identitäts-, Zertifikats- und Schlüsselmanagementnachweise,
- Verträge, Provider- und Empfängerprüfungen,
- VVT-, DSFA- und Drittlandreferenzen,
- Funktions-, Sicherheits-, Fehler- und Wiederanlauftests,
- Monitoring-, Abstimmungs- und Reviewprotokolle,
- Change-, Störungs- und Stilllegungsnachweise.
Das Wiki führt Methodik, Status und kontrollierte Referenzen. Sensible Originale verbleiben in der geschützten Nachweisablage.
¶ 43. Schutz der Flussdokumentation
Flussmodelle können Angriffswege, kritische Abhängigkeiten, Empfänger und Schutzmechanismen offenlegen. Nicht öffentlich gehören insbesondere reale Endpunkte, Adressen, Netzsegmente, Konten, Schlüssel, Zertifikatsdetails, Schwachstellen, Sicherheitsregeln und vollständige Empfängerlisten.
Zugriff, Export, Änderung, Aufbewahrung, Sicherung und Löschung der Dokumentation werden ihrem Schutzbedarf entsprechend geregelt. Veröffentlichte Diagramme werden auf sensible Metadaten und eingebettete Inhalte geprüft.
¶ 44. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| nur Netzverbindung dokumentiert | Zweck, Inhalt und Empfänger bleiben unklar | technische und fachliche Sicht verknüpfen |
| Diagramm ohne IDs und Version | Änderungen sind nicht nachvollziehbar | Fluss-IDs, Scope, Stand und Owner ergänzen |
| „verschlüsselt“ ohne Endpunktprüfung | Scheinsicherheit | Verfahren, Identität und Lebenszyklus nachweisen |
| manueller Export fehlt | Nebenweg bleibt unkontrolliert | Interviews, Prozessbeobachtung und Exportquellen nutzen |
| technischer Erfolg = fachliche Vollständigkeit | verlorene oder doppelte Datensätze bleiben unerkannt | Abstimmung und fachliche Kontrollsumme definieren |
| Notfallweg nie getestet | Ausfall führt zu ungeplantem Kontrollverlust | sicheren Ersatzweg risikobasiert üben |
| VVT und Flussregister widersprechen sich | Empfänger und Zwecke sind unklar | stabile IDs und verantworteten Abgleich verwenden |
| Live-Diagramm enthält Geheimnisse | erhöhte Angriffs- und Offenlegungsgefahr | bereinigte Steuerungssicht veröffentlichen |
¶ 45. Qualitätsgate vor Freigabe
- Sind Dienst, Zweck, Quelle, Ziel, Empfänger und Owner eindeutig?
- Sind Informationskategorie, Klassifizierung und Personenbezug bestätigt?
- Sind Zwischenstationen und Vertrauensgrenzen vollständig?
- Sind technische Identitäten, Berechtigungen, Verschlüsselung und Integrität steuerbar?
- Sind Fehler, Wiederholung, Abstimmung, Alarm und Eskalation definiert?
- Stimmen Normal-, Notfall- und Stilllegungsweg mit Kontinuitätszielen überein?
- Sind externe Provider, Regionen und Datenschutzreferenzen aktuell?
- Wurden Funktion, Sicherheit, Fehler- und Wiederanlaufverhalten angemessen getestet?
- Sind Änderungen, Reviews, Ausnahmen und Nachweise nachvollziehbar?
- Sind technische Details, personenbezogene Daten und Sicherheitsinformationen geschützt?
Erst nach bestandenem Qualitätsgate wird der Fluss für den festgelegten Zweck freigegeben.
¶ 46. Offene Entscheidungen vor produktiver Nutzung
- führendes Register, Fluss-ID und Versionsmodell festlegen,
- Abstraktionsebenen, Flusstypen und Pflichtfelder freigeben,
- Rollen, Gegenprüfung und Reviewintervalle bestimmen,
- Asset-, Dienst-, Klassifizierungs- und VVT-Verknüpfung operationalisieren,
- technische und fachliche Ermittlungsquellen anbinden,
- Vertrauensgrenzen, Schutz- und Schnittstellenmuster freigeben,
- Test-, Monitoring-, Fehler- und Abstimmverfahren bestimmen,
- Notfall-, Änderungs- und Stilllegungsprozess pilotieren,
- geschützte Diagramm- und Nachweisablage einrichten,
- mindestens einen kritischen Ende-zu-Ende-Fluss vollständig prüfen und freigeben.
Bis zur Entscheidung bleiben sämtliche Musterwerte ausdrücklich Entwurf.
¶ 47. Verknüpfte Seiten
- Asset- und Systeminventar
- Netz- und Informationssysteme
- Relevante Dienste und Prozesse
- Kritikalität und Abhängigkeiten
- Externe Dienste und Cloud
- NIS2-Risikoregister
- NIS2-Nachweisregister
- Informationsübertragung
- Netzwerke und Kommunikation
- Kryptografie und Schlüssel
- Protokollierung und Überwachung
- Informationsklassifizierung
- DSGVO Verzeichnis von Verarbeitungstätigkeiten
¶ 48. Offizielle Grundlagen
- § 30 BSIG – Schutz der für Dienste genutzten Systeme, Komponenten und Prozesse
- EUR-Lex – Durchführungsverordnung (EU) 2024/2690, insbesondere Nummern 3.2, 6.7 und 6.8
- EUR-Lex – Datenschutz-Grundverordnung, insbesondere Artikel 30
- BSI – IT-Grundschutz und Strukturanalyse als fachliche Orientierung
Anwendbarkeit, Rechtsstand, Geltungsbereich und sektorale Anforderungen werden vor produktiver Nutzung aktuell geprüft. Die externen Links öffnen in einem neuen Tab.
¶ 49. Weiterführende Unterstützung durch SMCT MANAGEMENT
Unterstützung bei NIS2-, ISMS- und Datenschutz-Schnittstellenmodellen, Datenflussregistern, Schutzkonzepten und Nachweisführung.
Informationen zur NIS2-Beratung öffnen
¶ 50. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Rechtsrahmen, Flusssichten, Vertrauensgrenzen, Schnittstellenverträge, Identitäten, Verschlüsselung, Integrität, Fehlerbehandlung, Cloud/OT/manuelle Wege, Diagramme, Tests, Qualitätsampel, Musterregister, Kennzahlen und Qualitätsgate umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Verfahren, Rollen, Schutzkontrollen, Fehlerbehandlung, Notfallwege, Kennzahlen und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Leere Musterstruktur für Daten- und Informationsflüsse erstellt | Ausstehend |