Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité

Dans la santé et l'action sociale, protéger l'information est indissociable de la prestation des soins : les mêmes données qui sauvent une vie peuvent, si elles sont mal gérées, briser la confiance qui rend le traitement possible — la façon dont vous gouvernez, partagez et sécurisez ces données est donc une obligation clinique, éthique et de confiance publique, pas un à-côté de conformité.

Pourquoi c'est important dans la santé et l'action sociale#

Les données de santé et d'action sociale comptent parmi les informations les plus sensibles qu'une personne créera jamais. Elles enregistrent des diagnostics, des médicaments, des épisodes de santé mentale, la santé sexuelle, des droits liés à l'immigration, et les détails intimes de vies fragiles et vulnérables. Les personnes divulguent ces éléments aux cliniciens sur la promesse implicite que l'information sera utilisée pour les aider et ne sera pas diffusée avec négligence. Lorsque cette promesse est rompue — par une fuite, une panne due à un rançongiciel, ou un accord de partage de données inexpliqué — les patients retiennent des informations, refusent l'accès à leurs dossiers, ou évitent les soins tout simplement. Ce n'est pas un préjudice abstrait ; cela dégrade directement la sécurité clinique et la santé de la population.

Les enjeux sont aussi opérationnels. Un hôpital moderne ne peut fonctionner sans ses systèmes électroniques : communications de commandes, résultats, prescription électronique, imagerie et administration des patients sont tous numériques. Lorsque ces systèmes tombent en panne, les ambulances sont déroutées, les opérations sont annulées, et les cliniciens reviennent au papier d'une manière qui introduit ses propres erreurs. La gouvernance de l'information et la cybersécurité sont donc des disciplines de continuité des soins. Elles se situent aux côtés de la sécurité clinique (Sujet 1.6 — Sécurité clinique et gestion des risques), pas dans un silo de conformité séparé.

Enfin, il existe une tension réelle et incontournable au cœur de ce sujet. Le public attend à juste titre que le service de santé utilise les données pour améliorer les soins, planifier les services et soutenir la recherche qui trouvera les traitements de demain. Il attend aussi la confidentialité et le contrôle. Ces objectifs se tirent dans des directions opposées, et votre travail en tant que dirigeant n'est pas de prétendre que la tension n'existe pas, mais de la gérer ouvertement — en permettant un usage légitime tout en rendant visibles et honnêtes les garanties et les choix offerts aux patients. Se tromper dans cet équilibre, dans un sens ou dans l'autre, fait perdre : soit vous privez les soins et la recherche de données, soit vous érodez la confiance dont dépend tout le système.

Concepts fondamentaux#

Ce domaine repose sur la discipline de la gouvernance de l'information — le cadre de règles, de rôles et de contrôles par lequel une organisation traite l'information de manière légale, sécurisée et éthique. Au Royaume-Uni, les fondements juridiques principaux sont le Règlement général sur la protection des données britannique (UK GDPR), la version nationale du règlement européen conservée après le Brexit, et le Data Protection Act 2018 (DPA 2018), qui le complète. Ensemble, ils exigent que les données personnelles soient traitées de manière licite, loyale et transparente, et que chaque activité de traitement repose sur une base légale. Les informations de santé constituent des données de catégorie spéciale, qui nécessitent à la fois une base légale au titre de l'article 6 et une condition supplémentaire au titre de l'article 9 — pour les soins directs, typiquement la fourniture de soins de santé ou sociaux par un professionnel soumis à une obligation de confidentialité.

Le droit de la protection des données n'est pas la seule contrainte. Le devoir de confidentialité de common law est une obligation distincte et plus ancienne : l'information donnée en confidence ne peut être divulguée sans consentement, exigence légale, ou intérêt public prépondérant. Vous pouvez être pleinement conforme à l'UK GDPR et pourtant enfreindre la confidentialité — les deux doivent donc être satisfaits.

