SecNumCloud : maîtriser les risques juridiques et extra‑européens du cloud

Lecture rapide

Le prestataire doit apprécier et documenter les risques, y compris ceux liés aux lois extra-européennes visant la collecte de données sans consentement, et mettre ces éléments à disposition du commanditaire. Il doit organiser la sécurité de l’information, désigner un responsable de la sécurité des systèmes d’information et, le cas échéant, un délégué à la protection des données. Des procédures encadrent sélection du personnel, gestion des actifs, contrôle d’accès, administration, journalisation, télémaintenance et sécurité physique.

Analyse juridique

1. Appréciation des risques et protection contre le droit extra-européen

1.1. Le référentiel impose au prestataire une appréciation des risques intégrant la menace de « collecte de données ou métadonnées des commanditaires sans leur consentement préalable » par des autorités extra-européennes. L’exigence 5.3.e prévoit que le prestataire doit mettre à disposition du commanditaire, sur demande, les éléments d’appréciation des risques liés à la soumission des données au droit d’un État non-membre de l’Union Européenne. Cette obligation est prolongée par l’exigence 19.1.e, qui impose de formaliser dans la convention de service cette mise à disposition d’éléments d’appréciation des risques, et par le chapitre 19.6 sur la protection vis-à-vis du droit extra-européen, qui encadre la structure capitalistique, la localisation du siège et les conditions de recours à des sociétés tierces non européennes.

1.2. L’exigence 5.3.f impose de prendre en compte les exigences légales, réglementaires ou sectorielles spécifiques liées aux types d’informations confiées par le commanditaire, sans jamais abaisser le niveau de sécurité défini par le référentiel. La direction du prestataire doit accepter formellement les risques résiduels (5.3.g) et réviser annuellement l’appréciation des risques, ainsi qu’à chaque changement majeur (5.3.h). Cette logique de révision régulière se retrouve dans la gestion des changements (12.2), la continuité d’activité (17.1, 17.3) et la conformité (18.1, 18.2), ce qui ancre la sécurité dans un cycle d’amélioration continue.

1.3. Le chapitre 19.6 précise les garde-fous contre le droit extra-européen. Le siège statutaire, l’administration centrale et le principal établissement du prestataire doivent être situés dans l’Union Européenne (19.6.a). Le capital social et les droits de vote détenus par des entités tierces non européennes sont plafonnés (19.6.b), et ces entités ne doivent pas disposer de droit de veto ni de la capacité de désigner la majorité des organes de direction. Lorsqu’une société tierce non européenne intervient (19.6.c), elle ne doit pas avoir la possibilité technique d’obtenir les données confiées au prestataire ni les données techniques (identités des bénéficiaires et administrateurs, journaux de l’infrastructure technique, annuaire, certificats, configuration des accès, etc.). L’exigence 19.6.d impose en outre une autonomie d’exploitation continue, éventuellement via des sociétés tierces qualifiées SecNumCloud. Enfin, le prestataire doit informer formellement le commanditaire de tout changement juridique, organisationnel ou technique pouvant affecter cette conformité (19.6.f).

2. Organisation de la sécurité de l’information et gouvernance

2.1. Le chapitre 6 impose une organisation interne de la sécurité de l’information documentée, couvrant la définition, la mise en place et le suivi du fonctionnement opérationnel de la sécurité. Le prestataire doit désigner un responsable de la sécurité des systèmes d’information (RSSI) et un responsable de la sécurité physique (6.1.b). Les responsabilités en matière de sécurité de l’information doivent être définies et attribuées à tout le personnel impliqué dans la fourniture du service (6.1.c), et réévaluées après tout changement majeur (6.1.d).

2.2. En matière de protection des données à caractère personnel, le prestataire doit définir des responsabilités cohérentes avec son rôle (responsable de traitement, sous-traitant ou co-responsable) (6.1.e). Lorsqu’il traite un grand nombre de données, dont des catégories particulières de données à caractère personnel au sens du [RGPD], il doit désigner un délégué à la protection des données (6.1.f), cette désignation étant recommandée dans tous les cas (6.1.g). Il doit réaliser ou contribuer à une analyse d’impact relative à la protection des données (AIPD) lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes (6.1.h), en combinant évaluation juridique (respect des principes et droits fondamentaux) et étude technique des mesures de protection de la vie privée.

