Matrice de responsabilité partagée dans le cloud pour ISO, NIS2, DORA

Le directeur des opérations d’une fintech appelle le RSSI à 07 h 15 un lundi.

Un client bancaire européen demande des éléments démontrant que la plateforme SaaS de l’entreprise peut satisfaire aux exigences DORA relatives au risque lié aux TIC posé par les tiers. L’équipe commerciale a déjà transmis le dossier fournisseur habituel : certificat ISO, synthèse exécutive du test d’intrusion, attestation d’assurance cyber, note d’information et rapport d’assurance du fournisseur cloud.

La banque revient avec une question plus précise :

« Montrez-nous qui porte chaque contrôle dans votre environnement cloud. Vous, votre fournisseur cloud, votre fournisseur de base de données managée, votre fournisseur d’identité, votre fournisseur de journalisation et tous les sous-traitants ultérieurs. Puis montrez les éléments de preuve. »

Plus tard dans la matinée, le RSSI participe à une réunion du conseil d’administration. Le directeur général posera la même question en termes métier : « Sommes-nous certains que cette plateforme est sécurisée, et qui est responsable si quelque chose se passe mal ? »

C’est à ce stade que de nombreux programmes de conformité cloud s’enrayent.

L’organisation peut disposer d’un fournisseur cloud robuste, de bons outils, de politiques raisonnables et d’un registre des risques. Mais lorsqu’il faut démontrer les périmètres de responsabilité, les éléments de preuve sont dispersés. Les achats détiennent les contrats. Le juridique détient le DPA. L’ingénierie détient les schémas d’architecture. La sécurité détient les journaux et les configurations cloud. L’équipe protection des données détient la liste des sous-traitants ultérieurs. La conformité détient la Déclaration d’applicabilité. Personne ne détient un livrable contrôlé unique indiquant, contrôle par contrôle, ce que fait le fournisseur, ce que le client doit configurer, quel sous-traitant ultérieur intervient, quelle clause rend l’obligation opposable et quels éléments de preuve un auditeur doit attendre.

Ce livrable est la matrice de responsabilité partagée dans le cloud.

Pas la diapositive générique d’un hyperscaler indiquant que le fournisseur sécurise le cloud et que le client sécurise ce qui se trouve dans le cloud. Une véritable matrice de responsabilité partagée dans le cloud pour ISO/IEC 27001:2022, NIS2, DORA et GDPR est un enregistrement de gouvernance. Elle résiste aux diligences raisonnables des clients, à un audit ISO, à une revue DORA, à une contestation de responsabilité au titre de GDPR et à une investigation d’incident.

Pourquoi la responsabilité partagée dans le cloud devient un sujet d’audit

Le modèle de responsabilité partagée est généralement présenté comme une frontière technique. En IaaS, le fournisseur gère les installations physiques, le matériel, la virtualisation et l’infrastructure de base. Le client gère les identités, les données, les charges de travail, les règles réseau, les choix de chiffrement et les configurations. En SaaS, le fournisseur assume davantage de responsabilité opérationnelle, mais le client conserve la responsabilité des accès utilisateurs, de la gouvernance des données, de la base légale, de la configuration, des attentes de surveillance et de l’escalade des incidents.

Cette explication est utile, mais incomplète.

Les auditeurs, les autorités de régulation et les grands comptes demandent davantage que « qui exploite le contrôle ? ». Ils veulent savoir :

• Qui est responsable du risque ?
• Quelle clause contractuelle rend cette responsabilité opposable ?
• Quelle politique impose le contrôle ?
• Quel service cloud, quelle plateforme SaaS ou quel sous-traitant ultérieur est dans le champ d’application ?
• Quels éléments de preuve démontrent que le contrôle a fonctionné pendant la période de revue ?
• À quelle exigence de référentiel les éléments de preuve répondent-ils ?
• Que se passe-t-il si le fournisseur modifie son service, sa localisation, son sous-traitant ou son niveau de contrôle ?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 en fait un sujet de système de management. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, les parties intéressées, les obligations légales et contractuelles, le domaine d’application du SMSI, les interfaces et les dépendances. Les clauses 6.1.1 à 6.1.3 exigent l’appréciation des risques, le traitement des risques, l’approbation par le propriétaire du risque, l’acceptation du risque résiduel et une Déclaration d’applicabilité. La clause 8.1 exige la planification et la maîtrise opérationnelles, y compris la maîtrise des processus, produits et services fournis par des tiers et pertinents pour le SMSI.

