DLP für Exchange Online und Teams: E-Mail und Chat absichern, ohne die Kommunikation zu ersticken

Die meisten Datenpannen, die ich in zwanzig Jahren gesehen habe, waren keine Angriffe. Sie waren E-Mails. Die Gehaltsliste als Anhang an den falschen „Müller" aus der Autovervollständigung. Die Kundenliste an die private Adresse, weil man am Wochenende weitermachen wollte. Der Vertragsentwurf per „Allen antworten" an einen Verteiler, in dem der Wettbewerber saß. Und seit Teams dazugekommen ist, kommt eine neue Klasse hinzu: die IBAN im Chat mit dem externen Berater, das Passwort im Kanal, in dem noch drei Gäste vom letzten Projekt sitzen. E-Mail und Chat sind die Kanäle, auf denen Daten das Haus im Alltag verlassen – nicht per USB-Stick, sondern per Senden-Knopf.

Data Loss Prevention für Exchange Online und Microsoft Teams setzt genau an diesem Knopf an. In Outlook zeigt es beim Schreiben einen Hinweis, prüft die Mail im Transport und kann sie blockieren, verschlüsseln oder mit Begründung durchlassen. In Teams prüft es Chats und Kanalnachrichten nach dem Senden und ersetzt sie bei Bedarf durch einen Platzhalter. Dieselbe Richtlinie, dieselben Sensitive Info Types, dieselben Labels – aber zwei sehr unterschiedliche Kanäle mit eigenen Feinheiten: Anhänge, Passwortschutz, Verteiler, Gäste, Federation, und die Frage, wie sich das alles zu den guten alten Transportregeln verhält, die in vielen Exchange-Umgebungen seit Jahren dasselbe zu tun versuchen.

Dieser Artikel zeigt, was DLP in Exchange und Teams prüft und was nicht, welche Bedingungen und Aktionen den Alltag treffen, wie du Regeln baust, die den Geschäftsbrief durchlassen und die Kundenliste anhalten, und wie Policy Tips und erzwungene Verschlüsselung aus einer Blockade einen Ausweg machen. Der Einführungsweg – Simulation, Tips, Override, Blocking – ist im Spoke zur DLP-Einführung beschrieben und gilt hier unverändert; wo DLP im Gesamtbild von Purview steht, zeigt der Überblick zum Kompetenzbereich Microsoft Purview.

E-Mail: der klassische Abflusskanal und wie Exchange-DLP ihn prüft

Exchange Online hat unter allen Purview-Speicherorten die reifste DLP-Integration – kein Wunder, E-Mail war der Kanal, für den Microsoft DLP ursprünglich gebaut hat, lange bevor es Purview hieß. Das merkt man an zwei Dingen: Die Prüfung ist tief (bis in Anhänge und Archive hinein), und der Policy Tip ist dort am ausgereiftesten, wo er hingehört – beim Schreiben, bevor die Mail das Haus verlassen hat. Trotzdem stolpern Projekte regelmäßig über dieselben Details: Was genau wird geprüft, welche Bedingungen gibt es jenseits von „enthält IBAN", und was passiert mit den Transportregeln, die seit Jahren dasselbe versuchen?

Was geprüft wird: Text, Betreff, Kopfzeilen und der Anhang mit seinen Tücken

Exchange-DLP liest die ganze Nachricht: den Text, den Betreff, die Kopfzeilen und jeden Anhang, den es öffnen kann – Office-Formate, PDF, Textdateien, und den Inhalt von ZIP-Archiven eine Ebene tief. Bilder werden nicht per OCR gelesen; ein Foto der Kundenliste geht durch. Und dann gibt es die Anhänge, die DLP nicht öffnen kann: passwortgeschützte Office-Dateien, verschlüsselte ZIPs, unbekannte Formate. Genau dafür gibt es eine eigene Bedingung – „Dokument konnte nicht gescannt werden" oder „ist passwortgeschützt" –, und die ist in Projekten regelmäßig die interessanteste Regel überhaupt: Wer eine passwortgeschützte ZIP an eine externe Adresse schickt, tut das selten aus Versehen. Eine Warnregel dafür findet Prozesse, von denen niemand wusste, und schließt gleichzeitig die naheliegendste Umgehung des ganzen Systems.

