Der Evidence Pack für CDP: auditfähig statt screenshotbasiert

Lösung: Definiere einen festen Evidence Pack pro Datenprodukt, der laufend im Betrieb entsteht und nicht anlassbezogen erzeugt wird.

In einem Satz: Definiere einen festen Evidence Pack pro Datenprodukt, der laufend im Betrieb entsteht und nicht anlassbezogen erzeugt wird.

Problem

Die meisten CDP-Umgebungen sind besser kontrolliert, als sie beweisen können. Ranger setzt Policies durch, Atlas kennt Klassifikationen, NiFi zeichnet Provenance auf, Audit-Logs laufen in eine Sammelstelle. Trotzdem beginnt jede Prüfung mit derselben Szene: Jemand öffnet eine Konsole, macht Screenshots, exportiert eine Liste und schreibt eine Erklärung dazu, warum das Bild von heute den Zustand vom letzten Quartal repräsentiert.

Das Problem ist nicht die Menge der Daten, sondern die fehlende Verknüpfung. Die Policy hat eine Version, aber der Test kennt sie nicht. Das Audit-Log hat einen Zeitstempel, aber keinen Bezug zum Datenprodukt. Die Atlas-Klassifikation existiert, aber niemand kann sagen, wer sie wann auf welcher Grundlage gesetzt hat. Fünf korrekte Artefakte, die sich nicht aufeinander beziehen, ergeben keinen Nachweis.

Der zweite Fehler ist der Zeitpunkt. Evidenz, die vor dem Audit gebaut wird, beschreibt einen rekonstruierten Zustand, keinen betriebenen. Sie ist teuer, bindet die erfahrensten Leute für Wochen und beantwortet die eigentliche Frage nicht: War das Control zu dem Zeitpunkt wirksam, an dem es wirksam sein musste? Ein Screenshot von heute kann diese Frage grundsätzlich nicht beantworten.

Entscheidung

Definiere einen festen Evidence Pack pro Datenprodukt, der laufend im Betrieb entsteht und nicht anlassbezogen erzeugt wird. Er besteht aus fünf Bestandteilen: Policy-Version mit Wirksamkeitszeitraum, Atlas-Klassifikation mit Provenance, NiFi-Provenance beziehungsweise Verarbeitungsnachweis, Audit-Log-Auszug und Effective-Access-Testergebnis. Jeder Bestandteil trägt denselben Produkt-Identifier.

Behandle Screenshots als ergänzende Illustration, nie als primären Nachweis. Primär sind reproduzierbare Exporte, maschinelle Testergebnisse, versionierte Konfiguration aus einem Repository und unveränderliche Audit-Ereignisse. Wo nur ein manueller Nachweis möglich ist, werden Ersteller, Reviewer, Methode und Stichprobenumfang protokolliert.

Der Pilot umfasst ein Datenprodukt in einem CDP-Environment mit den fünf Pack-Bestandteilen. Der Prüfmaßstab ist die Stichprobenrekonstruktion: Eine beliebige Anforderung — regulatorisch, vertraglich oder intern — muss ohne mündliches Zusatzwissen bis zur tatsächlich wirksamen Plattformkonfiguration und zurück verfolgt werden können. Gelingt das für das Pilotprodukt in unter 30 Minuten, ist der Pack tragfähig.

Scope und Abgrenzung

Scope-in sind ein Datenprodukt, seine Controls, die zugehörigen Entscheidungen und Ausnahmen sowie der Zeitraum, für den Nachweis geführt wird. Der Zeitraum ist ein bewusst gesetzter Parameter: Ein Pack ohne definierten Gültigkeitszeitraum ist nur eine Momentaufnahme mit hübscher Struktur.

Scope-out sind Controls, die außerhalb der Plattform wirken, etwa organisatorische Freigaben oder Verträge mit Dritten. Sie werden im Pack referenziert, aber nicht kopiert. Die Referenz nennt System, Identifier und Owner, damit ein Prüfer den Weg selbst gehen kann.

