Lorsque les coordonnées d'un professionnel sont récupérées dans un annuaire comme le RPPS ou le RPPS+ (considéré comme un "autre système en amont"), les coordonnées sont supposées fiables et leur vérification n'est pas demandée dans la gestion du compte.

Ces exigences permettent à la fois de s'assurer que le professionnel sera effectivement en mesure de s'authentifier (ou de récupérer son compte) le moment venu, et de renforcer la sécurité de l'authentification.
En effet :

• Si par exemple le professionnel commet une erreur à la saisie de son numéro de téléphone portable et que ce numéro est utilisé pour lui envoyer un code OTP par SMS comme second facteur d'authentification, alors le professionnel ne recevra pas cet OTP au moment de son authentification et ne pourra pas se connecter. Le professionnel va demander une modification de cette coordonnée, mais à ce moment-là, il faudra s'assurer de son identité de manière fiable, avec deux facteurs d'authentification. Ceci peut devenir contraignant et constituer une très mauvaise expérience pour un nouvel utilisateur ;
• Si le professionnel commet une erreur à la saisie d'une adresse email utilisée comme second facteur d'authentification en cas d'oubli de son mot de passe par exemple, alors il découvrira ce problème le jour où il a besoin de récupérer son compte. Déjà en situation exceptionnelle et de perte de temps, le professionnel ne pourra pas récupérer son compte facilement et devra alors passer par une vérification fiable mais contraignante de son identité.
  La vérification permet de s'assurer que la coordonnée est bien exacte et sous la maîtrise du professionnel. De plus, ceci évite la tentation de demander le contournement des mesures de sécurité pour répondre à des situations problématiques et urgentes, prétextes justement utilisés par des attaquants pour prendre possession illégalement d'un compte. 

Pour être évaluées, les preuves doivent être déposées sur Convergence dans un conteneur ZED garantissant l'intégrité et la confidentialité des documents. Ces preuves sont consultées par les vérificateurs uniquement.

La procédure de sauvegarde et de restauration doit contenir des informations détaillées sur la manière de réaliser des sauvegardes efficaces, ainsi que sur la manière de restaurer les données en cas de besoin. Cela peut inclure :

• Les acteurs de la procédure de sauvegarde et de restauration et leurs rôles (RACI) ;
• La fréquence de sauvegarde ;
• Le plan de sauvegarde mis en place par l'éditeur ;
• Le champ d'application (périmètre de la sauvegarde) ;
• Le lieu de stockage des sauvegardes ;
• Les méthodes de sauvegarde (ex: sauvegardes complètes, incrémentielles ou différentielles)
• Les règles de sécurité : les mesures de sécurité sont mises en place pour protéger les sauvegardes (ex: chiffrement des données, l'accès restreint aux sauvegardes,etc.) ;
• Les tests de récupération (champ des tests, fréquence, etc.) 

Les principaux objectifs de la procédure de sauvegarde et de restauration sont de garantir la disponibilité des données essentielles en cas de défaillance du système, de perturbation ou de perte de données.
Cette procédure contribue à la sécurité des solutions en minimisant les risques de perte de données critiques. Elle permet de restaurer rapidement et efficacement les systèmes à un état de fonctionnement antérieur, réduisant ainsi les temps d'indisponibilité et les impacts potentiels sur la sécurité et la continuité des opérations.

La responsabilité de garantir le bon fonctionnement de ces processus et de veiller à l'application en temps opportun des correctifs repose sur l'équipe ou la personne chargée de la sécurité informatique de votre système.

La veille technologique concerne les composants du système tels que les bibliothèques, les logiciels, les dépendances, etc.

La réalisation d’un audit PASSI (conditions de réalisation spécifiques et auditeur certifié PASSI) n’est pas requise. La seule obligation est de faire réaliser le test d'intrusion par un organisme qualifié PASSI.
La liste des prestataires de services qualifiés peut être retrouvée ici : https://cyber.gouv.fr/decouvrir-les-solutions-qualifiees

NB : Le lien ci-dessus est susceptible de changer si l'ANSSI y apporte des modifications a posteriori.

Un "standard de développement sécurisé" est un ensemble de lignes directrices, de bonnes pratiques que les développeurs devraient suivre pour garantir la sécurité d'un système. Il peut provenir de différentes sources (ex : guide de l'ANSSI, documentation interne, OWASP, PGSSI-S, etc.). Il comprend des recommandations sur la vérification de la qualité du code, la gestion de l'obsolescence des bibliothèques, la sécurisation de la plateforme système, et bien d'autres aspects liés à la sécurité. Il est essentiel car il permet de réduire les vulnérabilités potentielles, les failles de sécurité et les risques de cyberattaques, assurant ainsi la sécurité du système.

La responsabilité de la rédaction du plan d'assurance sécurité du système peut être partagée entre l'éditeur et l'hébergeur ou le fournisseur de services SaaS, en fonction des accords contractuels. Cependant, il est essentiel que ce plan soit clairement et doit contenir : 

• Le cadre juridique : les références légales, les réglementations et les obligations contractuelles liées à l'hébergement du système, en précisant les responsabilités et les droits des parties impliquées, etc. ;
• Les mesures de sécurité : les dispositions et les procédures de sécurité mises en place pour protéger le système hébergé (ex: contrôles d'accès, protection des données, etc.) ;
• Les engagements entre l'hébergeur et la structure utilisatrice comme par exemple des garanties de disponibilité, des délais de réponse en cas de problème, des mesures de résilience en cas de panne, etc. ;
• L'environnement de mise en œuvre du système : il s'agit de décrire l'environnement technique et opérationnel dans lequel le système doit être déployé (ex: configuration réseau, connectivité, etc.). 

Le plan d'assurance sécurité du système (PAS) est un document qui définit les mesures de sécurité et les engagements entre l'hébergeur et la structure utilisatrice pour l'environnement de mise en œuvre du système. Il vise à garantir la sécurité des données et des composants du système lorsqu'ils sont hébergés par un tiers ou fournis sous forme de services (SaaS).

La négligence dans la désignation des responsables de la sécurité peut entraîner un certain nombre de risques, notamment :

• Des failles de sécurité non détectées ;
• Des retards dans la réponse aux incidents de sécurité ;
• Un manque de coordination dans la gestion des risques ;
• Une faible sensibilisation à la sécurité au sein de l'équipe.

La désignation d'acteurs responsables de la sécurité apporte plusieurs avantages, notamment :

• Une meilleure gestion des risques de sécurité ;
• Une responsabilité claire pour les problèmes de sécurité ;
• Une amélioration de la coordination des activités de sécurité ;
• Une sensibilisation accrue à la sécurité au sein de l'équipe de développement ;
• Une conformité aux normes de sécurité.

La désignation des personnes responsables de la sécurité des produits nécessite les étapes suivantes :
- Identifier les exigences spécifiques de votre produit en matière de sécurité ;
- Évaluer les compétences et l'expérience des membres de votre équipe ;
- Désigner les responsabilités en matière de sécurité en fonction des compétences des membres de l'équipe ;
- Formaliser ces responsabilités dans un document dédié et les communiquer aux équipes.

Le choix du responsable de la sécurité dépend de la structure de l'éditeur. Cela implique d'identifier les personnes qui ont les compétences et l'expertise pour prendre en charge la sécurité de la solution. Il peut s'agir de responsables sécurité, de développeurs sécurité expérimentés, d'architectes sécurité, etc.