Flussdiagramm Datenzugriffsantrag: vom Antrag bis zum Entzug

So funktioniert es

1. Benennen Sie die Bahnen nach Ihrer eigenen Organisation

   Ersetzen Sie Antragsteller, Data Steward, Dateneigentümer, Datenschutz und Datenplattform-Team durch die Rollen, die es bei Ihnen wirklich gibt. Halten Sie den Dateneigentümer vom Plattformteam getrennt, selbst wenn heute dieselbe Person beides macht — genau das Zusammenlegen erzeugt den Prozess, in dem die freigebende und die einrichtende Stelle identisch sind. Gibt es keine eigene Datenschutzfunktion, benennen Sie die Person, die die Verantwortung trägt, statt die Bahn zu löschen; und ist die Rolle des Data Stewards bei Ihnen informell, setzen Sie die fachliche Leitung der Domäne dorthin und schreiben Sie das auf.

2. Schreiben Sie Ihr Klassifizierungsschema in das Diagramm

   „Klassifizierung und Handhabungsregeln lesen“ bleibt wirkungslos, solange die Stufen nicht existieren. Benennen Sie sie — öffentlich, intern, vertraulich, streng vertraulich oder was auch immer Ihr Schema verwendet — und halten Sie zu jeder fest, was sie erlaubt: nur Abfrage im System, Extraktion zulässig, Maskierung verpflichtend, unterzeichnete Vereinbarung erforderlich. Legen Sie dann fest, welche Stufe den Zweig mit der Nutzungsvereinbarung auslöst und welche Stufe die Analyseumgebung nie verlassen darf. Ohne diese Tabelle wird jeder Antrag von Grund auf neu diskutiert, und die Antworten driften mit der freigebenden Person.

3. Lassen Sie die Zweckangabe echte Arbeit leisten

   Legen Sie fest, was ein Antrag mindestens sagen muss: die Frage, die beantwortet werden soll, die benötigten Tabellen und Spalten, wessen Daten betroffen sind, für wie lange der Zugriff gebraucht wird und wo ein etwaiger Auszug gespeichert wird. „Für Auswertungen“ gehört zurückgegeben und nicht freigegeben. Das ist die billigste Kontrolle auf dieser Seite, denn ein sauber geschriebener Zweck macht die Prüfung auf minimal notwendige Rechte, die Maskierungsentscheidung und das Ablaufdatum nahezu mechanisch, während ein vager Zweck alle drei willkürlich macht.

4. Setzen Sie Standardfristen je Klassifizierungsstufe

   Hinterlegen Sie zu „Zugriff mit Ablaufdatum gewähren“ je Stufe einen Standard: das Störungsfenster für den Notfallzugriff, etwa 90 Tage für streng vertrauliche Daten, sechs oder zwölf Monate für interne Daten und das Enddatum des Projekts, wo es eines gibt. Lassen Sie kürzere Fristen auf Wunsch zu und machen Sie alles, was über den Standard hinausgeht, zu einer ausdrücklichen Entscheidung des Eigentümers. Das Ablaufdatum ist die Kontrolle, die Reorganisationen, Werkzeugwechsel und das allgemeine Vergessen des Prozesses überlebt.

5. Vereinbaren Sie den Notfallweg, bevor Sie ihn brauchen

   Entscheiden Sie, wer den Notfallzugriff auslösen darf, was er gewährt, über welches Konto er läuft, wie die Sitzung protokolliert wird und wer im Moment der Freigabe alarmiert wird. Setzen Sie danach die Frist für die nachträgliche Bestätigung — wenige Arbeitstage — und, wichtiger noch, legen Sie fest, was geschieht, wenn niemand bestätigt. Der automatische Entzug zum Fristende ist die einzige Variante, die hält, denn eine Warteschlange nachträglicher Freigaben ohne Konsequenz ist binnen eines Quartals ein dauerhafter Rückstand.

6. Gehen Sie es durch und veröffentlichen Sie eine Fassung

   Nehmen Sie das fertige Diagramm zu einem Dateneigentümer, zu einer Person, die häufig Zugriff beantragt, zu der Person, die die Freigaben technisch einrichtet, und zum Datenschutz — und prüfen Sie es an drei echten Anträgen aus dem letzten Quartal, darunter einer, der abgelehnt wurde, und einer, der über den Notfallweg lief. Korrigieren Sie das Diagramm auf das, was tatsächlich geschehen ist, und nicht auf das, was die Richtlinie sagt. Veröffentlichen Sie dann diese Fassung, behalten Sie die älteren und verlinken Sie sie aus der Data-Governance-Richtlinie, damit erkennbar bleibt, welche Version jemand vor sich hat.

Häufig gestellte Fragen

Welche Schritte umfasst ein Prozess für Datenzugriffsanträge?

Einen Antrag stellen, der den Zweck nennt und nicht das System; den Datenbestand im Katalog finden und seine Klassifizierung und Handhabungsregeln lesen; bestätigen, dass er einen benannten Eigentümer hat, und ihn andernfalls zuerst klassifizieren; diesen Eigentümer den Zweck gegen die minimal notwendigen Rechte prüfen und entscheiden lassen; bei personenbezogenen Daten die Rechtsgrundlage festhalten, die Felder minimieren und den Fall durch die Datenschutzprüfung oder eine Datenschutz-Folgenabschätzung führen; vor dem Rohzugriff eine maskierte oder aggregierte Sicht anbieten; für streng vertrauliche Daten eine unterzeichnete Nutzungsvereinbarung ergänzen; den Zugriff mit Ablaufdatum gewähren; die Abfrageprotokollierung aktivieren; die Berechtigung im Zugriffsregister erfassen; und sie danach entweder vor dem Ablauf rezertifizieren oder entziehen — sofort, wenn sich Rolle oder Zweck ändern. In der Praxis fehlen am häufigsten dieselben drei Schritte: die maskierte Alternative, das Ablaufdatum und der Auslöser für den Entzug bei einem Rollenwechsel.