Ausdrücklich nicht Ziel ist ein zentrales Nachweisarchiv, das alles dupliziert. Kopien altern und widersprechen der Quelle. Der Pack ist ein Index mit Verweisen, ergänzt um genau die Artefakte, die in der Quelle nicht dauerhaft verfügbar sind.

Rollen und Entscheidungsrechte

• kontrollverantwortliche Person: definiert, was ein Kontrollregel leisten soll, wie es getestet wird und was als bestanden gilt.
• Data Owner: bestätigt Klassifikation, zulässige Nutzung und akzeptiertes Restrisiko.
• Plattform-technischer Betreiber: erzeugt die technischen Nachweise und stellt Reproduzierbarkeit sicher.
• Nachweis verantwortliche Person: verantwortet Vollständigkeit, Aktualität und Auffindbarkeit des Packs.
• Compliance oder Interne Revision: prüft, ob der Pack die geltende Anforderung tatsächlich adressiert.
• Externer Prüfer: konsumiert den Pack; seine Rückfragen sind Testdaten für dessen Qualität.

Die Rolle des Evidence Owners fehlt in vielen Organisationen. Ohne sie ist Nachweisführung eine Nebentätigkeit, die dann anfällt, wenn niemand Zeit hat. Sie muss benannt und mit Zeitbudget versehen sein, sonst gilt der Rest dieses Playbooks nur auf dem Papier.

Die fünf Bestandteile

Policy-Version mit Wirksamkeitszeitraum

Die Ranger-Policy allein ist kein Nachweis, weil sie den aktuellen Stand zeigt. Der Nachweis ist die Version mit Zeitraum: Diese Policy war von Datum A bis Datum B in dieser Fassung wirksam. Wenn Policies aus einem Repository deployt werden, liefert die Versionsverwaltung diesen Nachweis fast von selbst. Wenn sie in der Konsole gepflegt werden, muss ein regelmäßiger Export mit Zeitstempel die Lücke schließen.

Zu jeder Version gehört die auslösende Entscheidung: Wer hat sie beantragt, wer genehmigt, auf welcher Grundlage. Ohne diesen Bezug bleibt eine Änderung technisch nachvollziehbar und fachlich unbegründet.

Atlas-Klassifikation mit Provenance

Eine Klassifikation ist eine Behauptung über die Daten. Der Nachweis besteht aus der Behauptung plus ihrer Herkunft: automatisch erkannt, manuell gesetzt, aus einem Quellsystem übernommen oder aus einer Freigabe abgeleitet. Halte zusätzlich fest, wann sie zuletzt bestätigt wurde und wer sie bestätigt hat.

Klassifikationen ohne Bestätigungsdatum verlieren im Zeitverlauf ihren Wert. Ein Tag, das vor drei Jahren automatisch gesetzt und nie geprüft wurde, ist ein Hinweis, aber kein belastbarer Nachweis über den heutigen Schutzbedarf.

NiFi-Provenance und Verarbeitungsnachweis

Provenance beantwortet die Frage, welche Daten wann über welchen Weg verarbeitet wurden. Für die Nachweisführung ist entscheidend, dass die Aufbewahrungsdauer der Provenance-Daten zum Nachweiszeitraum passt. Eine Aufbewahrung von sieben Tagen bei einem Nachweiszeitraum von einem Jahr ist eine bekannte Lücke, die dokumentiert und entschieden werden muss — nicht ein Detail, das im Audit auffällt.

Wo Verarbeitung nicht über NiFi läuft, tritt der entsprechende Nachweis an ihre Stelle: Job-Definition aus dem Repository, Ausführungsprotokoll des Schedulers, Lineage-Eintrag in Atlas. Wichtig ist die Verknüpfung über den Produkt-Identifier, nicht die Herkunft aus einem bestimmten Werkzeug.

Audit-Log-Auszug

Audit-Logs zeigen tatsächliche Zugriffe. Für den Pack wird nicht das gesamte Log abgelegt, sondern ein definierter Auszug: Zugriffe auf die Ressourcen dieses Datenprodukts im Nachweiszeitraum, mit Identität, Zeit, Ressource, Aktion und Ergebnis. Der Auszug muss reproduzierbar sein — die Abfrage selbst gehört ins Pack, nicht nur ihr Ergebnis.