Die Bedingungen jenseits des Inhalts sind der zweite große Hebel. Exchange-DLP kennt den Kontext einer Mail: Geht sie nach außen? An welche Domäne? Von welcher Domäne? An wie viele Empfänger? Wie groß ist sie? Welche Anhangstypen hängen dran? Trägt sie oder ein Anhang ein Sensitivity Label? Kommt sie von einem bestimmten Absender oder einer Gruppe? Diese Kontextbedingungen sind der Grund, warum eine gute Exchange-Regel selten „enthält IBAN, dann warnen" lautet, sondern „Empfänger außerhalb der Organisation UND nicht Partnerdomäne UND enthält drei oder mehr IBANs mit hoher Konfidenz UND kein Label ‚Öffentlich‘ – dann blockieren mit Override". Wie die Inhaltsbedingungen dahinter gebaut werden, damit sie Kundenlisten treffen und Geschäftsbriefe in Ruhe lassen, steht im Spoke zu Sensitive Info Types und Klassifizierern.

Skizze 1: Der Mailfluss mit DLP-Prüfpunkt – Policy Tip beim Schreiben, Prüfung im Transport, Aktion vor der Zustellung.

Aktionen: vom Hinweis über die Verschlüsselung bis zum Block

Die Aktionen einer Exchange-Regel sind reicher als bei jedem anderen Speicherort. Der Policy Tip erscheint in Outlook Desktop, im neuen Outlook und in Outlook im Web schon beim Schreiben, sobald die Bedingung erkennbar ist – ein Satz über dem Betreff, gern mit Link zur Hilfe. Blockieren mit Override liefert dem Absender eine Rückmeldung mit Erklärung und lässt ihn mit Begründung erneut senden. Blockieren ohne Override ist der Hartblock. Dazwischen liegt die Aktion, die Exchange-DLP von allen anderen unterscheidet: Verschlüsselung erzwingen. Statt die Mail anzuhalten, wendet die Regel ein Sensitivity Label mit Verschlüsselung oder die Nachrichtenverschlüsselung („Nur verschlüsseln", „Nicht weiterleiten") an – die Mail geht raus, aber nur der Empfänger kann sie öffnen. Für Personaldaten an den Steuerberater ist das die richtige Antwort; für Kundenlisten an eine Gmail-Adresse nicht. Ergänzt wird das Ganze durch Benachrichtigungen an Vorgesetzte oder Datenschutz, Vorfallberichte mit dem Treffer im Detail und Alarme nach Schweregrad. Was Verschlüsselung per Label im Detail leistet und welche Ausnahmen sie braucht, steht im Spoke zur Verschlüsselung per Sensitivity Label.

DLP oder Transportregel? Beides – aber mit klarer Arbeitsteilung

In fast jeder gewachsenen Exchange-Umgebung gibt es Transportregeln (Mail Flow Rules), die Inhalte prüfen: „Wenn Betreff enthält ‚vertraulich‘, dann verschlüsseln." Sie funktionieren, sie sind alt, und niemand traut sich, sie anzufassen. Meine Empfehlung ist eine klare Arbeitsteilung: Transportregeln bleiben für alles, was Routing und Form betrifft – Disclaimer, Weiterleitung an Archive, Moderation, Anhangsgrößen, Partnerverschlüsselung per Domäne. Inhaltsbasierter Schutz mit Sensitive Info Types und Labels wandert in Purview-DLP, weil dort die Simulation, die Policy Tips, die Override-Begründungen, die Alarme und die Berichte liegen, die eine Transportregel nie hatte. Wo beide dieselbe Bedingung prüfen, entstehen doppelte Verschlüsselung, widersprüchliche Hinweise und Effekte, die niemand mehr nachvollziehen kann. Also: inventarisieren, die inhaltsprüfenden Transportregeln eine nach der anderen durch DLP-Regeln ersetzen – im Simulationsmodus parallel laufen lassen, vergleichen, dann die alte abschalten.

Die Tabelle stellt Bedingungen und Aktionen für Exchange und Teams nebeneinander. Die Unterschiede in der letzten Spalte sind der Grund, warum eine Richtlinie zwar beide Speicherorte enthalten kann, die Regeln darin aber je Kanal anders aussehen.

Teams: Chat, Kanal, Gäste – und warum die Nachricht schon weg ist

