DSGVO im Reporting: Wenn der Mietvertrag den Klarnamen verrät

Personenbezogene Daten landen selten über die Vordertür im Reporting. Niemand baut bewusst eine Spalte „Mietername" ins Dashboard. Sie kommen über ein unscheinbares Feld herein, das fachlich harmlos klingt. Und plötzlich steht ein Klarname in einem Visual, das breit geteilt wird.

Die Ausgangslage

In einem Reporting für Wohnimmobilien gab es das Feld Vertragsbezeichnung. Im Gewerbebereich steht dort ein Objekt- oder Firmenname. Unkritisch. Im Wohnbereich enthält dieselbe Spalte aber häufig den Namen des Mieters. Damit ist sie personenbezogen im Sinne der DSGVO, obwohl sie technisch nur ein Textfeld einer Dimension ist.

Aufgefallen ist das erst, als der Bericht in den operativen Betrieb ging und jemand die Detailtabelle mit dieser Spalte über mehrere Abteilungen teilen wollte.

Das Problem: PII im Dimensionsfeld

Der Kern ist nicht „eine verbotene Spalte", sondern eine Kontextabhängigkeit: Dasselbe Feld ist mal unkritisch (Gewerbe), mal personenbezogen (Wohnen). Ein pauschales „Spalte raus" zerstört den Bericht für die unkritischen Fälle; ein pauschales „Spalte rein" verletzt den Datenschutz für die kritischen.

Solche Felder sind tückisch, weil sie:

• in Exports mitwandern, auch wenn das Visual sie nicht zeigt,
• über Drilldowns sichtbar werden, die niemand explizit gebaut hat,
• und in breit geteilten Berichten ein ganz anderes Publikum erreichen als in einer geschützten Detailsicht.

Die Lösung: erlaubte Granularität definieren

Statt einer Ja/Nein-Entscheidung über die Spalte wird festgelegt, welche Granularität für welches Publikum erlaubt ist:

Die Regeln im Klartext:

• Keine Klarnamen in Visuals oder Exports, sobald Personenbezug möglich ist.
• Erlaubt als Identifikatoren: Vertragsnummer und Wirtschaftseinheit. Eindeutig, aber nicht personenbeziehbar.
• Detailsichten ohne Namen und nur für eng berechtigte Rollen.
• Breit geteilte Berichte nur aggregiert: je Wirtschaftseinheit, Periode oder Klauseltyp.

Technisch durchgesetzt wird das doppelt: Die kritische Spalte wird gar nicht erst ins Gold-Modell übernommen (statt sie nur im Visual auszublenden), und der Zugriff auf Detailebenen wird über Row-Level-Security gesteuert. Was nicht im Modell ist, kann auch nicht versehentlich exportiert werden.

Die Stolperfallen

1. Im Visual ausblenden ≠ entfernen. Eine ausgeblendete Spalte ist im Export und oft im Drilldown weiterhin da. Personenbezogene Felder gehören aus dem Modell, nicht nur aus der Ansicht.
2. Den Kontext übersehen. Ein Feld, das in 90 % der Zeilen harmlos ist, kann in den restlichen 10 % personenbezogen sein. Die Klassifikation richtet sich nach dem kritischsten Fall.
3. Governance nur mündlich. Wenn die Regel nicht verbindlich dokumentiert ist, lebt sie nur im Kopf einer Person. Sie gehört in ein Governance-Dokument, auf das sich der Bericht beruft. Nachvollziehbar bei einer Prüfung.

Das Takeaway

Datenschutz im Reporting ist seltener eine Frage großer Architektur als ein Blick auf die unscheinbaren Felder: Steckt in dieser Dimension ein Personenbezug? Die saubere Antwort ist nicht „Spalte weg", sondern eine definierte Granularität je Publikum. Identifikatoren statt Namen, Aggregat statt Detail, Berechtigung statt Vertrauen. Das macht den Bericht datenschutzkonform, ohne ihn fachlich zu entwerten. Und es ist gut investierte Zeit: Ein Klarname im falschen Export ist später deutlich teurer als die Klärung vorab.