Différences

Ci-dessous, les différences entre deux révisions de la page.

--- smsi:declaration_de_politique_de_securite [2026/10/14 15:56] – - Imported by DokuWiki Advanced Plugin cardynal
+++ smsi:declaration_de_politique_de_securite [2026/10/16 13:00] (Version actuelle) – [Acteurs et garanties] cardynal
@@ Ligne 1: / Ligne 1: @@
+====== Déclaration de politique de sécurité ======
 <data doc>
 TypeDoc: DECL
 Processus: FONC
 </data>
-====== Déclaration de politique de sécurité ======
 ===== Objet =====
-===== Engagement de la direction =====
+La déclaration de politique de sécurité est un document que l'Organisation partage avec ses usagers. Elle explicite les objectifs et l'organisation du Système de Management de la Sécurité de l'Information (SMSI) mis en place pour la protection des informations confiées à l'Organisation.
+Elle est complétée par une politique de sécurité détaillée, interne à l'Organisation et consultable dans le cadre d'un audit.
 ===== Contexte =====
 ==== Domaine d'application ====
 === Activités du domaine d'application ===
+L'Organisation opère un service de collecte et de partage permettant à des patients d'enregistrer des observations quotidiennes, hebdomadaires ou mensuelles sur leur état (mesures, appréciations) et de les partager avec les professionnels de santé de leur choix.
 === Informations à protéger ===
+Les informations à protéger sont celles déposées par les usagers. Elles comportent :
+  * des données personnelles concernant les patients:
+    * données administratives: identité, date de naissance.
+    * données de santé: observations soumises, analyses de tendance
+    * paramétrages: questionnaires retenus, seuils d'alerte
+    * données d'usage: historique des connexions et soumissions d'observations
+  * des données personnelles concernant les professionnels de santé:
+    * identité, situation d'exercice
+    * liste des patients suivis
+  * des données non personnelles:
+    * questionnaires complémentaires élaborés par les professionnels de santé
+Le service s'appuie sur une plateforme tierce pour le paiement par les professionnels de santé de la souscription au service. Il ne détient pas de données bancaires.
 === Périmètre physique ===
+L'Organisation opère depuis son siège social situé dans un immeuble d'entreprises. Elle y dispose de sa propre salle serveurs.
+=== Périmètre logique ===
+Le SMSI ne concerne que le service de collecte et de partage. Le fonctionnement de l'Organisation en général n'est considéré que dans la mesure où il influe sur la sécurité des informations confiées par les usagers de ce service.
+=== Périmètre organisationnel ===
+Le SMSI ne concerne que l'Organisation et ses prestataires:
+  * Opérateur de paiement
+  * Opérateur de sauvegarde externalisée
+==== Acteurs et garanties ====
+Les services de l'Organisation sont intégralement réalisés en France. Ils n'entrainent aucun transfert de données de santé à caractère personnel vers un pays n'appartenant pas l'Espace Économique Européen.
+Les acteurs de traitement des données sont l'Organisation et son sous-traitant opérateur de sauvegarde.
+^ Acteur ^ Rôle ^  Certifié HDS  ^  Qualifié SecNumCloud 3.2  ^  Activités d'hébergement  ^  Accès depuis un pays tiers à l'EEA  ^  Risque d'accès imposé \\ par la législation d'un pays tiers  ^
+|  Organisation            |  Hébergeur |  Oui  |  Non  |  1 à 4    |  Non  |  Non  |
+| Opérateur de sauvegarde  |  Hébergeur |  Oui  |  Non  |  1 à 3,6  |  Non  |  Non  |
 ==== Enjeux externes et internes ====
 === Enjeux externes ===
+Les enjeux externes sont répertoriés ici selon la méthode PESTEL.
+== Enjeu Politique ==
+== Enjeu Économique ==
+== Enjeu Sociologique ==
+== Enjeu Technologique ==
+== Enjeu Environnemental ==
+== Enjeu Légal ==
 === Enjeux internes ===
+== Enjeu de réputation ==
+== Enjeu de résilience ==
+== Enjeu d'attractivité ==
 ==== Attentes des parties intéressées ====
+=== Attentes des patients ===
+=== Attentes des professionnels de santé ===
+=== Attentes des personnels ===
+=== Attentes des fournisseurs ===
+===== Objectifs de sécurité =====
+==== Objectifs stratégiques ====
+==== Objectifs opérationnels ====
 ===== Gouvernance de la sécurité de l'information =====
