Le document discute de l'impact de la certification HDS v1 sur les hébergeurs de données de santé, abordant les défis liés à un cadre initialement mal défini et aux obligations réglementaires. Il souligne les changements dans la méthode de certification, la redéfinition des périmètres d'activité, ainsi que les nouvelles exigences contractuelles qui offrent plus de flexibilité aux hébergeurs. Enfin, il met en avant les implications pour les différents acteurs du secteur, notamment en matière de sécurité des données et de conformité aux référentiels.

1. AFHADS
Impact du passage à la certification des HDS
14 décembre 2017

2. HDS v1 – Un cadre mal né
• Une profession réglementée avant que d’exister
• Un référentiel bâti à la hâte, pour un périmètre mal défini
et sous estimé
• Le report sur l’hébergeur d’obligations techniques et
fonctionnelles portant sur l’application ou son usage.

3. HDS v1 – Un succès inattendu
• Un service innovant d’accompagnement dans une
réglementation foisonnante
• Co-construction entre hébergeur et éditeurs
• Un modèle vertueux, économiquement viable et efficace
• Point de passage obligé, y compris pour les petits projets
• Rationalisation des compétences techniques et réglementaires
• Rappel aux droits des personnes concernées

4. Pourquoi changer de méthode ?
• Structure administrative inadaptée
• Coûts et délais de traitement
• Frein à l’innovation dans les offres et les moyens
• Opacité des périmètres et des critères
• Faible cohérence des décisions
• Hétérogénéité des offres selon le niveau de report

5. La séquence
• Loi d’habilitation (26 janvier 2016)
• Ordonnance (12 janvier 2017)
• Décret (à paraître, projet de juillet 2017)
• Référentiels (Novembre 2017)

6. Le projet de décret
• Redéfinition du périmètre de l’HDS
• Mesures techniques de changement de méthode
• Transfert d’exigences du dossier d’agrément au contrat
• Suppression des exigences liées à l’application
• Abandon du lien à la personne concernée

7. Redéfinition du périmètre
Une ou plusieurs activités parmi :
Hébergeur d’infrastructure
• Colocation
• « Infrastructure as a Service » physique
Hébergeur infogéreur
• « Infrastructure as a Service » virtuelle
• « Platform as a Service »
• Administration et exploitation du SI
• Sauvegardes
• Risque d’obsolescence ou d’incomplétude
• Cas des télémaintenances des éditeurs
• Exclusion de l’hébergement temporaire sans finalité pour les parties

8. Changement de méthode
Report aux organismes certificateurs de :
• L’audit de la politique de sécurité
• Les contrôles
• Renouvellement, suspension et retrait
La certification comme mécanisme est préférable à
l’agrément, car plus efficace et plus complète.

9. Exigences sur le contrat
Report au contrat d’éléments du dossier :
• Définition de la prestation
• Identification des sous-traitants
• Indicateurs de qualité de performance
• Obligations en cas d’évolutions
• Garanties en cas de défaillance
• Réversibilité
Donne plus de souplesse à l’hébergeur pour adapter sa
prestation selon les contextes et au fil du temps.

10. Exigences sur l’application
Les obligations de l’hébergeur disparaissent sur :
• Les procédés d’identification et d’authentification
• La gestion des habilitations
• La traçabilité des accès
• La pérennité des données lors des évolutions techniques
Le responsable de traitement (en général le professionnel
ou l’établissement de santé) se retrouve seul porteur de
ces obligations.

11. Lien à la personne concernée
Les obligations de l’hébergeur disparaissent sur :
• Les conditions de recueil des consentements
• Les droits de consultation et de rectification
• Signalement des incidents à la personne concernée
• La fourniture de l’historique des accès aux données
• Le médecin de l’hébergeur
Les droits sont maintenus mais sans contrôle a priori par
l’hébergeur, hormis l’historique d’accès aux données qui
n’a plus de fondement légal.

12. Analyse du décret
• Vise à la banalisation de l’HDS
• Favorable
• Aux grands hébergeurs généralistes
• Aux éditeurs globaux
• Défavorable aux autres acteurs qui perdent un appui
compétent et un contrepoids aux éditeurs globaux.
• Personnes concernées
• Etablissements et professionnels de santé
• Startups et petits éditeurs
• Dilution de l’expertise sur la sécurité des données de
santé à caractère personnel.

13. Les référentiels
• Référentiel d’accréditation
• Périmètres ‘hébergeur d’infrastructure’ et ‘hébergeur infogéreur’
• Notifications à l’ASIP Santé des suspensions et retraits
• Rapport mensuel à l’ASIP Santé des certifications valides
• Rapport annuel à l’ASIP Santé avec synthèse des non-conformités
• Equivalence des certifications 27001 ou 20000 déjà obtenues
• Dispositions générales sur l’accréditation et la certification
• Exigences et contrôles
• Réduits (très peu) pour un hébergeur d’infrastructure.
• Base 27001, plus :
• Des exigences sélectionnées de 20000 (ITIL)
• Des exigences sélectionnées de 27017 et 27018 (Codes of practice)
• Des précisions ou des exigences spécifiques

14. Précisions sur la 27001
• Protection des DSCP dans le domaine d’application
• Ajout des exigences additionnelles dans la DDA
• Mesures de sécurité pour les sauvegardes des données
• Définition d’une procédure d’audit par les clients

15. Compléments issus de la 20000
• Planification des services nouveaux ou modifiés
• Conception et développement des services
• Gestion de la continuité et de la disponibilité des services
• Gestion de la capacité
• Critères d’acceptation pour les services
• Vérification des applications hébergées
• Définition et vérification des prérequis à l’hébergement
• Processus de test et de validation de l’impact de nouveaux
services sur les performances et la sécurité.
Au vu de la précision chaque application hébergée doit être
considérée comme un service.

16. Compléments issus de la 27018
31 exigences dont beaucoup sont redondantes avec la
27001 ou le RGPD.
Restent principalement :
• L’engagement contractuel sur les mesures de sécurité
• Le choix du pays d’hébergement
• La communication des traces d’accès des administrateurs
• L’information et la consignation des divulgations de
données faites sous contrainte légale

17. Complément issu de la 27017
Documentation de la répartition des rôles entre l’hébergeur
et son client sur la sécurité de l’information, notamment :
• La propriété des données
• Les contrôles d’accès
• La maintenance de l’infrastructure
• La propriété des actifs
• Les sauvegardes et restaurations

18. Autres exigences
• Information et recueil de l’engagement de conformité aux
référentiels opposables de la PGSSI-S.
• Communication aux clients des rapports d’audits de
certification.
• Mise à disposition de l’ASIP Santé de la liste des contacts
clients pour une notification des retraits et suspensions.
• Interfaces et support de premier niveau en langue
française.

19. Durée d’audit selon effectif
0
2
4
6
8
10
12
14
16
1 à 10 10 à 15 16 à 25 26 à 45 46 à 65 66 à 85 86 à 125
27001 Compléments
85% du temps attribué à la 27001

20. Conclusion et perspectives
• Une implémentation a minima sur la base d’une
certification 27001 existante est possible.
• La certification apporte une garantie réduite par rapport
aux objectifs de l’agrément.
• L’explicitation des contrats, les prérequis à l’hébergement
et leur vérification permettent à ceux qui le souhaitent de
maintenir un service de niveau élevé.
• L’AFHADS a défini et porte un socle commun partagé par
ses membres.
• Ce socle a vocation à devenir un code de conduite au
sens du RGPD.