DLP 2026: ISO 27001 für GDPR, NIS2 und DORA

Es beginnt mit einer Tabelle.

Um 08:17 Uhr an einem Montag exportiert ein Customer-Success-Manager 14.000 Unternehmenskontakte aus dem CRM, um eine Verlängerungskampagne vorzubereiten. Um 08:24 Uhr wird die Tabelle an eine E-Mail angehängt. Um 08:26 Uhr wird die E-Mail an ein privates Gmail-Konto gesendet, weil der Mitarbeiter während einer Zugfahrt arbeiten möchte. Um 08:31 Uhr wird dieselbe Datei in einen nicht genehmigten KI-Notizdienst hochgeladen, um „Duplikate zu bereinigen“.

Noch sieht nichts wie ein Sicherheitsvorfall aus. Es gibt keine Ransomware-Nachricht, kein Malware-Beaconing, kein kompromittiertes Administratorkonto und keinen öffentlichen Datenabfluss. Für den CISO, den Compliance-Manager und den DPO stellt sich die eigentliche Frage jedoch bereits: Kann die Organisation nachweisen, dass diese Datenbewegung erlaubt, klassifiziert, protokolliert, verschlüsselt, begründet und rückgängig zu machen war?

Dasselbe Szenario spielt sich im Finanzdienstleistungssektor jede Woche ab. Ein Entwickler versucht, Q1_Investor_Projections_DRAFT.xlsx auf ein persönliches Cloud-Laufwerk hochzuladen, weil das VPN langsam ist. Eine Vertriebsleiterin exportiert eine Kundenliste in eine Collaboration-App für Verbraucher. Ein Support-Analyst fügt Kundendatensätze in ein nicht genehmigtes KI-Werkzeug ein. In jedem Fall ist die Absicht vielleicht Bequemlichkeit statt Böswilligkeit; das Risiko bleibt jedoch dasselbe. Sensible Daten haben eine Grenze überschritten oder beinahe überschritten, die die Organisation nicht kontrolliert.

Das ist das moderne Problem der Data Loss Prevention. DLP ist nicht mehr nur eine E-Mail-Gateway-Regel oder ein Endpoint-Agent. Wirksame Data Loss Prevention ist 2026 ein gesteuertes, nachweisbasiertes Kontrollsystem über SaaS, Cloud-Speicher, Endpunkte, mobile Geräte, Lieferanten, Programmierschnittstellen, Entwicklungsumgebungen, Backup-Exporte, Kollaborationswerkzeuge und menschliche Abkürzungen hinweg.

GDPR Article 32 verlangt geeignete technische und organisatorische Maßnahmen für die Sicherheit der Verarbeitung. NIS2 Article 21 verlangt risikobasierte Cybersicherheitsmaßnahmen, einschließlich Cyberhygiene, Zugriffskontrolle, Asset-Management, Sicherheit der Lieferkette, Management von Informationssicherheitsvorfällen, Verschlüsselung und Wirksamkeitsprüfung. DORA verlangt von Finanzunternehmen, IKT-Risiken durch Governance, Erkennung, Reaktion, Wiederherstellung, Tests, Aufsicht über Drittparteien und Auditierbarkeit zu steuern. ISO/IEC 27001:2022 liefert das Rückgrat des Managementsystems, um diese Verpflichtungen operativ, messbar und auditierbar umzusetzen.

Der Fehler vieler Organisationen besteht darin, ein DLP-Werkzeug zu kaufen, bevor sie definiert haben, was „Verlust“ bedeutet. Der Ansatz von Clarysec setzt früher an: Daten klassifizieren, erlaubte Übertragungen definieren, die Richtlinie durchsetzen, Ausnahmen überwachen, Nachweise für die Reaktion vorbereiten und alles mit dem ISMS verbinden.

Wie es die Zenith Blueprint: An Auditor’s 30-Step Roadmap in der Phase „Controls in Action“, Schritt 19, „Technological Controls I“ formuliert:

Data Leakage Prevention dient dazu, die unbefugte oder versehentliche Offenlegung sensibler Informationen zu verhindern – unabhängig davon, ob sie über E-Mail, Cloud-Uploads, portable Medien oder sogar einen vergessenen Ausdruck erfolgt. Control 8.12 adressiert die Notwendigkeit, alle Daten zu überwachen, zu beschränken und darauf zu reagieren, die die vertrauenswürdigen Grenzen der Organisation verlassen, unabhängig davon, ob dies digital, physisch oder durch menschliches Handeln geschieht. Zenith Blueprint

Dieser Satz ist der Kern von DLP im Jahr 2026: überwachen, beschränken und reagieren.

Warum DLP jetzt ein Compliance-Thema für das Leitungsorgan ist

Das Leitungsorgan fragt in der Regel nicht, ob ein DLP-Regex nationale Identifikationsnummern erkennt. Es fragt, ob die Organisation das Vertrauen der Kunden schützen, den Betrieb aufrechterhalten, regulatorische Exponierung vermeiden und angemessene Sicherheit nachweisen kann, wenn etwas schiefgeht.

Genau dort laufen GDPR, NIS2 und DORA zusammen.