En termes simples, si un fournisseur cloud, un fournisseur SaaS ou un sous-traitant ultérieur soutient un processus métier inclus dans le périmètre, il ne peut pas rester en dehors du SMSI. Il doit être visible dans le périmètre, les risques, le traitement, les contrôles contractuels et les éléments de preuve.

NIS2 renforce les exigences. Article 21 impose aux entités essentielles et importantes de mettre en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité, la sécurité de la chaîne d’approvisionnement, l’acquisition sécurisée, le développement sécurisé, la gestion des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et l’authentification multifacteur ou l’authentification continue lorsque cela est approprié. Article 20 place la responsabilité de gouvernance sur les organes de direction.

DORA est encore plus explicite pour les entités financières. Il s’applique à compter du 17 janvier 2025 et impose aux entités financières de gérer le risque lié aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle numérique et le risque lié aux TIC posé par les tiers. Les Articles 28 à 30 imposent la gestion des risques liés aux prestataires tiers de services TIC, l’appréciation préalable du risque de concentration, des garanties contractuelles, des droits d’audit et d’accès, la visibilité sur la sous-traitance, les droits de résiliation et les stratégies de sortie.

GDPR ajoute le test de responsabilité. Article 5 exige que les données à caractère personnel soient traitées avec intégrité et confidentialité, et Article 5(2) exige que le responsable du traitement soit en mesure de démontrer la conformité. Article 28 encadre les contrats de sous-traitance et les sous-traitants ultérieurs. Article 32 exige la sécurité du traitement. Les Articles 33 et 34 exigent la notification des violations de données à caractère personnel lorsqu’elle est applicable.

La matrice de responsabilité partagée dans le cloud devient le lien opérationnel entre ces obligations.

La définition Clarysec : un livrable de gouvernance, pas un schéma

Dans les missions Clarysec, une matrice de responsabilité partagée dans le cloud est un enregistrement contrôlé du SMSI qui relie services cloud, fournisseurs, sous-traitants ultérieurs, contrôles, politiques, obligations contractuelles, éléments de preuve et attentes d’audit.

L’explication la plus forte figure dans Zenith Blueprint Zenith Blueprint, dans la phase Controls in Action, étape 23 :

« Les fournisseurs cloud sécurisent l’infrastructure, mais vous restez responsables de vos données, de vos configurations, de vos politiques d’accès et de votre préparation à la réponse aux incidents. »

La même étape explique que l’utilisation du cloud doit être traitée comme une partie du SMSI, y compris la classification des services cloud, la compréhension des données traitées ou stockées, l’évaluation du fournisseur, les clauses contractuelles et la gestion des changements de service. Cela transforme la responsabilité partagée d’un concept en une structure de contrôle traçable.

Zenith Controls Zenith Controls traite les contrôles de l’Annexe A ISO/IEC 27001:2022 et les recommandations ISO/IEC 27002:2022 5.20, 5.21 et 5.23 comme des ancrages centraux :

• 5.20, traiter la sécurité de l’information dans les accords avec les fournisseurs.
• 5.21, gérer la sécurité de l’information dans la chaîne d’approvisionnement TIC.
• 5.23, sécurité de l’information pour l’utilisation des services cloud.

Ces points ne sont pas des éléments isolés d’une liste de contrôle. Ils définissent l’ossature de la matrice.

