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

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.
   

Le test PCA est un exercice terrain qui « simule en temps réel l’indisponibilité d’une ou plusieurs ressources critiques » afin de tester la mise en œuvre des solutions de continuité d’activité à l’échelle des services.
C’est donc bien une simulation d’arrêt (d’un service, d’une ressource ou d’un périmètre défini), réalisée de manière contrôlée, pour vérifier l’efficacité du PCA et recueillir un retour d’expérience.
Il est rappelé que les PCA attendus au titre de l'objectif D2.O2.C portent sur le scénario d’indisponibilité numérique et un second scénario d’indisponibilité au choix de l'établissement.

L'exercice peut être réalisé sur tout domaine (au-delà des deux abordés dans l'objectif D2.O1.B), mais la transmission du PCA utilisé et du cas de test est requise.
 

Il est possible pour un établissement de valoriser des actions de formation si elles ont permis de contribuer directement à l'atteinte d'un objectif (par exemple, pour des professionnels disposant d'une lettre de mission) du présent domaine. 

Les formations citées en exemples (ISO 270001, 27002, 27005, EBIOS) ne contribuent pas directement à l’atteinte d’un objectif du domaine, et ne sont pas des dépenses considérées éligibles.
 

Les documents justificatifs attendus dans le cadre du domaine seront soumis par le candidat au travers de la plateforme sécurisée e-CaRE, et pour les documents les plus sensibles et confidentiels au travers d'un conteneur Zed.

Les documents transmis sont exclusivement analysés par les équipes de votre Agence régionale de santé (à l’exception des documents présents dans un conteneur Zed) et de l'Agence du Numérique de Santé (ANS) aux fins de contrôle telles que définies dans la convention à venir entre l'ANS et le candidat.

Par ailleurs, ladite convention fixe également les durées de conservation et les modalités de suppression des données recueillies. Pour certains prérequis et objectifs (notamment D2.P1, D2.O2.A, D2.O3.A, D2.O3.B et D2.O3.C), le candidat peut soumettre une présentation synthétique ou une attestation de présence du document attendu.
 

Plusieurs documents nécessitent la validation de la direction ou d'une instance décisionnelle dans le cadre de l'atteinte des prérequis et des objectifs.

Pour rappel, les documents justificatifs devant faire l'objet d'une validation sont les suivants : 

• Au titre du D2.P1 : la PSSI doit être "validée par le représentant légal du candidat, ou le cas échéant, par chaque établissement". Le document doit donc être signé formellement par une personne habilitée.
• Au titre du D2.O1.A : le schéma de gouvernance du PCRA doit être "signé par la direction du candidat " et accompagné du "compte rendu d'une instance décisionnelle" ayant validé ce schéma.

Il est attendu un document signé formellement par une personne habilitée, et un compte rendu de l'instance ayant validée le schéma.

Dans le cas où une délégation de signature est mise en place par le représentant légal du candidat, alors les documents peuvent être signés par ce directeur fonctionnel. Le candidat est alors invité à soumettre une pièce justifiant de la délégation de signature dudit directeur.
 

L’organisation du dispositif de gouvernance constitue en effet l’un des éléments constitutifs du PCRA cadre attendu au titre du D2.O2.C.

Pour autant, l’atteinte de cet objectif repose sur des éléments complémentaires tels que la présentation de l’équipe projet ou la formalisation du macro-planning. Le candidat est libre de présenter l’organisation qui lui apparaît la plus appropriée, et l’équipe projet peut donc intégrer des collaborateurs spécifiques par périmètres adressés.

L'équipe projet, définie en réponse à cet objectif, constituera l'équipe pérenne sur les chantiers de renforcement de la continuité d’activité. Elle diffère, en ce sens, de l'équipe proposée en réponse au prérequis D2.P2 qui est chargée quant à elle des travaux nécessaires à l’atteinte des objectifs de l’objectif D2.O1.
 

Dans le cas d’un SI mutualisé, un PCA unique peut être réalisé concernant la prise en compte du risque numérique. Le PCA doit néanmoins prendre en compte les spécificités organisationnelles de chaque établissement utilisant le SI mutualisé, et pourra inclure ces éléments au sein d’un PCA unique.

La réalisation d'un exercice de test PCA portant sur un périmètre inclus dans le SI mutualisé répond à l'exigence de réalisation d'un exercice de continuité d'activité (i.e. la réalisation d'un test minimum est attendu dans le cadre de cet objectif).

Le test doit être réalisé à l’échelle d’un service : si les services d’une entité A et d’une entité B s’appuient sur un même SI mutualité, alors le test doit être réalisé sur chacun des services des deux entités. Le scénario de test doit être identique et il est recommandé de réaliser simultanément sur les sites concernés. 

Il est rappelé que le test doit avoir été réalisé sur un nombre d’établissements (juridiques pour un GHT, ou géographique pour un candidat privé) représentant au moins 66% de l'activité du candidat.
 

Le Domaine 2 s'implique uniformément au système d'information de l'établissement (tant sur les objectifs de continuité d'activité que ceux de sauvegarde), et donc aux applications hébergées en mode HDS.