Wer sollte den Zugriff auf einen Datenbestand freigeben — die IT oder der Dateneigentümer?

Der Dateneigentümer, also die im Fachbereich verantwortliche Person für den Gegenstand, den die Daten beschreiben, und nicht das Team, das die Plattform betreibt, auf der sie liegen. Zu beurteilen ist, ob dieser Zweck diese Daten rechtfertigt, und das kann nur jemand, der versteht, was die einzelnen Datensätze bedeuten. Das Plattformteam führt die Freigabe aus, setzt das Ablaufdatum und aktiviert die Protokollierung; es sollte nicht zusätzlich darüber entscheiden, wer Entgelt-, Patienten- oder Kundendaten lesen darf. Eine Freigabe durch die Führungskraft lohnt sich als erstes Tor, weil sie bestätigt, dass der Antrag zur Aufgabe der Person gehört, ersetzt aber die Entscheidung des Eigentümers nicht. Hat ein Datenbestand tatsächlich keinen Eigentümer, ist das für sich genommen ein Befund — deshalb stellt dieses Diagramm „Katalogisiert mit benanntem Eigentümer?“ vor die Prüfung und nicht dahinter.

Wie lange sollte ein Datenzugriff gelten, bevor er abläuft?

So lange, wie der angegebene Zweck es erfordert, und keinen Tag länger — mit einem Standard, der sich aus der Klassifizierung ergibt und nicht je Antrag ausgehandelt wird. Ein tragfähiges Muster ist: die Dauer der Störung beim Notfallzugriff, rund 90 Tage für streng vertrauliche oder personenbezogene Daten, sechs bis zwölf Monate für gewöhnliche interne Daten und das Projektende, wenn der Antrag an ein Projekt gebunden ist. Wichtiger als die Zahlen ist der Mechanismus: Ein Ablaufdatum macht den Entzug zum Normalfall und die Verlängerung zur bewussten Handlung, sodass Rechte von selbst verfallen, wenn der Prozess vernachlässigt wird. Zugriff ohne Ablaufdatum sammelt sich stattdessen an. Wenn Sie einen Eigentümer um die Rezertifizierung bitten, schicken Sie die Zahl der Abfragen mit — eine Berechtigung, die seit sechs Monaten niemand genutzt hat, wird ohne Diskussion entzogen, während eine bloße Namensliste ohne Nutzungsdaten fast immer pauschal bestätigt wird.

Wann braucht ein Datenzugriffsantrag eine Datenschutz-Folgenabschätzung?

Nach Art. 35 DSGVO ist eine Datenschutz-Folgenabschätzung (DSFA) erforderlich, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat; ausdrücklich genannt sind unter anderem die umfangreiche Verarbeitung besonderer Kategorien personenbezogener Daten, die systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche und die systematische umfassende Bewertung persönlicher Aspekte, auf die automatisierte Entscheidungen mit rechtlicher Wirkung gestützt werden. Die Aufsichtsbehörden veröffentlichen darüber hinaus nach Art. 35 Abs. 4 DSGVO Listen von Verarbeitungsvorgängen, für die eine DSFA in jedem Fall durchzuführen ist. Für einen internen Auswertungsantrag sind die ehrlichen Auslöser meist der Umfang der betroffenen Population, ob es sich um besondere Kategorien oder um Daten zu Straftaten handelt, ob die Betroffenen mit dieser Nutzung vernünftigerweise rechnen und ob das Ergebnis in eine Entscheidung über sie einfließt. Zwei Dinge helfen in der Praxis: jeden Antrag mit Personenbezug zu screenen, statt auf einen Einwand zu warten, und das Ergebnis als Auflagen an die Freigabe zu binden — maskierte Spalten, Aufbewahrungsdauer, Verbot der Re-Identifizierung — statt als Dokument, das abgelegt und vergessen wird. Betrifft die Auswertung Beschäftigtendaten, kommt in Deutschland die Mitbestimmung hinzu: Technische Einrichtungen, die dazu bestimmt oder objektiv geeignet sind, Verhalten oder Leistung der Beschäftigten zu überwachen, unterliegen § 87 Abs. 1 Nr. 6 BetrVG und werden üblicherweise in einer Betriebsvereinbarung geregelt.

Worin unterscheidet sich das von einem allgemeinen Berechtigungsantrag?

Der allgemeine Berechtigungsantrag unter /de/templates/berechtigungsantrag-prozess deckt Systeme und Anwendungen ab: Jemand braucht eine Rolle in einem Fachsystem, Führungskraft und Systemverantwortlicher geben frei, die Funktionstrennung wird geprüft, und die IT richtet ein. Diese Seite deckt Datenbestände ab, und dadurch ändern sich drei Dinge. Freigebende Stelle ist der Dateneigentümer und nicht der Systemverantwortliche, weil es um die Bedeutung der Datensätze geht und nicht um die Funktion einer Anwendung. In der Mitte steht ein Schritt zur Klassifizierung, weil die Antwort davon abhängt, was in der Tabelle steht. Und es gibt die maskierte oder aggregierte Alternative, für die es beim Anwendungszugriff keine Entsprechung gibt — man kann niemandem 60 Prozent eines Finanzmoduls geben, wohl aber eine Sicht, aus der die Identifikatoren entfernt sind. Entwerfen Sie ein Service-Desk-Formular für Anwendungszugriffe, beginnen Sie beim allgemeinen Prozess; regeln Sie, wer das Data Warehouse abfragen darf, beginnen Sie hier.