Les normes de soutien peuvent renforcer la matrice. ISO/IEC 27017 aide pour les pratiques de sécurité spécifiques au cloud. ISO/IEC 27018 et ISO/IEC 27701 soutiennent la gouvernance des PII et de la vie privée. ISO/IEC 27005 soutient l’appréciation des risques. ISO 22301 soutient la continuité et la résilience. ISO/IEC 27035 soutient la gestion des incidents. ISO/IEC 20000-1 peut aider lorsque les services cloud font partie d’une prestation de services managés.

La matrice minimale viable de responsabilité partagée

Une matrice mature ne commence pas par 200 lignes. Elle commence par les services cloud les plus importants.

Pour une entreprise SaaS, une fintech ou une PME réglementée, Clarysec commence généralement par :

1. Environnement cloud de production orienté clients.
2. Fournisseur d’identité.
3. Base de données managée ou service de stockage managé.
4. Plateforme de journalisation, de surveillance et SIEM.
5. SaaS de paiement, de KYC, d’analytique ou de support client.
6. Service de sauvegarde et de reprise après sinistre.
7. Prestataire de services managés ou prestataire de services de sécurité managés.
8. Sous-traitants ultérieurs qui accèdent aux données client, les stockent ou les traitent.

La première matrice doit inclure les colonnes suivantes.

Une ligne pratique de journalisation pourrait ressembler à ceci.

Cette ligne n’est pas une simple documentation. Elle indique à la sécurité ce qu’il faut configurer, aux achats quel libellé contractuel vérifier, à l’équipe protection des données quel flux de données enregistrer et aux auditeurs quels éléments de preuve demander.

Fondement politique : transformer la matrice en exigence opposable

Une matrice de responsabilité partagée dans le cloud sans appui politique n’est qu’un tableur. Les politiques Clarysec la rendent opposable.

Pour les PME, Politique d’utilisation du cloud - PME Politique d’utilisation du cloud - PME, section « Exigences de gouvernance », clause 5.3 exige :

« Un registre des services cloud doit être maintenu par le prestataire informatique ou le DG. Il doit enregistrer : »

La même politique PME, clause 5.2.3, relie la gouvernance cloud au risque de protection de la vie privée et de localisation :

« La localisation des données et les pratiques de protection de la vie privée sont conformes aux exigences légales applicables (par exemple, GDPR). »

Pour les environnements d’entreprise, Politique d’utilisation du cloud Politique d’utilisation du cloud, section « Exigences de gouvernance », clause 5.1 dispose :

« L’organisation doit maintenir un registre centralisé des services cloud, détenu par le RSSI, contenant : »

La clause 5.4 rend ensuite les responsabilités cloud contractuellement opposables :

« Tous les contrats de CSP (fournisseur de services cloud) doivent inclure des dispositions opposables concernant : »

La gouvernance des fournisseurs étend la matrice au-delà du fournisseur immédiat. Politique de sécurité des tiers et des fournisseurs - PME Politique de sécurité des tiers et des fournisseurs - PME, section « Exigences de gouvernance », clause 5.3.5 exige :

« Restrictions relatives à toute sous-traitance ultérieure sans approbation »

La même politique fournisseur PME, section « Exigences de mise en œuvre de la politique », clause 6.3.1 ajoute une revue périodique :

« Les fournisseurs critiques ou à haut risque doivent être revus au moins une fois par an. La revue doit vérifier : »

Au niveau entreprise, Politique de sécurité des tiers et des fournisseurs Politique de sécurité des tiers et des fournisseurs, section « Exigences de gouvernance », clause 5.3 dispose :

« Les contrats avec les fournisseurs doivent inclure : »

Pour les données à caractère personnel, Politique de protection des données et de la vie privée Politique de protection des données et de la vie privée, section « Application et conformité », clause 8.5.1 exige :

« Les contrats avec les sous-traitants doivent inclure : »

Pour la visibilité sur les dépendances, Politique de gestion des risques de dépendance vis-à-vis des fournisseurs Politique de gestion des risques de dépendance vis-à-vis des fournisseurs, clause 6.5.4 exige :

