Legal / Compliance Landscape

Begriffe vor dem Lesen

• Obligation Register — geführte Liste rechtlicher und vertraglicher Pflichten mit Umfang, verantwortliche Person, Frist und betroffenem Datenobjekt — kein Wiki-Absatz.
• Legal Hold — befristetes Verbot von Löschung, Überschreiben und unkontrollierter Ableitung für einen Identifier-Kreis.
• Retention — Regel, wann Daten nach Zweckende gelöscht oder archiviert werden dürfen — nicht dasselbe wie Hold.
• Richtlinie-Version — die wirksame Text- und Regelversion zum Zeitpunkt einer Handlung, nicht „die aktuelle PDF“.
• Nachweis Request — nachvollziehbare Anforderung von Nachweis (Umfang, Frist, Format, Empfänger) mit Lieferstatus.
• Auslegung — verbindliche fachliche Entscheidung, was eine Pflicht für Daten und Systeme bedeutet; Tool-Admin führt sie aus, ersetzt sie nicht.

Lesepfad (Peer-Karten, keine Lernleiter)

1. Governance in Legal und Compliance
2. Governance im Risk Management
3. Governance im Customer Service
4. Governance in Software- und Produktentwicklung
5. Governance im Procurement

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Aktenzeichen, System- und Toolnamen durch eure Catalog-, Ticket- und Prozessquellen.

Konzept halten — Last-Säulen: PII und DSDR tragen diese Kette; Access ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.

Orientierung — Pflicht und Nachweis ohne Legal-Tech zu übernehmen

Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation

Produkte und Entscheidungen

Legal braucht nicht „eine Compliance-Datenbank“, sondern geschnittene Produkte.

Obligation Register

Dieses Produkt beschreibt:

• Pflicht-ID; Rechtsgrund oder Vertragsklausel; betroffene Datenobjekte; Jurisdiktion; Frist; Review-Rhythmus; Accountable Counsel.

Entscheidungen:

• Welche Pflicht ist in Umfang für diesen Betrieb?; Wer darf den Registereintrag schließen?; Wann ist eine Pflicht „erfüllt“ gegenüber einer nur dokumentierten Absicht?

Legal-Hold-Produkt

Der Hold ist kein Ticket-Status. Er ist ein Identifier-Kreis plus Durchsetzung.

Er benötigt:

• Hold-ID; auslösende Sache; Identifier (Akte, Partei, Periode); verbundene Systeme; Ableitungsregeln; Beginn; geplanter Release; Freigeber.

Entscheidungen:

• Was gehört zum Hold-Kreis (Mailbox, Ticket, Lake-Kopie, Backup)?; Wer darf Hold erweitern oder aufheben?; Welche Jobs (Löschen, Recompaction, TTL) müssen pausieren?

Retention- und Lifecycle-Produkt

Retention sagt, wann gelöscht werden darf. Hold sagt, wann nicht.

Entscheidungen:

• Welcher Zweck endet wann?; Welche Archive gelten als Aufbewahrung, welche als Schattenkopie?; Wer entscheidet Konflikte Hold vs. Löschfrist?

Policy-Version und Evidence Request

Eine Auskunft oder ein Aufsichtsersuchen braucht die wirksame Regel, nicht die schönste Folie.

Entscheidungen:

• Welche Richtlinie-Version galt am Exporttag?; Wer nimmt Nachweis Requests an?; Welches Format und welche Redaction gelten als erfüllt?

Wo Governance hängt

Zwischen Memo und Job

Ein Legal-Memo ohne Job-Pause ist Theater. Der Custodian braucht eine maschinenlesbare Hold-Liste, nicht nur eine E-Mail.

Zwischen Hold und Analytics-Kopie

Der Lake-Export ist oft außerhalb des Ticket-Systems. Ohne Ableitungsregel gehört die Kopie stillschweigend nicht zum Hold — bis die Gegenpartei danach fragt.

Zwischen DPO und Counsel

Datenschutz-Löschung und Beweispflicht können denselben Datensatz meinen. Genau ein Accountable entscheidet den Konflikt; der andere berät.

Zwischen „aktueller Policy“ und Version

Reports, die „gemäß Richtlinie“ behaupten, ohne Versionsstempel, sind nicht auditierbar.

