Governance im Public Sector — Register, Akten und Datennutzung verbinden

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Sizing: Kleine Behörde — ein Register- oder Aktenprodukt mit Zweck, Aufbewahrung und klarer Zuständigkeit. Größere Organisation — Once-only-Handoffs, E-Akte und Analytics getrennt steuern. Verbund/Enterprise — Shared Services, Klassifikation, Transparenz, Vendor Hosting, On-Prem oder souveräne Cloud mit verbindlichen Betriebsnachweisen führen.

Behörden besitzen bereits Zuständigkeiten, Aktenpläne, Fachverfahren und gesetzliche Aufträge. Trotzdem ist Data Governance nicht automatisch gelöst. Ein Register kann fachlich autoritativ sein, während eine E-Akte den entscheidungsrelevanten Verlauf nachweist. Eine Statistik darf Daten nutzen, die für eine Einzelfallentscheidung nicht wiederverwendet werden dürfen. Ein Transparenzanspruch kann bestehen, obwohl einzelne Inhalte geschützt oder klassifiziert bleiben müssen. Und nicht jedes Tool darf einfach als SaaS eingeführt werden: Datenresidenz, Vergaberecht, Geheimschutz, Rollenmodell, Protokollierung, Betriebsverantwortung und Exit-Fähigkeit können On-Prem, eine eigene Cloud, eine souveräne Cloud oder Plattformen wie Cloudera CDP sinnvoller machen als ein schnell aktiviertes Standardprodukt.

Governance verbindet deshalb vier Wahrheiten:

• die autoritative Registerinformation;
• die aktenmäßige Nachvollziehbarkeit einer Entscheidung;
• die zweckgebundene analytische Nutzung;
• die veröffentlichbare oder organisationsübergreifend nutzbare Sicht.

Public-Sector-Governance schützt nicht nur Daten. Sie schützt Zuständigkeit, Rechtmäßigkeit, Nachvollziehbarkeit und das Vertrauen in staatliches Handeln.

Die Serie Governance in der Behörden- und Public-Sector-Landschaft gibt dir den Einstieg und den roten Faden für die folgenden Teile.

Ausgangslage

Ein Registerfakt wird für eine Einzelfallentscheidung wiederverwendet, die der ursprüngliche Abrufzweck nicht deckt. Ein Analytics-Export aus der E-Akte überlebt die Aktenfrist. Ein Transparenzantrag trifft auf ein Feld, das intern sichtbar, aber nicht veröffentlichbar ist. Gleichzeitig möchte ein Projektteam ein neues Cloud-Tool nutzen, obwohl Datenresidenz, Betriebsmodell und Löschpfad nicht geklärt sind.

Die eigentliche Governance-Frage lautet deshalb nicht „welchen Katalog kaufen wir?“. Sie lautet: Welche Stelle ist zuständig, welcher Zweck erlaubt die Nutzung, welcher Nachweis muss später prüfbar sein und welche technische Umgebung darf diese Daten überhaupt verarbeiten?

Was diese Serie klärt

• Orientierung: Register, Akten, Zweckbindung und Datennutzung verbinden
• Vertiefung: Register, Once-only und Zweckbindung
• Vertiefung: E-Akte, Analytics-Lifecycle und Aufbewahrung trennen
• Vertiefung: Transparenz, Klassifikation und Veröffentlichung kontrollieren
• Abschluss mit betreibbaren Next Steps über Shared Services, Wiederverwendung und Dienstleister Hosting

Begriffe und Kürzel vor dem Lesen

• Once-only — verantworteter Registerabruf mit Zweck, Attributen und Authority — kein pauschaler Zugriffstitel.
• E-Akte — aktenmäßiger Nachweis einer Entscheidung mit Aufbewahrung — kein Analytics Store.
• Analytics-Lifecycle — zweckgebundener Ausschnitt mit Löschung unabhängig von der Akte — keine vollständige Aktenkopie.
• Klassifikation — Schutzklasse und Ausschlussgrund je Bestandteil — kein pauschales Sperren.
• Transparenz — veröffentlichbare Sicht nach Release Vereinbarung — kein ungefilterter Vorgang.
• Souveräne Cloud / On-Prem — Betriebsform, die Datenresidenz, Kontrolle, Nachweis und Ausstieg-Anforderungen erfüllen kann. Kein Freifahrtschein ohne Governance.

Lesepfad

1. Governance im Public Sector — Register, Akten und Datennutzung verbinden
2. Register, Once-only und Zweckbindung
3. E-Akte — Aufbewahrung vs. Analytics-Lifecycle
4. Transparenz vs. Klassifikationsgrenzen
5. Shared Services, Wiederverwendung und Vendor Hosting

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.

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

Orientierung — Verfahren steuern ohne den Fachverfahren-Stack

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

Produkte und Entscheidungen

Registerprodukt

