E-Discovery mit gemischten Formaten: Die Compliance-Lücke schließen
Eine Anfrage zur Dokumentenproduktion trifft ein. Der Bestand umfasst fünf Formate: PDF-Verträge, Word-Dokumente, Excel-Tabellen, CSV-Exporte und JSON-Protokolle. Jedes Format braucht ein anderes Tool. Das ist das Problem.
Ein Everlaw-Bericht zur E-Discovery von 2025 zeigt: Rechtsteams nutzen im Durchschnitt 3,2 Tools für Produktionen mit gemischten Formaten. Der operative Aufwand ist hoch. Das Compliance-Risiko ist höher.
Unsere Compliance-Übersicht und Sicherheitspraktiken erläutern, wie wir Dokumentenproduktionen handhaben.
Warum Tool-Fragmentierung Lücken schafft
Verschiedene Tools bedeuten verschiedene Standards. Drei Schwachstellen entstehen dadurch.
Die Entitätsabdeckung variiert je Tool. Adobe Acrobat sucht nach Textzeichenfolgen, die Sie manuell eingeben. Es erkennt keine Entitäten automatisch. Ein Word-Makro erfasst möglicherweise Namen und E-Mail-Adressen. Es übersieht wahrscheinlich mehr als 280 andere Entitätstypen. Excel-Suche-und-Ersetzen findet nur, was eingegeben wurde. Dieselbe Sozialversicherungsnummer in einer PDF und einer Excel-Datei kann von verschiedenen Tools unterschiedlich behandelt werden.
Prüfprotokolle sind fragmentiert. Jedes Tool protokolliert seine eigenen Aktionen — oder gar nichts. Eine Datenschutzbehörde fragt möglicherweise, wie alle personenbezogenen Daten gefunden und verarbeitet wurden. Drei separate Protokolle aus drei Tools sind eine schwache Antwort.
Einstellungen driften auseinander. Die vor sechs Monaten festgelegte PDF-Schwärzungsregel stimmt möglicherweise nicht mit dem letzte Woche aktualisierten Word-Makro überein. Die Lücke bleibt verborgen, bis ein Produktionsfehler sie aufdeckt.
Gerichte haben dieses Problem angesprochen. Sanktionen für E-Discovery-Fehler wurden mit inkonsistenten Standards bei verschiedenen Dokumenttypen in einer einzigen Produktion begründet. Gerichte erwarten einen systematischen Prozess. Format-spezifische Tools arbeiten dagegen.
Die DSAR-Konsistenzanforderung
DSGVO-DSARs enthalten eine im Gesetz verankerte Konsistenzregel.
Artikel 15 verlangt, dass die betroffene Person Informationen über alle gespeicherten personenbezogenen Daten erhält. Nicht alle Daten in PDFs und die meisten in Word-Dokumenten. Alle.
Die ICO-DSAR-Leitlinien sind klar. Organisationen müssen einen systematischen Ansatz über alle Systeme und Formate hinweg anwenden. Eine einheitliche Methodik ist erforderlich. Format-spezifische Tools mit unterschiedlichen Standards erfüllen diese Anforderung nicht.
Wenn eine Datenschutzbehörde eine DSAR-Beschwerde untersucht, entstehen vier Fragen:
- Welcher Prozess hat alle personenbezogenen Daten gefunden?
- Welche Tools haben welche Dokumenttypen verarbeitet?
- Welche Entitätstypen wurden in jedem Format gesucht?
- Welches Prüfprotokoll belegt die Vollständigkeit?
Separate Tools mit separaten Protokollen können die Fragen 3 und 4 nicht sauber beantworten.
Der Vorteil einer einheitlichen Engine
Eine einheitliche Engine wendet dieselbe Erkennungslogik auf jedes Format an. Vier Vorteile ergeben sich daraus.
Einheitliche Entitätsabdeckung. Ein Preset mit 32 Entitätstypen verarbeitet eine PDF, DOCX, XLSX und CSV auf dieselbe Weise. Die Sozialversicherungsnummer in Excel erhält denselben Konfidenzwert wie die in der PDF.
Ein einziges Prüfprotokoll. Ein Protokoll deckt alle Dateien in einem Stapel ab. Es zeigt Dateiname, Typ, erkannte Entitäten, Konfidenzwerte und ergriffene Maßnahmen. Ein Dokument belegt die Compliance für die gesamte Produktion.
Referenzielle Integrität. Angenommen, „Sarah Johnson" erscheint in einem PDF-Vertrag, einem Word-Brief und einer Excel-Tabelle. Derselbe Token — PERSON_0001 — ersetzt ihren Namen in allen drei. Die betroffene Person kann ihr Datensatz durch die gesamte Produktion verfolgen.
Einfacherer Workflow. Legen Sie 15 Dateien in verschiedenen Formaten in einen Stapel. Wenden Sie ein Preset an. Erhalten Sie 15 anonymisierte Ausgaben und einen Prüfbericht. Drei separate Tool-Workflows werden zu einem.
Mehr zur Anwendung von Presets auf Stapelverarbeitungen finden Sie in unserem Leitfaden zur DSGVO-DSAR-Stapelverarbeitung.
US-FOIA: Dasselbe Problem in größerem Maßstab
US-Bundesbehörden stehen vor der Mehrformat-Herausforderung bei höherem Volumen.
FOIA-Anfragen umfassen Legacy-Mainframe-Exporte, moderne Word-Dokumente, gescannte PDF-Archive sowie CSV- und JSON-Datenbankexporte. Keine Behörde verwendet nur ein Format.
DOJ und HHS haben beide automatisierte Schwärzungssysteme erprobt. Manuelle Mehrformat-Verarbeitung skaliert nicht mit ihren Anfragevolumen. Jede Pilotierung hatte dieselbe Grundanforderung: ein Ausnahmestandard für alle Formate. Ein dokumentiertes Prüfprotokoll war ebenfalls erforderlich.
Dasselbe Prinzip gilt außerhalb der Bundesbehörden. Jede Organisation mit Mehrformat-Compliance benötigt dasselbe. Ein Standard. Ein Prüfprotokoll. Das ist die Grundlage vertretbarer Compliance-Nachweise.
Fallstudie: Anwaltskanzlei
Eine mittelgroße Anwaltskanzlei bearbeitete DSGVO-DSARs für Unternehmenskunden.
Vor der Vereinheitlichung nutzte die Kanzlei vier verschiedene Tools. Adobe Acrobat bearbeitete PDFs. Ein Word-Makro bearbeitete DOCX-Dateien — nur Namen und E-Mails. Excel-Suche-und-Ersetzen bearbeitete XLSX-Dateien. CSV-Exporte wurden manuell geprüft. Jeder DSAR dauerte 8–12 Stunden. Nur 2–3 Entitätstypen wurden einheitlich über alle Formate geprüft.
Danach verarbeitete eine einheitliche Engine alle Formate in einem Stapel. Das Preset: „DSAR EU Individual." Die Engine prüfte 32 Entitätstypen einheitlich über alle Formate. Jeder DSAR dauerte unter einer Stunde. Ein Prüfbericht ging an den DSB zur Freigabe.
Die Kanzlei kann jetzt eine einheitliche Entitätsabdeckung über alle Dokumenttypen in einer DSAR-Produktion nachweisen. Ein Prüfdokument deckt jede Antwort ab. Die Zeit sank von 8–12 Stunden auf unter eine Stunde. Das ist eine erhebliche operative Veränderung. Der Wandel machte DSAR-Compliance zu einem skalierbaren Service.
Verwandter Artikel: Dokumentenformat-Fragmentierung und PII-Anonymisierung.
Fazit
Format-Fragmentierung ist eine Compliance-Haftung. Verschiedene Tools bedeuten verschiedene Standards. Verschiedene Standards erzeugen Prüflücken. Prüflücken bringen Regulierungsrisiken.
Eine einheitliche Engine behebt dies an der Quelle. Ein Erkennungsstandard. Ein Prüfprotokoll. Ein Workflow — für jedes Format.