« Exploiter la relation fournisseur pour obtenir des mises à jour sur les sous-traitants ou les dépendances de chaîne d’approvisionnement à un niveau en aval lorsqu’ils pourraient nous affecter (par exemple, si un fournisseur logiciel critique dépend fortement d’une bibliothèque tierce, cela doit être enregistré). »

Pour les journaux, Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME, section « Exigences de gouvernance », clause 5.5.1.3 fournit une exigence contractuelle concrète :

« Les contrats doivent exiger que les fournisseurs conservent les journaux pendant au moins 12 mois et fournissent un accès sur demande. »

Ensemble, ces politiques font de la matrice un enregistrement de gouvernance obligatoire qui soutient l’approbation des fournisseurs, l’intégration des services cloud, la responsabilité en matière de protection de la vie privée, la revue annuelle et les éléments de preuve d’audit.

Cartographier la matrice entre ISO/IEC 27001:2022, NIS2, DORA et GDPR

L’erreur classique consiste à créer quatre classeurs de conformité séparés. Un contrôle peut satisfaire plusieurs obligations si la responsabilité et les éléments de preuve sont traçables.

ISO/IEC 27001:2022 fournit le moteur du SMSI : contexte, parties intéressées, périmètre, leadership, traitement des risques, objectifs, maîtrise opérationnelle, évaluation des performances et amélioration. L’Annexe A fournit la structure de contrôle opérationnelle.

NIS2 Article 21 se cartographie naturellement sur la même matrice via la sécurité de la chaîne d’approvisionnement, la gestion des incidents, la continuité, le contrôle d’accès, la gestion des actifs et l’acquisition sécurisée. Article 20 rend la matrice pertinente pour le conseil d’administration, car les organes de direction doivent approuver et superviser les mesures de gestion des risques de cybersécurité.

DORA transforme la matrice en outil de gestion du risque lié aux TIC posé par les tiers. Les Articles 5, 6 et 8 exigent la gouvernance, une gestion des risques liés aux TIC documentée et l’identification des actifs, fonctions et dépendances. Les Articles 17 à 19 exigent la détection, la classification, l’escalade, la communication et la notification des incidents. Les Articles 28 à 30 exigent la gestion des risques liés aux tiers, l’analyse du risque de concentration, des clauses contractuelles, des contrôles de sous-traitance, des droits d’audit, des droits de résiliation et des stratégies de sortie.

GDPR apporte le prisme des données à caractère personnel. Chaque ligne de service cloud doit indiquer si des données à caractère personnel sont traitées, si le fournisseur est sous-traitant ou sous-traitant ultérieur, si la localisation des données importe et quels éléments contractuels ou DPA existent.

NIST CSF 2.0 aide à communiquer la même matrice dans un langage d’objectifs. La fonction GOVERN couvre le contexte organisationnel, les exigences légales et réglementaires, les dépendances, la gestion des risques, les rôles, les politiques et la supervision. Les résultats GV.SC sont particulièrement utiles pour le risque cyber fournisseur, notamment les rôles fournisseurs, la criticité, les exigences contractuelles, les diligences raisonnables, la surveillance, la coordination des incidents et la planification de la résiliation.

COBIT 2019 ajoute une perspective d’assurance et de gouvernance. Il demande si la responsabilité, les pratiques de gestion, la propriété, la surveillance et la remédiation des problèmes sont répétables et étayées par des éléments de preuve.

Construire la matrice depuis le registre jusqu’à la preuve

Imaginez une entreprise SaaS utilisant une plateforme IaaS hyperscale, une base de données managée, un fournisseur d’identité tiers, une plateforme SaaS de support client et un SIEM externe. Le flux de mise en œuvre est direct.

Étape 1 : commencer par le registre des services cloud

Utilisez la Politique d’utilisation du cloud ou la Politique d’utilisation du cloud - PME comme déclencheur. Enregistrez chaque service cloud, son propriétaire, son objet, les catégories de données, la localisation, la fonction métier, le niveau fournisseur, le responsable du contrat et la date de revue.

