Se préparer à un audit de données et à une revue réglementaire

L'inspecteur s'assoit, ouvre son ordinateur portable et dit : « Montrez-moi tout ce que vous détenez sur le compte client 48213, et prouvez-moi qui y a touché, quand, et pourquoi. » Vous avez peut-être 48 heures pour produire une réponse propre. Les sociétés capables de reconstituer cette piste de preuves à la demande passent. Celles qui fouillent dans des tableurs et des fils d'e-mails échouent, et l'échec porte rarement sur les décisions d'investissement elles-mêmes. Il porte sur la gouvernance des données.

Cette leçon parcourt les preuves exactes qu'attend un inspecteur de la FCA ou de la SEC, en prenant le parcours de données d'un client comme exemple pratique, puis répète les questions qui mettent à nu une gouvernance faible en direct.

Qui pose les questions, et en vertu de quelle autorité

Deux régulateurs dominent pour les gérants d'actifs et de patrimoine.

• FCA (Financial Conduct Authority) : le régulateur britannique de conduite. Son rulebook (SYSC, le sourcebook Systems and Controls) exige des sociétés qu'elles tiennent des registres ordonnés et démontrent leur mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →îtrise des données clients. La protection des données relève du UK GDPR et du Data Protection Act 2018, appliqués par l'ICO (Information Commissioner's Office).
• SEC (Securities and Exchange Commission) : le régulateur américain des marchés. Pour les conseillers en investissement enregistrés, la Books and Records Rule (Rule 204-2 de l'Investment Advisers Act de 1940) et la Marketing Rule définissent ce qui doit être conservé et produit. La Safeguards Rule de la Regulation S-P régit la sécurité des données clients.

Dans l'UE, les règles de record keeping de MiFID II et le GDPR (General Data Protection Regulation) s'appliquent, avec les régulateurs nationaux (BaFin en Allemagne, AMF en France) aux côtés des autorités de protection des données.

Notez la répartition : les régulateurs de conduite veulent que vous puissiez reconstituer le parcours de données d'un client pour le record keeping et l'adéquation. Les régulateurs de la vie privée veulent que l'accès ait été licite, minimal et limité dans le temps. Une bonne préparation d'audit satisfait les deux.

Les trois piliers de la piste de preuves

Un inspecteur qui examine un seul client vérifie en réalité trois choses : la lineage (d'où viennent les données et comment elles ont circulé), les access logs (qui les a vues ou modifiées) et la preuve de rétention (combien de temps vous les conservez et comment vous les supprimez).

Pilier 1 : la data lineagedata lineageLe data lineage cartographie les déplacements et transformations de la donnée à travers les systèmes, de l'origine à la consommation : d'où elle vient, ce qui l'a modifiée, et où elle va.Voir la définition complète →

La lineage est le chemin documenté d'un élément de donnée, de son origine à son état actuel. Pour le client 48213, cela signifie retracer un champ unique, par exemple son score de tolérance au risque, depuis le questionnaire d'onboarding, à travers le CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète →, jusqu'au système de gestion de portefeuille, puis jusqu'au rapport d'adéquation.

Une lineage faible ressemble à : « Le score est dans le système. » Une lineage solide ressemble à une chaîne cartographiée :

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)

Chaque flèche exige un horodatage, un système de référence et une note de transformation. Si le score de risque a changé (disons que le client l'a mis à jour en 2025-09), la lineage doit montrer les deux versions et indiquer quel rapport a utilisé laquelle.

Pour une introduction en langage clair aux raisons pour lesquelles la lineage compte dans les régimes de type GDPRGDPRRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →, le guide de l'ICO sur l'accountability et la gouvernance est une référence gratuite solide.

Pilier 2 : les access logs

L'inspecteur veut connaître chaque humain et chaque système qui a touché au compte 48213, et savoir si cet accès était justifié.

Champs minimaux par événement d'accès : identifiant utilisateur, rôle, horodatage, action (lecture, écriture, export, suppression) et idéalement un motif métier. Les accès privilégiés (administrateurs, développeurs) attirent le plus d'attention car ils peuvent contourner les contrôles.

Les signaux d'alerte qu'un inspecteur traque :

• Un collaborateur parti dont les accès n'ont pas été révoqués.
• Des exports massifs de données clients vers une machine locale ou une messagerie personnelle.
• Des développeurs qui lisent des enregistrements clients en production sans référence de ticket.
• Aucun log avant une certaine date (ce qui suggère qu'un changement de système a effacé l'historique).

Le principe derrière tout cela est le least privilege : chacun n'obtient que les accès requis par son rôle, et rien de plus. Si un analyste junior peut lire l'intégralité du portefeuille de 5 000 clients alors qu'il n'en suit que 30, c'est un constat d'audit.

Pilier 3 : la preuve de rétention

La preuve de rétention montre que vous conservez les données aussi longtemps qu'exigé, et pas davantage. Selon la SEC Rule 204-2, la plupart des registres d'un conseiller doivent être conservés au moins cinq ans (les deux premières années dans un endroit facilement accessible). MiFID II exige généralement une conservation de cinq ans au minimum, extensible à sept à la demande d'un régulateur. Le GDPR tire dans l'autre sens : vous ne devez pas conserver de données personnelles plus longtemps que nécessaire au regard de leur finalité.

La tension est précisément le sujet. Pour le client 48213, vous devez montrer :

1. Le calendrier de rétention applicable à chaque catégorie de données.
2. La preuve que ce calendrier est appliqué (travaux automatisés de suppression ou d'archivage, avec logs).
3. Le traitement d'une demande de suppression. Si 48213 a exercé un droit à l'effacement GDPR, vous devez montrer ce qui a été supprimé et ce qui a été légitimement conservé au titre du record keeping réglementaire (l'obligation de record keeping prime généralement sur l'effacement pour les enregistrements de transactions).

Un extrait de calendrier de rétention pourrait indiquer : documents KYC, sept ans après la fin de la relation ; consentement marketing, jusqu'à retrait ; enregistrements d'appels sous MiFID II, cinq ans.

🎬 [VIDEO: "GDPR Data Retention Explained" - youtube.com - panorama clair en 10 minutes des obligations de rétention et de leur interaction avec les règles de record keeping financier]

Constituer le classeur d'audit avant l'arrivée de l'inspecteur

Ne l'assemblez pas pendant l'audit. Constituez un « classeur d'audit » permanent (généralement un dossier numérique contrôlé) que toute personne habilitée peut produire en quelques heures.

Pour un parcours mono-client, le classeur doit contenir :

• Une data map pour ce client montrant chaque système détenant ses données.
• Le schéma de lineage pour au moins les données d'adéquation et de transactions.
• Un rapport d'accès couvrant la période examinée, filtré sur ce compte.
• Le calendrier de rétention ainsi que la preuve de son application (logs de jobs, accusés d'archivage).
• Tout enregistrement de DSAR (Data Subject Access Request) ou d'effacement pour ce client.
• Le data processing agreement avec tout tiers (dépositaire, administrateur de fonds, fournisseur cloud) qui touche aux données.

Le dernier point s'oublie facilement. Si vous recourez à un administrateur tiers, l'inspecteur peut demander comment vous vous assurez de ses contrôles. Appuyez-vous sur votre due diligence et les clauses contractuelles relatives aux données, pas sur une confiance vague.

Répéter les questions qui mettent à nu une gouvernance faible

Les inspecteurs cherchent les failles, pas le théâtre de la conformité. Organisez un audit à blanc et jouez ces questions en direct. Si vous hésitez, voilà votre liste de remédiation.

« Expliquez-moi comment le score de risque de ce client est arrivé dans ce rapport. »

Teste la lineage. Une réponse faible décrit les systèmes en général. Une réponse solide nomme l'enregistrement source, la transformation et l'horodatage.

« Qui a accédé à ce compte au cours des 12 derniers mois, et pourquoi chaque personne en avait-elle besoin ? »

Teste les access logs et le least privilege. Si vous ne pouvez expliquer un seul accès, c'est un constat d'audit.

« Montrez-moi un client qui a demandé sa suppression, et prouvez ce qui s'est passé. »

Teste la tension entre GDPR et record keeping. La bonne réponse supprime les données marketing et les données personnelles non essentielles tout en conservant les enregistrements de transactions au titre de l'exemption légale, avec documentation du raisonnement.

« Votre politique dit que les données sont supprimées après sept ans. Montrez-moi que cela a bien eu lieu. »

Teste l'application, pas la politique. Produisez les logs des jobs de suppression. Une politique sans preuve d'exécution est pire que pas de politique, car elle révèle un écart de contrôle que vous prétendiez avoir comblé.

« Qui est propriétaire de ces données, et qui valide les changements d'accès ? »

Teste les rôles de gouvernance. Nommez le data owner (responsable d'un domaine de données) et le workflow d'approbation. « C'est l'IT qui gère » est une réponse éliminatoire, car l'IT exploite les systèmes ; le métier est propriétaire des données.

« Quand avez-vous testé pour la dernière fois la restaurabilité de vos sauvegardes et la complétude de vos access logs ? »

Teste la réalité opérationnelle. Les sauvegardes non testées et les logs troués remontent en permanence.

La logique : chaque question passe de la politique (ce que vous dites) à la preuve (ce que vous pouvez démontrer). Une gouvernance qui ne vit que dans les documents échoue à la seconde étape.

Un calcul d'auto-évaluation rapide

Une métrique simple que les inspecteurs apprécient : le taux de couverture des revues d'accès. Si votre politique prévoit que tous les comptes privilégiés sont revus chaque trimestre, et que vous avez 40 comptes privilégiés, vous devriez voir environ 160 enregistrements de revue par an. Si vos logs en montrent 90, la couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → est d'environ 56 %, et l'écart est votre futur constat d'audit. (Chiffres illustratifs.)

Points clés

• L'audit d'un seul client teste trois piliers : la lineage (chemin de données documenté avec horodatages), les access logs (qui y a touché et pourquoi, sous least privilege) et la preuve de rétention (calendriers appliqués, pas seulement des politiques).
• Connaissez les vrais textes : SEC Rule 204-2 et Regulation S-P aux États-Unis, FCA SYSC plus UK GDPR au Royaume-Uni, record keeping MiFID II plus GDPR dans l'UE. Les obligations de record keeping priment généralement sur l'effacement GDPR pour les données de transactions.
• Constituez un classeur d'audit permanent pour un parcours mono-client avant que l'inspecteur ne le demande. Incluez les data processing agreements avec les tiers.
• Chaque question d'inspecteur passe de la politique à la preuve. Si vous ne pouvez produire le log, la preuve du calendrier ou l'enregistrement de suppression, le contrôle n'existe pas en pratique.
• Nommez vos data owners et votre workflow d'approbation des accès. « C'est l'IT qui gère » est une réponse éliminatoire.