GDPR gilt breit für die automatisierte Verarbeitung personenbezogener Daten, einschließlich in der EU niedergelassener Verantwortlicher und Auftragsverarbeiter sowie Nicht-EU-Organisationen, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten. GDPR definiert personenbezogene Daten weit und umfasst Vorgänge wie Erhebung, Speicherung, Nutzung, Offenlegung, Löschung und Vernichtung. Die unbefugte Offenlegung personenbezogener Daten oder der unbefugte Zugriff darauf kann eine Verletzung des Schutzes personenbezogener Daten darstellen. GDPR Article 5 macht auch die Rechenschaftspflicht ausdrücklich: Organisationen müssen nicht nur Grundsätze wie Datenminimierung, Speicherbegrenzung, Integrität und Vertraulichkeit einhalten, sondern diese Einhaltung auch nachweisen können.

NIS2 erhöht den Druck über den Datenschutz hinaus. Sie gilt für viele wesentliche und wichtige Einrichtungen, unter anderem in Sektoren wie Banken, Finanzmarktinfrastrukturen, Cloud-Computing-Anbieter, Rechenzentrumsanbieter, Managed Service Provider, Managed Security Service Provider, Online-Marktplätze, Suchmaschinen und Plattformen sozialer Netzwerke. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Sicherheitsrichtlinien für Informationssysteme, Management von Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Entwicklung, Wirksamkeitsprüfung, Cyberhygiene, Schulung, Kryptografie, Zugriffskontrolle, Asset-Management und Authentifizierung.

DORA gilt seit dem 17. Januar 2025 und fungiert als eigenes Regelwerk des Finanzsektors für digitale operationale Resilienz. Für Finanzunternehmen im Anwendungsbereich wird DORA bei Überschneidungen mit NIS2 als sektorspezifischer Rechtsakt der Union behandelt. DORA bringt DLP in das IKT-Risikomanagement, die Vorfallklassifizierung, Datenverluste mit Auswirkungen auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit, Tests der digitalen operationalen Resilienz, das Management von IKT-Drittparteien und vertragliche Kontrollen.

Die DLP-Frage im Jahr 2026 lautet nicht: „Besitzen wir ein Werkzeug?“ Sie lautet:

1. Wissen wir, welche Informationen sensibel sind?
2. Wissen wir, wo sie gespeichert, verarbeitet und übertragen werden?
3. Sind erlaubte und verbotene Übertragungswege definiert?
4. Sind Benutzer geschult und technisch eingeschränkt?
5. Werden Cloud- und SaaS-Wege gesteuert?
6. Sind Protokolle für Untersuchungen ausreichend?
7. Werden Warnmeldungen triagiert und Vorfälle schnell klassifiziert?
8. Sind Lieferanten und ausgelagerte IKT-Dienstleistungen vertraglich gebunden?
9. Können wir nachweisen, dass Kontrollen wirksam betrieben werden?

ISO/IEC 27001:2022 eignet sich gut zur Beantwortung dieser Fragen, weil sie Kontext, Anforderungen interessierter Parteien, Risikobeurteilung, Risikobehandlung, messbare Ziele, operative Steuerung, dokumentierte Nachweise, Lieferantenkontrolle, interne Audits, Managementbewertung und kontinuierliche Verbesserung verlangt. Sie ist kein DLP-Standard, macht DLP aber aus einer isolierten Technologiekonfiguration zu einem kontrollierten Prozess des Managementsystems.

Die ISO 27001-Kontrollkette hinter wirksamer DLP

Ein belastbares DLP-Programm basiert nicht auf einer einzelnen Kontrolle. Es basiert auf einer Kette.

Clarysecs Zenith Controls: The Cross-Compliance Guide ordnet ISO/IEC 27002:2022 Maßnahme 8.12, Verhinderung von Datenabfluss, als präventive und detektive Kontrolle mit Fokus auf Vertraulichkeit ein, ausgerichtet an den Cybersicherheitskonzepten Protect und Detect, mit Informationsschutz als operativer Fähigkeit und Schutz/Verteidigung als Sicherheitsdomäne. Zenith Controls

Das ist relevant, weil Auditoren sowohl Blockierung als auch Transparenz erwarten. Eine präventive DLP-Regel ohne Überprüfung von Warnmeldungen ist unvollständig. Ein Ansatz, der nur protokolliert und bei risikobehafteten Übertragungen keine Durchsetzung vorsieht, ist ebenfalls schwach.

Derselbe Leitfaden ordnet ISO/IEC 27002:2022 Maßnahme 5.12, Klassifizierung von Informationen, als präventiv ein, mit Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit sowie Ausrichtung an Identify. Er ordnet Maßnahme 5.14, Informationsübertragung, als präventiv ein, mit Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit sowie Ausrichtung an Protect, Asset Management und Information Protection.

Praktisch sieht die DLP-Kontrollkette so aus:

Die Zenith Blueprint, Schritt 22, erläutert die Abhängigkeit zwischen Asset-Inventar, Klassifizierung und DLP:

Überprüfen Sie Ihr aktuelles Asset-Inventar (5.9), um sicherzustellen, dass es sowohl physische als auch logische Assets, Verantwortliche und Klassifizierungen enthält. Verknüpfen Sie dieses Inventar mit Ihrem Klassifizierungsschema (5.12), sodass sensible Assets angemessen gekennzeichnet und geschützt werden. Definieren Sie bei Bedarf Aufbewahrung, Backup oder Isolation auf Grundlage der Klassifizierung.

Deshalb beginnt Clarysec ein DLP-Engagement nur selten mit dem Feintuning von Regeln. Wir beginnen mit dem Abgleich von Assets, Verantwortlichen, Datentypen, Klassifizierungskennzeichnungen, Übertragungswegen und Nachweisaufzeichnungen. Wenn eine Organisation nicht sagen kann, welche Datenbestände vertraulich, reguliert, kundeneigen, zahlungsbezogen oder unternehmenskritisch sind, kann ein DLP-Werkzeug nur raten.

Die drei Säulen eines modernen DLP-Programms

Ein modernes DLP-Programm steht auf drei sich gegenseitig verstärkenden Säulen: Daten kennen, Datenflüsse steuern und Grenzen verteidigen. Diese Säulen machen ISO/IEC 27001:2022 für die Einhaltung von GDPR, NIS2 und DORA praktisch anwendbar.

Säule 1: Daten durch Klassifizierung und Kennzeichnung kennen

Man kann nicht schützen, was man nicht versteht. ISO/IEC 27002:2022 Maßnahmen 5.12 und 5.13 verlangen, dass Organisationen Informationen nach Sensitivität und Handhabungsanforderungen klassifizieren und kennzeichnen. Das ist keine Papierübung. Es ist die Grundlage für automatisierte Durchsetzung.

Für KMU heißt es in der Richtlinie zur Datenklassifizierung und Kennzeichnung:

Vertraulich: Erfordert Verschlüsselung während der Übertragung und im Ruhezustand, eingeschränkten Zugriff, ausdrückliche Genehmigung für die Weitergabe und sichere Vernichtung bei der Entsorgung. Data Classification and Labeling Policy - SME

Dieses Zitat aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.3.3, gibt dem DLP-Programm vier durchsetzbare Bedingungen: Verschlüsselung, eingeschränkter Zugriff, Genehmigung der Weitergabe und sichere Entsorgung.

In Unternehmensumgebungen ist die Richtlinie zur Datenklassifizierung und Kennzeichnung noch direkter. Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.2.6.2:

Blockierung der Übertragung (z. B. externe E-Mail) bei falsch gekennzeichneten sensiblen Daten Data Classification and Labeling Policy

Und aus Abschnitt „Durchsetzung und Einhaltung“, Klausel 8.3.2:

Automatisierte Klassifizierungsprüfung mittels Data Loss Prevention (DLP) und Discovery-Werkzeugen

Diese Klauseln machen Klassifizierung zu einer Kontrolle. Eine als Vertraulich gekennzeichnete Datei kann Verschlüsselung auslösen, externe Übertragung blockieren, Genehmigung verlangen oder eine Sicherheitswarnmeldung erzeugen. DLP wird damit zur Durchsetzungsebene für eine Richtlinie, die Benutzer, Systeme und Auditoren verstehen können.

Säule 2: Datenflüsse durch sichere Informationsübertragung steuern

Sobald Daten klassifiziert sind, muss die Organisation steuern, wie sie sich bewegen. ISO/IEC 27002:2022 Maßnahme 5.14, Informationsübertragung, wird oft übersehen, ist aber der Punkt, an dem viele DLP-Fehler beginnen.

Die Zenith Blueprint beschreibt Maßnahme 5.14 als Notwendigkeit, Informationsflüsse so zu steuern, dass Übertragungen sicher, beabsichtigt und mit Klassifizierung sowie Geschäftszweck konsistent sind. Dies gilt für E-Mail, sichere Dateifreigabe, Programmierschnittstellen, SaaS-Integrationen, Wechselmedien, gedruckte Berichte und Lieferantenportale.

Remote-Arbeit macht dies besonders wichtig. Die Richtlinie für Remote-Arbeit, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.3.1.3, verlangt von Mitarbeitern:

Ausschließlich genehmigte Dateifreigabelösungen verwenden (z. B. M365, Google Workspace mit Data-Loss-Prevention-(DLP)-Kontrollen) Remote Work Policy

Für mobile Geräte und BYOD enthält die Richtlinie für mobile Geräte und Bring-Your-Own-Device (BYOD), Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.6.4, konkrete Endpoint-Durchsetzung:

Data-Loss-Prevention-(DLP)-Richtlinien müssen unbefugte Uploads, Bildschirmaufnahmen, Clipboard-Zugriff oder die Datenweitergabe aus verwalteten Anwendungen in persönliche Bereiche blockieren. Mobile device and byod policy

Das ist wichtig, weil Daten nicht nur über E-Mail abfließen. Sie verlassen die Organisation über Screenshots, Clipboard-Synchronisierung, unverwaltete Browserprofile, persönliche Laufwerke, mobile Freigabefunktionen, Collaboration-Plugins und KI-Werkzeuge.

