Die Eigentümerauskunft ist die eine Funktion in Ihrem Geoportal, bei der ein Fehler nicht nur peinlich, sondern teuer wird. Ein zu weit gefasster Zugriff, ein fehlendes Protokoll, ein nie definiertes Löschkonzept – und aus einem nützlichen Verwaltungswerkzeug wird ein datenschutzrechtliches Risiko, das Ihnen die Aufsichtsbehörde um die Ohren haut. Das Tückische: Technisch funktioniert die Auskunft auch dann tadellos. Sie merken den Fehler erst, wenn jemand fragt: „Wer hat wann warum auf diesen Eigentümer zugegriffen?” – und Sie keine Antwort haben.
Dieser Beitrag trennt das, was die Eigentümerauskunft rechtlich verlangt, sauber von dem, was sie technisch braucht. Beides hängt enger zusammen, als die meisten Ausschreibungen vermuten lassen.
Was die Eigentümerauskunft rechtlich verlangt
Zunächst die wichtigste Unterscheidung, die im Alltag ständig verschwimmt: Eigentümerangaben werden im Liegenschaftskataster (ALKIS) nur nachrichtlich geführt. Führend für die Eigentumsverhältnisse ist das Grundbuch; das Kataster übernimmt die Angaben über einen automatisierten, tagesaktuellen Datenaustausch mit dem Grundbuchamt [1]. Für die Auskunft heißt das: Sie geben personenbezogene Daten weiter, die ein anderes Register verantwortet – mit allen Sorgfaltspflichten, die das mit sich bringt.
Die Geobasisdaten zerfallen damit in zwei rechtlich völlig unterschiedliche Klassen:
| Datenklasse | Beispiele | Zugang |
|---|---|---|
| Stammdaten / Liegenschaftsdaten | Flurstückskennzeichen, Lage, Fläche, tatsächliche Nutzung, Gebäudeumring | grundsätzlich für jedermann |
| Personenbezogene Daten | Eigentümername, Anschrift, Eigentumsanteil, Erbbauberechtigte, Bevollmächtigte | nur unter besonderen Voraussetzungen |
Diese Trennung ist nicht nur Konvention, sie steht im Gesetz. In Schleswig-Holstein etwa kann nach § 13 Abs. 1 i. V. m. § 11 VermKatG grundsätzlich jeder die Nachweise des Liegenschaftskatasters einsehen – die personenbezogenen Daten nach § 12 Abs. 5 VermKatG sind davon aber ausdrücklich ausgenommen und richten sich nach den strengeren Voraussetzungen des § 13 Abs. 3 VermKatG [2]. In Nordrhein-Westfalen regelt § 11 VermKatG NRW dieselbe Logik: Eigentümerinformationen erhält, wer ein berechtigtes Interesse darlegt [3].
Wichtig: Das Vermessungs- und Katasterrecht ist Ländersache. Die Paragrafen, ihre Nummerierung und die Details unterscheiden sich von Bundesland zu Bundesland. Das Grundprinzip – Stammdaten offen, Eigentümerdaten nur bei berechtigtem Interesse – ist aber bundesweit konsistent.
Das „berechtigte Interesse” ist mehr als eine Floskel
Ein berechtigtes Interesse liegt vor, wenn ein verständiges, durch die Sachlage gerechtfertigtes Interesse besteht – rechtlicher, tatsächlicher, wirtschaftlicher, öffentlicher oder wissenschaftlicher Art. Ausgeschlossen sind die Verfolgung unbefugter Zwecke und reine Neugier [2]. Ein bloß rechtliches Interesse ist nicht erforderlich; auch ein rein tatsächliches, insbesondere wirtschaftliches Interesse genügt [3].
Bestimmte Stellen müssen das Interesse nicht im Einzelfall darlegen, weil es bei ihnen regelmäßig vorausgesetzt wird:
- Eigentümerinnen und Eigentümer – über die sie selbst betreffenden Liegenschaften
- Vermessungsstellen und Notare (z. B. Öffentlich bestellte Vermessungsingenieure), soweit zur Aufgabenerfüllung erforderlich
- Behörden – die Gemeindeverwaltung etwa gebietsdeckend für ihr Gemeindegebiet
- Ver- und Entsorger für die von ihren Leitungen betroffenen Flurstücke
Alle anderen müssen ihr Interesse darlegen – und Darlegen bedeutet mehr als Behaupten. Die schlagwortartige Bezeichnung angeblicher Gründe reicht nicht; das Interesse ist für den Einzelfall hinreichend konkret vorzutragen, etwa mit der Vorlage entsprechender Nachweise [2].
Wo die Grenze genau verläuft, ist Gegenstand laufender Rechtsprechung. Ein einseitiges Kauf- oder Mietinteresse wird von mehreren Vermessungsverwaltungen für sich genommen als nicht ausreichend angesehen [4]; Gerichte haben in Einzelfällen jedoch differenzierter entschieden [5]. Auch gilt: Selbst wenn ein berechtigtes Interesse besteht, dürfen nur die dafür erforderlichen Daten herausgegeben werden – das Geburtsdatum etwa bleibt regelmäßig außen vor [6]. Das ist gelebte Datenminimierung.
Warum das ein Architektur-Problem ist
Hier kommt der Denkfehler, der die meisten Portale ausbremst: Datenschutzkonformität wird als Feature behandelt, das man am Ende „noch dranbaut”. Tatsächlich ist sie eine Eigenschaft der Architektur – und Architektur lässt sich nicht nachrüsten.
Die DSGVO verlangt für jede Verarbeitung personenbezogener Daten eine Rechtsgrundlage (Art. 6 DSGVO) [7], Zweckbindung und Datenminimierung sowie – und das wird gern überlesen – die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO [8]. Rechenschaftspflicht heißt: Sie müssen die Einhaltung nicht nur behaupten, sondern nachweisen können. Ein Portal, das zeigt „wer darf was sehen”, aber nicht belegt „wer hat tatsächlich was gesehen”, erfüllt diese Pflicht nicht.
Daraus folgen drei nicht verhandelbare Architekturprinzipien:
- Need-to-know statt Alles-für-alle – Sichtbarkeit von Eigentümerdaten an Rolle und Aufgabe gebunden.
- Serverseitige Durchsetzung – die Entscheidung „darf sehen / darf nicht sehen” fällt im Backend, nie nur im Frontend.
- Lückenlose Protokollierung – jeder Zugriff auf personenbezogene Daten ist nachvollziehbar.
Das Rollen- und Berechtigungskonzept konkret
In der kommunalen Praxis bewährt sich ein abgestuftes Modell, das die zwei Datenklassen von oben in zwei Sichten übersetzt. Die kommunale Eigentümerrecherche in Brandenburg zeigt das Muster exemplarisch: Das Geoportal stellt Bürgern keine Eigentümerdaten bereit; personenbezogene Daten sind ausschließlich im internen Bereich nutzbar, über geschützte, personenbezogene Zugänge, die erst nach einer Einzelfallprüfung eingerichtet werden [1].
| Rolle | Sichtbare Daten | Voraussetzung | Protokollierung |
|---|---|---|---|
| Öffentlich (Bürger) | Stammdaten: Flurstück, Lage, Fläche, Nutzung | keine | nicht erforderlich (keine personenbezogenen Daten) |
| Fachanwender intern | + Eigentümername, Anschrift, Grundbuchbezug | benannte Person, dienstlicher Zweck | jeder Zugriff |
| Administration | Konfiguration, keine Routine-Auskunft | Vier-Augen-Prinzip | jeder administrative Eingriff |
Die technische Durchsetzung gehört nicht ins Portal, sondern an einen Identity-Provider. Über Single Sign-on (z. B. Keycloak mit Anbindung ans Active Directory) wird die vorhandene Verwaltungsidentität genutzt, und eine feingranulare Rolle – etwa eine dedizierte Rolle für die Eigentümerauskunft – entscheidet serverseitig über die Sichtbarkeit. Der Vorteil: keine separaten Portal-Logins, keine verwaisten Konten, eine zentrale Berechtigungsmatrix. Wie das im Detail aufgesetzt wird, ist ein eigenes Thema – entscheidend ist hier nur, dass die Rolle die personenbezogene Sicht freischaltet, nicht ein Häkchen im Browser.
Schon bei der Einrichtung wird dieser Rahmen abgesteckt: Bei der Beantragung des Zugriffs auf die ALKIS-Eigentümerdaten benennt die Kommune die berechtigten Mitarbeitenden, legt das Gebiet fest, beschreibt den Nutzungszweck und bestätigt, dass Vorkehrungen gegen unberechtigten Zugriff Dritter getroffen sind. Die öffentliche Wiedergabe, Verbreitung oder Präsentation der personenbezogenen Daten ist dabei ausdrücklich ausgeschlossen [1].
Zugriffsprotokollierung und Löschkonzept
Hier entscheidet sich, ob Ihr Portal eine Aufsichtsprüfung übersteht. Die Protokollierung ist kein Logging „fürs Gefühl”, sondern der Nachweis Ihrer Rechenschaftspflicht.
Was ein belastbares Zugriffsprotokoll enthalten muss: wer (Identität des Zugreifenden), wann (Zeitstempel), worauf (welcher Datensatz / welches Flurstück) und idealerweise wozu (Zweck/Vorgangsbezug). Genau diese Granularität macht aus „irgendjemand hat zugegriffen” ein nachvollziehbares Ereignis.
Für die Protokolldaten selbst gelten die Anforderungen der Datenschutzaufsicht:
- Begrenzte Aufbewahrung. Die Orientierungshilfe der Datenschutzaufsichtsbehörden empfiehlt für Protokolldaten regelmäßig Fristen zwischen sieben Tagen und drei Monaten; längere Aufbewahrung ist besonders zu rechtfertigen, und mehrere Landesdatenschutzgesetze begrenzen die Speicherdauer auf höchstens ein Jahr [9].
- Unveränderbarkeit und Zugriffsschutz. Protokolldaten dürfen nicht nachträglich verändert werden und nur Berechtigten zugänglich sein – der Zugriff sollte nach dem Vier-Augen-Prinzip erfolgen [9].
- Strikte Zweckbindung. Die Protokollierung dient allein der Datensicherheit und Datenschutzkontrolle und darf nicht zur Verhaltens- oder Leistungskontrolle der Beschäftigten zweckentfremdet werden [10].
Dazu kommen die organisatorischen Pflichten, die unabhängig von der Technik bestehen: Die Verarbeitung „Eigentümerauskunft” gehört ins Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO – inklusive der vorgesehenen Löschfristen [11] [12]. Und Betroffene haben Rechte, die Sie praktisch bedienen können müssen: das Auskunftsrecht nach Art. 15 DSGVO [13] und das Beschwerderecht bei der Aufsichtsbehörde nach Art. 77 DSGVO [14].
Brücke zum Geoportal: ein System, zwei Sichten
Die saubere Lösung ist nicht ein zweites, abgeschottetes Fachsystem neben dem Bürgerportal – das erzeugt nur Doppelpflege und Inkonsistenz. Die saubere Lösung ist eine Datenbasis und ein Portal mit serverseitig durchgesetzter Sichtbarkeit:
- Der öffentliche Modus liefert Stammdaten ohne Login – das Bürgergeoportal.
- Die geschützte Rolle schaltet, über den Identity-Provider durchgesetzt, die Eigentümersicht frei – das interne Fachportal.
- Jeder Zugriff auf personenbezogene Daten läuft durch das Zugriffsprotokoll.
In der Praxis sieht das so aus, wie es eine kommunale ALKIS-Auskunft heute schon kann: Klick auf das Flurstück in der Karte, Anzeige der Sachinformationen, und – nur im internen Bereich – Eigentümer, Anschrift und Grundbuchbezug, mit Suche nach Adresse, Flurstück, Eigentümername oder Grundbuchblatt und Export als PDF [1]. Der Unterschied zwischen einem auditierbaren und einem riskanten Portal liegt nicht in dieser Oberfläche, sondern darunter: ob die Eigentümersicht serverseitig an eine Rolle gebunden ist und ob jeder Zugriff protokolliert wird.
Wer ALKIS sauber integriert und die Sichtbarkeit serverseitig durchsetzt, hat die Datenschutzkonformität nicht als Nachgedanken, sondern als Eigenschaft seines Portals.
Wie ein fertiges Produkt diese Trennung umsetzt – Rollenmodell, Anmeldung über Keycloak und ein Zugriffsprotokoll mit festen Feldern –, zeigt der Abschnitt Rollenmodell und Anmeldung in ALKIS Direkt.
Handlungsempfehlung
- Rechtsgrundlage je Land klären. Welches Landesvermessungs-/Katastergesetz gilt, welche Paragrafen regeln die Abgabe personenbezogener Daten, wer ist ohne Einzeldarlegung berechtigt? Das ist die Basis jeder Konfiguration.
- Daten- und Rollenmodell ableiten. Stammdaten und personenbezogene Eigentümerdaten konsequent trennen; Rollen nach Need-to-know schneiden statt großzügiger Sammelberechtigungen.
- Berechtigung serverseitig durchsetzen. Identität über SSO/Active Directory, Sichtbarkeit der Eigentümerdaten an eine dedizierte Rolle binden – die Entscheidung fällt im Backend.
- Zugriffsprotokoll und Löschkonzept verbindlich dokumentieren. Wer/wann/worauf/wozu protokollieren; Aufbewahrungsfrist der Protokolle festlegen; Unveränderbarkeit, Zugriffsschutz und Zweckbindung sicherstellen.
- Datenschutz-Abnahme einplanen. Verarbeitung ins Verzeichnis nach Art. 30 aufnehmen, ggf. Datenschutz-Folgenabschätzung, und die Trennung Bürger-/Fachportal vom oder von der Datenschutzbeauftragten abnehmen lassen.
Fazit
Die Eigentümerauskunft trennt seriöse Geoportale von Bastellösungen – nicht an der Kartenoberfläche, sondern an der Architektur darunter. Gewinner sind die Kommunen, die Stammdaten öffentlich, Eigentümerdaten rollenbasiert und jeden Zugriff protokolliert bereitstellen – ein System, zwei Sichten, eine lückenlose Spur. Verlierer ist, wer Datenschutz als nachträgliche Pflichtübung behandelt und im Frontend „ausblendet”, was serverseitig längst hätte geschützt sein müssen. Die gute Nachricht: Wer die Trennung von Anfang an in die Architektur legt, bekommt Bürgerservice und Compliance nicht als Gegensatz, sondern als zwei Seiten derselben sauberen Lösung.
Quellen
- [1] Christoph König (IGGV mbH): Den Überblick behalten – Eigentümerrecherche mit ALKIS. Ein Blick aus kommunaler Sicht. PDF, geobasis-bb.de
- [2] Landesamt für Vermessung und Geoinformation Schleswig-Holstein: Hinweise zur Abgabe personenbezogener Daten des Liegenschaftskatasters (Stand November 2024; §§ 11, 12 Abs. 5, 13 VermKatG SH). PDF, schleswig-holstein.de
- [3] Vermessungs- und Katastergesetz Nordrhein-Westfalen (VermKatG NRW), § 11 – Geobasisinformationssystem für den Bereich des Liegenschaftskatasters / Eigentümerinformation (geltende Fassung). recht.nrw.de
- [4] Haufe: Liegenschaftskataster – Auskunft nur bei berechtigtem Interesse. haufe.de
- [5] VGH München, Urteil vom 09.03.2023 – 13a B 22.1688 (Auskunft über Eigentümerdaten aus dem Liegenschaftskataster). gesetze-bayern.de
- [6] Kanzlei Dr. Bahr: VG Darmstadt – Weitergabe von Eigentümerdaten aus dem Liegenschaftskataster an Kaufinteressenten (zum Umfang herauszugebender Daten). dr-bahr.com
- [7] Art. 6 DSGVO – Rechtmäßigkeit der Verarbeitung. dsgvo-gesetz.de
- [8] Art. 5 DSGVO – Grundsätze für die Verarbeitung (insb. Abs. 2, Rechenschaftspflicht). dsgvo-gesetz.de
- [9] Der Landesbeauftragte für den Datenschutz Niedersachsen: Orientierungshilfe für datenschutzgerechte Protokollierung. PDF, lfd.niedersachsen.de
- [10] Arbeitskreis Technik der Datenschutzbeauftragten: Orientierungshilfe „Protokollierung”. PDF, baden-wuerttemberg.datenschutz.de
- [11] Art. 30 DSGVO – Verzeichnis von Verarbeitungstätigkeiten. dejure.org
- [12] Bundesbeauftragter für den Datenschutz und die Informationsfreiheit (BfDI): Hinweise und Muster zum Verzeichnis von Verarbeitungstätigkeiten. bfdi.bund.de
- [13] Art. 15 DSGVO – Auskunftsrecht der betroffenen Person. dsgvo-gesetz.de
- [14] Art. 77 DSGVO – Recht auf Beschwerde bei einer Aufsichtsbehörde. dsgvo-gesetz.de