Si le service stocke des enregistrements client, des journaux d’authentification ou des tickets de support, marquez-le comme pertinent pour la protection de la vie privée. S’il soutient la disponibilité de la production, marquez-le comme critique sur le plan opérationnel. S’il soutient une fonction critique ou importante d’un client financier, marquez-le comme pertinent au titre de DORA.

Étape 2 : ajouter les domaines de responsabilité partagée

Pour chaque service, définissez les responsabilités dans les domaines clés.

Étape 3 : relier les contrôles au risque et à la Déclaration d’applicabilité

Zenith Blueprint, phase Risk Management, étape 13, explique l’exigence de traçabilité :

« Référencer les réglementations : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez l’indiquer soit dans le registre des risques (dans la justification de l’impact du risque), soit dans les notes de la SoA. »

Par exemple, le risque « accès non autorisé aux données de production client via une mauvaise configuration cloud » peut se rattacher au contrôle d’accès, à l’utilisation du cloud, à la journalisation, à la cryptographie, à la gestion des vulnérabilités et aux accords fournisseurs. La SoA peut référencer ISO/IEC 27001:2022 Annexe A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 et 8.24, avec des notes relatives à GDPR Article 32, NIS2 Article 21 et à la gestion du risque lié aux TIC DORA lorsque cela est applicable.

Étape 4 : rattacher les éléments de preuve avant la saison d’audit

Les éléments de preuve doivent être intégrés à la conception de la matrice, et non collectés dans l’urgence.

La liste des éléments de preuve transforme la responsabilité en preuve. Elle aide également les équipes commerciales à répondre plus rapidement aux diligences raisonnables des grands comptes, car elles peuvent présenter non seulement des certifications, mais aussi la propriété des contrôles et des éléments probants de fonctionnement.

Sous-traitants ultérieurs : l’angle mort de la plupart des matrices

Les sous-traitants ultérieurs sont le point où la responsabilité partagée devient un véritable risque de chaîne d’approvisionnement.

Un fournisseur SaaS peut être votre sous-traitant au titre de GDPR. Ce fournisseur peut s’appuyer sur un prestataire d’hébergement cloud, un CDN, un service d’analytique, une plateforme de support, un service d’envoi de courriels, une base de données managée, un fournisseur d’observabilité et un prestataire de paiement. Certains peuvent accéder aux données à caractère personnel. Certains peuvent soutenir la fourniture d’un service critique sans voir directement les données. Certains peuvent être situés hors de l’UE. Certains peuvent être remplaçables. D’autres peuvent créer un risque de concentration.

DORA Article 29 exige une appréciation du risque de concentration pour les services TIC critiques ou importants, notamment la substituabilité, les arrangements multiples avec des fournisseurs identiques ou liés, les chaînes de sous-traitance, les sous-traitants de pays tiers, le droit de l’insolvabilité, les contraintes de récupération des données et l’opposabilité de la protection des données de l’Union. DORA Article 30 exige des dispositions contractuelles relatives aux conditions de sous-traitance, aux localisations, au traitement et au stockage des données, à l’accès et à la récupération, à l’assistance en cas d’incident, à la coopération avec les autorités, aux droits d’audit, à la résiliation et à la sortie.

NIS2 Article 21 exige de manière similaire la sécurité de la chaîne d’approvisionnement pour les fournisseurs directs et les prestataires de services, ainsi que la prise en compte des vulnérabilités propres aux fournisseurs, des pratiques de cybersécurité des fournisseurs et des procédures de développement sécurisé.

C’est pourquoi Clarysec traite la cartographie des sous-traitants ultérieurs comme une extension obligatoire de la gouvernance des fournisseurs, et non comme une simple liste tenue par l’équipe protection des données. Le registre des sous-traitants ultérieurs doit indiquer quel fournisseur utilise le sous-traitant ultérieur, de quel service il dépend, si des données à caractère personnel sont traitées, s’il soutient une fonction critique, la région de traitement le cas échéant, les obligations répercutées, les droits d’approbation ou d’opposition, l’assurance disponible, la méthode de surveillance et l’option de sortie.