Zwischen Tool-Admin und Auslegung

Wer das Retention-Flag setzen kann, ist nicht automatisch berechtigt zu entscheiden, ob gelöscht werden darf.

Rollen-Mapping

Data Owner (Legal / Compliance)

General Counsel, Head of Compliance oder benannter Process Owner ist accountable für Zweck der Legal-Datenprodukte, Hold- und Retention-Konflikte, akzeptables Restrisiko und Freigabe zentraler Nachweise. Der Owner entscheidet nicht die Warehouse-Modellierung.

Data Steward

Legal Operations oder Compliance Operations triagiert Evidence Requests, pflegt Obligation-IDs, überwacht Hold-Fristen und eskaliert widersprüchliche Systemlisten.

Data Product Owner

Priorisiert Register, Hold-Feed und Evidence-Index. Nutzen und Lieferbarkeit — nicht die Rechtsauslegung.

Data Architect

Schützt Identifier-Bezugs- und Detailebene (Akte ≠ Ticket ≠ Party), Lineage zu Ableitungen und Breaking Changes an Hold-Schnittstellen.

Data Custodian

IAM, Plattform und Backup setzen Hold, Zugriff und Job-Pausen um. Konfigurationsmacht ist keine Auslegungshoheit.

Data Consumer

Litigation, Internal Audit, DPO, Aufsichts-Koordination, Analytics (nur mit Zweck). Abweichungen laufen über denselben Intake — keine stillen Spreadsheet-Holds.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

Zum Owner nur bei Definitions- oder Risiko-Streit. Schema- und Join-Fragen bleiben bei Expert oder Custodian. Achtundvierzig Stunden Antwort — nicht stilles Slack.

Mini-Fall

Alltagssituation: Ein automatischer Löschjob entfernt Mailboxen nach 90 Tagen. Gleichzeitig läuft ein Streitfall, für den bestimmte Nachrichten aufbewahrt werden müssen. Legal hat den Aufbewahrungsstopp in einem Ticket vermerkt, aber Kopien mit demselben Kundenschlüssel liegen bereits in einer Analyseumgebung.

Was schiefläuft: Der Hinweis im Ticket erreicht nicht automatisch alle Systeme, Jobs und Kopien. Ein Katalog-Tag hilft beim Finden, stoppt aber keine Löschung und erklärt nicht, welche abgeleiteten Daten ebenfalls betroffen sind.

Vereinbarung: Hold-ID mit Identifier-Kreis, verbundene Systeme inklusive Lake-Kopie, pausierte Jobs, verantwortliche Person, Release-Datum. Nachweis Request dokumentiert, welche Exports vor Hold-Beginn existieren.

Kritische Übergaben

Anti-Patterns

• Hold nur im Ticket, nicht in Lösch- und Compaction-Jobs
• Retention und Hold in einem Flag vermischen
• Tool-Admin entscheidet Auslegung, weil die UI es hergibt
• „Aktuelle Richtlinie“ ohne Versionsstempel als Nachweis
• Analytics-Kopien aus dem Hold-Kreis vergessen
• Nachweis als Screenshot-Ordner ohne Request-ID

Erster Umsetzungsschnitt

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes
• Functions Hub — Legal & Compliance

Lege Tag 1–20 als ersten Slice in den Plan. Spätere Arbeiten bleiben in derselben Instanz. Erster Kontakt für Hüte: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Einen laufenden oder jüngsten Hold- oder Aufsichtsfall wählen. Identifier, Systeme, Kopien und Löschjobs aufnehmen. Obligation Register mit fünf Einträgen schneiden.

Schritt 2: Control und Nachweis umsetzen

Hold-Feed und mindestens eine Job-Pause produktiv schalten. Evidence Request mit Scope und Lieferstatus einführen. Negativtest: Löschjob trifft Hold-Identifier und muss fehlschlagen.

Schritt 3: Testen und Ausnahmen sichtbar machen

Policy-Version am Exporttag rekonstruieren. Einen Hold-Release und einen Konflikt Hold vs. Löschung mit Owner-Entscheidung durchspielen.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Feed, Request, Version) auf eine zweite Jurisdiktion oder ein zweites Quellsystem übertragen.

Exit-Kriterien