2.3. La séparation des tâches (6.2) impose d’identifier les risques liés aux cumuls de responsabilités et de mettre en œuvre des mesures de réduction. Le prestataire est encouragé à entretenir des relations avec les autorités compétentes (6.3) et avec des groupes de travail spécialisés (6.4) pour intégrer les nouvelles menaces et mesures de sécurité. La sécurité de l’information dans la gestion de projet (6.5) exige une estimation des risques préalable à tout projet pouvant impacter le service, et une information écrite du commanditaire lorsque le niveau de sécurité est affecté, avec description des impacts, des mesures de réduction et des risques résiduels.

3. Sécurité des ressources humaines et éthique

3.1. Le chapitre 7 encadre la sécurité des ressources humaines. Le prestataire doit mettre en œuvre une procédure de vérification des informations concernant son personnel (7.1.a), proportionnée à la sensibilité des informations du commanditaire. Pour les personnels disposant de privilèges d’administration élevés (capacité d’élévation de privilèges, actions sans traces techniques, désactivation ou altération des traces), les vérifications doivent être renforcées (7.1.b). Ces exigences sont reprises pour les interventions de support technique (9.7.d, 12.13) et pour les accès en zones privées et sensibles (11.2.1.g, 11.2.2.g).

3.2. Les conditions d’embauche (7.2) imposent une charte d’éthique intégrée au règlement intérieur, couvrant la loyauté, la discrétion, l’impartialité, la confidentialité des informations, l’usage exclusif de méthodes et outils validés, l’interdiction de divulgation d’informations à des tiers, l’obligation de signaler tout contenu manifestement illicite et le respect de la législation et des bonnes pratiques. Cette charte doit être signée par toutes les personnes impliquées dans la fourniture du service (7.2.b). Pour les administrateurs à privilèges élevés, le contrat de travail doit inclure un engagement de responsabilité renvoyant aux clauses du code du travail sur la protection du secret des affaires et de la propriété intellectuelle (7.2.c). Le règlement intérieur et la charte doivent être accessibles au commanditaire sur demande (7.2.d).

3.3. Le prestataire doit organiser la sensibilisation, l’apprentissage et les formations à la sécurité de l’information (7.3), avec un plan de formation validé par le RSSI (7.3.c). Un processus disciplinaire doit être défini pour les violations de la politique de sécurité (7.4), avec communication des sanctions possibles au commanditaire (7.4.b). Les rôles et responsabilités liés à la rupture, au terme ou à la modification du contrat de travail doivent être définis (7.5), ce qui conditionne la bonne gestion des droits d’accès et la restitution des actifs.

4. Gestion des actifs et supports

4.1. Le chapitre 8 impose un inventaire des actifs couvrant l’ensemble des équipements et logiciels mettant en œuvre le service (8.1). Pour chaque équipement, doivent être renseignés les identifiants (noms, adresses IP, adresses MAC), la fonction, le modèle, la localisation, le propriétaire et le besoin de sécurité des informations (8.1.a). L’inventaire des logiciels doit préciser la version et les équipements sur lesquels ils sont installés (8.1.b), et la validité des licences doit être assurée (8.1.c).

4.2. Une procédure de restitution des actifs (8.2) doit garantir que chaque personne restitue tous les actifs à la fin de sa période d’emploi ou de contrat. Le prestataire doit identifier les besoins de sécurité de l’information (8.3), y compris les besoins spécifiques liés à des contraintes légales, réglementaires ou sectorielles (8.3.b). Il est recommandé de mettre en œuvre une procédure de marquage et manipulation de l’information (8.4) adaptée au besoin de sécurité, et une procédure de gestion des supports amovibles (8.5), avec supports dédiés lorsqu’ils sont utilisés sur l’infrastructure technique ou pour des tâches d’administration.

5. Contrôle d’accès, gestion des identités et interfaces d’administration

5.1. Le chapitre 9 définit une politique de contrôle d’accès basée sur l’appréciation des risques et le partage des responsabilités (9.1.a), révisée annuellement et après tout changement majeur (9.1.b). Une procédure d’enregistrement et de désinscription des utilisateurs (9.2) doit s’appuyer sur une interface de gestion des comptes et droits d’accès, préciser les données à supprimer au départ d’un utilisateur (9.2.a), imposer des comptes nominatifs (9.2.b) et garantir la suppression de tous les accès et données associées lors de la désinscription (9.2.c).

