Evidence Pack für Argonos: auditfähig statt screenshotbasiert

zustand repräsentiert.

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

Viele Argonos-Umgebungen sind besser kontrolliert, als sie beweisen können. Rechte existieren, Audit läuft, Lineage ist sichtbar — und die Prüfung beginnt mit Screenshots und einer Erklärung, warum das Bild von heute den Quartalszustand repräsentiert.

Das Problem ist nicht die Menge der Artefakte, sondern die fehlende Verknüpfung. Die Rollenkonfiguration hat einen Stand, aber der Access-Test kennt ihn nicht. Das Audit-Ereignis hat einen Zeitstempel, aber keinen Bezug zum Datenprodukt. Der Residenzhinweis existiert im Vertrag, aber niemand kann sagen, welcher Dienststand er abdeckt. Fünf korrekte Fragmente ohne gemeinsamen Product Identifier ergeben keinen Nachweis.

Der zweite Fehler ist der Zeitpunkt. Evidenz, die vor dem Audit gebaut wird, beschreibt einen rekonstruierten Zustand, keinen betriebenen. Sie 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 das grundsätzlich nicht.

Muster und Prinzipien analog: Cloudera Evidence Pack — dieselben Governance-Anforderungen, andere Oberfläche. Vorarbeit in dieser Serie: Privacy, Residenz und DSDR, Zugriff und ABAC.

Entscheidung

Definiere einen festen Evidence Pack pro Datenprodukt, der laufend im Betrieb entsteht und nicht anlassbezogen erzeugt wird. Er besteht aus sieben Bestandteilen, die alle denselben Product Identifier tragen:

1. Product Record (Owner, Steward, Zweck, Kritikalität)
2. Policy-/Rollenversion mit Wirksamkeitszeitraum
3. Effective-Access-Testergebnisse (Allow, Deny, Service, Privileged/Support)
4. Lineage-/Traceability-Ausschnitt inklusive benannter Blind Spots
5. Residenz-/Support-Nachweis (Deployment, Vertragshinweis, Reviewdatum)
6. Change- und Incident-Referenzen
7. Ausnahmen mit Expiry, Risiko, kompensierendem Control und Recert

Behandle Screenshots als ergänzende Illustration, nie als Primärnachweis. Primär sind reproduzierbare Exporte, maschinelle oder protokollierte Testergebnisse, versionierte Entscheidungen und unveränderliche Audit-Ereignisse. Wo nur ein manueller Nachweis möglich ist, werden Ersteller, Reviewer, Methode und Stichprobenumfang protokolliert.

Der Pilot umfasst ein Decision-Produkt in einem Tenant mit den sieben Pack-Bestandteilen. Prüfmaßstab ist die Stichprobenrekonstruktion: Eine beliebige Anforderung muss ohne mündliches Zusatzwissen bis zur wirksamen Konfiguration 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 Nachweiszeitraum. Der Zeitraum ist ein bewusst gesetzter Parameter: Ein Pack ohne Gültigkeitszeitraum ist nur eine Momentaufnahme mit Struktur.

Scope-out sind Controls außerhalb der Plattform — organisatorische Freigaben, Verträge, DPIAs. Sie werden referenziert (System, Identifier, Owner), nicht kopiert. Scope-out ist auch ein zentrales Dump-Archiv aller Logs: Kopien altern und widersprechen der Quelle. Der Pack ist Index plus genau die Artefakte, die in Quellen nicht dauerhaft verfügbar bleiben.

Ausdrücklich nicht Ziel ist herstellerspezifische API-Romantik. Der Pack beschreibt Governance-Artefakte und Nachweiswege plattformagnostisch; konkrete Exportwege legt der Custodian fest und dokumentiert sie im Index.

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, Zweck und akzeptiertes Restrisiko im Product Record.
• Data Steward / Nachweis verantwortliche Person: verantwortet Vollständigkeit, Aktualität und Auffindbarkeit des Packs; oft dieselbe Person mit klar getrenntem Zeitbudget.
• Plattform-technischer Betreiber: erzeugt technische Nachweise und stellt Reproduzierbarkeit der Exporte sicher.
• Compliance oder Interne Revision: prüft, ob der Pack die geltende Anforderung adressiert.
• Externer Prüfer: konsumiert den Pack; seine Rückfragen sind Testdaten für dessen Qualität.

