Article

IEC 81001-5-1 et MDR : intégrer la cybersécurité au cycle de vie logiciel

Illustration : cybersécurité des logiciels de santé et cycle de vie IEC 81001-5-1.

Pour un logiciel de santé sous MDR/IVDR, la cybersécurité n'est plus un pack annexé en fin de projet. Les exigences générales de sécurité et de performances du MDR (et de l'IVDR) exigent une conception et une fabrication qui tiennent compte de l'état de l'art, y compris face aux risques liés à un accès non autorisé.

Cet article montre comment intégrer IEC 81001-5-1:2021 (activités de sécurité dans le cycle de vie des logiciels de santé) au SDLC et au SMQ, en s'appuyant aussi sur le MDCG 2019-16 Rev.1 (guidance cybersécurité des dispositifs médicaux).

Pourquoi IEC 81001-5-1 compte sous MDR

IEC 81001-5-1 définit des processus, activités et tâches de cycle de vie pour renforcer la cybersécurité des logiciels de santé, en lien avec les principes de sûreté, d'efficacité et de sécurité de la famille ISO/IEC 81001. Elle se positionne comme complément opérationnel au cycle de vie logiciel (souvent IEC 62304) et à la gestion des risques (ISO 14971).

Le MDCG 2019-16 aide les fabricants à interpréter les GSPR cybersécurité de l'annexe I MDR/IVDR (conception sécurisée, documentation, information aux utilisateurs / établissements, surveillance post-marché). En audit, les organismes notifiés cherchent des preuves de cycle de vie, pas seulement une checklist outil.

Point de prudence : la présomption de conformité liée à une norme harmonisée dépend de la publication de la référence au Journal officiel de l'UE. Suivez la page Commission sur les normes harmonisées et le statut OJEU de la version EN que vous revendiquez. Même hors présomption formelle, IEC 81001-5-1 est largement traitée comme référence d'état de l'art.

Intégrer la cyber au cycle de vie (pas en add-on)

Menace, risques et exigences

Modélisez les menaces tôt, transférez les risques sécurité vers le fichier de risques produit, et dérivez des exigences de sécurité testables. Sans ce lien, le SBOM et les scans restent décoratifs.

SBOM et composants tiers

Maintenez un inventaire de logiciels / composants (SBOM) utile à la gestion des vulnérabilités, avec responsabilités fournisseurs et critères de mise à jour. Documentez les décisions de patch dans le change control.

Vérification, release et post-marché

Vérifiez les contrôles de sécurité comme des exigences produit. En post-marché, branchez veille vulnérabilités, incident response et PMS : une faille critique est aussi un signal réglementaire, pas seulement un ticket IT.

Preuves à brancher sur le dossier technique

  • Plan / rapports d'activités IEC 81001-5-1 (ou équivalent justifié).
  • Traçabilité menaces → risques → exigences → tests → release.
  • SBOM, politique de vulnérabilités, preuves de correctifs.
  • Instructions de sécurité pour déployeurs / établissements (cohérentes MDCG 2019-16).
  • Procédures PMS / vigilance incluant les incidents de cybersécurité.

Pour industrialiser ces preuves dans le flux produit, couplez marquage CE, eQMS et Qapsule.

FAQ

IEC 81001-5-1 est-elle obligatoire sous MDR ?

Aucune norme n'est « obligatoire » au sens strict du MDR : vous devez démontrer la conformité aux GSPR. En pratique, IEC 81001-5-1 est la référence de cycle de vie la plus attendue pour la cybersécurité des logiciels de santé. Vérifiez le statut harmonisé OJEU de la version EN revendiquée.

Que demande le MDCG 2019-16 ?

Il guide les fabricants sur la façon de satisfaire les exigences cybersécurité de l'annexe I MDR/IVDR : conception sécurisée, documentation, information aux acteurs de la chaîne, et activités post-marché. Ce n'est pas un texte juridiquement contraignant, mais il oriente fortement les attentes d'évaluation.

Un SBOM suffit-il comme preuve cyber ?

Non. Un SBOM est nécessaire mais insuffisant. Il faut le relier à l'analyse de menaces, au risque, aux tests, à la gestion des vulnérabilités et à la surveillance post-marché.

Comment éviter la « cyber pack » hors SMQ ?

Intégrez les activités sécurité dans les SOP design control / SDLC existantes, avec les mêmes reviews et enregistrements que pour la sûreté clinique. Outillez la traçabilité dans l'eQMS plutôt que dans un dépôt isolé.

Par où commencer sur un SaMD déjà en développement ?

Gap analysis IEC 81001-5-1 + MDCG 2019-16, priorisation des écarts sur le chemin critique release, puis plan de preuves pour le dossier technique. QARA PULSE peut cadrer cet audit ciblé.

Article QARA PULSE (mai 2026), fondé sur IEC 81001-5-1, MDCG 2019-16 et les règlements MDR/IVDR. Vérifiez le statut OJEU des normes harmonisées et adaptez à votre architecture produit.

En lien : Marquage CE · Déploiement eQMS · Qapsule · AI Act et SaMD · Contact

← Toutes les ressources