5.2. La gestion des droits d’accès (9.3) doit couvrir l’attribution, la modification et le retrait des droits (9.3.a), offrir aux commanditaires des moyens de différenciation des rôles (9.3.b), maintenir un inventaire des utilisateurs disposant de droits d’administration (9.3.c) et permettre de produire, pour une ressource ou un utilisateur donné, la liste des accès et droits associés (9.3.d, 9.3.e). Le prestataire doit définir une liste de droits d’accès incompatibles et empêcher leur cumul (9.3.f), et inclure dans la procédure les actions de révocation ou suspension des droits (9.3.g). Une revue annuelle des droits d’accès (9.4.a) et une revue trimestrielle des utilisateurs pouvant utiliser des comptes techniques (9.4.c) sont exigées, avec mise à disposition d’outils de revue pour le commanditaire (9.4.b).

5.3. La gestion des authentifications (9.5) impose des procédures couvrant la gestion des moyens d’authentification, la mise en place de mécanismes d’authentification à multiples facteurs et le respect des recommandations [G_AUTH] pour les mots de passe (9.5.a). Tout mécanisme doit prévoir le blocage de compte après un nombre limité de tentatives infructueuses (9.5.b). Dans un service SaaS, le prestataire doit proposer des moyens d’authentification multifacteur pour les utilisateurs finaux (9.5.c). Lorsque des comptes techniques non nominatifs sont nécessaires, l’accès doit être conditionné à une authentification préalable avec un compte nominatif (9.5.d).

5.4. Les interfaces d’administration (9.6) doivent être strictement cloisonnées. Les comptes d’administration sous la responsabilité du prestataire doivent être gérés via des outils et annuaires distincts de ceux des comptes utilisateurs du commanditaire (9.6.a). Les interfaces d’administration destinées aux commanditaires doivent être distinctes de celles utilisées par le prestataire (9.6.b) et ne pas permettre de connexion avec des comptes d’administrateurs du prestataire (9.6.c). Les interfaces d’administration du prestataire ne doivent pas être accessibles depuis un réseau public (9.6.d). Si des interfaces d’administration sont accessibles via un réseau public, les flux doivent être authentifiés et chiffrés conformément au chapitre 10.2 (9.6.e), et un système d’authentification multifacteur fort doit être mis en place pour toutes les interfaces d’administration (9.6.f). Dans un service SaaS, les interfaces d’administration des commanditaires doivent être différenciées de celles des utilisateurs finaux (9.6.g), et l’authentification doit intervenir avant toute interaction lorsque l’interface est accessible depuis un réseau public (9.6.h). Les ressources utilisées par le prestataire sur des services IaaS, CaaS ou PaaS ne doivent jamais être accessibles via les interfaces publiques destinées aux autres commanditaires (9.6.i, 9.6.j, 9.6.k).

5.5. Le chapitre 9.7 impose des restrictions d’accès à l’information par cloisonnement entre commanditaires, entre le système d’information du service et les autres systèmes du prestataire, et entre l’infrastructure technique et les équipements d’administration. Dans le cadre du support technique, l’accès aux données du commanditaire nécessite un consentement explicite (9.7.d), la vérification des antécédents de la personne (7.1.b) et, pour une intervention à distance hors UE, l’usage d’une passerelle sécurisée (poste de rebond) répondant aux objectifs de sécurité du guide [G_EXT] (authentification de la machine et de la personne, journalisation des actions d’administration, suppression de l’autorisation d’accès, prévention des vulnérabilités, garantie de confidentialité, intégrité, traçabilité de confiance, innocuité de la télémaintenance et absence de fuite d’informations).

6. Cryptologie et gestion des secrets

6.1. Le chapitre 10 encadre la cryptologie. Pour le chiffrement des données stockées (10.1), le prestataire doit empêcher la récupération des données en cas de réallocation de ressource ou de récupération du support physique. Pour les services IaaS ou CaaS, cela peut passer par le chiffrement de disque ou de système de fichiers, ou par un chiffrement par volume avec au moins une clé par commanditaire. Pour les services PaaS ou SaaS, un chiffrement applicatif avec au moins une clé par commanditaire est envisagé. Les méthodes de chiffrement doivent respecter les règles de [CRYPTO_B1] (10.1.b), et il est recommandé de suivre ses recommandations (10.1.c). Les supports amovibles et de sauvegarde quittant le périmètre de sécurité physique doivent être chiffrés en fonction du besoin de sécurité (10.1.d).