Teams-DLP funktioniert nach demselben Prinzip wie Exchange-DLP, aber mit einem Unterschied, der alles verändert: In Outlook sieht der Anwender den Hinweis, bevor er auf Senden klickt. In Teams klickt er auf Senden, die Nachricht erscheint im Chat, und Sekunden bis wenige Minuten später prüft DLP – und ersetzt die Nachricht, wenn die Regel zieht, durch einen Platzhalter: „Diese Nachricht wurde aufgrund einer Richtlinie blockiert." Der Absender bekommt einen Policy Tip mit Erklärung und gegebenenfalls Override-Option, der Empfänger sieht nur den Platzhalter. Das heißt: Teams-DLP ist kein Echtzeitfilter. In den Sekunden dazwischen ist die Nachricht lesbar und ein Bildschirmfoto möglich. Es ist ein Erziehungs- und Nachweiswerkzeug, das Gewohnheiten korrigiert und Vorfälle dokumentiert – wer mehr erwartet, wird enttäuscht, wer weniger erwartet, verschenkt ein sehr wirksames Mittel.

Chat, Kanal, Besprechung: was erfasst wird

Teams-DLP erfasst Nachrichten in 1:1-Chats, Gruppenchats, Standard- und privaten Kanälen sowie in Besprechungschats – und zwar unabhängig davon, ob die Gegenseite ein Kollege, ein Gast im eigenen Tenant oder ein externer Benutzer aus einem anderen Tenant per Federation ist. Die Bedingung „Empfänger außerhalb der Organisation" funktioniert auch hier und ist auch hier der wichtigste Schalter: Ein Chat unter Kollegen darf IBANs enthalten; ein Chat mit dem externen Berater sollte zumindest einen Hinweis auslösen. Für Shared Channels gilt die Richtlinie des Tenants, der den Kanal hostet – wer als Gast in einem fremden Shared Channel schreibt, unterliegt fremden Regeln. Und was Teams-DLP nicht erfasst: die Dateien. Ein Anhang im Chat liegt in OneDrive des Absenders, eine Datei im Kanal in der SharePoint-Site des Teams – dafür ist die SharePoint-/OneDrive-DLP zuständig, und die gehört in dieselbe Richtlinie, sonst hat man einen Chat, der die IBAN im Text blockiert und die Excel-Datei mit tausend IBANs durchlässt.

Skizze 2: Teams-Chat mit DLP – die Nachricht ist bereits sichtbar, wenn geprüft wird; die Regel ersetzt sie durch einen Platzhalter.

Regeln, die den Alltag treffen: Kontext zuerst, Inhalt danach

Die meisten Fehlalarme in Exchange- und Teams-DLP entstehen nicht durch schlechte Sensitive Info Types, sondern durch Regeln, die den Kontext ignorieren. „Enthält IBAN, dann warnen" trifft jeden Geschäftsbrief mit Bankverbindung in der Fußzeile, intern wie extern. Eine gute Regel fragt in dieser Reihenfolge: An wen geht die Nachricht? Ist der Empfänger ein Partner mit Vertrag? Was steckt drin, wie oft, mit welchem Label? Und erst dann: Wie hart reagieren wir? Diese Reihenfolge ist keine Stilfrage – sie entscheidet darüber, ob die Belegschaft die Hinweise ernst nimmt oder wegklickt.

Externe Empfänger sind die Schlüsselbedingung. Interner Mailverkehr bleibt in fast allen Projekten auf Audit; die Ausnahme sind „Streng vertraulich"-Inhalte an große Verteiler. Für externe Empfänger folgt die zweite Frage: Ist die Domäne ein Partner mit Vertrag – Steuerberater, Kanzlei, Auftragsverarbeiter? Dann ist die richtige Antwort nicht Blockieren, sondern Verschlüsselung erzwingen; die Ausnahmeliste der Partnerdomänen ist die wichtigste Pflegeaufgabe im Betrieb. Für alle anderen externen Ziele entscheidet der Inhalt: Ein bis zwei Treffer ohne Label sind der Geschäftsbrief und bekommen einen Policy Tip; eine Liste ab drei Treffern oder ein „Vertraulich"-Label bekommt Blockieren mit Override – oder besser noch erzwungene Verschlüsselung als Ausweg; „Streng vertraulich" wird blockiert, weil dafür der Datenraum da ist. Und die passwortgeschützte ZIP an extern bekommt ihre eigene Warnregel, ganz unabhängig vom Inhalt.