• Obligation Register hat Owner und Review-Datum.
• Hold-Kreis nennt Ableitungen, nicht nur das Quellsystem.
• Retention und Hold sind getrennte Entscheidungen.
• Nachweis Requests haben Status und wirksame Richtlinie-Version.
• technischer Betreiber liefert Konfigurationsnachweis ohne mündliche Brücke.

Weiterlesen

• Extended Functions Deep Dive
• Functions Hub — Legal / Compliance
• Deletion that sticks
• Audit Nachweis Operating

Begriffe vor dem Lesen

• Fachbereich — Bereich, der Zweck, Bedeutung und Nutzung fachlich versteht.
• Schnittstelle — Stelle, an der Verantwortung, Daten oder Nachweise an andere Bereiche übergehen.
• Nachweis — nachvollziehbarer Nachweis für Entscheidung, Kontrolle oder Übergabe.

Ausgangslage

Legal und Compliance braucht Governance nicht als zusätzliche Bürokratie, sondern als Schutz für Entscheidungen, die im Alltag Wirkung haben.

Typische Entscheidungen

Der fachliche Schwerpunkt liegt auf Rechtsgrundlage, Policy, Legal Hold, Aufsichtsfrage und Nachweispflicht.

Typische Entscheidungen sind:

• Welche Daten oder Begriffe sind für den Bereich verbindlich?
• Wer darf Definitionen, Ausnahmen oder Freigaben ändern?
• Welche Nutzung ist erlaubt und welche braucht Prüfung?
• Welche Entscheidung muss dokumentiert werden, weil sie später erklärbar sein muss?

Grenze

Diese Serie macht den Fachbereich verständlich. Technische Plattformdetails, Produktauswahl oder Branchenregulierung kommen erst danach, wenn die fachliche Entscheidung klar ist.

Konkretes Beispiel

Typische Entscheidungen wirken klein, sind aber die Stelle, an der Governance praktisch wird. Ein Begriff wird verbindlich definiert, eine Ausnahme wird erlaubt, ein Datenprodukt wird freigegeben oder ein Zugriff wird abgelehnt. Ohne klare Entscheidung entstehen später Diskussionen, obwohl alle dachten, das Thema sei bereits geklärt.

Bei Legal und Compliance — typische Entscheidungen sollte deshalb jede Entscheidung als vollständiger Satz formuliert werden: Was gilt, für welchen Scope, ab wann, mit welcher Begründung und mit welchem Nachweis? So kann ein neuer Leser nachvollziehen, warum die Entscheidung getroffen wurde und wann sie erneut geprüft werden muss.

Woran man eine gute Entscheidung erkennt

• Sie beschreibt den betroffenen Umfang.
• Sie nennt verantwortliche Person, beratende Rollen und technische Umsetzung.
• Sie erklärt die fachliche Begründung in normaler Sprache.
• Sie nennt, was nicht entschieden wurde.
• Sie hinterlässt einen Nachweis, nicht nur ein Meeting-Ergebnis.

Mini-Check

Kann jemand außerhalb des Projekts die Entscheidung verstehen, ohne die Vorgeschichte zu kennen?

Begriffe vor dem Lesen

• Fachbereich — Bereich, der Zweck, Bedeutung und Nutzung fachlich versteht.
• Schnittstelle — Stelle, an der Verantwortung, Daten oder Nachweise an andere Bereiche übergehen.
• Nachweis — nachvollziehbarer Nachweis für Entscheidung, Kontrolle oder Übergabe.

Ausgangslage

Legal und Compliance braucht Governance nicht als zusätzliche Bürokratie, sondern als Schutz für Entscheidungen, die im Alltag Wirkung haben.

Schnittstellen

Der fachliche Schwerpunkt liegt auf Rechtsgrundlage, Policy, Legal Hold, Aufsichtsfrage und Nachweispflicht.

Typische Nachbarbereiche sind: Datenschutz, Risk, IT Security, Procurement, Data Engineering.

Eine gute Schnittstelle nennt:

• was übergeben wird,
• wer fachlich entscheidet,
• wer technisch umsetzt,
• wer beraten muss,
• welcher Nachweis nach der Übergabe bleibt.

Grenze

Diese Serie macht den Fachbereich verständlich. Technische Plattformdetails, Produktauswahl oder Branchenregulierung kommen erst danach, wenn die fachliche Entscheidung klar ist.