6.2. Le chiffrement des flux (10.2) doit également respecter [CRYPTO_B1], avec application des recommandations [NT_TLS] pour TLS, [NT_IPSEC] pour IPsec et [NT_SSH] pour SSH. Pour le hachage des mots de passe (10.3), seules les empreintes doivent être stockées, générées par une fonction de hachage conforme à [CRYPTO_B1] et associée à un sel cryptographique. Les mécanismes de non-répudiation via signature électronique doivent également respecter [CRYPTO_B1] (10.4).

6.3. La gestion des secrets (10.5) impose l’usage de clés cryptographiques conformes à [CRYPTO_B2], protégées par des conteneurs de sécurité logiciels ou matériels, ou des supports disjoints. Les clés utilisées pour les tâches d’administration doivent être protégées par un conteneur de sécurité adapté. Enfin, les racines de confiance (10.6) exigent l’usage exclusif de certificats de clé publique issus d’une autorité de certification d’un État membre de l’Union Européenne, avec cérémonies de génération des clés maîtresses dans un pays membre et en présence du prestataire.

7. Sécurité physique et environnementale

7.1. Le chapitre 11 définit des périmètres de sécurité physique (zones publiques, privées et sensibles). Les zones publiques ne doivent héberger aucune ressource dévolue au service (11.1.1). Les zones privées peuvent héberger les plateformes et moyens de développement, les postes d’administration, d’exploitation et de supervision, ainsi que les locaux d’opération (11.1.2). Les zones sensibles sont réservées à l’hébergement du système d’information de production du service (11.1.3).

7.2. Le contrôle d’accès physique aux zones privées doit reposer sur au moins un facteur personnel (connaissance, possession ou biométrie) (11.2.1.a), et sur deux facteurs pour les zones sensibles (11.2.2.a), en cohérence avec les recommandations [G_CVAP]. Des mesures dérogatoires en cas d’urgence, des avertissements à l’entrée, des plages horaires et conditions d’accès, l’accompagnement systématique des visiteurs, la conservation de leur identité et la surveillance et détection des accès non autorisés sont exigés. Pour les zones sensibles, une journalisation des accès physiques avec revue mensuelle est imposée (11.2.2.i), ainsi que l’absence d’accès direct entre zone publique et zone sensible (11.2.2.j).

7.3. Le prestataire doit se protéger contre les menaces extérieures et environnementales (11.3) : sinistres physiques (incendie, dégât des eaux), risques climatiques, coupures d’alimentation électrique, pannes de climatisation. Des contrôles et tests réguliers des équipements de détection et de protection physique sont requis (11.3.e). Le travail en zones privées et sensibles (11.4) doit être encadré par des procédures communiquées aux intervenants. Les zones de livraison et de chargement sont considérées comme publiques et doivent être isolées des zones privées et sensibles (11.5).

7.4. La sécurité du câblage (11.6) impose des mesures de protection contre les dommages physiques et les interceptions, un plan de câblage à jour et, de manière recommandée, une identification des câbles. La maintenance des matériels (11.7) doit être compatible avec les exigences de confidentialité et de disponibilité, inclure des contrats de maintenance pour les mises à jour de sécurité, et garantir que les supports retournés à un tiers ne contiennent que des données chiffrées ou effacées de manière sécurisée. Le transfert hors site des actifs (11.8) nécessite une autorisation écrite de la direction et un niveau de protection équivalent à celui sur site. Le recyclage sécurisé du matériel (11.9) impose un effacement sécurisé ou l’effacement de la clé de chiffrement, et le matériel en attente d’utilisation doit être protégé (11.10).

8. Sécurité liée à l’exploitation, journalisation et vulnérabilités

8.1. Le chapitre 12 encadre la sécurité liée à l’exploitation. Les procédures d’exploitation doivent être documentées, tenues à jour et accessibles (12.1). La gestion des changements (12.2) impose une procédure formalisée, la communication anticipée aux commanditaires des opérations pouvant impacter la sécurité ou la disponibilité (date, nature, impacts, contact), l’information sur les modifications logicielles en PaaS lorsque la compatibilité n’est pas assurée, et l’information sur toute modification susceptible d’entraîner une perte de fonctionnalité.

