FAQ de l'offre : Ségur du numérique en santé

Pour l'objectif pour D2.O1.C, le BIA et le PCRA doivent être réalisés sur trois périmètres critiques (service de soins, processus administratif, plateau technique).

Dans un GHT, ces livrables doivent couvrir un nombre d’entités juridiques représentant au moins 66 % de l’activité combinée du candidat.

Si un système d'information est mutualisé entre plusieurs établissements, alors le risque numérique lié aux activités qu'il outille peut-être traité de manière mutualisée dans le BIA et le PCRA. Le candidat est invité à porter une vigilance quant à l'analyse des impacts en termes de processus et l'applicabilité des mesures de continuité d'activité aux différentes entités (géographiques ou juridiques) outillé par le SI. Le candidat devra clairement préciser le périmètre des entités (juridiques ou géographiques) concernées par ces documents.

En revanche, le BIA et le PCRA d'un second risque (RH, bâtiment, approvisionnement) ne peut être mutualisé dans la mesure où les processus et organisations métier peuvent être dépendantes du site.
 

Le test de continuité d'activité doit avoir été réalisé durant la phase opérationnelle du domaine, c'est à dire entre la date de publication de l'arrêté et la date de clôture du guichet de preuve.

De la même manière, les dépenses éligibles doivent être associées à des engagements et factures obtenus durant la phase opérationnelle.
 

Dans le cadre de l'objectif de continuité d'activité, deux documents sont à différencier : 

• le BIA, c'est-à-dire le document résultant de l’analyse de l’impact d’une perturbation sur la conduite des activités de l’établissement (et ce, selon la cause de la perturbation : SI, RH, locaux, fournisseurs). L’évaluation de la criticité d’une activité fait partie des travaux préparatoires à la rédaction d’un BIA ;
• le PCRA, c'est à dire le document opérationnel décrivant les solutions de continuité et/ou de reprise mises en place pour chaque activité critique identifiée.

La fiche de synthèse issue du BIA permet l'identification des activités critiques, mais ne permet pas seule de répondre à l'objectif.

Il est nécessaire que l'établissement définisse son plan de continuité et de reprise d'activité sur le périmètre critique identifié grâce au BIA.
 

Le BIA est réalisé sur chacune des activités de l’établissement et permet d’analyser l’impact d’une perturbation. Dans le cadre de l’objectif, le candidat est invité à transmettre l’ensemble des BIA réalisés ainsi qu’un document énumérant les activités critiques sur les périmètres a minima de chaque établissement. Un document supplémentaire est donc requis.
 

L'attendu défini pour le D2.01.C porte sur la réalisation d’un plan de continuité d’activité établie sur la base de 2 scénarios d’indisponibilité portant sur (i) l'indisponibilité du SI, et (ii) un autre scénario au choix du candidat.

Il est fortement recommandé de traiter les 4 scénarios d'indisponibilités listés dans le kit PCA / PRA proposé par l’ANS : indisponibilité des ressources humaines, indisponibilité bâtimentaire, indisponibilité des fournisseurs et indisponibilité informatique. Auquel cas, l'ensemble des dépenses associées à la réalisation des scénarios d'indisponibilité non encore couverts sont éligibles.
 

Un « périmètre » correspond à une activité critique ou une fonction identifiée comme devant faire l’objet d’un PCA/PRA suite à la réalisation d'un BIA.

A titre d’exemple, un périmètre peut être : un service de soins, un plateau technique, un processus administratif.
 

Si le volet numérique du plan blanc s’appuie sur le PCRI et intègre clairement les risques numériques (cellule de crise, modalités de signalement), alors l'exigence peut être atteinte. Auquel cas, l'établissement sera invité à transmettre son PCRI en tant que document justificatif.

Néanmoins, la mention unique du PCRI - sans lien explicite avec le plan blanc, et sans prise en compte des impacts sur les processus métier, ne permet pas l'atteinte de l'objectif.
 

Oui, il s’agit de deux supports différents.

En revanche aucun des deux n’est ‘hors ligne’ (1 du 3-2-1).
 

L’intégration, via API, des rapports de sauvegarde dans un outil de supervision avec génération automatique d’alertes répond à ces attendus : il s’agit bien d’une supervision centralisée et automatisée des sauvegardes.
 

Non.

L’objectif D2.O3.B ne vise pas à instaurer un système de sauvegarde global pour l’ensemble du SI, mais à garantir la séparation et l’isolation des systèmes de sauvegarde.

La logique est différente de celle de NIS2 : il ne s’agit pas de remplacer la sauvegarde par SIE par une sauvegarde unique couvrant tout le SI, mais de sécuriser les environnements de sauvegarde existants.