Die Aufbewahrung der Audit-Daten ist ebenfalls eine Governance-Entscheidung. Sie wird an der längsten geltenden Nachweispflicht ausgerichtet und nicht am freien Speicherplatz.

Effective-Access-Test

Der Test ist der einzige Bestandteil, der Wirkung statt Absicht zeigt. Er umfasst mindestens einen erlaubten, einen verweigerten, einen Service- und einen privilegierten Zugriff und nennt jeweils Identität, Zeitpunkt, Ressource, erwartetes und tatsächliches Ergebnis sowie die zum Testzeitpunkt wirksame Policy-Version.

Ein Test ohne Policy-Versionsbezug ist im Nachhinein wertlos, weil sich nicht mehr feststellen lässt, welche Konfiguration er belegt hat. Diese eine Verknüpfung ist der größte Qualitätsunterschied zwischen einem Testprotokoll und einem Nachweis.

Ausnahme-Lebenszyklus

Eine Ausnahme ist eine Entscheidung mit Ablaufdatum, kein Kommentar im Ticket. Sie besteht aus Scope, Begründung, Risikobewertung, kompensierendem Control, accountable Genehmiger, Ablaufdatum und Remediation Owner. Fehlt eines dieser Felder, ist es keine Ausnahme, sondern ein unbearbeiteter Mangel.

Der Lebenszyklus hat vier Zustände: beantragt, genehmigt, in Remediation, geschlossen. Der Übergang von „genehmigt“ zu „in Remediation“ passiert automatisch mit dem Erreichen eines definierten Vorlaufs vor dem Ablaufdatum. Ohne diesen Automatismus verlängert sich jede Ausnahme durch Vergessen.

Für das Audit ist weniger die Anzahl der Ausnahmen relevant als ihr Alter und ihr Fortschritt. Zehn junge Ausnahmen mit klarem Remediation-Plan sind ein Zeichen funktionierender Governance. Drei Ausnahmen ohne Fortschritt seit zwei Jahren sind ein Zeichen dafür, dass das Control faktisch nicht gilt.

Stichprobenrekonstruktion als Qualitätstest

Der beste Test für einen Evidence Pack ist eine Trockenübung. Wähle eine konkrete Anforderung und verfolge sie in beide Richtungen: von der Anforderung zur wirksamen Konfiguration und vom beobachteten Zugriff zurück zur genehmigenden Entscheidung.

Miss dabei drei Dinge: die benötigte Zeit, die Anzahl der Personen, die befragt werden mussten, und die Anzahl der Stellen, an denen mündliches Zusatzwissen nötig war. Die dritte Zahl ist die wichtigste. Jedes Stück Wissen, das nur in einem Kopf existiert, ist ein Ausfallrisiko und im Audit ein Fund.

Wiederhole die Übung mit einer anderen Person als beim ersten Mal. Wenn nur der Autor den Pack navigieren kann, ist er nicht auditfähig, sondern eine persönliche Notizsammlung mit ordentlicher Struktur.

Häufige Anti-Patterns

Screenshots als Primärnachweis

Ein Bild zeigt einen Moment ohne Version, ohne Zeitraum und ohne Reproduzierbarkeit.

Evidenz wird vor dem Audit erzeugt

Rekonstruierter Nachweis ist teuer und belegt möglicherweise nicht den tatsächlich betriebenen Zustand.

Test ohne Versionsbezug

Ein bestandener Test, dessen zugehörige Konfiguration unbekannt ist, belegt nichts.

Aufbewahrung kürzer als Nachweispflicht

Provenance und Audit-Daten, die früher verfallen als die Pflicht reicht, erzeugen eine strukturelle Lücke.

Zentrales Kopierarchiv

Duplizierte Nachweise altern gegenüber der Quelle und erzeugen Widersprüche statt Sicherheit.

Ausnahmen ohne Ablauf

Dauerhaft temporäre Abweichungen sind ein zweites, undokumentiertes Betriebsmodell.

Umsetzung in 90 Tagen

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 — Cloudera CDP Governance
• Lernpfad — Cloudera CDP Governance

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.

Schritt 1: Anforderung und Zeitraum klären

