1.1. Les exigences issues du Journal officiel de la République française du 14 août 2026 encadrent de manière très précise la sécurité des services d’informatique en nuage. Elles visent à garantir la confidentialité et l’intégrité des données sur le système d’information (SI), à assurer une traçabilité de confiance des actions, à préserver l’innocuité de la télémaintenance et à garantir l’absence de fuite d’informations vers l’extérieur. Ces exigences s’inscrivent dans le cadre du référentiel SecNumCloud porté par l’ANSSI et renvoient à de nombreuses références légales et techniques (notamment [RGPD], [LOI_IL], et les guides de l’ANSSI).
1.2. Le prestataire doit, à l’issue de toute intervention de télémaintenance ou de support, supprimer l’autorisation d’accès accordée au technicien. Cette exigence complète l’obligation de garantir l’innocuité de la fonction de télémaintenance vis-à-vis du système faisant l’objet du télédiagnostic et des systèmes connexes. Elle participe à la réduction de la surface d’attaque et à la prévention des accès non autorisés persistants.
1.3. L’ensemble des dispositions détaillées dans les chapitres 12 à 19 du texte officiel structure une approche globale de la sécurité : surveillance des flux sortants, sécurité des communications, développement sécurisé, relations avec les tiers, gestion des incidents, continuité d’activité, conformité, convention de service, localisation des données, protection des données à caractère personnel et protection vis-à-vis du droit extra-européen. Ces exigences sont conçues pour assurer une défense en profondeur et une maîtrise juridique et technique du service d’informatique en nuage.
2.1. Le chapitre 12.14. Surveillance des flux sortants de l’infrastructure impose au prestataire de fournir une capacité d’inspection et de suppression des sortants de l’infrastructure technique relatifs au périmètre du service (informations de facturation, journaux nécessaires au traitement d’incidents, etc.). L’objectif est de s’assurer que les flux sortants ne compromettent pas la confidentialité des données des commanditaires.
2.2. Les sortants doivent pouvoir être expurgés des données pouvant porter atteinte à la confidentialité. La capacité d’inspection et de suppression doit générer des journaux d’activité et pouvoir faire l’objet d’un audit de code. Cette exigence renforce la transparence et la vérifiabilité des mécanismes de filtrage et de traitement des flux sortants.
2.3. Les sortants sont traités sur des dispositifs spécifiques opérés et maintenus par le prestataire, hébergés dans une zone cloisonnée du reste de l’infrastructure, de type zone démilitarisée (DMZ) telle que définie dans [G_INT]. Ce cloisonnement réduit le risque de propagation d’incidents et limite l’exposition des systèmes internes.
3.1.1. Le prestataire doit établir et tenir à jour une cartographie du système d’information du service, en lien avec l’inventaire des actifs (voir chapitre 8.1). Cette cartographie comprend au minimum : la liste des ressources matérielles ou virtualisées, les noms et fonctions des applications supportant le service, le schéma d’architecture réseau au niveau 3 du modèle OSI avec identification des points d’interconnexion (réseaux tiers et publics), des réseaux et sous-réseaux (notamment réseaux d’administration), des équipements de sécurité (filtrage, authentification, chiffrement, etc.) et des serveurs hébergeant des données ou assurant des fonctions sensibles.
3.1.2. La cartographie doit intégrer une matrice des flux réseau autorisés précisant pour chaque flux : la description technique (services, protocoles, ports), la justification métier ou technique et, le cas échéant, les mesures compensatoires mises en place lorsque des services, protocoles ou ports réputés non sûrs sont utilisés, dans une logique de défense en profondeur. Le prestataire doit réviser au moins annuellement cette cartographie.
3.2.1. Le prestataire doit documenter et mettre en œuvre des mesures de cloisonnement (logique, physique ou par chiffrement) pour séparer les flux réseau selon la sensibilité des informations, la nature des flux (production, administration, supervision, etc.), le domaine d’appartenance (commanditaires, prestataire, tiers) et le domaine technique (traitement, stockage, etc.).
3.2.2. Tous les flux de données internes au système d’information du service doivent être cloisonnés, physiquement ou par chiffrement, vis-à-vis de tout autre système d’information. Lorsque le cloisonnement est réalisé par chiffrement, il doit respecter les exigences du chapitre 10.2. Si le réseau d’administration ne fait pas l’objet d’un cloisonnement physique, les flux d’administration doivent transiter dans un tunnel chiffré, également conforme au chapitre 10.2.
3.2.3. Le prestataire doit mettre en place et configurer un pare-feu applicatif pour protéger les interfaces d’administration destinées aux commanditaires et exposées sur un réseau public. Il doit aussi déployer sur l’ensemble des interfaces d’administration et de supervision un mécanisme de filtrage n’autorisant que les connexions légitimes identifiées dans la matrice des flux autorisés.
3.3.1. Le prestataire doit disposer d’une ou plusieurs sondes de détection d’incidents de sécurité sur le système d’information du service. Ces sondes doivent permettre la supervision de chacune des interconnexions avec des systèmes d’information tiers et des réseaux publics. Elles constituent des sources de collecte pour l’infrastructure d’analyse et de corrélation des événements (voir chapitre 12.9), contribuant à la détection précoce des incidents.
4.1.1. Le prestataire doit documenter et mettre en œuvre des règles de développement sécurisé des logiciels et des systèmes, et les appliquer à tous les développements internes. Il doit également mettre en place une formation adaptée en développement sécurisé pour les employés concernés, afin de réduire les vulnérabilités introduites lors du cycle de développement.
4.2.1. Une procédure de contrôle des changements apportés au système d’information du service doit être documentée et appliquée. Toute modification doit être validée en environnement de pré-production avant mise en production. Le prestataire doit conserver un historique des versions des logiciels et systèmes (internes, externes, produits commerciaux) pour pouvoir reconstituer un environnement complet tel qu’il existait à une date donnée, avec une durée de conservation cohérente avec celle des sauvegardes (voir chapitre 12.5).
4.3.1. Le prestataire doit mettre en œuvre une procédure de test des applications après tout changement apporté à la plateforme d’exploitation, afin de vérifier l’absence d’effet indésirable sur l’activité ou la sécurité du service. Cette revue technique est un élément clé de la maîtrise des risques liés aux évolutions.
4.4.1. Un environnement sécurisé de développement doit être mis en œuvre pour gérer l’intégralité du cycle de développement du système d’information du service. Les environnements de développement doivent être pris en compte dans l’appréciation des risques et protégés conformément au référentiel, afin d’éviter qu’ils ne deviennent un point faible.
4.5.1. Le prestataire doit disposer d’une procédure de supervision et de contrôle du développement externalisé. Cette procédure doit garantir que les développements réalisés par des tiers sont conformes à la politique de développement sécurisé du prestataire et atteignent un niveau de sécurité équivalent à celui des développements internes (voir exigence 14.1 a).
4.6.1. Les systèmes d’information, nouveaux ou mis à jour, doivent être soumis à des tests de conformité et de fonctionnalité de sécurité pendant le développement. Une procédure de test doit identifier les tâches à réaliser, les données d’entrée et les résultats attendus, afin de structurer et d’industrialiser la vérification de la sécurité.
4.7.1. Le prestataire doit assurer l’intégrité des données de test utilisées en pré-production via une procédure dédiée. S’il souhaite utiliser des données de production du commanditaire pour des tests, il doit obtenir l’accord préalable du commanditaire et anonymiser ces données, en garantissant leur confidentialité lors de l’anonymisation.
5.1.1. Le prestataire doit tenir à jour une liste exhaustive des tiers participant à la mise en œuvre du service (hébergeur, développeur, intégrateur, archiveur, sous-traitant sur site ou à distance, fournisseurs de climatisation, etc.). Cette liste précise la contribution de chaque tiers au service et au traitement des données à caractère personnel, y compris en cas de sous-traitance à plusieurs niveaux.
5.1.2. Le prestataire doit tenir à disposition du commanditaire la liste de l’ensemble des tiers pouvant accéder aux données et l’informer de tout changement de sous-traitants au sens de l’article 28 du [RGPD], afin de permettre au commanditaire d’émettre des objections.
5.2.1. Le prestataire doit exiger des tiers un niveau de sécurité au moins équivalent à celui de sa propre politique de sécurité, via des exigences adaptées intégrées dans les cahiers des charges, clauses de sécurité et contrats. Il doit également contractualiser des clauses d’audit permettant à un organisme de qualification de vérifier le respect du référentiel par ces tiers.
5.2.2. Les rôles et responsabilités relatifs à la modification ou à la fin du contrat avec un tiers doivent être clairement définis et attribués, afin de maîtriser les impacts sur la sécurité du service.
5.3.1. Une procédure de contrôle régulier des mesures de sécurité mises en place par les tiers doit être documentée et appliquée, conformément au chapitre 18.3. Le prestataire doit également suivre les changements apportés par les tiers susceptibles d’affecter le niveau de sécurité du système d’information du service.
5.3.2. En cas de changement de tiers affectant le niveau de sécurité, le prestataire doit en informer sans délai l’ensemble des commanditaires (conformément au chapitre 12.2) et mettre en œuvre les mesures nécessaires pour rétablir le niveau de sécurité précédent.
5.4.1. Le prestataire doit disposer d’une procédure de révision annuelle des exigences en matière d’engagements de confidentialité ou de non-divulgation vis-à-vis des tiers participant à la mise en œuvre du service, afin de maintenir un niveau de protection adapté.
6.1.1. Le prestataire doit documenter et mettre en œuvre une procédure de réponse aux incidents de sécurité permettant d’apporter des réponses rapides et efficaces. Cette procédure définit les moyens et délais de communication des incidents aux commanditaires concernés, ainsi que le niveau de confidentialité exigé pour ces communications.
6.1.2. Le prestataire doit informer ses employés et l’ensemble des tiers participant au service de cette procédure. Il doit documenter toute violation de données à caractère personnel et en informer le commanditaire. Lorsque la violation présente un risque pour les droits et libertés des personnes concernées, elle doit être notifiée à la CNIL et, en cas de risque élevé pour la vie privée, faire l’objet d’une information des personnes concernées.
6.2.1. Le prestataire doit exiger de ses employés et des tiers qu’ils signalent tout incident de sécurité, avéré ou suspecté, ainsi que toute faille de sécurité. Une procédure doit également permettre aux commanditaires de signaler de tels incidents ou failles.
6.2.2. Le prestataire doit communiquer sans délai aux commanditaires les incidents de sécurité et les préconisations associées pour en limiter les impacts. Il doit permettre au commanditaire de choisir les niveaux de gravité des incidents pour lesquels il souhaite être informé et doit communiquer les incidents aux autorités compétentes conformément aux exigences légales et réglementaires.
6.3.1. Le prestataire doit apprécier les événements liés à la sécurité et décider s’il faut les qualifier en incidents de sécurité, en s’appuyant sur une ou plusieurs échelles d’estimation ou d’évaluation partagées avec le commanditaire. Les incidents de sécurité incluent explicitement les violations de données à caractère personnel.
6.3.2. Une classification des incidents doit permettre d’identifier clairement ceux touchant des données relatives aux commanditaires, en cohérence avec l’appréciation des risques. Cette classification inclut les violations de données à caractère personnel.
6.4.1. Le prestataire doit traiter les incidents de sécurité jusqu’à leur résolution et informer les commanditaires conformément aux procédures. Il doit archiver les documents détaillant les incidents de sécurité. Il est recommandé de recourir à un prestataire de réponse aux incidents de sécurité [PRIS] qualifié pour les incidents nécessitant une expertise supplémentaire.
6.4.2. Un processus d’amélioration continue doit être mis en œuvre pour diminuer l’occurrence et l’impact des types d’incidents déjà traités. Le prestataire doit également disposer d’une procédure de recueil de preuves permettant d’enregistrer les informations relatives aux incidents pouvant servir d’éléments de preuve.
7.1.1. Le prestataire doit documenter et mettre en œuvre un plan de continuité d’activité prenant en compte la sécurité de l’information. Ce plan doit être révisé annuellement et à chaque changement majeur pouvant avoir un impact sur le service.
7.1.2. Des procédures de maintien ou de restauration de l’exploitation du service doivent être définies pour assurer la disponibilité des informations au niveau et dans les délais prévus dans la convention de service.
7.2.1. Le prestataire doit tester le plan de continuité d’activité afin de s’assurer de sa pertinence et de son efficacité en situation de crise. Il doit mettre en œuvre les mesures nécessaires pour répondre au besoin de disponibilité défini dans la convention de service (voir chapitre 19.1).
7.2.2. Une procédure de sauvegarde hors-ligne de la configuration de l’infrastructure technique doit être mise en œuvre. Le prestataire doit également mettre à disposition du commanditaire un service de sauvegarde de ses données, afin de garantir la résilience des informations.
8.1.1. Le prestataire doit identifier les exigences légales, réglementaires et contractuelles applicables au service. En France, il doit au minimum considérer : la loi Informatique et Libertés [LOI_IL], le [RGPD], les dispositions relatives au secret professionnel [CP_ART_226-13], à l’abus de confiance [CP_ART_314-1], au secret des correspondances [CP_ART_226-15], à l’atteinte à la vie privée [CP_ART_226-1] et à l’accès ou maintien frauduleux à un système d’information [CP_ART_323-1].
8.1.2. Selon son rôle (responsable de traitement, sous-traitant ou co-responsable), le prestataire doit justifier et documenter les mesures techniques et organisationnelles mises en place pour répondre aux exigences de protection des données à caractère personnel du référentiel (voir partie 19.5). Il doit documenter et appliquer les procédures permettant de respecter ces exigences et les besoins de sécurité spécifiques (voir exigence 8.3 b)), et rendre ces procédures accessibles au commanditaire sur demande. Un processus de veille actif sur les exigences légales, réglementaires et contractuelles doit être mis en œuvre.
8.2.1. Le prestataire doit mettre en place un programme d’audit sur trois ans définissant périmètre et fréquence des audits, en accord avec la gestion du changement, les politiques et les résultats de l’appréciation des risques. Ce programme doit inclure au moins un audit qualifié par an réalisé par un prestataire d’audit de la sécurité des systèmes d’information [PASSI] qualifié. Il couvre notamment : l’audit de la configuration de l’infrastructure technique (par échantillonnage), les tests d’intrusion des interfaces d’administration exposées sur un réseau public, les tests d’intrusion de l’interface utilisateur pour les services SaaS, et, en cas de développements internes, l’audit de code source portant sur les fonctionnalités de sécurité (approche continue privilégiée).
8.2.2. Il est recommandé de mettre en œuvre des mécanismes automatisés d’audit de configuration adaptés à l’infrastructure. Avant la qualification du service, une revue indépendante initiale par un [PASSI] qualifié doit couvrir l’audit de configuration des ressources, systèmes d’exploitation et logiciels de base, ainsi que des tests d’intrusion sur les interfaces d’administration et, pour les SaaS, sur l’interface utilisateur et le code source (authentification, gestion des sessions, cloisonnement multi-tenant). Pour un SaaS rendant un service de sécurité de l’information, une certification produit dédiée est nécessaire.
8.2.3. En cas de changement majeur pouvant affecter le service, une revue indépendante de changement par un [PASSI] qualifié doit couvrir l’audit d’architecture, l’audit organisationnel et physique, l’audit de configuration, des tests d’intrusion sur les interfaces d’administration et, pour les SaaS, sur l’interface utilisateur et le code source (authentification, sessions, cloisonnement multi-tenant).
8.3.1. Le responsable de la sécurité de l’information doit s’assurer régulièrement de la bonne exécution des procédures de sécurité pour garantir leur conformité aux politiques et normes de sécurité. Une politique d’examen de la conformité technique doit définir objectifs, méthodes, fréquences, résultats attendus et mesures correctrices pour vérifier la conformité du service au référentiel.
9.1.1. Le prestataire doit établir une convention de service avec chaque commanditaire. Toute modification doit être soumise à l’acceptation du commanditaire. La convention doit identifier les obligations, droits et responsabilités des parties, les éléments exclus des responsabilités du prestataire (dans le respect des exigences légales, notamment l’article 28 du [RGPD]), ainsi que la localisation du service et du support (notamment si réalisé hors UE).
9.1.2. La convention doit appliquer le droit d’un État membre de l’Union européenne, préciser que les traitements de données (avant-vente, mise en œuvre, maintenance, arrêt du service) sont réalisés conformément à la législation en vigueur, et indiquer que le prestataire met à disposition, 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’UE (voir 5.3 e). Elle doit décrire les moyens techniques et organisationnels mis en œuvre pour assurer le respect du droit applicable.
9.1.3. La convention doit inclure une clause de révision prévoyant une résiliation sans pénalité pour le commanditaire en cas de perte de qualification du service, ainsi qu’une clause de réversibilité permettant au commanditaire de récupérer l’ensemble de ses données (fournies ou produites dans le cadre du service). La réversibilité doit être assurée via la mise à disposition de fichiers dans des formats documentés et exploitables ou via des interfaces techniques (API, format pivot). La convention doit préciser le niveau de disponibilité du service, indiquer que le prestataire ne peut disposer des données transmises et générées par le commanditaire, et qu’il ne divulgue aucune information relative à la prestation à des tiers sans autorisation écrite.
9.1.4. La convention doit indiquer si les données du commanditaire sont automatiquement sauvegardées. Dans le cas contraire, le prestataire doit sensibiliser le commanditaire aux risques et indiquer clairement les opérations à mener pour assurer la sauvegarde. Elle doit préciser si un accès distant est autorisé pour l’administration ou le support. La convention doit mentionner que le service est qualifié, inclure l’attestation de qualification, informer le commanditaire de la possibilité de déposer une réclamation auprès de l’ANSSI et préciser que le commanditaire autorise l’ANSSI et l’organisme de qualification à auditer le service.
9.1.5. La convention doit préciser que le commanditaire autorise un [PASSI] qualifié mandaté par le prestataire à auditer le service dans le cadre du plan de contrôle, et que le prestataire s’engage à mettre à disposition toutes les informations nécessaires aux audits de conformité à l’article 28 du [RGPD], menés par le commanditaire ou un tiers mandaté (idéalement un [PASSI] qualifié).
9.2.1. Le prestataire doit documenter et communiquer au commanditaire la localisation du stockage et du traitement des données. Il doit stocker et traiter les données du commanditaire au sein de l’Union européenne, et réaliser les opérations d’administration et de supervision depuis l’UE. Les données techniques (identités des bénéficiaires et administrateurs, journaux, annuaire, certificats, configuration des accès, etc.) doivent également être stockées et traitées au sein de l’UE.
9.2.2. Le prestataire peut réaliser des opérations de support depuis un État hors UE, à condition de documenter la liste des opérations concernées et les mécanismes de contrôle d’accès et de supervision depuis l’UE. Il doit s’assurer que les interfaces du service accessibles au commanditaire sont au moins disponibles en langue française et fournir un support de premier niveau en français.
9.3.1. À la fin du contrat, le prestataire doit assurer un effacement sécurisé de l’intégralité des données du commanditaire, après un préavis formel de vingt et un jours calendaires. L’effacement peut être réalisé par réécriture complète des supports, par effacement des clés de chiffrement des espaces de stockage (chapitre 10.1) ou par recyclage sécurisé (chapitre 11.9). Il doit également supprimer les données techniques relatives au commanditaire (annuaire, certificats, configuration des accès, etc.).
9.4.1. Pour les traitements mis en œuvre pour son propre compte, le prestataire doit justifier du respect des principes de protection des données : finalités déterminées, explicites et légitimes, traçabilité des activités de traitement, fondement licite, interdiction du détournement de finalité, minimisation des données (adéquates, pertinentes, limitées), qualité des données (exactes, tenues à jour) et durées de conservation définies et limitées.
9.4.2. Il doit également justifier du respect des droits des personnes concernées : information loyale et transparente, recueil du consentement (exprès, démontrable, retirable), possibilité d’exercer les droits d’accès, de rectification, d’effacement, ainsi que les droits de limitation, de portabilité et d’opposition. Lorsqu’il agit en qualité de sous-traitant au sens de l’article 28 du [RGPD], il doit apporter assistance et conseil au commanditaire, notamment en l’informant si une instruction constitue une violation des règles de protection des données.
9.5.1. Le siège statutaire, l’administration centrale et le principal établissement du prestataire doivent être établis dans un État membre de l’UE. Le capital social et les droits de vote ne doivent pas être, directement ou indirectement, individuellement détenus à plus de 24 % et collectivement à plus de 39 % par des entités tierces ayant leur siège hors UE. Ces entités ne doivent pas disposer d’un droit de veto ni pouvoir désigner la majorité des organes de direction.
9.5.2. En cas de recours à une société tierce hors UE (ou contrôlée par une société hors UE), celle-ci ne doit pas avoir la possibilité technique d’obtenir les données opérées au travers du service (données confiées par les commanditaires et données techniques). Toute société tierce utilisée doit garantir au prestataire une autonomie d’exploitation continue ou être qualifiée SecNumCloud. Le service doit respecter la législation en vigueur en matière de droits fondamentaux et les valeurs de l’Union (dignité humaine, liberté, égalité, démocratie, État de droit). Le prestataire doit informer formellement le commanditaire, dans un délai d’un mois, de tout changement juridique, organisationnel ou technique pouvant affecter la conformité aux exigences du chapitre 19.6.
10.1. L’annexe du texte officiel formule des recommandations aux commanditaires de prestations d’informatique en nuage. Les autorités administratives ou opérateurs d’importance vitale peuvent solliciter l’ANSSI pour la définition du cahier des charges. Il est recommandé de choisir un prestataire dans le catalogue des prestataires qualifiés publié par l’ANSSI, la qualification attestant de la conformité au référentiel SecNumCloud.
10.2. Pour bénéficier d’une prestation qualifiée, le commanditaire doit à la fois choisir un prestataire qualifié et exiger que la convention de service stipule que la prestation est qualifiée. Le [GUIDE_ACHAT] peut accompagner la fonction achat lors des appels d’offres. Le commanditaire peut déposer une réclamation auprès de l’ANSSI contre un prestataire qualifié qui ne respecterait pas le référentiel, ce qui peut conduire à une suspension, un retrait ou une réduction de la portée de la qualification.
10.3. La qualification n’atteste pas de la capacité à accéder ou détenir des informations classifiées de défense [IGI_1300] ni des articles contrôlés de la sécurité des systèmes d’information [II_910]. La conformité au référentiel SecNumCloud ne se substitue pas aux exigences spécifiques applicables à certaines données (par exemple données de santé ou de niveau Diffusion Restreinte). Pour l’accès aux interfaces de gestion du service, il est recommandé d’utiliser des moyens dédiés conformes au guide [NT_ADMIN].
11.1. Textes législatifs et réglementaires :
– Loi du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés [LOI_IL]
– Règlement (UE) 2016/679 (RGPD) [RGPD]
– Code pénal – abus de confiance [CP_ART_314-1]
– Code pénal – atteinte à la vie privée [CP_ART_226-1]
– Code pénal – secret professionnel [CP_ART_226-13]
– Code pénal – secret des correspondances [CP_ART_226-15]
– Code pénal – accès ou maintien frauduleux dans un système d’information [CP_ART_323-1]
– Instruction interministérielle ACSSI n°910/SGDSN/ANSSI [II_910]
– Politique de sécurité des systèmes d’information de l’État (PSSIE)
11.2. Normes et guides techniques ANSSI :
– Règles et recommandations cryptographiques [CRYPTO_B1] et gestion des clés [CRYPTO_B2]
– L’homologation de sécurité en neuf étapes simples [HOMOLOGATION]
– Guide d’Hygiène Informatique [HYGIENE]
– Recommandations relatives à l’interconnexion à Internet [INTERNET] / [G_INT]
– Recommandations de sécurité relatives à IPsec [NT_IPSEC]
– Recommandations de sécurité relatives à TLS [NT_TLS]
– Recommandations pour un usage sécurisé d’(Open)SSH [NT_SSH]
– Recommandations pour la journalisation [NT_JOURNAL]
– Administration sécurisée des systèmes d’information [NT_ADMIN]
Type d’acte, par exemple : Proposition de loi, Protocole, décret, arrêté, loi, ordonnance, délibération, recommandation, circulaire, instruction, avis, décision, communiqué, rapport, question ministérielle, réponse ministérielle, autre
Référentiel
Autorité / organisme : Reprendre l’autorité, le ministère, l’institution, l’organisme, l’autorité administrative indépendante ou autorité ayant rendu ce texte officiel
Agence nationale de la sécurité des systèmes d’information
Date du texte sous la forme jour mois année, exemple de sortie : 14 avril 2026
14 août 2026
Numéro exact du texte sauf si non indiqué
Variantes exactes de recherche :
Résumé :
Suite de l’extrait du référentiel de sécurité pour les prestataires d’informatique en nuage publié au Journal officiel, détaillant les exigences relatives à la surveillance des flux sortants, à la sécurité des communications et au cloisonnement réseau, au développement sécurisé, aux relations avec les tiers, à la gestion des incidents, à la continuité d’activité, à la conformité et aux audits, ainsi qu’aux conventions de service, à la localisation des données, à la fin de contrat et à la protection contre le droit extra-européen. Le texte comporte une liste structurée de références législatives, réglementaires et techniques (RGPD, loi Informatique et libertés, guides et référentiels ANSSI, normes ISO) et une annexe de recommandations aux commanditaires souhaitant recourir à des services de cloud qualifiés.
Approfondir ce sujet :