Deux cadres spécifiques à la santé traduisent ces obligations en pratique. Les principes Caldicott — un ensemble de principes (désormais huit) pour traiter les informations confidentielles des patients, énoncés pour la première fois dans le rapport Caldicott de 1997 — sont défendus au sein de chaque organisation par un Caldicott Guardian, une personne haut placée responsable de la protection de la confidentialité des patients et de la facilitation d'un partage approprié de l'information. Au niveau national, le National Data Guardian for Health and Social Care (NDG) est une voix statutaire indépendante conseillant sur la manière dont les données des patients doivent être utilisées et protégées. Le national data opt-out donne aux patients un mécanisme pour empêcher que leurs informations confidentielles soient utilisées à des fins autres que leurs soins directs, comme la planification et la recherche, et les organisations doivent le respecter.

Sur le plan opérationnel, une évaluation d'impact relative à la protection des données (DPIA) est l'évaluation structurée que vous réalisez avant tout traitement susceptible de présenter un risque élevé — ce qui est le cas de la plupart des nouveaux projets de données de santé — afin d'identifier et d'atténuer les risques pour la vie privée. Chaque organisation doit nommer un Data Protection Officer (DPO), un rôle indépendant chargé de conseiller sur la conformité et de la surveiller. En Angleterre, le Data Security and Protection Toolkit (DSPT) est l'auto-évaluation annuelle par laquelle les organisations de santé et d'action sociale démontrent qu'elles respectent les normes de sécurité des données et de gouvernance de l'information requises pour traiter les données du NHS.

Côté sécurité, le National Cyber Security Centre (NCSC) fournit des directives britanniques faisant autorité et, à travers son Cyber Assessment Framework (CAF), un moyen structuré de mesurer la résilience cyber. Les bonnes pratiques reposent sur des fondamentaux bien établis : la défense en profondeur, qui superpose plusieurs contrôles afin qu'aucune défaillance unique ne soit catastrophique ; le principe du moindre privilège, qui n'accorde aux personnes et aux systèmes que l'accès dont ils ont réellement besoin ; une gestion rigoureuse des correctifs et des sauvegardes testées ; et la préparation face aux rançongiciels, ces logiciels malveillants qui chiffrent les systèmes à des fins d'extorsion. Parce que la prévention seule ne tient jamais, les organisations matures investissent aussi dans les opérations : un centre d'opérations de sécurité (SOC) — une capacité, interne ou partagée, qui surveille les journaux et la télémétrie pour détecter et contenir les intrusions — et un processus rodé de réponse aux incidents pour passer rapidement de la détection au rétablissement. L'attaque du rançongiciel WannaCry de 2017, qui a perturbé environ un tiers des trusts du NHS en Angleterre et causé un impact estimé à 92 millions de livres sterling, demeure l'exemple emblématique de mise en garde — ses dégâts découlaient largement de systèmes non corrigés, pas d'un piratage exotique.

Bonnes pratiques#

1. Commencez chaque projet de données par une DPIA, et traitez-la comme de la conception, pas de la paperasse. Avant de construire ou d'acquérir quoi que ce soit qui traite des données personnelles, travaillez sur une évaluation d'impact relative à la protection des données avec votre DPO et votre Caldicott Guardian. Réalisée tôt, elle façonne la conception — en minimisant les données collectées, en choisissant la pseudonymisation, en resserrant l'accès — plutôt que d'entériner des décisions déjà prises. Une DPIA reléguée jusqu'à la mise en production est un signe d'alerte indiquant que la gouvernance n'est que théâtre.

2. Nommez explicitement votre base légale et votre base de confidentialité, et consignez-les par écrit. Pour chaque flux de données de santé, indiquez la base légale de l'article 6, la condition de catégorie spéciale de l'article 9, et comment le devoir de confidentialité de common law est satisfait — consentement, passerelle légale, ou intérêt public. L'ambiguïté ici est ce qui fait échouer les projets ou les fait retirer après leur lancement. Être explicite permet aussi d'expliquer le traitement aux patients en langage clair, ce qui est en soi une exigence légale.