Ohne benannten Evidence Owner ist Nachweisführung Nebentätigkeit — und fällt genau dann an, wenn niemand Zeit hat. Die Rolle muss mit Cadence und Zeitbudget versehen sein, sonst gilt der Rest dieses Playbooks nur auf dem Papier.

Die sieben Bestandteile

Product Record

Der Record ist der Anker: stabiler Identifier, Owner, Steward, Zweck, Kritikalität, erlaubte Consumer-Klassen. Ohne ihn lassen sich Tests und Residenznachweise nicht zuordnen. Änderungen am Zweck oder an der Kritikalität erzeugen eine neue Record-Version und lösen Pack-Review aus.

Policy-/Rollenversion mit Wirksamkeitszeitraum

Der aktuelle Rollenstand in der Konsole ist kein Nachweis. Der Nachweis ist die Version mit Zeitraum: Diese Policy-/Rollenfassung war von Datum A bis Datum B wirksam. Wo Konfiguration aus einem Repository kommt, liefert die Versionsverwaltung den Bezug. Wo sie in der Oberfläche gepflegt wird, schließen regelmäßige Exporte mit Zeitstempel die Lücke.

Zu jeder Version gehört die auslösende Entscheidung: Antrag, Genehmigung, Grundlage. Ohne diesen Bezug bleibt eine Änderung technisch nachvollziehbar und fachlich unbegründet.

Effective-Access-Test

Der Test zeigt Wirkung statt Absicht. Mindestens Allow, Deny, Service und Privileged/Support — jeweils mit Identität, Zeitpunkt, Ressource, erwartetem und tatsächlichem Ergebnis sowie der zum Testzeitpunkt wirksamen Policy-/Rollenversion. Ein Test ohne Versionsbezug ist im Nachhinein wertlos.

Lineage-/Traceability-Ausschnitt

Der Ausschnitt beantwortet, welche Quellen und Ableitungen zum Product gehören und wo der Path endet. Blind Spots — fehlende Upstream-Links, manuelle Exporte, Sandbox-Kopien — werden explizit benannt. Ein Lineage-Bild ohne Blind-Spot-Liste suggeriert Vollständigkeit, die nicht existiert.

Residenz-/Support-Nachweis

Verweis auf die aktuelle Residenzmatrix und den Vertragshinweis aus Privacy, Residenz und DSDR: Dienste, Regionen, Supportpfade, Subprozessoren, Reviewdatum. Der Pack kopiert den Vertrag nicht; er belegt, welcher Stand für den Nachweiszeitraum galt.

Change- und Incident-Referenzen

Material Changes und Incidents, die Controls oder Zweck betreffen, werden referenziert — nicht als Chatverlauf, sondern mit Identifier, Datum, Entscheidung und Auswirkung auf den Pack. Ohne diesen Bezug wirkt der Pack wie ein Idealzustand neben der Realität.

Ausnahmen mit Lebenszyklus

Eine Ausnahme ist eine Entscheidung mit Ablaufdatum: Scope, Begründung, Risiko, kompensierendes Control, accountable Genehmiger, Ablauf, Remediation Owner. Fehlt ein Feld, ist es ein unbearbeiteter Mangel. Zustände: beantragt, genehmigt, in Remediation, geschlossen. Wiedervorlage vor Ablauf verhindert „dauerhaft temporär“.

Stichprobenrekonstruktion als Qualitätstest

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 drei Dinge: benötigte Zeit, Anzahl der befragten Personen, Anzahl der Stellen mit mündlichem Zusatzwissen. Die dritte Zahl ist die wichtigste. Wiederhole die Übung mit einer anderen Person. Wenn nur der Autor den Pack navigieren kann, ist er eine persönliche Notizsammlung mit Struktur — nicht auditfähig.

Betrieb statt Kampagne

Der Pack entsteht im Betrieb: Export-Cadence, Test-Cadence, Review nach Material Change. Jede genehmigte Ausnahme verkürzt die Vertrauensdauer und erzwingt früheres Review. Nach Material Change entsteht ein Pack-Delta — nicht nur ein Folien-Update.