Cloud-Governance ist ebenso wichtig. In der KMU-Richtlinie zur Nutzung von Cloud-Diensten, Abschnitt „Governance-Anforderungen“, Klausel 5.5, heißt es:

Shadow IT, definiert als Nutzung nicht genehmigter Cloud-Werkzeuge, muss als Richtlinienverstoß behandelt und durch den GM und den IT-Dienstleister überprüft werden, um Risiko und erforderliche Abhilfemaßnahmen zu bestimmen. Cloud Usage Policy-sme - SME

Für Unternehmensorganisationen erhöht die Richtlinie zur Nutzung von Cloud-Diensten, Abschnitt „Governance-Anforderungen“, Klausel 5.5, die Anforderungen an die Überwachung:

Das Informationssicherheitsteam muss Netzwerkverkehr, DNS-Aktivität und Protokolle regelmäßig bewerten, um unbefugte Cloud-Nutzung (Shadow IT) zu erkennen. Festgestellte Verstöße müssen unverzüglich untersucht werden. Cloud Usage Policy

Shadow IT ist nicht nur ein IT-Ärgernis. Unter GDPR kann sie zur unrechtmäßigen Offenlegung oder unkontrollierten Verarbeitung werden. Unter NIS2 ist sie eine Schwäche bei Cyberhygiene und Lieferkette. Unter DORA kann sie zu einem IKT-Drittparteienrisiko und einem Thema der Vorfallklassifizierung werden.

Säule 3: Grenzen mit DLP-Technologie, Richtlinien und Sensibilisierung verteidigen

ISO/IEC 27002:2022 Maßnahme 8.12, Verhinderung von Datenabfluss, ist die Kontrolle, die die meisten mit DLP verbinden. In einem ausgereiften Programm ist sie jedoch die letzte Verteidigungslinie, nicht die erste.

Die Zenith Blueprint erläutert, dass DLP einen dreischichtigen Ansatz erfordert: Technologie, Richtlinien und Sensibilisierung. Technologie umfasst Endpoint-DLP, E-Mail-Sicherheit, Inhaltsprüfung, Cloud-Zugriffssicherheit, SaaS-Kontrollen, Browser-Kontrollen, Filterung ausgehenden Netzwerkverkehrs und Weiterleitung von Warnmeldungen. Richtlinien definieren, was die Werkzeuge durchsetzen. Sensibilisierung stellt sicher, dass Mitarbeiter verstehen, warum private E-Mail, Cloud-Speicher für Verbraucher und nicht genehmigte KI-Werkzeuge keine zulässigen Handhabungsmethoden für regulierte oder vertrauliche Informationen sind.

Die Reaktionskomponente ist genauso wichtig wie Prävention. Die Zenith Blueprint, Schritt 19, stellt fest:

DLP ist jedoch nicht nur Prävention, sondern auch Reaktion. Wenn ein potenzieller Datenabfluss erkannt wird:

✓ Warnmeldungen sollten schnell triagiert werden, ✓ Protokollierung sollte forensische Analysen unterstützen, ✓ der Incident Response Plan muss unverzüglich ausgelöst werden.

Ein DLP-Programm, das Ereignisse blockiert, sie aber nicht triagiert, untersucht und daraus lernt, ist nicht auditbereit. Es ist nur teilweise ausgerollt.

Vom Tabellenabfluss zur auditbereiten Reaktion

Kehren wir zur Tabelle am Montagmorgen zurück.

In einem schwachen Programm entdeckt die Organisation den Upload drei Wochen später während einer Datenschutzprüfung. Niemand weiß, wer den Export genehmigt hat, ob es sich bei den Daten um personenbezogene Daten handelte, ob besondere Kategorien personenbezogener Daten betroffen waren, ob das KI-Werkzeug die Datei gespeichert hat oder ob Kunden benachrichtigt werden müssen.

In einem von Clarysec konzipierten Programm sieht die Abfolge anders aus.

Erstens wird der CRM-Export als Vertraulich gekennzeichnet, weil er personenbezogene Daten und kommerzielle Kundeninformationen enthält. Zweitens wird das Exportereignis protokolliert. Drittens erkennt das E-Mail-Gateway einen vertraulichen Anhang an eine private E-Mail-Domain und blockiert ihn, sofern keine genehmigte Ausnahme besteht. Viertens löst der versuchte Upload in einen nicht genehmigten Cloud-Service eine Warnmeldung zur Cloud-Nutzung aus. Fünftens wird die Warnmeldung anhand des Verfahrens zur Reaktion auf Informationssicherheitsvorfälle triagiert. Sechstens stellt das Sicherheitsteam fest, ob eine tatsächliche Offenlegung vorlag, ob die Daten verschlüsselt waren, ob der Anbieter sie verarbeitet oder gespeichert hat, ob GDPR-Kriterien für eine Verletzung erfüllt sind und ob Schwellenwerte für Vorfälle nach NIS2 oder DORA gelten.

Die KMU-Richtlinie zur Protokollierung und Überwachung, Abschnitt „Governance-Anforderungen“, Klausel 5.4.3, sagt dem Team genau, was sichtbar sein muss:

Zugriffsprotokolle: Dateizugriffe (insbesondere auf sensible oder personenbezogene Daten), Berechtigungsänderungen, Nutzung gemeinsamer Ressourcen Logging and Monitoring Policy - SME

Diese Klausel ist kurz, aber entscheidend. Wenn Dateizugriffe, Berechtigungsänderungen und die Nutzung gemeinsamer Ressourcen nicht protokolliert werden, wird die DLP-Untersuchung zur Spekulation.

Nach NIS2 Article 23 erfordern erhebliche Vorfälle eine gestufte Meldung: eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, eine Vorfallmeldung innerhalb von 72 Stunden und einen Abschlussbericht spätestens einen Monat nach der Vorfallmeldung. Nach DORA verlangen Articles 17 bis 19 von Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle zu erkennen, zu steuern, zu klassifizieren, aufzuzeichnen, zu eskalieren und zu melden. Die Klassifizierung umfasst Datenverlust mit Auswirkungen auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sowie betroffene Kunden, Dauer, geografische Ausbreitung, Kritikalität und wirtschaftliche Auswirkungen. Nach GDPR kann eine unbefugte Offenlegung personenbezogener Daten eine Bewertung der Verletzung und, bei Erreichen der Schwellenwerte, eine Meldung erforderlich machen.

Eine DLP-Warnmeldung ist daher nicht bloß ein Sicherheitsereignis. Sie kann zu einer Bewertung einer Verletzung des Schutzes personenbezogener Daten, einem NIS2-Vorfallsworkflow, einer DORA-IKT-Vorfallklassifizierung, einem Auslöser für Kundenbenachrichtigungen und einem Auditnachweispaket werden.

DLP-Kontrollen für GDPR Article 32

GDPR Article 32 wird häufig in eine Liste von Maßnahmen übersetzt: Verschlüsselung, Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit, Tests und Wiederherstellung. Für DLP ist der Schlüssel der Schutz über den gesamten Lebenszyklus.

Personenbezogene Daten bewegen sich durch Erhebung, Speicherung, Nutzung, Übertragung, Offenlegung, Aufbewahrung und Löschung. GDPR Article 5 verlangt Datenminimierung, Zweckbindung, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. GDPR Article 6 verlangt eine Rechtsgrundlage und Zweckkompatibilität. GDPR Article 9 verlangt strengere Schutzmaßnahmen für besondere Kategorien personenbezogener Daten.

DLP unterstützt diese Verpflichtungen, wenn es mit Datenklassifizierung, Aufzeichnungen zur rechtmäßigen Verarbeitung und genehmigten Übertragungswegen verbunden ist.

Clarysecs Richtlinie zur Datenmaskierung und Pseudonymisierung, Abschnitt „Zweck“, Klausel 1.2, unterstützt diesen Lebenszyklusansatz:

Diese Techniken sind verpflichtend, wenn Produktivdaten nicht erforderlich sind, einschließlich in Entwicklung, Analysen und Szenarien mit Drittdienstleistern, um das Risiko von Offenlegung, Missbrauch oder Verstößen zu reduzieren. Data Masking and Pseudonymization Policy-sme - SME

Dies ist eine praktische Kontrolle für GDPR Article 32. Wenn Entwickler, Analysten oder Lieferanten keine echten personenbezogenen Produktivdaten benötigen, sollte DLP nicht die einzige Barriere sein. Maskierung und Pseudonymisierung reduzieren den Schadensradius, bevor sich Daten überhaupt bewegen.

Eine starke, datenschutzorientierte DLP-Matrix sollte personenbezogene Datentypen Klassifizierungskennzeichnungen, Rechtsgrundlagen, genehmigten Systemen, genehmigten Exportmethoden, Verschlüsselungsanforderungen, DLP-Regeln, Aufbewahrungsregeln und Vorfallauslösern zuordnen. Diese Matrix wird zur Brücke zwischen Datenschutz-Governance und Sicherheitsbetrieb.

NIS2-Cyberhygiene und DLP jenseits des Datenschutzteams

NIS2 verändert die DLP-Diskussion, weil sie Datenabfluss als Teil von Cyberhygiene und Resilienz betrachtet, nicht nur als Datenschutzthema.

Article 20 verlangt von Leitungsorganen wesentlicher und wichtiger Einrichtungen, Cybersicherheits-Risikomanagementmaßnahmen zu genehmigen, deren Umsetzung zu überwachen und Cybersicherheitsschulungen zu erhalten. Article 21 verlangt geeignete und verhältnismäßige Maßnahmen in den Bereichen Richtlinien, Management von Informationssicherheitsvorfällen, Kontinuität, Lieferkette, sichere Entwicklung, Wirksamkeitsprüfung, Cyberhygiene, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle und Asset-Management. Article 25 fördert die Nutzung einschlägiger europäischer und internationaler Normen und technischer Spezifikationen.

DLP trägt direkt zu diesen Bereichen bei:

Die Netzwerksicherheitsrichtlinie, Abschnitt „Ziele“, Klausel 3.4, macht das Exfiltrationsziel ausdrücklich:

