# Preparing for a data audit and regulatory review
The examiner sits down, opens a laptop, and says: "Show me everything you hold on client account 48213, and prove who touched it, when, and why." You have maybe 48 hours to produce a clean answer. Firms that can assemble that evidence trail on demand pass. Firms that scramble through spreadsheets and email threads fail, and the failure is rarely about the underlying investment decisions. It is about data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète →.
This lesson walks through the exact evidence an FCA or SEC examiner expects, using one client's data journey as the worked example, then rehearses the questions that expose weak governance live.
Two regulators dominate for asset and wealth managers.
In the EU, MiFID II record keeping rules and the GDPR (General Data Protection Regulation) apply, with national regulators (BaFin in Germany, AMF in France) alongside data authorities.
Note the split: conduct regulators care that you can reconstruct a client's data journey for record keeping and suitability. Privacy regulators care that access was lawful, minimal, and time bound. A good audit prep satisfies both.
An examiner reviewing a single client is really checking three things: lineage (where did the data come from and how did it move), access logs (who saw or changed it), and retention proof (how long you keep it and how you delete it).
Lineage is the documented path of a data element from origin to current state. For client 48213, that means tracing a single field, say their risk tolerance score, from the onboarding questionnaire, through the CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète →, into the portfolio management system, and onto the suitability report.
Weak lineage looks like: "The score is in the system." Strong lineage looks like a mapped chain:
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)Each arrow needs a timestamp, a system of record, and a transformation note. If the risk score changed (say the client updated it in 2025-09), the lineage must show both versions and which report used which.
For a plain-English primer on why lineage matters under GDPR-style regimes, the ICO's guide to accountability and governance is a solid free reference.
The examiner wants to know every human and system that touched account 48213, and whether that access was justified.
Minimum fields per access event: user ID, role, timestamp, action (read, write, export, delete), and ideally a business reason. Privileged access (admins, developers) draws the most scrutiny because it can bypass controls.
Red flags an examiner hunts for:
The principle behind this is least privilege: each person gets only the access their role requires, and nothing more. If a junior analyst can read the full book of 5,000 clients when they only service 30, that is a finding.
Retention proof shows you keep data as long as required, and no longer. Under SEC Rule 204-2, most adviser records must be kept for at least five years (the first two in an easily accessible place). MiFID II generally requires records for at least five years, extendable to seven at a regulator's request. GDPR pulls the other way: you must not keep personal data longer than necessary for its purpose.
The tension is the point. For client 48213 you must show:
1. The retention schedule that applies to each data category.
2. Evidence the schedule is enforced (automated deletion or archival jobs, with logs).
3. Handling of a deletion request. If 48213 exercised a GDPR erasure right, you must show what was deleted and what was lawfully retained for regulatory record keeping (the record keeping obligation usually overrides erasure for transaction records).
A retention schedule fragment might read: KYC documents, seven years after relationship ends; marketing consent, until withdrawn; call recordings under MiFID II, five years.
🎬 [VIDEO: "GDPR Data Retention Explained" - youtube.com - clear 10 minute overview of retention obligations and how they interact with financial record keeping rules]
Do not assemble this during the audit. Build a standing "audit binder" (usually a controlled digital folder) that any authorised person can produce in hours.
For a single-client walkthrough, the binder should contain:
The last point is easy to forget. If you use a third-party administrator, the examiner may ask how you assure their controls. Point to your due diligence and the contractual data clauses, not vague trust.
Vérification des acquis
1. When an examiner asks a firm to prove 'who touched a client's data, when, and why,' the most common reason firms fail is that they cannot:
2. What is the fundamental distinction between what a conduct regulator (like the FCA) and a privacy regulator (like the ICO) each care about during a review?
3. Why does good audit preparation need to satisfy both conduct and privacy regulators simultaneously rather than treating them separately?
4. Select ALL correct answers about the regulatory frameworks that govern asset and wealth managers' data obligations.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers describing what characterizes a firm that would PASS a data audit versus one that would fail.
Sélectionnez toutes les réponses correctes.
Examiners probe for gaps, not compliance theatre. Run a mock audit and role-play these live questions. If you stumble, that is your remediation list.
"Walk me through how this client's risk score reached this report."
Tests lineage. A weak answer describes systems in general. A strong answer names the source record, the transformation, and the timestamp.
"Who has accessed this account in the last 12 months, and why did each person need to?"
Tests access logs and least privilege. If you cannot explain a single access, that is a finding.
"Show me a client who asked to be deleted, and prove what happened."
Tests the GDPR versus record keeping tension. The correct answer deletes marketing and non-essential personal data while retaining transaction records under the legal exemption, with documentation of the reasoning.
"Your policy says data is deleted after seven years. Show me it actually happened."
Tests enforcement, not policy. Produce the deletion job logs. A policy with no evidence of execution is worse than no policy, because it shows a control gap you claimed to have closed.
"Who owns this data, and who signs off on access changes?"
Tests governance roles. Name the data owner (accountable for a data domain) and the approval workflow. "IT handles it" is a failing answer because IT operates systems; the business owns the data.
"When did you last test that your backups are restorable and that access logs are complete?"
Tests operational reality. Untested backups and gappy logs surface constantly.
The pattern: every question moves from policy (what you say) to evidence (what you can prove). Governance that only lives in documents fails the second step.
One simple metric examiners appreciate: access review coverage. If your policy says all privileged accounts are reviewed quarterly, and you have 40 privileged accounts, you should see roughly 160 review records per year. If your logs show 90, coverage is about 56 percent, and the gap is your finding waiting to happen. (Illustrative figures.)