Zenith Blueprint, phase Controls in Action, étape 23, indique :

« Pour chaque fournisseur critique, identifiez s’il utilise des sous-traitants (sous-traitants ultérieurs) susceptibles d’accéder à vos données ou systèmes. Documentez la manière dont vos exigences de sécurité de l’information sont répercutées sur ces parties, soit par les conditions contractuelles de votre fournisseur, soit par vos propres clauses directes. »

C’est le niveau de preuve attendu par les auditeurs lorsqu’ils demandent si les responsabilités cloud sont maîtrisées en aval.

Comment les auditeurs testent la même matrice

Une matrice de responsabilité partagée dans le cloud robuste résiste à plusieurs approches d’audit, car elle est construite autour de la propriété, de l’opposabilité et des éléments de preuve.

La matrice n’est pas l’objectif final. C’est la carte utilisée par les auditeurs pour tester si le système de gouvernance est réel.

Un auditeur ISO peut sélectionner un risque d’accès cloud à fort impact et le retracer depuis le registre des risques jusqu’à la SoA, puis jusqu’aux revues d’accès, aux éléments de preuve MFA et aux alertes de surveillance. Un évaluateur DORA peut sélectionner un fournisseur TIC critique et demander le test de sortie, l’analyse de sous-traitance et les droits d’audit contractuels. Un relecteur GDPR peut se concentrer sur la suppression, la localisation des données, la notification des violations et la transparence des sous-traitants ultérieurs.

Schémas d’échec fréquents

Les échecs les plus fréquents en matière de responsabilité partagée ne sont pas exotiques.

Premièrement, les organisations s’appuient sur les rapports d’assurance du fournisseur sans les relier aux responsabilités du client. Un fournisseur cloud peut démontrer la sécurité physique, la résilience de l’infrastructure et les contrôles de plateforme, mais pas que votre compartiment de stockage était privé, que les rôles IAM respectaient le moindre privilège ou que les journaux étaient activés.

Deuxièmement, les contrats contiennent un langage de sécurité générique, mais aucun délai d’incident, droit d’accès aux journaux, droit d’audit, limite de sous-traitance, disposition de restitution des données ou support de sortie. Zenith Blueprint, phase Controls in Action, étape 23, met en avant des domaines typiques d’accords fournisseurs tels que la confidentialité, le contrôle d’accès, les mesures techniques et organisationnelles, les délais d’incident, le droit d’audit, les contrôles des sous-traitants et les dispositions de fin de contrat.

Troisièmement, les sous-traitants ultérieurs sont listés à des fins de protection de la vie privée, mais ne sont pas reliés à la sécurité, à la continuité ou au risque de concentration. Un fournisseur d’observabilité ou de support en aval peut ne jamais apparaître dans le registre des risques alors même que son indisponibilité ou sa violation pourrait affecter la fourniture du service client.

Quatrièmement, la SoA indique qu’un contrôle est applicable, mais personne ne peut produire d’éléments probants de fonctionnement. La journalisation cloud peut être marquée comme mise en œuvre, mais l’organisation ne peut pas démontrer les paramètres de conservation, les revues d’accès, la gestion des alertes ou les engagements du fournisseur en matière d’accès aux journaux.

Cinquièmement, les plans de réponse aux incidents ne reflètent pas la dépendance vis-à-vis du fournisseur. Si le fournisseur notifie un incident de plateforme, qui évalue l’impact client ? Qui détermine si une notification NIS2, DORA ou GDPR est requise ? Qui contacte les clients affectés ? Que se passe-t-il si la cause racine relève d’un sous-traitant ultérieur ?

Responsabilité de la direction : pourquoi le conseil d’administration doit s’en préoccuper