Skizze 3: Die Regellogik für eine E-Mail – erst der Kontext (an wen), dann der Inhalt (was), dann die Aktion (wie hart).

Als Umsetzungshilfe fünf Startregeln, mit denen ich Exchange- und Teams-DLP in Projekten typischerweise beginne. Alle starten im Simulationsmodus; die Spalte „Zielstufe" nennt die Stufe, auf der sie nach der Einführung dauerhaft laufen.

Policy Tips in Outlook und Teams – und Verschlüsselung als Ausweg statt Blockade

Ein Policy Tip in Outlook ist die eleganteste Form von DLP, die es gibt: Der Anwender tippt die externe Adresse ein, fügt die Kundenliste an, und über dem Betreff erscheint ein Satz – „Diese Nachricht enthält Bankdaten von Kunden und geht an einen externen Empfänger. Bitte prüfen. Fragen? Hier klicken." Kein Fenster, keine Blockade, keine Begründungspflicht. Der Anwender liest, denkt nach, ändert oder sendet. Nach vier Wochen weiß die Belegschaft, was Kundendaten sind. In Teams ist derselbe Mechanismus rauer, weil die Nachricht erst nach dem Senden verschwindet – umso wichtiger ist dort ein Tipptext, der erklärt, was passiert ist und was der Anwender jetzt tun kann. Beide Texte formuliere ich in Projekten mit einem Vertreter des Fachbereichs und lasse sie von jemandem lesen, der nichts mit IT zu tun hat.

Der zweite Gedanke, der Exchange-DLP von einer Blockade zu einem Werkzeug macht: Verschlüsseln statt blocken. Viele Fälle, in denen eine Regel eine Mail anhält, sind legitime Geschäftsvorgänge – Personaldaten an den Steuerberater, Vertragsentwürfe an die Kanzlei, Patientendaten an das Labor. Wer sie blockiert, erzeugt Overrides und Frust; wer sie mit erzwungener Verschlüsselung durchlässt, hat den Schutz erreicht, ohne den Prozess zu stören. Ein Sensitivity Label mit Verschlüsselung als DLP-Aktion oder die Nachrichtenverschlüsselung „Nur verschlüsseln" sind dafür die Werkzeuge; der Empfänger öffnet die Mail nach einer einmaligen Anmeldung oder mit einem Einmalcode. Was im Betrieb daraus wird – wer die Alarme sieht, wer die Partnerliste pflegt, wie oft die Regeln nachgeschärft werden –, ist Thema des Spokes zu DLP im Betrieb.

Der Deutschland-Winkel: E-Mail-Verschlüsselung, Gäste und der Betriebsrat

Die deutschen Aufsichtsbehörden haben zur E-Mail-Verschlüsselung eine klare Haltung: Personenbezogene Daten mit hohem Risiko – Gesundheitsdaten, Bonitätsinformationen, Personalunterlagen – gehören nicht unverschlüsselt in eine E-Mail; die Orientierungshilfe der Datenschutzkonferenz zu Maßnahmen beim E-Mail-Versand macht das seit Jahren deutlich, und Bußgeldverfahren wegen unverschlüsselter Gehaltsabrechnungen per Mail sind dokumentiert. Exchange-DLP mit erzwungener Verschlüsselung ist das Werkzeug, mit dem diese Anforderung technisch durchgesetzt wird, statt sie in einer Richtlinie zu wünschen – und genau so sollte der Datenschutzbeauftragte sie im Verzeichnis der Verarbeitungstätigkeiten und in der TOM-Dokumentation nach Art. 32 DSGVO führen. Für Teams gilt dasselbe für den Chat: Gäste und externe Benutzer sind Empfänger im Sinne der DSGVO, und ein Chat mit dem Berater ist eine Übermittlung.

Beim Betriebsrat sind Exchange- und Teams-DLP das, was DLP überall ist: eine technische Einrichtung, die aufzeichnet, wer wann welche sensiblen Inhalte an wen gesendet hat, mit Override-Begründungen im Wortlaut – § 87 Abs. 1 Nr. 6 BetrVG in Reinform, mitbestimmungspflichtig ab dem Simulationsmodus. Zwei Punkte sind kanalspezifisch: Auf Postfächern mit erlaubter Privatnutzung erfasst DLP auch private Mails mit Treffern – die private Steuererklärung an den eigenen Berater etwa; das gehört in die Datenschutzinformation für die Beschäftigten und ist ein weiteres Argument für klare Regeln zur Privatnutzung. Und Teams-Chats sind für viele Beschäftigte informeller als E-Mail; dass dort dieselben Regeln gelten, sollte in der Betriebsvereinbarung ausdrücklich stehen, damit niemand überrascht ist. Für NIS2-pflichtige Unternehmen liefern beide Kanäle greifbare Nachweise für den Schutz vor Datenabfluss aus dem Maßnahmenkatalog. Wie immer: keine Rechtsberatung, Stand 2026 – Datenschutzbeauftragter, Betriebsrat und bei Bedarf ein Jurist gehören an den Tisch, bevor die erste Regel simuliert.