8.2. Les environnements de développement, de test et d’exploitation doivent être séparés physiquement (12.3). Des mesures de détection, prévention et restauration contre les codes malveillants (12.4) doivent couvrir au minimum les postes utilisateurs du prestataire et les flux entrants, complétées par une sensibilisation des employés. La sauvegarde des informations (12.5) impose une politique de sauvegarde et de restauration avec sauvegarde quotidienne, protection des sauvegardes selon la politique de contrôle d’accès, revue mensuelle des traces d’accès, tests réguliers de restauration, localisation des sauvegardes à distance suffisante, et chiffrement des communications entre site principal et site de sauvegarde conformément au chapitre 10.

8.3. La journalisation des événements (12.6) doit être encadrée par une politique précisant les sources de collecte, les événements à journaliser, l’objet, la fréquence, la durée de rétention, les mesures de protection (chiffrement, duplication) et la localisation des journaux. Les événements à collecter incluent les activités des utilisateurs liées à la sécurité, les modifications de droits d’accès, les événements des mécanismes anti-malware, les exceptions, défaillances et tout événement lié à la sécurité. Les journaux doivent être conservés au moins six mois, fournis au commanditaire sur demande, et idéalement conformes aux recommandations [NT_JOURNAL]. La protection de l’information journalisée (12.7) impose la protection des équipements de journalisation, le dimensionnement adéquat de l’espace de stockage, le transfert sécurisé vers des serveurs centraux dédiés distincts des machines génératrices, la sauvegarde des événements collectés et la limitation des accès aux journaux.

8.4. La synchronisation des horloges (12.8) doit s’appuyer sur des sources de temps internes cohérentes, éventuellement synchronisées sur des sources externes fiables, et chaque événement doit être horodaté. L’analyse et la corrélation des événements (12.9) doivent permettre la détection en temps réel ou a posteriori (jusqu’à six mois) des événements susceptibles d’affecter la sécurité, en s’appuyant idéalement sur le référentiel [PDIS]. Les alarmes doivent être acquittées au moins quotidiennement.

8.5. L’installation de logiciels sur des systèmes en exploitation (12.10) doit être contrôlée, avec une gestion de la configuration des environnements logiciels mis à disposition du commanditaire et une capacité d’inspection et de suppression des entrants (mises à jour, outils fournis) opérée sur des dispositifs spécifiques en zone cloisonnée (type DMZ au sens de [G_INT]), générant des journaux d’activité et auditables en code. La gestion des vulnérabilités techniques (12.11) impose un processus de veille, l’évaluation de l’exposition et l’application de mesures de traitement du risque adaptées.

8.6. L’administration (12.12) doit s’effectuer depuis des terminaux dédiés, durcis conformément à [NT_ADMIN], maîtrisés et maintenus à jour. En situation de mobilité, une politique documentée doit garantir un niveau de sécurité équivalent, incluant un tunnel chiffré non débrayable pour tous les flux (10.2) et le chiffrement intégral du disque (10.1). Le télédiagnostic et la télémaintenance (12.13) reprennent les exigences de vérification des antécédents (7.1.b), l’usage d’une passerelle sécurisée conforme à [G_EXT] lorsque la personne n’a pas satisfait à ces vérifications, la journalisation des actions comme des actions d’administration et la suppression de l’autorisation d’accès à l’issue de l’intervention.

8.7. La surveillance des flux sortants de l’infrastructure (12.14) impose une capacité d’inspection et de suppression des sortants (informations de facturation, journaux nécessaires au traitement d’incidents, etc.), avec possibilité d’expurger les données pouvant porter atteinte à la confidentialité des données des commanditaires, génération de journaux d’activité et auditabilité du code. Ces sortants doivent être traités sur des dispositifs spécifiques opérés par le prestataire et hébergés dans une zone cloisonnée (type DMZ au sens de [G_INT]).

9. Sécurité des communications et cloisonnement des réseaux

9.1. Le chapitre 13 impose une cartographie du système d’information (13.1) en lien avec l’inventaire des actifs, incluant la liste des ressources matérielles ou virtualisées, les applications supportant le service, le schéma d’architecture réseau (niveau 3 du modèle OSI) avec identification des points d’interconnexion, des réseaux et sous-réseaux (dont réseaux d’administration), des équipements de sécurité (filtrage, authentification, chiffrement) et des serveurs hébergeant des données ou fonctions sensibles. Une matrice des flux réseau autorisés doit décrire les services, protocoles, ports, la justification métier ou d’infrastructure, et les mesures compensatoires pour les services réputés non sûrs. La cartographie doit être révisée au moins annuellement.

