Les normes au service de la cybersécurité des dispositifs médicaux numériques : ISO 13485, IEC 81001-5-1, ISO 27001 — ce qu'elles apportent concrètement
Dans un précédent article, nous avons exploré les obligations réglementaires qui s'imposent aux fabricants de DMIL au titre du MDR 2017/745 et du Cyber Resilience Act. Mais une fois qu'on a compris ce que les textes exigent, une question reste entière : comment les mettre en œuvre ? C'est précisément le rôle des normes.
Réglementation et normes : deux niveaux distincts, deux rôles complémentaires
C'est une confusion très fréquente dans les équipes.
Le MDR, le RGPD, NIS2, le CRA — ces textes réglementaires définissent des obligations. Ils disent ce que vous devez faire, et ce qui arrive si vous ne le faites pas.
Les normes techniques, elles, décrivent comment vous pouvez y arriver.
Elles ne sont pas juridiquement contraignantes en elles-mêmes. Mais elles représentent l'état de l'art reconnu. Les invoquer dans votre dossier technique, c'est démontrer que vous avez suivi une méthode éprouvée pour répondre aux exigences réglementaires.
Pour un fabricant de dispositif médical intégrant du logiciel, trois normes sont particulièrement structurantes. Non pas parce qu'elles s'additionnent, mais parce qu'elles se complètent de façon logique.
ISO 13485 : le cadre qualité dans lequel tout s'intègre
L'ISO 13485 est souvent vue comme la norme qualité des fabricants de DM. Ce qu'on oublie parfois, c'est qu'elle est aussi le cadre organisationnel dans lequel doivent vivre tous vos processus cyber.
Concrètement, cela veut dire quoi ?
Que votre analyse de risques cybersécurité n'est pas un document qu'on sort pour l'audit de certification et qu'on range ensuite. Elle doit être :
- intégrée à votre système documentaire,
- reliée à vos processus de conception et de développement,
- mise à jour à chaque version majeure,
- alimentée par votre surveillance post-marché,
- revue par la direction comme n'importe quel autre risque qualité.
Les recommandations ANSM sont explicites sur ce point. La recommandation R1 — la première et la principale — précise que l'analyse de risques cyber doit être gérée selon les exigences de l'ISO 13485. Ce n'est pas un ajout optionnel. C'est le socle.
Ce que ça change pour vous : si vous avez déjà un SMQ ISO 13485, vous n'avez pas à tout reconstruire. Vous avez à l'étendre. La cybersécurité s'y intègre — elle ne lui est pas parallèle.
IEC 81001-5-1 : la norme que vous devez connaître
Publiée en 2021, l'IEC 81001-5-1 s'intitule "Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product lifecycle".
Son nom est long. Son utilité est immédiate.
C'est la norme qui adapte le cadre de sécurité industrielle (IEC 62443-4-1) spécifiquement au contexte des logiciels de santé. Et ce n'est pas un détail : les enjeux d'un logiciel pilotant une pompe à insuline ne sont pas ceux d'un automate industriel standard.
Ce qu'elle apporte que le MDR ne donne pas :
Le MDR Art. 17.2 exige que votre logiciel soit développé selon l'état de l'art, en prenant en compte la sécurité de l'information. Mais il ne vous dit pas comment faire.
L'IEC 81001-5-1 vous dit comment. Elle structure les activités de sécurité en huit pratiques, couvrant l'intégralité du cycle de vie :
- Security Management — planifier et documenter toutes les activités de sécurité
- Specification of Security Requirements — définir ce que le produit doit pouvoir faire en termes de sécurité
- Secure by Design — concevoir avec une défense en profondeur
- Secure Implementation — sécuriser chaque composant du code
- Security V&V Testing — tester et valider toutes les exigences de sécurité
- Management of Security Issues — gérer les vulnérabilités et incidents
- Security Update Management — patches testés et déployés dans les délais
- Security Guidelines — documenter comment l'opérateur intègre le DM de façon sécurisée
Ces huit pratiques ne vous disent peut-être rien à première lecture. Mais si vous avez déjà lu le guide MDCG 2019-16, vous les reconnaissez : la guidance européenne s'en inspire directement. Ce n'est pas un hasard. L'IEC 81001-5-1 est la base technique sur laquelle le MDCG 2019-16 s'appuie.
Son statut réglementaire : elle n'est pas encore harmonisée au titre du MDR, ce qui signifie qu'elle ne confère pas de présomption de conformité automatique. Mais sa mise en œuvre documentée constitue un argument solide pour démontrer la conformité à l'Art. 17.2 MDR. Dans un dossier technique soumis à un organisme notifié, la citer et s'y référer est une bonne pratique.
Ce qu'elle complète : l'IEC 62304, que beaucoup de fabricants connaissent déjà, traite du cycle de vie du logiciel DM sous l'angle de la sûreté fonctionnelle. L'IEC 81001-5-1 prend en charge le volet sécurité face aux menaces intentionnelles. Les deux se lisent ensemble, pas l'une à la place de l'autre.
ISO 27001 : quand est-elle vraiment nécessaire ?
L'ISO 27001 est la norme de référence pour les Systèmes de Management de la Sécurité de l'Information (SMSI). C'est une norme d'organisation, pas une norme produit.
Elle ne remplace pas l'IEC 81001-5-1. Elle ne remplace pas l'ISO 13485. Mais dans certains contextes, elle devient incontournable.
Quand la certification ISO 27001 s'impose ou s'impose presque :
- Vous hébergez des données de santé à caractère personnel → la certification HDS (Hébergeur de Données de Santé) l'exige pour les activités d'hébergement d'infrastructure et de plateforme.
- Vous opérez en mode SaaS avec un logiciel DM accessible depuis le cloud → vos clients institutionnels (hôpitaux, GHT) vous la demanderont de plus en plus dans les appels d'offres.
- Vos clients sont des Opérateurs de Services Essentiels soumis à NIS2 → ils ont eux-mêmes des obligations de sécurité de leur chaîne de sous-traitance. ISO 27001 est le chemin de conformité le plus reconnu.
- Vous répondez à des marchés publics hospitaliers → elle est déjà notée ou attendue dans de nombreux cahiers des charges.
La vraie question n'est pas "dois-je certifier ?" mais "quel périmètre doit être couvert ?"
Une PME de 15 personnes qui développe un logiciel DM et l'héberge sur son propre serveur n'a pas forcément besoin d'une certification ISO 27001 complète pour commencer. En revanche, elle a besoin de mettre en place les pratiques organisationnelles que la norme décrit : gestion des accès, politique de sécurité, gestion des incidents, continuité.
Progressivement, ces pratiques peuvent évoluer vers une démarche certifiable. Ce n'est pas une course. C'est une trajectoire.
Le pont avec le RGPD : si vous traitez des données personnelles de patients — ce qui est presque inévitable pour un DMIL — l'ISO 27701:2025 est désormais une norme à part entière dédiée au management de la protection de la vie privée (PIMS). Sa version 2025, publiée en octobre 2025, rompt avec l'ancienne logique : elle n'est plus une extension de l'ISO 27001 et peut être déployée et certifiée de façon indépendante, sans prérequis ISO 27001. Pour autant, les deux normes restent naturellement complémentaires et leur mise en œuvre conjointe reste encouragée quand les deux périmètres sont en jeu. Pour un fabricant de DMIL hébergeant des données patient, c'est une bonne nouvelle : il peut désormais structurer sa démarche privacy sans avoir à certifier un SMSI complet au préalable.
Les passerelles concrètes : comment les trois normes s'articulent
Voici comment les lire ensemble, sans les confondre :
ISO 13485 → le cadre C'est votre système de management. Toutes vos procédures cyber y vivent. Votre analyse de risques, vos processus de développement, votre surveillance post-marché, votre gestion des incidents : tout doit être documenté et maîtrisé dans ce cadre.
IEC 81001-5-1 → la méthode produit C'est votre boîte à outils pour sécuriser le cycle de vie de votre logiciel. Elle répond à la question : qu'est-ce que je dois faire, à quelle étape du développement, pour démontrer que mon logiciel est sécurisé face aux menaces ? Elle s'intègre dans le SMQ ISO 13485 comme un ensemble de processus techniques à piloter.
ISO 27001 → la sécurité organisationnelle C'est votre cadre de gouvernance de la sécurité de l'information au niveau de l'entreprise. Elle couvre ce que l'IEC 81001-5-1 ne couvre pas : la sécurité de vos locaux, de vos postes de travail, de vos ressources humaines, de vos contrats fournisseurs, de vos sauvegardes.
Une image simple : L'ISO 13485 construit la maison. L'IEC 81001-5-1 sécurise le produit qu'on fabrique dedans. L'ISO 27001 sécurise la maison elle-même.
Ce que ça change pour votre dossier technique
Le dossier technique soumis à l'organisme notifié dans le cadre du marquage CE doit contenir des preuves de conformité aux exigences essentielles de l'Annexe I du MDR.
Pour la cybersécurité, les preuves attendues sont :
- Une analyse de risques cyber documentée, intégrée à l'ISO 14971
- La description des huit pratiques mises en œuvre (IEC 81001-5-1)
- Les résultats des tests de sécurité (tests fonctionnels, fuzz, scan de vulnérabilités, pentest si applicable)
- Le Software Bill of Materials (SBOM) — inventaire de tous vos composants logiciels
- Les exigences IT minimales documentées dans la notice d'utilisation (Art. 23.4.ab MDR)
- La procédure de gestion des mises à jour de sécurité
- Le plan de surveillance post-marché cyber
Aucune de ces preuves n'est produite spontanément. Elles résultent de processus organisés, documentés, et maintenus dans le temps. C'est précisément ce que l'articulation ISO 13485 + IEC 81001-5-1 permet de structurer.
Ce qu'il faut retenir
Les textes réglementaires disent ce qu'il faut faire. Les normes disent comment le faire. Ce n'est pas la même chose, et confondre les deux conduit à des dossiers techniques incomplets ou à des démarches qui tournent à vide.
Pour un fabricant de DMIL, la colonne vertébrale normative ressemble à ceci :
- ISO 13485 comme cadre qualité obligatoire, dans lequel tous les processus cyber s'intègrent
- IEC 81001-5-1 comme méthode de cybersécurité du cycle de vie logiciel, directement alignée avec le MDCG 2019-16
- ISO 14971 comme méthode d'analyse de risques, à étendre au volet cyber en convergence avec EBIOS RM
- ISO 27001 comme référentiel de gouvernance SI, obligatoire dans les contextes HDS et cloud, recommandé pour les autres
Ce n'est pas une liste à tout faire d'un coup. C'est une trajectoire à construire, en partant de ce qui est le plus critique pour votre produit et votre modèle.
La bonne question n'est pas "quelle norme dois-je certifier ?". La bonne question est "quelles normes dois-je utiliser pour démontrer que mon DMIL est sécurisé et que mon dossier tient la route ?"
Ce sont deux questions très différentes. Et c'est souvent là que l'accompagnement fait la différence.
Vous travaillez sur la conformité cyber de votre dispositif médical numérique ? Vous souhaitez comprendre comment articuler ces normes avec votre démarche qualité existante ?