3. Appliquez le moindre privilège et l'accès basé sur les rôles partout. N'accordez aux cliniciens, administrateurs, chercheurs et systèmes que l'accès requis par leur rôle, et révisez-le régulièrement à mesure que les personnes changent de poste ou partent. Consignez l'accès aux dossiers sensibles et auditez-le, car la menace crédible de détection dissuade la curiosité inappropriée autant que tout contrôle technique. La plupart des violations réelles sont banales — la mauvaise personne voyant le mauvais dossier — pas des intrusions sophistiquées.

4. Mettez en place les fondamentaux de la cybersécurité avant d'acheter des outils avancés. Les directives du NCSC sont peu glamour et efficaces : corriger rapidement, en particulier les systèmes exposés à Internet et les systèmes cliniques ; imposer l'authentification multifacteur ; segmenter les réseaux pour qu'une infection ne puisse pas se propager librement ; et maintenir des sauvegardes hors ligne et testées. WannaCry s'est propagé via des systèmes Windows non corrigés, et la leçon perdure — l'hygiène de base prévient la majorité des incidents. Dépensez d'abord sur les fondamentaux ; achetez une détection sophistiquée une fois les bases solides.

5. Supposez que vous serez attaqué, et répétez votre réponse. Maintenez et exercez un plan de réponse aux incidents et de continuité d'activité qui suppose que les systèmes seront indisponibles, incluant un repli clinique sur papier et un plan de communication pour le personnel et les patients. Testez vos sauvegardes en les restaurant réellement, car une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un contrôle. Organisez des exercices sur table pour que la première fois que votre équipe gère une panne due à un rançongiciel ne soit pas lors d'une véritable attaque.

6. Complétez le DSPT honnêtement et utilisez-le comme une véritable évaluation. Le Data Security and Protection Toolkit est une exigence pour traiter les données du NHS, mais sa valeur vient du fait de le traiter comme un bilan annuel honnête plutôt qu'un rituel de case à cocher. Là où vous ne pouvez pas atteindre une norme, consignez l'écart et un plan d'amélioration crédible plutôt que de surestimer votre position. Un retour DSPT gonflé donne à votre conseil d'administration une fausse assurance, ce qui est pire que l'absence d'assurance.

7. Faites du partage d'information une capacité conçue, pas un obstacle. À travers un integrated care system (ICS), les bons soins dépendent de données franchissant les frontières organisationnelles entre trusts, cabinets de médecins généralistes, action sociale et prestataires communautaires. Mettez en place des accords clairs de partage d'information (ISA) et des accords de partage de données, convenez conjointement des bases légales et de confidentialité, et concevez des dossiers partagés pour que le bon professionnel voie la bonne information au point de soin. L'objectif est un partage sûr, pas une absence de partage — retenir des données dont un clinicien a besoin est en soi un échec de sécurité des patients. Cela se connecte directement au Sujet 4.3 — Interopérabilité et normes de données.

8. Respectez le choix du patient et soyez transparent sur les usages secondaires. Respectez le national data opt-out dans chaque flux d'usage secondaire, et publiez des informations claires et accessibles sur la façon dont les données sont utilisées pour la planification et la recherche. Lorsque des données sont partagées avec des partenaires commerciaux ou utilisées pour entraîner des modèles, divulguez-le de manière proactive plutôt que de le laisser transparaître via une fuite — les accords cachés ont déclenché à plusieurs reprises un contrecoup public et des vagues de désinscription. La transparence n'est pas une courtoisie ; c'est ce qui maintient le flux de données.