Ein Registerprodukt repräsentiert autoritative Tatsachen in einem gesetzlich und organisatorisch bestimmten Scope.

Sein Contract umfasst:

• Registerobjekt und stabilen Identifier;
• zuständige Stelle und führendes Fachverfahren;
• Entstehung, Änderung und Gültigkeitszeitraum;
• Datenherkunft und Qualitätsstatus;
• erlaubte Empfänger und Abrufzwecke;
• Berichtigungs- und Widerspruchspfad.

Entscheidungen:

• Welche Stelle darf einen Eintrag begründen oder ändern?
• Welcher Zustand ist aktuell und welcher historisch?
• Welche Attribute dürfen für einen neuen Zweck abgerufen werden?
• Wie werden Fehler zwischen beteiligten Behörden korrigiert?

Fall- und Vorgangsprodukt

Ein Vorgang verbindet Antrag, Beteiligte, Bearbeitungsschritte, Fristen und Status. Er unterstützt die operative Leistungserbringung. Er ist nicht automatisch die vollständige Akte.

Der Contract klärt:

• Fall-ID, Leistung, zuständige Organisation und Bearbeitungsstatus;
• eingegangene und erzeugte Unterlagen;
• Fristen, Entscheidungen und Übergaben;
• erlaubte Automatisierung und menschliche Prüfung;
• Abschluss- und Übergabezeitpunkt an die Aktenführung.

E-Akten- und Nachweisprodukt

Die E-Akte bewahrt den entscheidungsrelevanten Kontext. Sie benötigt Aktenzeichen, Aktenplanposition, Version, Verfügung, Aufbewahrungsfrist und Aussonderungsentscheidung.

Die zentrale Entscheidung lautet nicht „alles speichern“. Sie lautet: Welche Unterlagen sind aktenrelevant, wann werden sie unveränderlich, wer darf sie sehen und wann beginnt die Frist?

Statistik- und Analyseprodukt

Analytische Produkte beantworten populationsbezogene Fragen. Sie dürfen operative Daten nicht stillschweigend in einen neuen Zweck überführen.

Ihr Contract nennt:

• Fragestellung und gesetzlich oder organisatorisch bestätigten Zweck;
• Grundgesamtheit, fachliche Ebene und Berichtszeitraum;
• Merkmale, Ableitungen und Ausschlüsse;
• Schutz vor Re-Identifikation;
• Freigabe, Veröffentlichung und Korrektur.

Transparenz- und Open-Data-Produkt

Veröffentlichung ist ein eigener Produktionsprozess. Ein intern verfügbares Dataset ist noch kein veröffentlichbares Dataset.

Der Contract umfasst:

• Rechts- und Freigabegrund;
• Schutzbedarfs- und Ausschlussprüfung;
• Redaktions-, Anonymisierungs- und Qualitätsschritte;
• Veröffentlichungsformat, Lizenz und Aktualität;
• Kontakt-, Berichtigungs- und Rücknahmepfad.

Shared-Service-Produkt

Ein Shared Service kann Identität, Dokumentenablage, Integration, Analytics oder AI bereitstellen. Wiederverwendung standardisiert Technik, überträgt aber nicht automatisch fachliche Zuständigkeit.

Entscheidungen:

• Welche Behörde bleibt verantwortliche Person für Zweck und Daten?
• Welche Kontrollregeln verantwortet der zentrale Betreiber?
• Welche Mandanten- und Klassifikationsgrenzen gelten?
• Wie funktionieren Ausstieg, Portabilität und Wiederanlauf?

Wo Governance hängt

Zwischen Register und Fachverfahren

Lokale Kopien werden zu Schattenregistern. Ohne Version, Abrufzeitpunkt und Korrekturpfad ist später unklar, welche Information eine Entscheidung getragen hat.

Zwischen Vorgang und E-Akte

Workflow-Status und Chat-Verlauf ersetzen keine Aktenführung. Umgekehrt sollte nicht jedes technische Ereignis dauerhaft in der Akte landen. Ein Übergabevertrag bestimmt Aktenrelevanz und Zeitpunkt.

Zwischen Once-only und Zweckbindung

„Der Staat hat die Daten bereits“ ist keine ausreichende Abrufentscheidung. Once-only reduziert Nachweise für Bürgerinnen, Bürger und Unternehmen. Jeder Abruf benötigt trotzdem Zuständigkeit, Zweck, erforderliche Attribute und protokollierte Nutzung.

Zwischen Transparenz und Schutzbedarf

Offenheit und Schutz sind keine binäre Systemeigenschaft. Dokumente können teilweise zugänglich, zeitlich gesperrt, redigiert oder nur aggregiert veröffentlichbar sein.

Zwischen zentralem Service und lokaler Verantwortung

Ein zentraler Plattformbetreiber kann sichere technische Controls liefern. Die nutzende Behörde bleibt für fachlichen Zweck, Datenminimierung und zulässige Entscheidung accountable, soweit der bestätigte Rahmen nichts anderes bestimmt.

