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

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.
 

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.
 

Autres questions : la restauration doit-elle être réalisée dans un environnement isolé ou est-il attendu de restaurer l’environnement de production ? Les équipes métier doivent-elles faire une recette de validation de la restauration ? Un exercice de terrain simultané doit-il être conduit pendant ce test ? 

Pour rappel, la validation de l'objectif D2.04 repose sur la réalisation de tests techniques portant sur la restauration d'une VM ou d'une base de données, et ce avec au moins un test conduit sur des données de production et pour un système outillant une activité critique.

Il n'est pas attendu de réaliser un effacement des données de production ou tout autre action pouvant impacter la continuité d'activité ou la conservation des données : ainsi, la restauration peut être réalisée sur un environnement isolé.
Le candidat est par exemple invité à réaliser la restauration de sa base de données de production sur un environnement de qualification ou de formation. Dans le cas où les espaces de stockage disponibles ne permettent pas une restauration complète de l’environnement, une restauration partielle peut être envisagée.

Le candidat est invité à la plus grande vigilance dans la préparation de ce test, et notamment dans la revue des fichiers de paramétrage ou scripts utilisés, pour garantir que la réalisation de ce test n’ait pas d’impact sur l’environnement de production du système ou les environnements de production de systèmes connexes.

Il est attendu qu'un correspondant métier soit identifié pour la réalisation de tests fonctionnels, néanmoins la réalisation de ces tests n'est pas objectivée. Aussi, les tests de restauration ne doivent pas nécessairement inclure une recette métier ou être accompagnés d'un test terrain mais cela est recommandé.
 

La soumission d'un "plan blanc" couvrant plusieurs entités juridiques différentes est autorisée au titre de l'objectif.

Le candidat devra veiller à ce que le document précise son périmètre d'application et intègre - le cas échéant - les spécificités des différentes structures. 
 

L’objectif D2.O1.B porte sur l’intégration du volet cyber dans le plan blanc, incluant notamment les modalités de signalement suivantes :

• les modalités de signalement montantes correspondent aux processus organisant la remontée en interne et vers les autorités externes compétentes (par exemple : ANSSI, ARS, CERT Santé) en cas d’incident ;
• les modalités de signalement descendantes correspondent aux processus organisant la prise en compte et le traitement d’une alerte reçue.