9.2. Le cloisonnement des réseaux (13.2) doit séparer les flux selon la sensibilité des informations, la nature des flux (production, administration, supervision), le domaine d’appartenance (commanditaires, prestataire, tiers) et le domaine technique (traitement, stockage). Tous les flux internes au système d’information du service doivent être cloisonnés vis-à-vis des autres systèmes d’information, physiquement ou par chiffrement conforme au chapitre 10.2. Si le réseau d’administration n’est pas physiquement cloisonné, les flux d’administration doivent transiter dans un tunnel chiffré. Un pare-feu applicatif doit protéger les interfaces d’administration exposées sur un réseau public, et un mécanisme de filtrage doit n’autoriser que les connexions légitimes identifiées dans la matrice des flux autorisés.

9.3. La surveillance des réseaux (13.3) impose la mise en place de sondes de détection d’incidents de sécurité sur le système d’information du service, couvrant chaque interconnexion avec des systèmes tiers et des réseaux publics. Ces sondes doivent alimenter l’infrastructure d’analyse et de corrélation des événements décrite au chapitre 12.9.

10. Acquisition, développement et maintenance des systèmes d’information

10.1. Le chapitre 14 impose une politique de développement sécurisé (14.1) appliquée aux développements internes, complétée par une formation adaptée des employés concernés. Les procédures de contrôle des changements de système (14.2) doivent encadrer les modifications apportées au système d’information du service, avec validation en pré-production et conservation d’un historique des versions permettant de reconstituer un environnement à une date donnée, en cohérence avec la durée de conservation des sauvegardes (12.5).

10.2. Une revue technique des applications après changement de la plateforme d’exploitation (14.3) doit vérifier l’absence d’effets indésirables sur l’activité ou la sécurité. Un environnement de développement sécurisé (14.4) doit couvrir l’intégralité du cycle de développement et être intégré à l’appréciation des risques. Le développement externalisé (14.5) doit être supervisé et contrôlé pour garantir un niveau de sécurité équivalent au développement interne, conforme à la politique de développement sécurisé.

10.3. Les tests de sécurité et de conformité (14.6) doivent être systématiques pour les systèmes nouveaux ou mis à jour, avec une procédure de test documentant les tâches, les données d’entrée et les résultats attendus. La protection des données de test (14.7) impose une procédure garantissant l’intégrité des données de test en pré-production. L’usage de données de production du commanditaire pour les tests nécessite son accord préalable, une anonymisation et la garantie de la confidentialité lors de cette anonymisation.

11. Relations avec les tiers et engagements de confidentialité

11.1. Le chapitre 15 impose l’identification des tiers (hébergeurs, développeurs, intégrateurs, archiveurs, sous-traitants, fournisseurs techniques, etc.) participant à la mise en œuvre du service, avec description de leur contribution et de leur rôle dans le traitement des données à caractère personnel, y compris la sous-traitance en cascade (15.1.a). Le prestataire doit tenir à disposition du commanditaire la liste des tiers pouvant accéder aux données et l’informer de tout changement de sous-traitant au sens de l’article 28 du [RGPD] (15.1.b).

11.2. La sécurité dans les accords conclus avec les tiers (15.2) impose d’exiger un niveau de sécurité au moins équivalent à celui du prestataire, via des exigences adaptées dans les cahiers des charges et contrats, incluant des clauses d’audit permettant à un organisme de qualification de vérifier le respect du référentiel. Les rôles et responsabilités relatifs à la modification ou à la fin du contrat avec un tiers doivent être définis (15.2.c). Une procédure de surveillance et revue des services des tiers (15.3) doit contrôler régulièrement les mesures mises en place par les tiers, et une procédure de gestion des changements apportés dans les services des tiers (15.4) doit encadrer les impacts sur le niveau de sécurité, avec information sans délai des commanditaires et mesures de rétablissement du niveau de sécurité précédent.