NIS2 Article 20 impose aux organes de direction d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de recevoir une formation. DORA Article 5 impose à l’organe de direction de définir, approuver, superviser et assumer la responsabilité des dispositifs de gestion du risque lié aux TIC, y compris les politiques relatives aux prestataires tiers de services TIC, les plans de continuité et de reprise, les plans d’audit, la formation et les canaux de reporting.

Cela change la finalité de la matrice. Elle n’est plus seulement une feuille de travail de sécurité. Elle devient un élément de preuve montrant que la direction sait :

• Quels services cloud soutiennent les opérations critiques.
• Quels tiers et sous-traitants ultérieurs sont significatifs.
• Quelles obligations s’appliquent au titre des contrats clients, de GDPR, de NIS2 et de DORA.
• Quelles responsabilités restent conservées par l’organisation.
• Quels engagements fournisseurs sont contractuellement opposables.
• Quelles lacunes exigent financement, remédiation ou acceptation du risque.

Pour les PME, la proportionnalité est essentielle. Une entité plus petite n’a pas besoin d’une bureaucratie lourde, mais elle a néanmoins besoin de documentation, de surveillance, de systèmes résilients, de détection des sources de risque lié aux TIC, d’identification des dépendances clés vis-à-vis de tiers, de mesures de continuité, de tests, de retours d’expérience et de revue périodique lorsque cela entre dans le périmètre.

La matrice est l’un des outils proportionnés les plus efficaces, car elle consolide les obligations au lieu de les multiplier.

Un sprint de 30 jours pour rendre votre modèle cloud compatible avec les exigences d’audit

Si vous ne pouvez pas répondre à la question de savoir qui porte chaque contrôle cloud, quels éléments de preuve le démontrent et quel sous-traitant ultérieur pourrait l’affecter, votre modèle de responsabilité partagée reste un schéma, pas un livrable de gouvernance.

Un sprint pratique de 30 jours ressemble à ceci :

1. Créer ou mettre à jour le registre des services cloud à l’aide de la Politique d’utilisation du cloud ou de la Politique d’utilisation du cloud - PME.
2. Identifier les services critiques, les traitements de données à caractère personnel, les systèmes orientés clients et la pertinence DORA ou NIS2.
3. Construire la première matrice autour des contrôles ISO/IEC 27001:2022 Annexe A 5.20, 5.21 et 5.23 à l’aide de Zenith Controls.
4. Relier chaque ligne au registre des risques et à la Déclaration d’applicabilité à l’aide de l’étape 13 de Zenith Blueprint.
5. Valider les clauses fournisseurs et sous-traitants à l’aide de la Politique de sécurité des tiers et des fournisseurs, de la Politique de sécurité des tiers et des fournisseurs - PME et de la Politique de protection des données et de la vie privée.
6. Ajouter les éléments de preuve relatifs à la conservation des journaux, à l’escalade des incidents, à l’approbation des sous-traitants ultérieurs, aux droits d’audit et à la sortie.
7. Revoir les fournisseurs critiques chaque année, ainsi qu’après des changements majeurs, des incidents, de nouveaux sous-traitants ultérieurs ou des constats d’audit.

L’objectif est simple. Lorsque le client, l’auditeur, l’autorité de régulation ou le conseil d’administration demande « qui porte ce contrôle ? », vous ne cherchez pas dans les contrats, les tickets et les dossiers. Vous ouvrez la matrice, montrez le responsable, montrez la clause, montrez les éléments de preuve et montrez la piste en aval.

Clarysec peut vous aider à transformer les dossiers d’assurance des fournisseurs cloud en une matrice intégrée de responsabilité partagée pour les audits ISO/IEC 27001:2022, la préparation NIS2, le risque lié aux TIC posé par les tiers au titre de DORA, la responsabilité GDPR et les diligences raisonnables des grands comptes.

Commencez par le registre. Construisez la matrice. Rattachez les éléments de preuve. Puis utilisez-la comme preuve présentable au conseil d’administration que le risque cloud n’est pas externalisé : il est gouverné.