Rollen-Mapping

Fachlich zuständige Stelle (Data Owner)

Sie entscheidet über Bedeutung, Zweck, autoritative Quelle und zulässige Nutzung im bestätigten Mandat — die öffentlich-rechtliche Form der Data-Owner-Accountability. Bei Rechtsauslegung bleiben Legal, Datenschutz und zuständige Fachaufsicht maßgeblich.

Register- oder Verfahrensverantwortliche

Sie verantworten Datenmodell, Änderungsprozess, Korrekturpfad und Betriebsanforderungen des Fachprodukts.

Registratur und Records Management

Sie bestimmen gemeinsam mit Fachseite und Legal die aktenmäßige Ordnung, Aufbewahrung, Aussonderung und Übergabe.

Datenschutz, Informationssicherheit und Geheimschutz

Diese Funktionen bewerten Anforderungen innerhalb ihres Mandats. Sie werden nicht durch Plattformrollen oder ein Governance Board ersetzt.

Data Steward

Stewards pflegen Definitionen, Datenflüsse, Qualitätsregeln, Empfänger und offene Entscheidungen. Sie bereiten Authority-Entscheidungen vor, treffen aber keine bindende Rechtsauslegung.

Data Custodian

Interne IT, IT-Dienstleister oder Cloud-Betreiber setzen freigegebene Controls um. Administration begründet keine fachliche Verantwortung.

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.

Kritische Übergaben

Mini-Fall

Symptom: Ein Dashboard wirkt plötzlich wie eine Entscheidung über einen Verwaltungsfall, weil die Vorgangsnummer als Statistikschlüssel in eine Auswertungstabelle übernommen wurde. Niemand hat sauber getrennt, was nur berichtet und was tatsächlich entschieden werden darf.

Typischer Fehlstart: Katalogimport und ein Bürger-Portal-Theme.

Vereinbarung: Akte bleibt führend; Analytics konsumiert aggregierte Zwecke; Warehouse erzeugt keine Verwaltungsentscheidung.

Häufige Anti-Patterns

Das Register wird zur Universalquelle

Autorität gilt nur für definierte Objekte, Attribute und Zeitpunkte. Ein Register entscheidet nicht automatisch über jeden Sekundärzweck.

Alles kommt in den Data Lake

Technische Zentralisierung ohne Zweck-, Frist- und Zugriffstrennung erzeugt eine neue Schattenverwaltung.

Die E-Akte wird zum Analytics Store

Aktenvollständigkeit und analytische Nutzbarkeit sind unterschiedliche Ziele. Exporte benötigen eigenen Zweck, Minimierung und Lifecycle.

Open by default ohne Redaktionsprozess

Ein Transparenzziel ersetzt keine Schutzprüfung, Freigabe oder Rücknahmefähigkeit.

Shared Service bedeutet Shared Accountability

Geteilte Ausführung ist sinnvoll. Unklare Accountability führt zu Lücken bei Incident, Auskunft, Löschung und Exit.

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang 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 Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Public Sector Landscape
• Lernpfad — Public Sector Landscape
• Functions Hub — Public Sector

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

Schritt: Leistung und Entscheidung wählen

Ein reales Verwaltungsprodukt wählen. Register, Vorgang, Akte, Analyse und Veröffentlichung als getrennte Objekte markieren.

Schritt: Authority und Zweck klären

Zuständige Stelle, Datenschutz, Legal, Security, Records Management und Betreiber je Zweckbereich benennen. Offene Rechtsfragen nicht technisch entscheiden.

Schritt: Datenfluss und Übergaben zeichnen

Quelle, Abruf, lokale Kopie, Fallbearbeitung, Aktenübergabe, Analytics und Veröffentlichung mit Identifiers verbinden.

Schritt: Controls und Fristen prüfen

Erlaubten Abruf, verweigerten Abruf, Aktenübergabe, Retention Hold und Redaktionsfall testen.

Schritt: Evidenz zusammenführen

Entscheidungen, Policy-Versionen, Logs, Lösch- und Veröffentlichungstests an einem Produkt-Identifier bündeln.

Schritt: Lücke schließen

Eine Schattenkopie, unklare Aufbewahrung oder ungetestete Shared-Service-Grenze beheben. Danach erst skalieren.

Exit-Kriterien

• Register-, Fall-, Akten- und Analyseobjekt besitzen getrennte Owner und Identifiers.
• Jeder organisationsübergreifende Abruf nennt Zweck, Attribute, Authority und Nachweis.
• Aufbewahrung und analytische Löschung sind getrennt entschieden und technisch getestet.
• Veröffentlichung durchläuft Schutzprüfung, Redigierung, Freigabe und Rücknahmepfad.
• Shared Responsibility und Ausstieg sind für mindestens einen zentralen Dienst praktisch erprobt.