11.3. Les engagements de confidentialité vis-à-vis des tiers (15.5) doivent être revus au moins annuellement. Ces exigences complètent les engagements de confidentialité internes (charte d’éthique, secret des affaires, propriété intellectuelle) et les obligations contractuelles de non-divulgation prévues dans la convention de service (19.1.l).

12. Gestion des incidents de sécurité de l’information

12.1. Le chapitre 16 impose des responsabilités et procédures pour apporter des réponses rapides et efficaces aux incidents de sécurité (16.1.a), en définissant les moyens et délais de communication aux commanditaires et le niveau de confidentialité de ces communications. Les employés et tiers doivent être informés de ces procédures (16.1.b). Toute violation de données à caractère personnel doit être documentée et notifiée au commanditaire, à la CNIL si elle présente un risque pour les droits et libertés, et aux personnes concernées si le risque pour leur vie privée est élevé (16.1.c).

12.2. Des procédures de signalement des incidents (16.2) doivent exiger des employés et des tiers qu’ils rapportent tout incident avéré ou suspecté et toute faille de sécurité, et permettre aux commanditaires de signaler eux-mêmes ces incidents. Le prestataire doit communiquer sans délai aux commanditaires les incidents et les préconisations pour en limiter les impacts, en leur laissant la possibilité de choisir les niveaux de gravité pour lesquels ils souhaitent être informés (16.2.c). Les incidents doivent également être communiqués aux autorités compétentes conformément aux exigences légales (16.2.d).

12.3. L’appréciation des événements (16.3) doit s’appuyer sur des échelles partagées avec le commanditaire pour décider de la qualification en incident de sécurité, incluant explicitement les violations de données à caractère personnel. Une classification doit permettre d’identifier clairement les incidents touchant des données relatives aux commanditaires. La réponse aux incidents (16.4) impose un traitement jusqu’à résolution, l’information des commanditaires et l’archivage des documents détaillant les incidents. Il est recommandé de recourir à un prestataire de réponse aux incidents de sécurité [PRIS] qualifié pour les cas nécessitant une expertise supplémentaire (16.4.c).

12.4. Le prestataire doit mettre en œuvre un processus d’amélioration continue (16.5) pour réduire l’occurrence et l’impact des incidents déjà traités, et une procédure de recueil de preuves (16.6) pour enregistrer les informations relatives aux incidents pouvant servir d’éléments de preuve.

13. Continuité d’activité et disponibilité

13.1. Le chapitre 17 impose un plan de continuité d’activité (PCA) prenant en compte la sécurité de l’information (17.1.a), révisé annuellement et après tout changement majeur (17.1.b). Des procédures doivent permettre de maintenir ou de restaurer l’exploitation du service et d’assurer la disponibilité des informations au niveau et dans les délais convenus dans la convention de service (17.2).

13.2. Le PCA doit être testé pour vérifier sa pertinence et son efficacité en situation de crise (17.3). Le prestataire doit mettre en œuvre des mesures pour répondre au besoin de disponibilité du service défini dans la convention (17.4), sauvegarder hors-ligne la configuration de l’infrastructure technique (17.5) et mettre à disposition du commanditaire un service de sauvegarde de ses données (17.6).

14. Conformité, audits et revue indépendante

14.1. Le chapitre 18 impose l’identification de la législation et des exigences contractuelles applicables (18.1), incluant au minimum la loi du 6 janvier 1978 [LOI_IL], le [RGPD], les articles du Code pénal relatifs au secret professionnel, à l’abus de confiance, au secret des correspondances, à l’atteinte à la vie privée et à l’accès ou maintien frauduleux dans un système d’information ([CP_ART_226-13], [CP_ART_314-1], [CP_ART_226-15], [CP_ART_226-1], [CP_ART_323-1]). Le prestataire doit justifier et documenter les mesures techniques et organisationnelles mises en œuvre pour répondre aux exigences de protection des données à caractère personnel (18.1.b), mettre en œuvre des procédures de conformité et un processus de veille actif (18.1.c, 18.1.e), et rendre ces procédures accessibles au commanditaire sur demande (18.1.d).

14.2. La revue indépendante de la sécurité de l’information (18.2) repose sur un programme d’audit sur trois ans inclu

Repères utiles

Les références essentielles de ce texte, en un coup d’œil.

Ce contenu constitue une information documentaire  juridique et ne remplace pas une consultation personnalisée. Pour une analyse appliquée à votre dossier, contactez un avocat partenaire LegalPlanet.