Konkretes Beispiel

Schnittstellen scheitern selten daran, dass niemand Daten übertragen kann. Sie scheitern daran, dass nach der Übergabe unklar ist, welche Bedeutung, Freigabe oder Einschränkung mitwandert. Ein Fachbereich liefert eine Liste, ein anderes Team baut ein Reporting, und später stellt sich heraus: Der Filter, der Zweck oder die Ausnahme war nur mündlich bekannt.

In Legal und Compliance — Schnittstellen muss deshalb jede Schnittstelle fachlich beschrieben werden. Nicht nur Quelle und Ziel sind wichtig, sondern auch die Entscheidung, die mit der Übergabe verbunden ist. Wer übernimmt Verantwortung? Wer darf verändern? Wer muss informiert werden, wenn sich Definition, Zugriff oder Qualität ändern?

Woran man eine gute Schnittstelle erkennt

• Quelle, Ziel und Zweck sind benannt.
• Der fachliche verantwortliche Person bleibt sichtbar.
• Technische Umsetzung ersetzt keine fachliche Freigabe.
• Ausnahmen haben Ablaufdatum und Kontakt.
• Nutzer wissen, wo sie Rückfragen oder Fehler melden.

Mini-Check

Kann eine neue Person nachlesen, was übergeben wurde, warum es erlaubt ist, wer entscheidet und welcher Nachweis gilt?

Begriffe vor dem Lesen

• Fachbereich — Bereich, der Zweck, Bedeutung und Nutzung fachlich versteht.
• Schnittstelle — Stelle, an der Verantwortung, Daten oder Nachweise an andere Bereiche übergehen.
• Nachweis — nachvollziehbarer Nachweis für Entscheidung, Kontrolle oder Übergabe.

Ausgangslage

Legal und Compliance braucht Governance nicht als zusätzliche Bürokratie, sondern als Schutz für Entscheidungen, die im Alltag Wirkung haben.

KPIs und Evidence

Der fachliche Schwerpunkt liegt auf Rechtsgrundlage, Policy, Legal Hold, Aufsichtsfrage und Nachweispflicht.

Gute KPIs und Nachweise beschreiben nicht nur Aktivität. Sie zeigen, ob Entscheidungen verlässlicher werden.

Geeignete Signale sind:

• Anzahl geklärter Definitionen oder Richtlinien,
• Anteil geprüfter kritischer Datenprodukte,
• offene Ausnahmen mit Owner und Ablaufdatum,
• Übergaben mit vollständigem Nachweis,
• wiederkehrende Fehler, die dauerhaft abgestellt wurden.

Grenze

Diese Serie macht den Fachbereich verständlich. Technische Plattformdetails, Produktauswahl oder Branchenregulierung kommen erst danach, wenn die fachliche Entscheidung klar ist.

Konkretes Beispiel

KPIs und Evidence werden oft zu spät verbunden. Ein Team zählt offene Ausnahmen, ein anderes berichtet erledigte Tickets, ein drittes zeigt eine grüne Ampel. Alles kann richtig gerechnet sein und trotzdem keine Governance-Wirkung zeigen. Entscheidend ist, ob eine wichtige Entscheidung dadurch nachvollziehbarer, schneller oder sicherer wurde.

Für Legal und Compliance — KPIs und Evidence sollten Kennzahlen deshalb immer an einen Zweck gebunden sein. Ein KPI ohne Owner ist nur Beobachtung. Evidence ohne Entscheidung ist Ablage. Erst zusammen zeigen sie, ob Governance im Alltag funktioniert.

Gute Signale

• Kritische Entscheidungen haben einen auffindbaren Nachweis.
• Offene Ausnahmen sind nicht nur gezählt, sondern besitzen Owner und Ablaufdatum.
• Wiederkehrende Fehler werden seltener oder früher erkannt.
• Fachbereiche können erklären, welche Zahl für welchen Zweck gilt.
• Audit, Datenschutz, Security oder Risk finden die relevante Evidenz ohne Sonderrecherche.

Mini-Check

Welche Entscheidung wird mit diesem KPI besser? Welcher Nachweis beweist das? Was wäre ein Warnsignal, dass die Zahl nur Aktivität misst?