9. Gérez les dossiers sur l'ensemble de leur cycle de vie. Appliquez des calendriers de conservation basés sur le NHS Records Management Code of Practice, en éliminant les dossiers de manière sécurisée à la fin de leur période de conservation et en les gardant accessibles et intacts tant qu'elle dure. Une mauvaise gestion des dossiers crée à la fois un risque (conserver des données dont vous n'avez plus besoin) et un préjudice (perdre des données dont dépendent les cliniciens). La migration entre systèmes est un moment à haut risque — planifiez délibérément la qualité des données, la cartographie et l'archivage.

10. Intégrez la gouvernance dans les achats et la gestion des fournisseurs. Inscrivez les exigences de protection des données et de sécurité dans les contrats : conditions de traitement des données, certification DSPT ou équivalente, délais de notification des violations, et droit d'audit. La sécurité faible d'un fournisseur devient votre incident et votre gros titre, alors évaluez la chaîne d'approvisionnement, pas seulement votre propre périmètre. Travaillez cela conjointement avec vos collègues commerciaux comme couvert au Sujet 6.3 — Achats et commercial, et exigez des réponses claires sur où les données sont hébergées et qui peut y accéder.

11. Investissez dans la détection, pas seulement la prévention. Supposez que certaines attaques traverseront vos défenses, et construisez la capacité de les voir : journalisation centralisée, surveillance des systèmes clés, et un centre d'opérations de sécurité — interne, partagé à travers un ICS, ou s'appuyant sur des services nationaux tels que le NCSC et les opérations cyber de NHS England — afin que l'activité suspecte soit repérée et contenue plutôt que découverte des semaines plus tard. Associez cela à une gestion continue des vulnérabilités et à une détection des menaces, afin de corriger les faiblesses que les attaquants exploitent réellement. La détection vous achète le temps de contenir un incident avant qu'il ne devienne une panne.

12. Traitez une cyberattaque grave comme un événement de continuité clinique. Rédigez, dotez en ressources et répétez un plan de réponse aux incidents cyber qui nomme qui déclare un incident, qui dirige la réponse technique, et qui est responsable de la sécurité clinique et des communications externes pendant que les systèmes sont hors service. Connectez-le directement à vos dispositions de continuité d'activité et de reprise après sinistre (voir Sujet 3.9 — Continuité d'activité et reprise après sinistre) et à vos processus de préparation aux incidents majeurs et EPRR (voir Sujet 3.10 — Préparation, résilience et réponse aux urgences), afin qu'une panne due à un rançongiciel soit traitée avec la même discipline que toute menace pour les soins aux patients. Un plan qui ne vit que dans le département informatique échouera au moment où une attaque devient une crise clinique.

Questions à discuter avec votre équipe#

1. Où, dans nos services, partageons-nous trop peu, et où partageons-nous trop — et comment le saurions-nous seulement ? Les échecs de gouvernance de l'information vont dans les deux sens. Le partage excessif se manifeste par des violations et une confiance érodée ; le partage insuffisant se manifeste discrètement, comme un clinicien qui n'a pas pu voir une allergie, une préoccupation de protection tombée entre les mailles des agences, ou une sortie qui a mal tourné parce que les équipes communautaires manquaient de contexte. Discutez de cas concrets de votre propre contexte. Avez-vous un biais — souvent défensif — qui traite la rétention comme automatiquement sûre ? Quels signaux vous indiqueraient qu'une frontière de partage nuit aux patients, et qui est responsable de le remarquer ? Une équipe mature peut nommer des exemples des deux types d'échec et dispose d'une voie pour escalader chacun.

2. Si une attaque par rançongiciel mettait nos systèmes cliniques hors ligne demain matin, que se passerait-il réellement dans la première heure ? Dépassez le plan sur papier pour aller vers la réalité vécue. Qui déclare l'incident, et comment le personnel l'apprend-il lorsque le courrier électronique et l'intranet peuvent être hors service ? Quel est le repli clinique pour la prescription, les résultats et l'identification des patients, et le personnel de première ligne l'a-t-il déjà pratiqué ? Combien de temps chaque service peut-il fonctionner sur papier avant que la sécurité des patients ne se dégrade, et comment décidez-vous de dérouter ou d'annuler ? Quand avez-vous restauré une sauvegarde pour la dernière fois afin de prouver qu'elle fonctionne ? L'honnêteté de cette conversation — en particulier les lacunes que les gens répugnent à admettre — est une meilleure mesure de la résilience que n'importe quel score de cadre.

