Mener un data audit : privacy risk assessments et BAA fournisseurs

La notification de breach à 4 h du matin

À 4 h du matin, le compliance officer d'un hôpital reçoit un appel : un vendor d'analytics cloud a laissé un storage bucket ouvert, et 60 000 dossiers patients ont été exposés pendant onze jours. L'hôpital a signé un contrat avec ce vendor il y a huit mois. Personne n'a revérifié les clauses de sécurité après le go-live. Personne n'a contrôlé par sondage si le flux de données « dé-identifié » l'était réellement.

Cette leçon construit le calendrier d'audit récurrent qui aurait détecté ces trois défaillances avant que le téléphone ne sonne.

Pourquoi un audit est un calendrier, pas un événement

Un data audit n'est pas un projet ponctuel. Les régulateurs attendent un programme continu.

Aux États-Unis, la loi de référence est HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (Health Insurance Portability and Accountability Act, 1996), appliquée par l'HHS Office for Civil Rights (OCR). La HIPAA Security Rule exige explicitement une risk analysis périodique, pas une validation unique. En Europe, le RGPDRGPDRè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 → (Règlement général sur la protection des données) impose une DPIA (Data Protection Impact Assessment) pour les traitements à haut risque, et les données de santé sont toujours à haut risque.

Les deux régimes partagent une idée : prouvez que vous vérifiez, de façon répétée, et documentez-le.

Voici la cadence annuelle que suit une véritable équipe data hospitalière.

Nous allons parcourir chaque point avec un seul exemple travaillé : l'onboarding d'un vendor d'analytics cloud (imaginez un outil de dashboard hébergé qui ingère des données de séjours patients pour afficher les tendances de durée d'hospitalisation).

Étape 1 : le privacy risk assessment

Un privacy risk assessment répond à une question : qu'est-ce qui peut mal tourner avec ces données, et à quel point ce serait grave ?

Pour notre vendor cloud, vous cartographiez d'abord le flux de données.