Verhinderung der Ausbreitung von Schadsoftware und der Datenexfiltration über Netzwerkkanäle Network Security Policy-sme - SME

Für NIS2 gibt ein solches Ziel Auditoren einen direkten Prüfpfad: ausgehende Filterung, DNS-Überwachung, Proxy-Protokolle, Endpoint-Warnmeldungen, blockierte Upload-Versuche und Untersuchungstickets vorlegen.

Die Zenith Blueprint, Schritt 23, ergänzt eine cloudspezifische Maßnahme, die für digitale und IKT-Anbieter im NIS2-Anwendungsbereich inzwischen wesentlich ist:

Listen Sie alle derzeit genutzten Cloud-Services (5.23) auf, einschließlich bekannter Shadow IT. Identifizieren Sie, wer sie genehmigt hat und ob gebotene Sorgfalt durchgeführt wurde. Entwickeln Sie eine schlanke Bewertungscheckliste, die Datenstandort, Zugriffsmodell, Protokollierung und Verschlüsselung abdeckt. Stellen Sie für künftige Services sicher, dass die Checkliste in den Beschaffungs- oder IT-Onboarding-Prozess integriert ist.

Viele Organisationen scheitern genau hier. Sie haben einen ISMS-Geltungsbereich und ein Lieferantenregister, aber keine echte Liste der SaaS-Werkzeuge, in denen Mitarbeitende regulierte Daten oder Kundendaten bewegen. DLP ohne Cloud-Discovery ist blind.

DORA-IKT-Risiko: DLP für Finanzunternehmen und Anbieter

Für Finanzunternehmen muss DLP in das IKT-Risikomanagementrahmenwerk von DORA passen.

DORA Article 5 verlangt ein internes Governance- und Kontrollrahmenwerk für das IKT-Risikomanagement. Das Leitungsorgan bleibt verantwortlich für IKT-Risiken, Richtlinien zur Wahrung von Datenverfügbarkeit, Authentizität, Integrität und Vertraulichkeit, klare IKT-Rollen, eine Strategie für digitale operationale Resilienz, IKT-Risikotoleranz, Kontinuitäts- sowie Reaktions- und Wiederherstellungspläne, Auditpläne, Ressourcen, Drittparteienrichtlinien und Meldekanäle.

Article 6 verlangt ein dokumentiertes IKT-Risikomanagementrahmenwerk, das Strategien, Richtlinien, Verfahren, IKT-Protokolle und Werkzeuge zum Schutz von Informationen und IKT-Assets umfasst. Article 9 behandelt Schutz und Prävention. Articles 11 bis 14 ergänzen Kontinuität, Reaktion, Wiederherstellung, Backup, Wiederherstellungstests, Datenintegritätsprüfungen, Lessons Learned, Sensibilisierungsschulungen und Krisenkommunikation.

DLP passt in dieses Rahmenwerk als Fähigkeit für Schutz, Erkennung, Reaktion und Tests.

DORA macht außerdem Drittparteienrisiken unvermeidbar. Articles 28 bis 30 verlangen IKT-Drittparteienrisikomanagement, Register der IKT-Dienstleistungsverträge, vorvertragliche gebotene Sorgfalt, vertragliche Anforderungen, Audit- und Inspektionsrechte, Kündigungsrechte, Exit-Strategien, Leistungsbeschreibungen, Orte der Datenverarbeitung und -speicherung, Datenzugriff, Wiederherstellung und Rückgabe, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Sicherheitsmaßnahmen und Bedingungen für Unterbeauftragungen.

Für ein Fintech oder eine Bank darf DLP nicht an der Grenze von Microsoft 365 oder Google Workspace enden. Es muss Zahlungsdienstleister, Anbieter für Identitätsprüfung, CRM-Plattformen, Data Warehouses, Cloud-Infrastruktur, ausgelagerte Support-Desks, Managed Service Provider und kritische SaaS-Integrationen abdecken.

Dies ist besonders wichtig, wenn DORA bei überschneidenden NIS2-Verpflichtungen als sektorspezifischer Rechtsakt der Union wirkt. Die Kontrollen müssen weiterhin bestehen. Der Melde- und Aufsichtsweg kann abweichen.

Ein 90-minütiger Sprint für eine DLP-Regel

Clarysec nutzt mit Kunden, die schnelle Fortschritte benötigen, einen praktischen Sprint, ohne vorzugeben, dass ein vollständiges DLP-Programm in einer einzigen Sitzung aufgebaut werden kann. Ziel ist die Umsetzung einer hochwertigen DLP-Kontrolle von der Richtlinie bis zum Nachweis.

Schritt 1: Einen Datentyp und einen Übertragungsweg auswählen

Wählen Sie „personenbezogene Kundendaten, die aus dem CRM exportiert und extern per E-Mail versendet werden“. Beginnen Sie nicht mit jedem Repository, jedem Land und jedem Datentyp.

Schritt 2: Klassifizierung und Kennzeichnung bestätigen