3. Comment expliquerions-nous nos usages des données à un patient sceptique, et sentirait-il que nous avons été honnêtes avec lui ? La confiance publique se gagne en langage clair, pas dans des avis juridiques. Choisissez un usage secondaire réel des données dans votre organisation — planification des services, partenariat de recherche, accord avec un fournisseur, outil d'IA — et essayez de l'expliquer à une personne ordinaire : quelles données, à quelle fin, qui en bénéficie, quelles garanties, et quel choix elle a. Où l'explication devient-elle inconfortable ou évasive ? Cet inconfort marque généralement quelque chose que vous devriez soit changer, soit communiquer plus ouvertement. Considérez à quoi ressembleraient le national data opt-out et vos supports de transparence pour quelqu'un prédisposé à la méfiance, et reliez ceci à la gouvernance de l'IA au Sujet 8.4 — Gouvernance de l'IA et des technologies émergentes.

4. Lorsqu'un fournisseur ou un partenaire détient les données de nos patients, de qui est l'incident — et sommes-nous sûrs de pouvoir le découvrir à temps ? La plupart des organisations de santé et d'action sociale dépendent désormais d'une chaîne de tiers : le fournisseur du DPI, un hébergeur cloud, un prestataire de services gérés, un partenaire de pathologie ou d'imagerie. Une violation ou une panne n'importe où dans cette chaîne devient votre crise clinique et votre gros titre, pourtant le contrat, la certification et le délai de notification de violation reçoivent souvent bien moins de scrutin que votre propre périmètre. Discutez de ce que vous savez réellement sur où vos données sont hébergées, qui peut y accéder, et à quelle vitesse un fournisseur est contractuellement tenu de vous informer lorsque quelque chose tourne mal. Avez-vous déjà testé cette voie de notification, ou vu le DSPT d'un fournisseur ou une assurance équivalente plutôt que de la prendre pour acquise ? Que se passe-t-il si un fournisseur critique est lui-même touché par un rançongiciel un vendredi soir ? Une réponse honnête nomme les fournisseurs que vous ne pouvez actuellement pas tenir responsables et relie ceci au Sujet 6.3 — Achats et commercial.

5. Qui possède réellement le risque de gouvernance de l'information ici — et en entendrait-il parler avant qu'il ne devienne une crise ? Sur le papier, un DPO et un Caldicott Guardian possèdent le risque de confidentialité et de protection des données, et le conseil d'administration possède la résilience cyber. En pratique, ces rôles sont souvent sous-dotés en ressources, consultés tardivement, ou traités comme une simple validation plutôt qu'une voix, de sorte que les risques ne sont ni remontés ni escaladés jusqu'à ce qu'ils se manifestent en incidents. Parlez honnêtement de savoir si votre Caldicott Guardian et votre DPO sont réellement impliqués tôt dans les décisions, s'ils peuvent dire non et être entendus, et si le risque cyber atteint le conseil d'administration comme quelque chose qu'il comprend et possède plutôt qu'un rapport technique qu'il approuve d'un signe de tête. Un clinicien de première ligne qui a repéré un accès inapproprié, ou un ingénieur qui a trouvé un système critique non corrigé, saurait-il comment le signaler et ferait-il confiance au fait que quelque chose se passerait ? Le test de l'appropriation n'est pas l'organigramme mais si les nouvelles inconfortables remontent rapidement, et ceci se relie à la culture de sécurité discutée au Sujet 1.6 — Sécurité clinique et gestion des risques.

6. Comment décidons-nous quelles données conserver, lesquelles supprimer, et qui a encore besoin d'accès — et quand l'avons-nous réellement fait pour la dernière fois ? L'attention de la gouvernance se concentre sur la collecte et le partage des données, mais la conservation, l'élimination et la révision des accès sont là où le risque silencieux s'accumule : dossiers conservés bien au-delà de leur période de conservation légale, comptes dormants qui ouvrent encore des systèmes actifs, et droits d'accès qui ont suivi les personnes lorsqu'elles ont changé de rôle mais qui n'ont jamais été retirés. Chaque dossier dont vous n'avez plus besoin est une responsabilité que vous stockez, et chaque identifiant obsolète est une voie d'accès pour un attaquant ou un initié curieux. Discutez de savoir si vos calendriers de conservation suivent le NHS Records Management Code of Practice en réalité ou seulement en politique, quand les droits d'accès ont été révisés et élagués pour la dernière fois, et comment vous gérez le moment à haut risque de la migration ou du démantèlement d'un système. Qui est responsable d'appuyer sur supprimer, et quelqu'un est-il mesuré là-dessus ? Une réponse honnête révèle généralement une accumulation de données et d'accès dont personne ne s'est occupé depuis des années.