-===== Gestion des risques =====
+==== Organisation ====
-==== Classification de l'information ====
+==== Revues et audits ====
-==== Événements redoutés ====
+===== Planification =====
-==== Appréciation du risque ====
+==== Risques et opportunités ====
-==== Traitement des risques ====
+=== Capacité du SMSI à atteindre les résultats escomptés ===
-===== Gestion des incidents de sécurité =====
+=== Limitation des effets indésirables ===
+=== Amélioration continue ===
+==== Gestion des risques ====
+=== Classification de l'information ===
+Les informations à protéger sont celles identifiées dans le domaine d'application. Elles sont classées en fonction:
+  * De leur caractère personnel ou non, qu'il s'agisse des données concernant les patients ou les professionnels de santé.
+  * Du fait de constituer ou pas des Données de Santé à caractère personnel (DSCP), révélant directement ou indirectement des informations sur l'état de santé de la personne concernée.
+  * De leur caractère original lorsqu'il s'agit de contributions des professionnels de santé.
+On identifie ainsi trois classes d'information:
+  * Les données générales (G): paramétrages globaux, questionnaires de la plateforme.
+  * Les données originales (O): questionnaires complémentaires des professionnels
+  * Les données à caractère personnel simples (P): données administratives, données d'usage
+  * Les données de santé à caractère personnel (S): liste des patients suivis par un professionnel, questionnaires retenus, seuils d'alerte, observations des patients.
+=== Événements redoutés ===
+Les critères de sécurité retenus sont:
+  * La disponibilité des informations au moment où elles seraient nécessaires
+  * L'intégrité des informations
+  * La confidentialité des informations
+//Nota: pour alléger le démonstrateur on n'inclut pas l'auditabilité.//
+Les événements redoutés sont les pertes d'un critère sur une classe d'information. Leurs gravités ont été évaluées comme suit.
+^ Code ^ Classe            ^ Disponibilité ^ Intégrité ^ Confidentialité ^
+| G | Données générales    |  Majeur   |  Majeur      |   Mineur      |
+| O | Données originales   |  Majeur   |  Majeur      |   Majeur      |
+| P | Données personnelles |  Majeur   |  Critique    |   Majeur      |
+| S | Données de santé     |  Majeur   |  Critique    |   Critique    |
+Interprétation:
+  * Mineur - Le service reste disponible, pas d'impact sur la sécurité des personnes
+  * Significatif - Indisponibilité du service < 24 heures
+  * Majeur - Service non rendu de manière explicite, divulgation de données personnelles
+  * Critique - Risque de santé encouru par les patients, divulgation de données de santé
+=== Appréciation du risque ===
+L'appréciation des risques est fondée sur l'évaluation:
+  * De la gravité en cas de survenue de l'événement redouté, comme exprimée ci-dessus.
+  * De la vraisemblance de cette survenue, compte-tenu des différents scénarios susceptibles de mener à l'occurrence de l'événement redouté.
+Trois niveaux de risque sont identifiés: Prioritaire, A surveiller et Acceptable, et attribués comme suit.
 ~~RISKTABLE:blank~~
-===== Objectifs de sécurité de l'information =====
+=== Traitement des risques ===
+Les risques de niveau Prioritaire ne sont pas acceptables et doivent faire l'objet d'une décision de traitement, visant à en réduire la vraisemblance.
+Les risques de niveau A surveiller peuvent être acceptés sous justification. Cette règle pourra être durcie ultérieurement au titre de l'amélioration continue.
+A niveau de risque équivalent, la priorité de traitement va au risque présentant la gravité la plus élevée.
+Un plan de traitement des risques est tenu à jour.
+===== Gestion des incidents de sécurité =====
+===== Gestion des incidents de sécurité =====
+Les événements susceptibles d'être des incidents de sécurité sont notifiés par la création d'un ticket de service.
+Tous les événements portant sur la confidentialité des données sont considérés comme des incidents de sécurité.
+Les événements portant sur l'intégrité ou la disponibilité sont considérés comme des incidents de sécurité uniquement s'ils sont imputables à l'Organisation. Par exemple, une indisponibilité résultant d'une erreur de manipulation d'un utilisateur ou d'une défaillance de son fournisseur d'accès ne sera pas classé comme incident de sécurité.
+Le niveau d'urgence des incidents est basé sur la gêne occasionnée pour les utilisateurs :
+  * **Basse** - Le problème peut être contourné sans difficulté ou n'entraine aucun risque significatif (exemple - une opération échoue immédiatement et doit être répétée pour aboutir)
+  * **Moyenne** : Le problème est gênant pour effectuer les tâches requises ou présente un risque de sécurité potentiel (exemples: déconnexions intempestives, une sauvegarde n'est pas effectuée en temps utile)
+  * **Haute** : Le problème empêche d'effectuer certaines tâches ou présente un risque de sécurité avérée. Il touche une part significative des utilisateurs.
+  * **Critique** : Le problème interdit le fonctionnement ou présente un risque de sécurité certain (exemples : site inaccessible, accès à un port inapproprié ouvert sur Internet)
+Le niveau de priorité d'un incident détermine son mode de traitement, ainsi que le délai au bout duquel l'outil de ticketing escaladera vers l'ensemble des membres du COPIL SMSI :
+^ Délais/Priorités ^ Basse   ^ Moyenne   ^ Haute   ^ Critique ^
+^ Prise en compte | 3 jours  | 3 jours  |  2 jours | 6 heures |
+^ Résolution      | 14 jours | 7 jours  |  5 jours | 2 jours  |
+Les délais indiqués sont en heures et jours ouvrés.
+L'Organisation communique avec les usagers impactés sur l'avancement de la résolution:
+  * Au moins une fois par jour ouvré pour les incidents de niveau haut.
+  * Toutes les deux heures pour les incidents de niveau critique.
+Les incidents survenus enrichissent l'analyse et le plan de traitement des risques.