Automatisierbare Exporte haben Vorrang vor manuellen Sammlungen. Wo Automatisierung fehlt, ist der manuelle Weg dokumentiert und terminiert, nicht „irgendwann vor dem Audit“.

Die sieben Bestandteile sind bewusst plattformagnostisch formuliert. Ob der Custodian einen konfigurierten Export, ein Ticket-Archiv oder ein Repository nutzt, ist nachrangig — solange Version, Zeitraum, Owner und Product Identifier reproduzierbar sind. Erfundene herstellerspezifische APIs gehören nicht in den Pack; fehlende Automatisierung gehört als Lücke oder Ausnahme hinein.

Häufige Anti-Muster

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 betriebenen Zustand.

Test ohne Versionsbezug

Ein bestandener Test ohne zugehörige Policy-/Rollenversion belegt nichts.

Pack ohne Product Identifier

Lose Artefakte ohne gemeinsamen Anker sind eine Sammlung, kein Nachweis.

Blind Spots verschweigen

Vollständig wirkende Lineage ohne Lückenliste erzeugt falsche Sicherheit.

Ausnahmen ohne Ablauf

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

Umsetzung in 45 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 — Argonos Governance
• Lernpfad — Argonos 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

Geltende Nachweispflichten sammeln, Nachweiszeitraum festlegen, Evidence Owner benennen, Pilotprodukt wählen.

Schritt 2: Pack-Struktur

Die sieben Bestandteile, Quellsysteme, Exportwege und Aufbewahrungsfristen für das Pilotprodukt dokumentieren.

Schritt 3: Laufende Erzeugung

Exporte, Access-Tests und Verknüpfung über den Product Identifier in den Betrieb integrieren; Aufbewahrungslücken schließen oder als Ausnahme führen.

Schritt 4: Ausnahmen und Changes

Bestehende Abweichungen in echte Ausnahmen überführen, Wiedervorlage setzen, Change-/Incident-Referenzen anbinden.

Schritt 5: Stichprobe rekonstruieren

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

Messung

• Zeit für eine vollständige Stichprobenrekonstruktion mit unbeteiligter Person
• Anzahl der Stellen mit mündlichem Zusatzwissen
• Anteil der Nachweise mit Version, Zeitraum, Owner und Product Identifier
• Anteil der Kontrollregeln mit Test jünger als der definierte Zyklus
• Anteil reproduzierbarer Exporte versus manueller Erstellung
• Alter und Remediation-Fortschritt offener Ausnahmen
• Anteil der Pack-Einträge mit benanntem Blind Spot oder explizitem „keine Lücke“

Checkliste

• Nachweiszeitraum je geltender Pflicht ist bestimmt.
• Nachweis verantwortliche Person ist benannt und hat Zeitbudget.
• Der Pack enthält die sieben definierten Bestandteile.
• Alle Bestandteile tragen denselben stabilen Product Identifier.
• Richtlinie-/Rollennachweise nennen Version und Wirksamkeitszeitraum.
• Jede Version ist mit der auslösenden Entscheidung verknüpft.
• Access-Tests nennen Allow/Deny/Service/Privileged und die wirksame Version.
• Lineage-Ausschnitt benennt Blind Spots explizit.
• Residenz-/Support-Nachweis ist reviewfähig und zeitbezogen.
• Change- und Incident-Referenzen sind auffindbar.
• Screenshots sind ausschließlich ergänzend verwendet.
• Ausnahmen haben Risiko, kompensierendes Kontrollregel, Ablauf und Remediation verantwortliche Person.
• Wiedervorlage von Ausnahmen ist terminiert.
• 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 autoritative 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 beantworten die Prüffragen: 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 Stichprobe aus.

Werkzeuge und Referenzen

• Governance Nachweis Register
• Authority Matrix Builder
• Access Recertification Checklist
• personenbezogene Daten/Auskunfts- und Löschrechte Readiness Checker
• Cloudera Nachweispaket
• Privacy, Residenz und Auskunfts- und Löschrechte auf Argonos
• Zugriff und ABAC auf Argonos
• Verantwortung und Stewardship auf Argonos
• Glossary: Data Governance, Audit Trail, Data Lineage