Nutzen Sie die Klassifizierungsrichtlinie, um zu bestätigen, dass dieser Export Vertraulich ist. In einem KMU verlangt Klausel 6.3.3 Verschlüsselung, eingeschränkten Zugriff, ausdrückliche Genehmigung für die Weitergabe und sichere Vernichtung. In einem Unternehmen unterstützt die Richtlinie zur Datenklassifizierung und Kennzeichnung die Blockierung der Übertragung falsch gekennzeichneter sensibler Daten und die automatisierte Prüfung mittels DLP und Discovery-Werkzeugen.

Schritt 3: Erlaubtes Übertragungsmuster definieren

Erlaubt: CRM-Export an eine genehmigte Kundendomain per verschlüsselter E-Mail oder über eine genehmigte sichere Dateifreigabeplattform, mit geschäftlicher Begründung.

Nicht erlaubt: private E-Mail, öffentliche Dateifreigabelinks, nicht genehmigte KI-Werkzeuge und unverwaltete Cloud-Laufwerke.

Dies entspricht der Zenith Blueprint, Schritt 22, die feststellt:

Wenn „vertrauliche“ Informationen das Unternehmen nicht ohne Verschlüsselung verlassen dürfen, müssen E-Mail-Systeme Verschlüsselungsrichtlinien durchsetzen oder externe Übertragungen blockieren.

Schritt 4: Minimale DLP-Regel konfigurieren

Konfigurieren Sie die E-Mail- oder Kollaborationsplattform so, dass sie die vertrauliche Kennzeichnung, ein Muster personenbezogener Daten oder die Namenskonvention für Exportdateien erkennt. Beginnen Sie mit Überwachung, wenn False Positives zu erwarten sind, und wechseln Sie anschließend zur Blockierung für private Domains und nicht genehmigte Empfänger.

Schritt 5: Protokollierung und Weiterleitung von Warnmeldungen aktivieren

Stellen Sie sicher, dass Protokolle Dateizugriffe, Berechtigungsänderungen und die Nutzung gemeinsamer Ressourcen erfassen, wie in der Logging and Monitoring Policy - SME gefordert. Leiten Sie Warnmeldungen mit Schweregrad, Datentyp, Absender, Empfänger, Dateiname, ergriffener Maßnahme und Prüfer an die Ticket-Warteschlange weiter.

Schritt 6: Drei Szenarien testen

Testen Sie eine genehmigte verschlüsselte Übertragung an einen Kunden, eine blockierte Übertragung an eine private E-Mail-Adresse und einen nur alarmierenden Upload-Versuch an eine nicht genehmigte Cloud-Domain.

Schritt 7: Nachweise sichern

Speichern Sie die Referenz auf die Richtlinienklausel, den Screenshot der DLP-Regel, Testergebnisse, das Alarmticket, die Entscheidung des Prüfers und die Genehmigung durch das Management. Nehmen Sie die Kontrolle in den Risikobehandlungsplan und die Erklärung zur Anwendbarkeit auf.

In Begriffen von ISO/IEC 27001:2022 verbindet diese Übung Clause 6.1.2 Risikobeurteilung, Clause 6.1.3 Risikobehandlung, Clause 8 operative Planung und Steuerung, Annex A Informationsübertragung, Verhinderung von Datenabfluss, Protokollierung, Überwachung, Lieferanten- und Cloud-Kontrollen sowie Clause 9 Leistungsbewertung.

Cross-Compliance-Zuordnung: Ein DLP-Programm, mehrere Verpflichtungen

Die Stärke des Clarysec-Ansatzes liegt darin, keine separaten Kontrollstapel für GDPR, NIS2, DORA, NIST und COBIT aufzubauen. Ein gut konzipiertes DLP-Programm kann mehrere Erwartungen erfüllen, wenn die Nachweise richtig strukturiert sind.

NIST CSF 2.0 ist als Kommunikationsebene nützlich. Die Funktion GOVERN unterstützt die Nachverfolgung rechtlicher, regulatorischer und vertraglicher Anforderungen, Risikobereitschaft, Richtliniendurchsetzung, Rollen und Aufsicht. Die Profile-Methode hilft Organisationen, aktuellen und angestrebten Zustand zu bestimmen, Lücken zu dokumentieren und einen Aktionsplan umzusetzen. Die Funktionen RESPOND und RECOVER unterstützen Eindämmung von DLP-Vorfällen, Ursachenanalyse, Beweissicherung und Wiederherstellung.

COBIT 2019 ergänzt eine Governance-Perspektive. Ein COBIT-orientierter Auditor wird fragen, ob DLP-Ziele an Unternehmenszielen ausgerichtet sind, ob Verantwortlichkeiten klar sind, ob Leistungsindikatoren bestehen, ob die Risikobereitschaft definiert ist und ob das Management aussagekräftige Berichte erhält.

Wie Auditoren Ihr DLP-Programm prüfen werden

DLP-Audits drehen sich selten um einen einzigen Screenshot. Unterschiedliche Audit-Hintergründe erzeugen unterschiedliche Nachweiserwartungen.