En pratique : un exemple de santé et d'action sociale#

Le Meadowford Integrated Care System met en place un dossier de soins partagé afin que les cliniciens hospitaliers, les médecins généralistes, les infirmières communautaires et les travailleurs sociaux puissent voir une vue unifiée de chaque personne. Le programme est populaire auprès des cliniciens et politiquement visible, et la tentation est d'aller vite.

Le directeur de programme insiste pour séquencer la gouvernance parallèlement à la construction plutôt que derrière elle. Une DPIA est ouverte dès le départ, dirigée conjointement par le DPO et le Caldicott Guardian principal issu des organisations partenaires. Elle force des décisions précoces et utiles : le dossier affichera un résumé clinique organisé plutôt que chaque document historique ; les dossiers d'action sociale contenant des informations de tiers seront traités selon des règles plus strictes ; et l'accès sera basé sur les rôles, avec une vérification de relation légitime afin qu'un professionnel ne puisse ouvrir un dossier que pour quelqu'un dont il a la charge. Chaque accès est consigné et audité, et le personnel en est informé clairement.

Les partenaires conviennent d'un accord unique de partage d'information couvrant le devoir de confidentialité de common law et les bases légales — soins directs au titre de l'article 6(1)(e) et de l'article 9(2)(h) — et ils confirment que le dossier partagé n'est utilisé que pour les soins directs, de sorte que le national data opt-out ne le restreint pas. Lorsqu'une proposition distincte arrive pour utiliser les mêmes données pour l'analytique de santé de la population, l'équipe la traite comme un flux distinct avec sa propre DPIA, sa propre base légale, la conformité de désinscription et des communications publiques, plutôt que d'étendre discrètement l'accord existant.

Six semaines avant la mise en production, le responsable de la sécurité organise un exercice sur table de rançongiciel. Il révèle que le dossier partagé n'a aucun repli clinique s'il devient indisponible et que les sauvegardes n'ont jamais été restaurées à titre de test. La mise en production est retardée d'un mois pendant que l'équipe ajoute une copie hors ligne en lecture seule rafraîchie chaque nuit, prouve que la restauration fonctionne, et informe le personnel de première ligne du repli sur papier. Le retard est impopulaire, mais lorsqu'une erreur de correctif d'un fournisseur met le système principal hors ligne pendant une matinée trois mois plus tard, les soins continuent sur le système de repli et aucun rendez-vous n'est perdu. La crédibilité du programme — et la confiance des cliniciens dans le dossier — survit intacte. Le compromis était explicite : un lancement plus lent a acheté une résilience qu'un lancement plus rapide aurait mise en jeu.

Angles sectoriels#

Startup#