Stolperfallen aus der Praxis

Kein „extern" in der Bedingung. Die Regel prüft nur den Inhalt und trifft jeden internen Geschäftsbrief mit Bankverbindung. Interner Verkehr bleibt Audit; „Empfänger außerhalb der Organisation" ist die erste Bedingung, nicht die letzte.

Transportregeln und DLP prüfen dasselbe. Doppelte Verschlüsselung, widersprüchliche Hinweise, Effekte, die niemand versteht. Inhaltsprüfung inventarisieren, in DLP überführen, alte Regel erst nach Parallellauf abschalten.

Teams-Dateien werden vergessen. Die Richtlinie deckt Teams-Chat ab, aber nicht SharePoint und OneDrive – die IBAN im Text wird ersetzt, die Excel-Datei mit tausend IBANs geht durch. Beide Speicherorte in dieselbe Richtlinie.

Der Teams-Tipptext ist der Richtlinienname. „Nachricht blockiert wegen DLP-TEAMS-002" führt zu „Teams ist kaputt" und WhatsApp. Ein Satz Warum, ein Satz Was tun, Hilfelink – vor dem Scharfschalten.

Partnerdomänen ohne Ausnahme. Steuerberater, Kanzlei und Lohnabrechner werden blockiert wie jede fremde Domäne; die Overrides häufen sich, die Begründungen werden zur Floskel. Partnerliste pflegen, Verschlüsselung erzwingen statt blocken.

Verschlüsselung erzwungen, Empfänger kann nicht öffnen. Die Regel wendet ein Label mit Verschlüsselung für „alle Mitarbeiter" an – der externe Empfänger sieht „nicht berechtigt". Für Mails an extern die Nachrichtenverschlüsselung oder ein Label mit Empfängerrechten nutzen; vorher mit einem echten externen Postfach testen.

Fazit: Der Senden-Knopf ist die Stelle, an der DLP erzieht

E-Mail und Chat sind die Kanäle, auf denen Daten das Haus im Alltag verlassen, und Exchange- und Teams-DLP sind die Werkzeuge, die genau dort ansetzen: mit dem Policy Tip beim Schreiben, der Prüfung im Transport, dem Platzhalter im Chat – und mit der Verschlüsselung als Ausweg, der aus einer Blockade einen sicheren Geschäftsvorgang macht. Kontext vor Inhalt, Partnerausnahmen mit Verschlüsselung, Anhänge und passwortgeschützte ZIPs im Blick, Teams-Dateien über SharePoint-DLP mitgedacht, Transportregeln sauber abgelöst: Das ist der Unterschied zwischen einer Richtlinie, die stört, und einer, die erzieht. Wo E-Mail- und Chat-DLP im Gesamtbild aus Labels, Endpoint DLP und Copilot-Absicherung stehen, zeigt der Purview-Überblick; die Lizenzfrage – Exchange ab E3, Teams-Chat prüfen – behandelt der Spoke zur Purview-Lizenzierung. Und was auf dem Client passiert, wenn die Datei gar nicht erst per Mail geht, sondern per USB, steht im Spoke zu Endpoint DLP.

Wenn du wissen willst, welche Transportregeln in deinem Exchange heute Inhalte prüfen, welche Partnerdomänen unverschlüsselt Personaldaten bekommen und wie ein Regelwerk für Mail und Chat aussähe, das die Belegschaft nicht auf WhatsApp treibt: Die Purview-Standortbestimmung liefert genau das – kompakt, zum Festpreis, mit Regelentwürfen im Simulationsmodus.

FAQ: Häufige Fragen zu DLP für Exchange Online und Teams

Was prüft DLP für Exchange Online genau?