Geltende Nachweispflichten sammeln, Nachweiszeitraum je Anforderung bestimmen, Evidence Owner benennen.

Schritt 2: Pack-Struktur definieren

Die fünf Bestandteile für ein Pilotprodukt festlegen, Quellsysteme, Exportwege und Aufbewahrungsfristen dokumentieren.

Schritt: Laufende Erzeugung aufbauen

Exporte, Testläufe und Verknüpfung über den Produkt-Identifier in den Betrieb integrieren; Aufbewahrungslücken schließen oder als Ausnahme führen.

Schritt: Ausnahmen und Lebenszyklus aktivieren

Bestehende Abweichungen in echte Ausnahmen überführen, Wiedervorlage automatisieren, Remediation-Owner zuordnen.

Schritt 4: Stichprobe rekonstruieren

Zwei Trockenübungen mit unterschiedlichen Personen durchführen, Zeit und Wissenslücken messen, Backlog priorisieren.

Messung

• Zeit für eine vollständige Stichprobenrekonstruktion, gemessen mit einer unbeteiligten Person
• Anzahl der Stellen, an denen mündliches Zusatzwissen erforderlich war
• Anteil der Nachweise mit Version, Zeitraum, Owner und Produkt-Identifier
• Anteil der Kontrollregeln mit einem Test, der jünger ist als der definierte Zyklus
• Anteil der Nachweise, die reproduzierbar exportiert statt manuell erstellt werden
• Verhältnis von Aufbewahrungsdauer zu geltender Nachweispflicht je Quelle
• Alter und Remediation-Fortschritt offener Ausnahmen

Checkliste

• Für jede Nachweispflicht ist der geltende Zeitraum bestimmt.
• Ein Nachweis verantwortliche Person ist benannt und hat Zeitbudget.
• Der Pack besteht aus den fünf definierten Bestandteilen.
• Alle Bestandteile tragen denselben stabilen Produkt-Identifier.
• Richtlinie-Nachweise nennen Version und Wirksamkeitszeitraum, nicht nur den aktuellen Stand.
• Jede Richtlinie-Version ist mit der auslösenden Entscheidung verknüpft.
• Klassifikationen tragen Herkunft und Datum der letzten Bestätigung.
• Aufbewahrungsfristen von Provenance und Audit-Daten decken die Nachweispflicht.
• Audit-Auszüge sind reproduzierbar; die Abfrage selbst ist Teil des Packs.
• Jeder Effective-Access-Test nennt die zum Testzeitpunkt wirksame Richtlinie-Version.
• Screenshots sind ausschließlich ergänzend verwendet.
• Ausnahmen haben Risiko, kompensierendes Kontrollregel, Ablauf und Remediation verantwortliche Person.
• Die Wiedervorlage von Ausnahmen läuft automatisch.
• Eine Stichprobe wurde von einer unbeteiligten Person erfolgreich rekonstruiert.

Artefakt

Das Ergebnis ist ein Evidence Index je Datenprodukt. Er kopiert keine Nachweise, sondern verweist auf die autoritativen Records und hält je Eintrag fest: Control, Nachweistyp, Quellsystem, Identifier, Version, Zeitraum, Owner, Aufbewahrung und Datum der letzten Prüfung.

Ergänzt wird er durch ein Ausnahmeregister mit Lebenszyklusstatus und durch das Testprotokoll der Effective-Access-Tests. Diese drei Dokumente zusammen beantworten die drei Fragen jedes Prüfers: Was sollte gelten, was galt tatsächlich, und was war bewusst anders geregelt.

Der Index ist versioniert. Änderungen an Controls, Aufbewahrung oder Nachweisquellen erzeugen eine neue Version und lösen eine erneute Stichprobenprüfung aus.

Tools und Verweise

• Authority Matrix
• Ranger Richtlinie Pattern Generator
• Custom Stack Builder
• Cloudera CDP Ranger Start
• Kafka Schema Registry Start
• Governance über mehrere Plattformen
• Lernpfad Cloudera CDP Governance
• Glossary: Apache Atlas, Apache Ranger, Apache NiFi, Cloudera CDP