Une startup de la health-tech a souvent les instincts techniques de sécurité les plus forts et la compréhension la plus faible de la confidentialité spécifique à la santé et des attentes spécifiques au NHS. Si vous êtes une startup, attendez-vous à devoir compléter le DSPT ou démontrer une assurance équivalente avant qu'un organisme du NHS ne partage des données avec vous, et nommez ou contractez un DPO tôt. Votre plus grand risque est d'aller vite sur les usages des données — analytique, entraînement de modèles, partenariats — sans la base légale, la DPIA et la transparence que le secteur exige, et de perdre un client du NHS du jour au lendemain lorsque cela se révèle. Traitez la gouvernance de l'information comme une exigence d'accès au marché, pas un coût supplémentaire, et intégrez-la pendant que vous êtes petit.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une agence de soins à domicile, une clinique monosite, ou un modeste fournisseur de health-tech — porte les mêmes obligations légales qu'un grand trust mais avec une fraction de la capacité : souvent aucune informatique interne, aucun DPO dédié, et un propriétaire ou un gestionnaire de cabinet qui gouverne les données parallèlement à une douzaine d'autres tâches. Votre voie réaliste est de vous appuyer sur une aide partagée et externe — un DPO contracté, un Caldicott Guardian partagé à travers un primary care network, le soutien cyber de votre ICS, et les directives du NCSC pour les petites organisations — plutôt que de construire une capacité que vous ne pouvez pas vous permettre. Complétez le DSPT honnêtement, car pour de nombreux petits prestataires c'est à la fois une exigence contractuelle et votre meilleure liste de contrôle structurée, et consignez les véritables lacunes plutôt que de gonfler le retour. Mettez d'abord en place les fondamentaux abordables — MFA, correctifs rapides, sauvegardes hors ligne testées, accès à moindre privilège, et un simple repli papier — car ceux-ci préviennent la plupart des incidents et coûtent plus de temps que d'argent. Soyez particulièrement prudent avec le verrouillage fournisseur et les accords cloud, où vous pourriez avoir peu de levier pour négocier les conditions et devez tout de même savoir où se trouvent les données des patients et qui peut y accéder.

Entreprise#

Un grand trust ou un fournisseur établi a des politiques matures mais peine avec l'échelle, l'héritage et la fragmentation : des dizaines de systèmes, des contrôles d'accès incohérents, un parc non corrigé, et une gouvernance diluée à travers les équipes. Votre défi est la cohérence — une vue unique du risque, un véritable inventaire des actifs, et suffisamment d'investissement en sécurité pour corriger les fondamentaux plutôt que d'acheter seulement des outils. WannaCry a frappé le plus durement les grandes organisations précisément à cause d'un parc hérité non corrigé. Utilisez le DSPT et le Cyber Assessment Framework du NCSC pour piloter une amélioration réelle, et assurez-vous que l'appropriation au niveau du conseil d'administration est réelle plutôt que déléguée dans l'invisibilité.

Gouvernement#

Les organismes nationaux et les commissioners établissent les cadres — les principes Caldicott, les directives du National Data Guardian, le national data opt-out, le DSPT — et portent la responsabilité de la confiance publique à l'échelle de la population. Vos initiatives de données sont vastes, visibles et politiquement chargées, et les programmes passés ont montré à quelle vitesse un partage de données caché ou mal expliqué déclenche un contrecoup et des vagues massives de désinscription. Menez avec la transparence, un engagement public significatif et une surveillance indépendante avant de passer à l'échelle, pas après. Reconnaissez le compromis que vous possédez : une politique nationale excessivement prudente prive les soins et la recherche de données, tandis qu'une politique négligente confisque le consentement du public à qui appartiennent les données.

Modes d'échec courants#

• La gouvernance comme théâtre. Des DPIA complétées après le lancement, des retours DSPT gonflés pour paraître conformes, et des politiques que personne ne suit. Cela produit une fausse assurance, plus dangereuse qu'une faiblesse reconnue.
• Fondamentaux de sécurité négligés au profit de l'achat d'outils clinquants. Systèmes non corrigés, absence d'authentification multifacteur, réseaux plats, et sauvegardes non testées — les conditions exactes qui ont permis à WannaCry de se propager — habillés d'une plateforme de détection coûteuse.
• Prudence excessive défensive déguisée en sécurité. Refuser de partager des données dont un clinicien a légitimement besoin, traiter le « non » comme sans risque alors qu'une allergie manquée ou une lacune de protection est elle-même un préjudice grave pour le patient.
• Usages secondaires cachés. Étendre les données collectées pour les soins à l'analytique, aux accords commerciaux, ou à l'entraînement de modèles sans nouvelle base légale, conformité de désinscription, ou transparence publique — jusqu'à ce que cela fuite et que la confiance s'effondre.
• Sauvegardes jamais restaurées. Découvrir pendant un incident réel de rançongiciel que les sauvegardes sont incomplètes, corrompues, ou chiffrées avec tout le reste.
• Responsabilité orpheline. Un DPO ou un Caldicott Guardian qui existe sur l'organigramme mais n'est pas consulté, doté en ressources, ou écouté, de sorte que les risques ne sont ni remontés ni possédés.

