Transparenz vs. Klassifikationsgrenzen

Transparenz und Schutzbedarf sind keine gegensätzlichen Plattformmodi. Ein Vorgang kann veröffentlichbare, redigierbare, zeitweise gesperrte und dauerhaft geschützte Bestandteile enthalten. Governance muss diese Entscheidungen nachvollziehbar machen, ohne pauschal alles zu öffnen oder zu blockieren.

Vorher: E-Akte und Analytics-Lifecycle. Weiter: Shared Services und Vendor Hosting.

Ansatz

Jede Veröffentlichung und jeder Informationszugang durchläuft einen versionierten Release Contract:

1. angefragtes oder zu veröffentlichendes Informationsobjekt;
2. zuständige Stelle und bestätigte Rechtsgrundlage;
3. Schutzklassen und konkrete Ausschlussgründe;
4. Redigierungs-, Aggregations- oder Anonymisierungsentscheidung;
5. Freigabe, Format, Lizenz und Veröffentlichungstermin;
6. Korrektur-, Rücknahme- und Protokollierungsweg.

Legal, Datenschutz, Informationssicherheit oder Geheimschutz entscheiden in ihren Mandaten. Open-Data- und Plattformteams produzieren die freigegebene Sicht.

Release Workflow

1. Objekt und Version fixieren

Nicht „die Datenbank“, sondern ein definierter Snapshot, Bericht oder Dokumentensatz wird geprüft. Ohne Versions-ID kann niemand später erklären, welche Fassung veröffentlicht wurde. Custodian speichert den geprüften Stand, bevor Redaktion beginnt.

2. Schutzgründe atomar bewerten

Personenbezug, Sicherheitsinteresse, Betriebsgeheimnis und laufendes Verfahren werden nicht in einem generischen Vertraulich-Flag vermischt. Jeder Grund trägt Authority und Nachweis. Ein Sammelflag erzeugt entweder Überblockade oder stille Leaks.

3. Teilzugang bevorzugen

Redaktion, Aggregation oder zeitliche Verzögerung werden geprüft, bevor das gesamte Objekt zurückgehalten wird. Open Data ohne Teilzugang ist oft ein Vollverweigerungsreflex. Der Release Contract dokumentiert, was bewusst nicht veröffentlicht wird.

4. Transformation reproduzieren

Redaktionsregeln, Filter, manuelle Entscheidungen und Quality Checks werden versioniert. Visuelles Schwärzen in einem PDF ohne regelbasierten Nachzug ist kein Control. Steward führt die Regeldatei; Custodian wendet sie an.

5. Negative Disclosure testen

Das Team prüft kleine Gruppen, Join-Angriffe, Metadaten, Dateianhänge und versteckte Spalten. Ein Release ohne diesen Test ist eine Hoffnung. Findings stoppen die Veröffentlichung oder erzwingen weitere Redaktion.

6. Veröffentlichung betreiben

Kontakt, Aktualität, Korrektur, Rücknahme und geänderte Sensitivität bleiben Teil des Produkts. Ein Portal-Upload ohne Rücknahmeweg ist kein Release Contract. Legal und Datenschutz bleiben für Nachträge erreichbar.

Kontakt, Aktualität, Korrektur, Rücknahme und neue Schutzlage gehören zum laufenden Produkt.

Handoffs

• Fachstelle liefert Kontext und Vollständigkeit.
• Legal/Privacy bestätigt Zugangs- und Schutzentscheidung.
• Security oder Geheimschutz bewertet technische und operative Offenlegung.
• Data Steward dokumentiert Definition, Filter und Version.
• Publishing technischer Betreiber setzt Format, Portal und Rücknahme um.

Anti-Patterns

• Ein einziges „vertraulich“-Label entscheidet jeden Fall.
• PDF-Redaktion verdeckt Text nur optisch.
• Open-Data-Exporte enthalten versteckte Felder oder stabile Personenidentifier.
• Ein veröffentlichter Snapshot besitzt keinen verantwortliche Person mehr.
• Neue Join-Möglichkeiten lösen keine erneute Prüfung aus.

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

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Ein regelmäßig veröffentlichtes Dataset auswählen.
2. Authority und Schutzgründe je Feld dokumentieren.
3. Redaktions- oder Aggregationspipeline versionieren.
4. Re-Identifikation und versteckte Metadaten testen.
5. Korrektur und Rücknahme simulieren.
6. Review-Trigger für neue Quellen und Joins festlegen.