Des solutions sur mesure pour les entreprises healthtech
Qui développe des logiciels pour des patients, des médecins ou des hôpitaux traite des données particulièrement sensibles. Les clients du secteur de la santé demandent des certificats et des attestations cloud, et les fabricants de dispositifs médicaux peuvent relever de NIS2. Sightadel vous guide à travers la protection des données, ISO 27001, NIS2 et le BSI C5 et tient les preuves sur une base commune.
Situation de départ
Les entreprises healthtech travaillent avec des données que le RGPD traite comme une catégorie particulière. Selon l’art. 9 du RGPD, les données de santé ne peuvent être traitées que si l’une des exceptions qui y sont prévues s’applique, par exemple un consentement explicite. S’y ajoute presque toujours une analyse d’impact, car le traitement est susceptible d’engendrer un risque élevé pour les personnes concernées.
Les clients sont exigeants. Hôpitaux, cabinets et caisses d’assurance maladie examinent les éditeurs en détail. Selon le § 393 SGB V (code social allemand, livre V), les prestataires de soins et les caisses d’assurance maladie ne peuvent faire traiter des données de santé dans le cloud que si une attestation C5 à jour existe. Pour un logiciel en SaaS, cela signifie souvent que la question de l’attestation arrive dès la vente.
Si votre logiciel est un dispositif médical, le règlement relatif aux dispositifs médicaux et ses exigences de sécurité informatique s’appliquent en plus. Les fabricants de dispositifs médicaux figurent en outre à l’annexe 2 de la BSIG et sont des entités importantes à partir d’une taille moyenne. Sightadel ne couvre pas le règlement relatif aux dispositifs médicaux. La sécurité de l’information qui le sous-tend, vous la gérez avec ISO 27001 sur la même base que tout le reste.
Pourquoi maintenant
Depuis le 1er juillet 2025, le § 393 SGB V exige en principe une attestation C5 de type 2. Pour les nouveaux systèmes mis sur le marché après le 30 juin 2025, le type 1 suffit pendant les 18 premiers mois.
Hôpitaux et caisses d’assurance maladie posent souvent ISO 27001 ou une preuve comparable comme condition. Sans certificat, vous restez à l’écart.
Sa destination peut faire d’une application un dispositif médical. L’entreprise relève alors en tant que fabricant de l’annexe 2 de la BSIG, à partir de 50 salariés ou de plus de 10 millions d’euros de chiffre d’affaires et de total de bilan.
Les fabricants d’applications de santé numériques remboursables en Allemagne (DiGA) prouvent depuis le 1er janvier 2025 la sécurité des données par un certificat du BSI et depuis le 1er août 2024 la protection des données par un certificat selon l’art. 42 du RGPD.
Chaque nouveau traitement a besoin d’une base légale selon l’art. 9 du RGPD et le plus souvent d’une analyse d’impact avant sa mise en service.
Dans la due diligence, investisseurs et partenaires pharmaceutiques posent des questions sur la protection des données, les certificats et les incidents. Un SMSI tenu à jour y répond sans heures supplémentaires.
Frameworks pertinents
Résumé avec nos propres mots, sans valeur de conseil juridique. Seul le texte original dans sa version en vigueur fait foi.
Les données de santé sont des catégories particulières selon l’art. 9 du RGPD. Il faut une exception à l’interdiction de traitement, une analyse d’impact selon l’art. 35 du RGPD pour les traitements à grande échelle et le plus souvent un délégué à la protection des données. En tant que sous-traitant de cabinets ou d’hôpitaux, des contrats selon l’art. 28 du RGPD s’y ajoutent.
Voir le framework →La preuve habituelle de sécurité de l’information envers les hôpitaux, les caisses et les partenaires. Un SMSI selon ISO 27001 est aussi une bonne base pour C5, NIS2 et les exigences de sécurité applicables aux logiciels dispositifs médicaux.
Voir le framework →Prévu par le § 393 SGB V pour le traitement cloud de données de santé et sociales par les prestataires de soins et les caisses d’assurance maladie. Si vous exploitez votre logiciel comme service cloud pour ces clients, une attestation propre est souvent demandée. L’attestation est délivrée par un auditeur selon ISAE 3000.
Voir le framework →Les fabricants de dispositifs médicaux et de dispositifs de diagnostic in vitro figurent à l’annexe 2 de la BSIG et sont des entités importantes à partir d’une taille moyenne. Un logiciel peut lui-même être un dispositif médical. Les fournisseurs de services cloud relèvent de l’infrastructure numérique à l’annexe 1. Le classement est une question juridique pour votre conseil.
Voir le framework →Pour les éditeurs dont le produit utilise l’IA, par exemple pour analyser des résultats d’examens. Un système de management selon ISO 42001 décrit comment les modèles sont choisis, les données utilisées et les risques évalués, et a la même structure qu’ISO 27001.
Voir le framework →Ordre recommandé
Quelles données de santé traitez-vous, dans quel but et sur quelle base selon l’art. 9 du RGPD ? Êtes-vous responsable du traitement ou sous-traitant ? Il en découle analyse d’impact, contrats et obligations d’information.
Votre logiciel est-il un dispositif médical ? Relevez-vous de NIS2 ? Vos clients exigent-ils une attestation C5 ? Les réponses déterminent l’ordre. L’appréciation juridique reste du ressort de votre conseil.
Analyse des risques, politiques, accès, développement sécurisé, journalisation, sauvegarde et gestion des incidents. Le SMSI porte ensuite C5, NIS2 et les exigences des clients.
Pour une attestation C5 de type 2, ce qui compte, c’est que les contrôles aient été efficaces pendant des mois. Revues des accès, changements et formations demandent des justificatifs continus.
Certificat, attestation et documents de protection des données viennent d’organismes indépendants. Ensuite, vous montrez l’état dans le Trust Center pour que hôpitaux et partenaires trouvent eux-mêmes les réponses.
Priorité
Avec les données de santé, autorités, clients et patients regardent de plus près. Quatre points devraient être réglés et consignés avant le lancement.
Consentement explicite, contrat de soins ou base légale : pour chaque traitement de données de santé, il est établi quelle exception selon l’art. 9 du RGPD s’applique. Cela vaut aussi pour les analyses et l’amélioration du produit.
Les nouvelles fonctions avec des données de santé reçoivent une analyse d’impact avant leur lancement. Elle est conservée comme preuve datée et revue en cas de changement.
Où sont les données, qui peut y accéder, quelles attestations ont les prestataires ? Les hôpitaux posent ces questions avant de signer. Le module Fournisseurs tient les réponses prêtes, avec les preuves.
Un incident peut déclencher des notifications à l’autorité de protection des données, aux clients et, en cas d’assujettissement à NIS2, au BSI. La procédure avec délais et responsabilités est fixée à l’avance.
Comment Sightadel vous aide
RGPD, ISO 27001, C5 et NIS2 sont traités question par question. Là où les exigences se recoupent, une preuve est rattachée à plusieurs frameworks.
En savoir plus →Analyses d’impact, contrats, formations et preuves techniques sont conservés dans l’archive des preuves avec version et date d’expiration. Ainsi, aucune preuve ne manque pour la période d’observation d’une attestation C5.
En savoir plus →Plateforme cloud, hébergement et autres prestataires figurent dans une liste avec localisation, contrat, attestations et risque. Les preuves expirées se remarquent avant qu’un client ne pose la question.
En savoir plus →Certificats, attestations, documents approuvés et sous-traitants sur une page dédiée. Hôpitaux et partenaires trouvent eux-mêmes les réponses.
En savoir plus →Les écarts issus des évaluations et des analyses d’impact deviennent des tâches avec délai et personne responsable, y compris pour le développement et l’exploitation.
En savoir plus →Les exigences pour lesquelles il n’existe pas de module prêt à l’emploi, par exemple des critères de votre demande DiGA ou les référentiels de groupements hospitaliers, se créent en framework personnalisé.
En savoir plus →Effort et durée
Ces fourchettes sont des valeurs d’expérience, pas un engagement. Les facteurs les plus déterminants sont le nombre de traitements de données de santé, la taille du périmètre et le classement éventuel de votre logiciel comme dispositif médical.
Ce que vous souscrivez · généralement Professional
Une entreprise healthtech typique pilote ISO 27001 et le RGPD dans l’édition Professional. Elle comprend dix utilisateurs, dix actifs et 25 fournisseurs, de quoi couvrir le développement, l’exploitation, la protection des données et la direction. Licence pour ISO 27001 : à partir de 750 € par mois. Si ISO 27001 fait partie de la licence, le RGPD et C5 coûtent durablement moins. Vous ajoutez le BSI C5 lorsque des clients du secteur de la santé l’exigent.
Licence par framework, durée minimale d’un an, paiement mensuel ou annuel. Tous les prix, remises et un simulateur se trouvent sur la page des tarifs. Les honoraires d’un organisme de certification ou d’audit s’ajoutent séparément.
Questions et réponses
Plus de réponses dans la FAQ ou directement via notre formulaire de contact.
Non. Cette page s’adresse aux entreprises qui développent ou exploitent des logiciels pour le secteur de la santé. Pour les cabinets et les MVZ, il existe une page de solution dédiée au § 390 SGB V, à la protection des données et à NIS2.
Cela dépend de vos clients et de votre architecture. Le § 393 SGB V s’adresse aux prestataires de soins et aux caisses d’assurance maladie qui font traiter des données de santé dans le cloud. Si vous exploitez un service cloud à cet effet, ces clients demanderont votre attestation. L’attestation de votre hébergeur ne couvre que sa propre part.
C’est la destination définie par le fabricant selon le règlement relatif aux dispositifs médicaux qui en décide. Un logiciel destiné par exemple au diagnostic, à la surveillance ou au traitement de maladies peut être un dispositif médical. Clarifiez le classement avec votre conseil réglementaire. Sightadel ne couvre pas ce règlement en tant que framework.
Selon le § 139e SGB V, les fabricants prouvent depuis le 1er janvier 2025 la sécurité des données par un certificat du BSI, sur la base de la directive technique TR-03161. Ils justifient la protection des données depuis le 1er août 2024 par un certificat selon l’art. 42 du RGPD. Sightadel ne délivre aucun de ces certificats. Un SMSI selon ISO 27001 aide à préparer les évaluations.
Les fabricants de dispositifs médicaux et de dispositifs de diagnostic in vitro figurent à l’annexe 2 de la BSIG. À partir de 50 salariés ou de plus de 10 millions d’euros de chiffre d’affaires et de total de bilan, ce sont des entités importantes. Si votre logiciel n’est pas un dispositif médical, un classement comme service cloud peut entrer en ligne de compte. L’appréciation de votre cas se clarifie avec votre conseil.
Pas toujours. L’art. 9 du RGPD prévoit plusieurs exceptions, par exemple le consentement explicite ou le traitement aux fins de la prise en charge sanitaire sur la base du droit ou d’un contrat conclu avec un professionnel de la santé. L’exception applicable dépend du traitement et figure dans votre registre.
Beaucoup d’exigences se recoupent, par exemple sur les accès, le chiffrement, la journalisation et les fournisseurs. Dans Sightadel, une preuve est rattachée aux deux frameworks. Certificat et attestation restent des audits distincts, avec leurs propres auditeurs.
14 jours, accès complet, sans données de paiement. Tout ce que vous créez est conservé dans l’offre payante.