Exchange-DLP prüft ausgehende und interne E-Mails im Transport: Nachrichtentext, Betreff, Kopfzeilen und Anhänge – Office-Dateien, PDF, Textformate und den Inhalt von ZIP-Archiven. Bilder werden nicht per Texterkennung gelesen; passwortgeschützte oder nicht scanbare Anhänge lassen sich über eine eigene Bedingung erkennen. Neben dem Inhalt kennt Exchange-DLP den Kontext: externe Empfänger, Domänen, Empfängerzahl, Größe, Anhangstypen und Sensitivity Labels.

Brauche ich für DLP in Exchange und Teams Microsoft 365 E5?

Für Exchange Online nicht: DLP für E-Mail mit Policy Tips, Override, Blockieren und erzwungener Verschlüsselung ist ab Microsoft 365 E3 enthalten. Für DLP in Teams-Chat- und Kanalnachrichten nennt Microsoft in den Lizenzunterlagen Microsoft 365 E5, E5 Compliance oder E5 Information Protection & Governance – das sollte vor der Planung tagesaktuell geprüft werden (Stand 2026). Dateien in Teams laufen ohnehin über SharePoint-/OneDrive-DLP, das in E3 enthalten ist.

Blockiert Teams-DLP eine Nachricht, bevor sie gesendet wird?

Nein. Teams-DLP prüft die Nachricht kurz nach dem Senden – Sekunden bis wenige Minuten – und ersetzt sie bei einem Treffer für alle Beteiligten durch einen Platzhalter; der Absender erhält einen Policy Tip mit Erklärung und gegebenenfalls Override-Option. In der Zwischenzeit ist die Nachricht lesbar. Teams-DLP ist deshalb ein Erziehungs- und Nachweiswerkzeug, kein Echtzeitfilter.

Prüft Teams-DLP auch Dateien, die im Chat geteilt werden?

Nicht direkt. Dateien in Chats liegen im OneDrive des Absenders, Dateien in Kanälen in der SharePoint-Site des Teams – sie werden von der SharePoint-/OneDrive-DLP erfasst, nicht von der Teams-DLP. Deshalb sollten Teams, SharePoint und OneDrive in derselben DLP-Richtlinie als Speicherorte stehen; sonst wird die IBAN im Text blockiert und die Excel-Datei mit tausend IBANs durchgelassen.

Was ist der Unterschied zwischen DLP und Exchange-Transportregeln?

Transportregeln (Mail Flow Rules) steuern Routing und Form – Disclaimer, Weiterleitung, Moderation, Anhangsgrößen, Partnerverschlüsselung per Domäne – und können auch Inhalte prüfen, aber ohne Simulation, Policy Tips, Override-Begründungen und Berichte. Purview-DLP ist für den inhaltsbasierten Schutz mit Sensitive Info Types und Labels zuständig und bringt genau diese Werkzeuge mit. Empfehlung: Inhaltsprüfung in DLP überführen, Transportregeln für Routing behalten, keine Bedingung doppelt prüfen.

Kann DLP eine E-Mail automatisch verschlüsseln statt sie zu blockieren?

Ja. Exchange-DLP kann als Aktion ein Sensitivity Label mit Verschlüsselung oder die Nachrichtenverschlüsselung („Nur verschlüsseln", „Nicht weiterleiten") anwenden. Die Mail geht dann raus, aber nur der Empfänger kann sie nach Anmeldung oder mit Einmalcode öffnen. Für Personaldaten an Steuerberater, Kanzleien oder Auftragsverarbeiter ist das die bessere Antwort als eine Blockade – vorausgesetzt, das verwendete Label räumt externen Empfängern auch Rechte ein.

Wo fange ich mit DLP für E-Mail und Chat an?

Mit Betriebsrat und Datenschutzbeauftragtem, dann mit einer Inventur der Transportregeln, die heute Inhalte prüfen, und mit drei bis fünf Regeln im Simulationsmodus: Kundendaten und Personaldaten an externe Empfänger, Label „Vertraulich" und „Streng vertraulich" nach extern, passwortgeschützte Anhänge nach extern – jeweils mit „Empfänger außerhalb der Organisation" als erster Bedingung und Partnerdomänen als Ausnahme mit erzwungener Verschlüsselung. Nach zwei bis vier Wochen Simulation folgen Policy Tips mit verständlichen Texten, dann Override, und Blockieren nur für „Streng vertraulich".