Ein starkes DLP-Auditpaket umfasst Geltungsbereich und Risikoaussage, Klassifizierungsschema, genehmigte Übertragungsmethoden, DLP-Regeln, Ausnahmegenehmigungen, Protokollierungsdesign, Verfahren zur Triage von Warnmeldungen, Entscheidungsbaum für Vorfallmeldungen, Lieferanten- und Cloud-Inventar, Testergebnisse und Aufzeichnungen zu Abhilfemaßnahmen.

Häufige DLP-Fehler im Jahr 2026

Die häufigsten DLP-Fehler sind operativ, nicht exotisch.

Erstens ist Klassifizierung optional oder uneinheitlich. Kennzeichnungen existieren in der Richtlinie, aber Benutzer wenden sie nicht an, Systeme setzen sie nicht durch und Repositories enthalten jahrelang unklassifizierte sensible Dateien.

Zweitens bleibt DLP dauerhaft im reinen Alarmmodus. Ein Alarmmodus ist während der Abstimmung nützlich, aber eine risikobehaftete Übertragung vertraulicher Kundendaten an eine private E-Mail-Adresse sollte letztlich blockiert werden, sofern keine genehmigte Ausnahme besteht.

Drittens wird Shadow IT als IT-Ärgernis statt als Datenschutzrisiko behandelt. Die Richtlinie zur Nutzung von Cloud-Diensten und die Richtlinie zur Nutzung von Cloud-Diensten für KMU sind darauf ausgelegt, nicht genehmigte Cloud-Werkzeuge sichtbar, überprüfbar und behebbar zu machen.

Viertens sind Protokolle für Untersuchungen nicht ausreichend. Wenn das Sicherheitsteam nicht rekonstruieren kann, wer zugegriffen, geteilt, heruntergeladen, hochgeladen oder Berechtigungen geändert hat, kann die Organisation Meldepflichten nach GDPR, NIS2 oder DORA nicht verlässlich bewerten.

Fünftens befinden sich Lieferanten außerhalb des DLP-Modells. DORA Articles 28 bis 30 machen dies für Finanzunternehmen besonders gefährlich; das Problem betrifft jedoch jeden Sektor. Verträge sollten Datenstandorte, Zugriff, Wiederherstellung, Rückgabe, Unterstützung bei Vorfällen, Sicherheitsmaßnahmen, Unterbeauftragung und Auditrechte definieren.

Sechstens umfasst Incident Response keine DLP-Szenarien. Eine fehlgeleitete E-Mail, ein unbefugter SaaS-Upload oder ein Massenexport aus dem CRM sollte ein Playbook, Schweregradkriterien und einen Entscheidungspfad für Meldungen haben.

Schließlich vergessen Organisationen physische und menschliche Kanäle. Die Zenith Blueprint erinnert daran, dass DLP auch Clean-Desk-Verhalten, sicheres Schreddern, gesperrte Druckwarteschlangen, Drucker-Auditprotokolle und Mitarbeitersensibilisierung umfasst. Ein DLP-Programm, das Papier, Screenshots und Gespräche ignoriert, ist unvollständig.

Ein DLP-Programm aufbauen, dem Auditoren vertrauen

Wenn Ihr DLP-Programm derzeit eine Werkzeugkonfiguration ist, ist 2026 das Jahr, es in ein gesteuertes, nachweisbasiertes Kontrollsystem zu überführen.

Beginnen Sie mit drei praktischen Maßnahmen:

1. Wählen Sie Ihre drei wichtigsten sensiblen Datentypen aus, zum Beispiel personenbezogene Kundendaten, Zahlungsdaten und Quellcode.
2. Kartieren Sie, wohin sie sich bewegen, einschließlich E-Mail, SaaS, Cloud-Speicher, Endpunkte, Programmierschnittstellen, Lieferanten und Entwicklungsumgebungen.
3. Bauen Sie je Datentyp eine durchsetzbare DLP-Regel auf, verknüpft mit Richtlinie, Protokollierung, Incident Response und Aufbewahrung von Nachweisen.

Clarysec kann Sie dabei durch die Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, die Zenith Controls: The Cross-Compliance Guide Zenith Controls und anpassungsbereite Richtlinien wie die Richtlinie zur Datenklassifizierung und Kennzeichnung Data Classification and Labeling Policy, Richtlinie für Remote-Arbeit Remote Work Policy, Richtlinie zur Nutzung von Cloud-Diensten Cloud Usage Policy, Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME und Richtlinie für mobile Geräte und Bring-Your-Own-Device (BYOD) Mobile device and byod policy unterstützen.

Das Ziel ist nicht, jede Datei an der Bewegung zu hindern. Das Ziel ist, sichere Bewegungen zum Standard zu machen, risikobehaftete Bewegungen sichtbar zu machen, verbotene Bewegungen zu blockieren und jede Ausnahme rechenschaftspflichtig zu dokumentieren.

Laden Sie die Clarysec-Toolkits herunter, überprüfen Sie Ihr DLP-Nachweispaket und buchen Sie eine Readiness-Bewertung, um zu prüfen, ob Ihre aktuellen Kontrollen einer Prüfung nach GDPR Article 32, den Erwartungen an NIS2-Cyberhygiene und einer DORA-IKT-Risikoprüfung standhalten.