• Quelles données sortent de l'hôpital ? ID patient, date d'admission, date de sortie, codes diagnostic (CIM-10), service.
• Où vont-elles ? Région cloud du vendor (à confirmer : États-Unis ? UE ? Cela compte pour la data residencydata residencyL'exigence de stocker et traiter les données physiquement dans un pays ou une région précise, souvent pour des raisons légales ou contractuelles.Voir la définition complète → RGPD).
• Qui peut les voir ? Ingénieurs du vendor, équipe support, sous-traitants.

Ensuite, vous scorez le risque. Une méthode courante est probabilité x impact. Restez simple :

• Probabilité : 1 (rare) à 5 (fréquent)
• Impact : 1 (mineur) à 5 (sévère, breach à déclarer)

L'exposition de PHI (Protected Health Information : toute donnée de santé rattachée à une personne identifiable) obtient par défaut un impact élevé.

Exemple travaillé : le scénario du bucket ouvert.

Risk: Vendor misconfigures storage, exposing PHI
Likelihood = 3   (cloud misconfig is common industry-wide)
Impact     = 5   (reportable breach, 60k records)
Risk score = 3 x 5 = 15  (out of 25)

Un score de 15 est élevé. Cela impose un contrôle : exiger le chiffrement at rest, restreindre l'accès au bucket, et ajouter un droit d'audit contractuel. Vous consignez le score, le contrôle et l'owner. L'année suivante, vous re-scorez.

L'HHS OCR fournit un outil gratuit et téléchargeable pour cela : le HHS Security Risk Assessment Tool. Il est conçu pour les petites structures de soins, mais la logique se transpose à toute échelle.

Étape 2 : la revue du business associate agreement (BAA)

Un Business Associate au sens d'HIPAA est toute société externe qui traite des PHI pour le compte de l'hôpital. Le vendor d'analytics cloud est un business associate. Son hébergeur cloud aussi, si des PHI y transitent.

Un BAA (Business Associate Agreement) est le contrat qui engage juridiquement le vendor à protéger les PHI. Pas de BAA, pas de PHI. C'est aussi simple que ça. Envoyer des PHI à un vendor sans BAA signé constitue en soi une violation d'HIPAA.

Ce qu'il faut vérifier à chaque revue

À l'onboarding du vendor, puis chaque année, parcourez cette liste :

1. Est-il signé et à jour ? Vérifiez que l'exemplaire contresigné existe. C'est la case que tout le monde suppose cochée et qui souvent ne l'est pas.
2. Délai de notification de breach. En combien de temps le vendor doit-il vous signaler un incident ? HIPAA laisse à l'hôpital jusqu'à 60 jours pour notifier les personnes concernées, donc votre BAA doit exiger une information du vendor bien plus tôt (beaucoup d'hôpitaux imposent 24 à 72 heures).
3. Répercussion sur les sous-traitants. L'hébergeur cloud du vendor a-t-il lui aussi un BAA avec le vendor ? Les PHI se retrouvent souvent chez un sous-traitant que vous n'avez jamais choisi.
4. Restitution ou destruction des données à la fin du contrat. Quand le contrat se termine, qu'advient-il des données de séjour ? Faites-le écrire.
5. Droits d'audit. Pouvez-vous demander leurs attestations de sécurité (par exemple un rapport SOC 2 ou une certification HITRUST) ?

Dans notre cas de 4 h du matin, le BAA existait mais restait muet sur le délai de notification, donc le vendor a attendu onze jours. Un délai serré dans le BAA aurait ramené cela à quelques heures.

Pour l'europe : le DPA

Le RGPD utilise un instrument différent : le DPA (Data Processing Agreement), ou contrat de sous-traitance, au titre de l'article 28. Même esprit qu'un BAA (engager le sous-traitant), mais avec des clauses propres au RGPD : base légale, garanties pour les transferts hors UE, droits des personnes concernées. Un hôpital américain soignant des patients européens, ou un vendor stockant des données dans l'UE, a besoin des deux.

🎬 [VIDEO: "HIPAA Business Associate Agreements Explained" - youtube.com - une explication en langage clair de ce que doit contenir un BAA et des manques les plus fréquents]

Étape 3 : les contrôles par sondage de la dé-identification

Les vendors adorent dire « pas d'inquiétude, les données sont dé-identifiées ». Votre travail est de vérifier, tous les trimestres.

La dé-identification consiste à retirer suffisamment d'éléments pour qu'une personne ne puisse pas raisonnablement être identifiée. HIPAA prévoit deux méthodes :

• Safe Harbor : retirer 18 identifiants précis (nom, code postal complet, toutes les dates plus fines que l'année, numéro de dossier médical, etc.).
• Expert Determination : un statisticien qualifié certifie que le risque de ré-identification est très faible.

Le piège : les équipes qualifient des données de « dé-identifiées » alors qu'elles sont seulement pseudonymisées (l'identifiant réel remplacé par un code). Sous RGPD, une donnée pseudonymisée reste une donnée personnelle et reste régulée.

Un contrôle par sondage concret

Extrayez un échantillon du flux « dé-identifié » et cherchez les violations Safe Harbor. Un script rapide signale les fuites habituelles :

import pandas as pd

df = pd.read_csv("vendor_feed_sample.csv")

# Repère les dates complètes (HIPAA n'autorise que l'année)
date_leaks = df.filter(regex="date|admit|discharge").apply(
    lambda c: c.astype(str).str.match(r"\d{4}-\d{2}-\d{2}").any()
)

# Repère les codes postaux à 5 chiffres (Safe Harbor exige 3 chiffres, avec exceptions)
zip_leaks = df["zip"].astype(str).str.match(r"\d{5}").any()

print("Columns with full-date leaks:\n", date_leaks[date_leaks].index.tolist())
print("Full 5-digit ZIP present:", zip_leaks)

Si les dates d'admission et de sortie arrivent sous forme de valeurs complètes 2026-03-14, c'est un échec Safe Harbor : les dates doivent être réduites à l'année. Si les deux dates sont présentes, la durée de séjour combinée à un code postal peut ré-identifier un cas rare. Signalez-le, renvoyez-le au vendor, consignez le constat.

Pour le standard sous-jacent, voir les recommandations de dé-identification de l'HHS.

Étape 4 : le mettre au calendrier

La défaillance de 4 h du matin n'était pas une règle manquante. Chacun des contrôles ci-dessus existait sur le papier. La défaillance, c'est que personne ne les exécutait selon un calendrier.

Construisez un registre vivant. Une ligne par vendor, une colonne par contrôle avec sa prochaine échéance.

Deux règles rendent la chose réelle :

• Chaque ligne a un owner humain nommé. « La compliance » n'est pas un owner. Une personne l'est.
• Les lignes en retard escaladent automatiquement. Un contrôle trimestriel qui glisse vers « on s'en occupera » est exactement ce qui produit onze jours d'exposition.

Qui fait quoi

La gouvernance est un sport collectif. Rôles typiques :

• Privacy Officer / DPO (Data Protection Officer) : porte les risk assessments et le reporting réglementaire. Le RGPD impose un DPO pour le traitement à grande échelle de données de santé.
• Data engineering : exécute les contrôles de dé-identification et les access logs.
• Juridique / achats : porte la signature et le renouvellement des BAA et DPA.

Le calendrier d'audit est l'artefact partagé qui empêche ces trois-là de supposer que les autres s'en sont chargés.

À retenir

• Les audits sont récurrents ; traitez-les comme un calendrier. La risk analysis HIPAA et les DPIA RGPD sont des obligations continues, pas des validations uniques.
• Pas de BAA signé, pas de PHI. Tout vendor qui touche à des Protected Health Information a besoin d'un Business Associate Agreement à jour (ou d'un Data Processing Agreement RGPD en Europe), revu à l'onboarding puis annuellement, avec un délai de notification de breach serré.
• Vérifiez la dé-identification, ne lui faites pas confiance. Contrôlez les flux en production tous les trimestres au regard des règles HIPAA Safe Harbor ; les dates complètes et les codes postaux à 5 chiffres sont les fuites classiques. Pseudonymisé n'est pas dé-identifié.
• Scorez le risque simplement et agissez. Probabilité x impact donne un chiffre défendable et impose un contrôle précis avec un owner.
• Désignez une personne, pas un département. Chaque contrôle du registre a besoin d'un owner nommé et d'une escalade automatique en cas de retard.