+150 XP

Vorbereitung auf ein Datenaudit und eine aufsichtsrechtliche Prüfung

# Vorbereitung auf ein Datenaudit und eine aufsichtsrechtliche Prüfung

Der Prüfer setzt sich hin, öffnet seinen Laptop und sagt: „Zeigen Sie mir alles, was Sie zu Kundenkonto 48213 gespeichert haben, und belegen Sie, wer wann und warum darauf zugegriffen hat.“ Sie haben vielleicht 48 Stunden, um eine saubere Antwort zu liefern. Firmen, die diesen Evidence Trail auf Abruf zusammenstellen können, bestehen. Firmen, die sich durch Spreadsheets und E-Mail-Threads wühlen, fallen durch, und das Scheitern hat selten mit den zugrunde liegenden Anlageentscheidungen zu tun. Es geht um Data Governance.

Diese Lektion geht genau die Belege durch, die ein Prüfer der FCA oder SEC erwartet, am Beispiel der Datenreise eines einzelnen Kunden, und probt anschließend die Fragen, die schwache Governance im Gespräch offenlegen.

Wer fragt, und mit welcher Befugnis

Zwei Aufsichtsbehörden dominieren bei Asset- und Wealth-Managern.

  • FCA (Financial Conduct Authority): die britische Aufsicht für Geschäftsverhalten. Ihr Regelwerk (SYSC, das Systems and Controls Sourcebook) verlangt von Firmen, geordnete Aufzeichnungen zu führen und Kontrolle über Kundendaten nachzuweisen. Datenschutz fällt unter die UK GDPR und den Data Protection Act 2018, durchgesetzt vom ICO (Information Commissioner's Office).
  • SEC (Securities and Exchange Commission): die US-Marktaufsicht. Für registrierte Investment Adviser definieren die Books and Records Rule (Rule 204-2 unter dem Investment Advisers Act of 1940) und die Marketing Rule, was aufzubewahren und vorzulegen ist. Die Safeguards Rule unter Regulation S-P regelt die Sicherheit von Kundendaten.

In der EU gelten die Aufzeichnungspflichten aus MiFID II und die GDPR (General Data Protection Regulation), mit nationalen Aufsichtsbehörden (BaFin in Deutschland, AMF in Frankreich) neben den Datenschutzbehörden.

Beachten Sie die Trennung: Verhaltensaufsichten wollen, dass Sie die Datenreise eines Kunden für Aufzeichnungspflichten und Geeignetheit rekonstruieren können. Datenschutzbehörden wollen, dass der Zugriff rechtmäßig, minimal und zeitlich begrenzt war. Eine gute Auditvorbereitung erfüllt beides.

Die drei Säulen des Evidence Trail

Ein Prüfer, der einen einzelnen Kunden untersucht, prüft eigentlich drei Dinge: Lineage (woher kamen die Daten und wie haben sie sich bewegt), Access Logs (wer hat sie gesehen oder geändert) und Aufbewahrungsnachweis (wie lange Sie sie behalten und wie Sie sie löschen).

Säule 1: Data Lineage

Lineage ist der dokumentierte Weg eines Datenelements vom Ursprung bis zum aktuellen Zustand. Für Kunde 48213 heißt das, ein einzelnes Feld nachzuverfolgen, etwa den Risikotoleranz-Score, vom Onboarding-Fragebogen über das CRM ins Portfoliomanagementsystem und weiter in den Geeignetheitsbericht.

Schwache Lineage klingt so: „Der Score ist im System.“ Starke Lineage sieht aus wie eine abgebildete Kette:

Source: onboarding form (submitted 2025-03-12, ref FORM-48213-A)
  -> CRM field client.risk_score (ingested 2025-03-12 via API job ONB-207)
    -> PMS suitability engine (read 2025-03-14, model SUIT-v4.2)
      -> Suitability report SR-48213 (generated 2025-03-14, sent 2025-03-15)

Jeder Pfeil braucht einen Zeitstempel, ein System of Record und einen Hinweis auf die Transformation. Wenn sich der Risiko-Score geändert hat (etwa weil der Kunde ihn im September 2025 aktualisiert hat), muss die Lineage beide Versionen zeigen und welcher Bericht welche verwendet hat.

Für eine verständliche Einführung, warum Lineage unter GDPR-artigen Regimen zählt, ist der Leitfaden des ICO zu Accountability und Governance eine solide kostenlose Referenz.

Säule 2: Access Logs

Der Prüfer will wissen, welcher Mensch und welches System auf Konto 48213 zugegriffen hat und ob dieser Zugriff begründet war.

Mindestfelder pro Zugriffsereignis: User-ID, Rolle, Zeitstempel, Aktion (Lesen, Schreiben, Export, Löschen) und idealerweise ein geschäftlicher Grund. Privilegierte Zugriffe (Admins, Entwickler) werden am genauesten geprüft, weil sie Kontrollen umgehen können.

Red Flags, nach denen ein Prüfer sucht:

  • Ein ausgeschiedener Mitarbeiter, dessen Zugriff nicht entzogen wurde.
  • Massenexporte von Kundendaten auf einen lokalen Rechner oder eine private E-Mail-Adresse.
  • Entwickler, die Produktivdaten von Kunden ohne Ticketreferenz lesen.
  • Gar keine Logs vor einem bestimmten Datum (was auf eine Systemumstellung hindeutet, die die Historie gelöscht hat).

Das Prinzip dahinter ist Least Privilege: Jede Person erhält nur den Zugriff, den ihre Rolle erfordert, und nicht mehr. Wenn ein Junior Analyst das gesamte Buch mit 5.000 Kunden lesen kann, obwohl er nur 30 betreut, ist das ein Finding.

Säule 3: Aufbewahrungsnachweis

Der Aufbewahrungsnachweis zeigt, dass Sie Daten so lange aufbewahren wie erforderlich, und nicht länger. Unter SEC Rule 204-2 müssen die meisten Adviser-Unterlagen mindestens fünf Jahre aufbewahrt werden (die ersten zwei an einem leicht zugänglichen Ort). MiFID II verlangt in der Regel mindestens fünf Jahre, auf Verlangen der Aufsicht verlängerbar auf sieben. Die GDPR zieht in die andere Richtung: Personenbezogene Daten dürfen nicht länger aufbewahrt werden als für den Zweck erforderlich.

Genau diese Spannung ist der Punkt. Für Kunde 48213 müssen Sie zeigen:

1. Den Aufbewahrungsplan, der für jede Datenkategorie gilt.

2. Belege, dass der Plan durchgesetzt wird (automatisierte Lösch- oder Archivierungsjobs, mit Logs).

3. Die Behandlung eines Löschantrags. Wenn 48213 ein Recht auf Löschung nach GDPR ausgeübt hat, müssen Sie zeigen, was gelöscht wurde und was rechtmäßig für aufsichtsrechtliche Aufzeichnungspflichten aufbewahrt blieb (die Aufzeichnungspflicht überlagert bei Transaktionsdaten üblicherweise das Löschrecht).

Ein Ausschnitt aus einem Aufbewahrungsplan könnte lauten: KYC-Dokumente, sieben Jahre nach Ende der Beziehung; Marketing-Einwilligung, bis zum Widerruf; Telefonaufzeichnungen unter MiFID II, fünf Jahre.

🎬 [VIDEO: „GDPR Data Retention Explained“ - youtube.com - klarer 10-minütiger Überblick über Aufbewahrungspflichten und ihr Zusammenspiel mit finanzaufsichtlichen Aufzeichnungsregeln]

Den Audit-Ordner aufbauen, bevor der Prüfer kommt

Stellen Sie das nicht während des Audits zusammen. Bauen Sie einen dauerhaften „Audit-Ordner“ (in der Regel ein kontrollierter digitaler Ordner), den jede berechtigte Person innerhalb von Stunden vorlegen kann.

Für einen Walkthrough zu einem einzelnen Kunden sollte der Ordner enthalten:

  • Eine Data Map für diesen Kunden, die jedes System zeigt, das seine Daten hält.
  • Das Lineage-Diagramm mindestens für die Geeignetheits- und Transaktionsdaten.
  • Einen Access Report für den Prüfzeitraum, gefiltert auf dieses Konto.
  • Den Aufbewahrungsplan plus Nachweis der Durchsetzung (Job-Logs, Archivierungsbelege).
  • Alle DSAR (Data Subject Access Request)- oder Löschvorgänge zu diesem Kunden.
  • Die Auftragsverarbeitungsvereinbarung mit jedem Dritten (Custodian, Fondsadministrator, Cloud-Provider), der die Daten berührt.

Der letzte Punkt wird leicht vergessen. Wenn Sie einen externen Administrator nutzen, kann der Prüfer fragen, wie Sie sich von dessen Kontrollen überzeugen. Verweisen Sie auf Ihre Due Diligence und die vertraglichen Datenklauseln, nicht auf vages Vertrauen.

Wissenscheck

1. Wenn ein Prüfer eine Firma auffordert zu belegen, „wer wann und warum auf die Daten eines Kunden zugegriffen hat“, scheitern Firmen meist daran, dass sie nicht in der Lage sind:

2. Was ist der grundlegende Unterschied zwischen dem, was eine Verhaltensaufsicht (wie die FCA) und eine Datenschutzbehörde (wie das ICO) in einer Prüfung jeweils interessiert?

3. Warum muss eine gute Auditvorbereitung Verhaltens- und Datenschutzaufsicht gleichzeitig erfüllen, statt sie getrennt zu behandeln?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten zu den Regelwerken, die die Datenpflichten von Asset- und Wealth-Managern bestimmen.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten, die beschreiben, was eine Firma auszeichnet, die ein Datenaudit BESTEHT, im Gegensatz zu einer, die durchfällt.

Wählen Sie alle richtigen Antworten aus.

Die Fragen proben, die schwache Governance offenlegen

Prüfer suchen Lücken, nicht Compliance-Theater. Führen Sie ein Mock Audit durch und spielen Sie diese Fragen live durch. Wo Sie ins Stocken geraten, steht Ihre Remediation-Liste.

„Erklären Sie mir, wie der Risiko-Score dieses Kunden in diesen Bericht gelangt ist.“

Testet Lineage. Eine schwache Antwort beschreibt Systeme allgemein. Eine starke Antwort nennt den Quelldatensatz, die Transformation und den Zeitstempel.

„Wer hat in den letzten 12 Monaten auf dieses Konto zugegriffen, und warum brauchte jede dieser Personen den Zugriff?“

Testet Access Logs und Least Privilege. Wenn Sie einen einzigen Zugriff nicht erklären können, ist das ein Finding.

„Zeigen Sie mir einen Kunden, der die Löschung verlangt hat, und belegen Sie, was passiert ist.“

Testet die Spannung zwischen GDPR und Aufzeichnungspflichten. Die richtige Antwort löscht Marketing- und nicht wesentliche personenbezogene Daten und behält Transaktionsdaten unter der gesetzlichen Ausnahme, mit Dokumentation der Begründung.

„Ihre Policy sagt, Daten werden nach sieben Jahren gelöscht. Zeigen Sie mir, dass das tatsächlich passiert ist.“

Testet Durchsetzung, nicht Policy. Legen Sie die Logs der Löschjobs vor. Eine Policy ohne Nachweis der Ausführung ist schlimmer als keine Policy, weil sie eine Kontrolllücke zeigt, die Sie als geschlossen angegeben haben.

„Wem gehören diese Daten, und wer genehmigt Änderungen an Zugriffsrechten?“

Testet Governance-Rollen. Nennen Sie den Data Owner (verantwortlich für eine Datendomäne) und den Genehmigungs-Workflow. „Das macht die IT“ ist eine durchgefallene Antwort, denn die IT betreibt Systeme; die Daten gehören dem Fachbereich.

„Wann haben Sie zuletzt getestet, dass Ihre Backups wiederherstellbar und Ihre Access Logs vollständig sind?“

Testet die operative Realität. Ungetestete Backups und lückenhafte Logs kommen ständig zum Vorschein.

Das Muster: Jede Frage geht von der Policy (was Sie sagen) zum Nachweis (was Sie belegen können). Governance, die nur in Dokumenten lebt, scheitert am zweiten Schritt.

Eine schnelle Selbstprüfung zum Nachrechnen

Eine einfache Kennzahl, die Prüfer schätzen: Access Review Coverage. Wenn Ihre Policy besagt, dass alle privilegierten Konten quartalsweise überprüft werden, und Sie 40 privilegierte Konten haben, sollten Sie etwa 160 Review-Datensätze pro Jahr sehen. Zeigen Ihre Logs 90, liegt die Abdeckung bei etwa 56 Prozent, und die Lücke ist Ihr Finding in Wartestellung. (Illustrative Zahlen.)

Wichtigste Erkenntnisse

  • Ein Audit eines einzelnen Kunden prüft drei Säulen: Lineage (dokumentierter Datenweg mit Zeitstempeln), Access Logs (wer hat zugegriffen und warum, unter Least Privilege) und Aufbewahrungsnachweis (durchgesetzte Pläne, nicht nur Policies).
  • Kennen Sie die tatsächlichen Regelwerke: SEC Rule 204-2 und Regulation S-P in den USA, FCA SYSC plus UK GDPR im Vereinigten Königreich, MiFID-II-Aufzeichnungspflichten plus GDPR in der EU. Aufzeichnungspflichten überlagern bei Transaktionsdaten üblicherweise das GDPR-Löschrecht.
  • Bauen Sie einen dauerhaften Audit-Ordner für einen Walkthrough zu einem einzelnen Kunden, bevor der Prüfer fragt. Nehmen Sie Auftragsverarbeitungsvereinbarungen mit Dritten auf.
  • Jede Prüferfrage geht von der Policy zum Nachweis. Wenn Sie das Log, den Nachweis des Aufbewahrungsplans oder den Löschbeleg nicht vorlegen können, existiert die Kontrolle faktisch nicht.
  • Benennen Sie Ihre Data Owner und den Genehmigungs-Workflow für Zugriffe. „Das macht die IT“ ist eine durchgefallene Antwort.