Modèle de maturité#

Liste de contrôle#

• Une DPIA est ouverte au début de chaque nouveau projet de données et validée par le DPO.
• La base légale, la condition de catégorie spéciale, et la base de confidentialité sont documentées pour chaque flux de données.
• Un Caldicott Guardian et un Data Protection Officer sont nommés, dotés en ressources, et réellement consultés.
• L'accès à moindre privilège et basé sur les rôles est appliqué, et l'accès aux dossiers sensibles est consigné et audité.
• Les systèmes sont corrigés rapidement, l'authentification multifacteur est appliquée, et les réseaux sont segmentés.
• Les sauvegardes sont effectuées, conservées hors ligne, et restaurées à titre de test selon un calendrier régulier.
• Un plan de réponse aux incidents et de continuité d'activité, incluant un repli clinique sur papier, est documenté et répété.
• Le DSPT est complété honnêtement, avec des lacunes consignées et des plans d'amélioration crédibles.
• Des accords de partage d'information sont en place entre partenaires de l'ICS avec des bases convenues.
• Le national data opt-out est appliqué à tous les usages secondaires et les supports de transparence sont publiés.
• La conservation des dossiers et leur élimination sécurisée suivent le NHS Records Management Code of Practice.
• Les exigences de protection des données et de sécurité sont inscrites dans les contrats fournisseurs et la chaîne d'approvisionnement est évaluée.

Sources clés#

• Information Commissioner's Office (ICO) — Guide to UK GDPR, DPIAs, and lawful bases.
• National Data Guardian — reviews and guidance on data security and the Caldicott Principles.
• NHS England — Data Security and Protection Toolkit and the national data opt-out.
• National Cyber Security Centre (NCSC) — cyber security guidance and the Cyber Assessment Framework.
• UK Caldicott Guardian Council — role and responsibilities of the Caldicott Guardian.
• National Audit Office — investigation into the WannaCry cyber attack and the NHS (2017–18).
• NHS Records Management Code of Practice.

Références#

1. Information governance — Wikipédia — https://en.wikipedia.org/wiki/Information_governance
2. General Data Protection Regulation — Wikipédia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
3. Data Protection Act 2018 — Wikipédia — https://en.wikipedia.org/wiki/Data_Protection_Act_2018
4. Duty of confidentiality — Wikipédia — https://en.wikipedia.org/wiki/Duty_of_confidentiality
5. Caldicott guardian — Wikipédia — https://en.wikipedia.org/wiki/Caldicott_guardian
6. National Data Guardian for Health and Social Care — Wikipédia — https://en.wikipedia.org/wiki/National_Data_Guardian_for_Health_and_Social_Care
7. Data protection impact assessment (Privacy impact assessment) — Wikipédia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
8. Data protection officer — Wikipédia — https://en.wikipedia.org/wiki/Data_protection_officer
9. National Cyber Security Centre (United Kingdom) — Wikipédia — https://en.wikipedia.org/wiki/National_Cyber_Security_Centre_(United_Kingdom)
10. Defense in depth (computing) — Wikipédia — https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
11. Principle of least privilege — Wikipédia — https://en.wikipedia.org/wiki/Principle_of_least_privilege
12. Ransomware — Wikipédia — https://en.wikipedia.org/wiki/Ransomware
13. WannaCry ransomware attack — Wikipédia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
14. Guide to the UK GDPR — Information Commissioner's Office — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. National data opt-out — NHS England — https://digital.nhs.uk/services/national-data-opt-out
17. Cyber Assessment Framework — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-assessment-framework
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. Information security operations center — Wikipédia — https://en.wikipedia.org/wiki/Information_security_operations_center
20. Incident response — Wikipédia — https://en.wikipedia.org/wiki/Incident_response