Stratégies de sortie TIC DORA appuyées par les contrôles ISO 27001

À 07 h 42 un lundi, un responsable des opérations d’une fintech reçoit le message que personne ne souhaite lire : le prestataire cloud de surveillance des transactions de l’entreprise subit une panne régionale majeure. À 08 h 15, le directeur des risques demande si le service affecté soutient une fonction critique ou importante. À 08 h 40, la direction juridique veut savoir si le contrat accorde à l’entreprise une assistance à la transition, des droits d’export des données, de suppression et d’audit. À 09 h 05, le RSSI recherche les éléments de preuve démontrant que le plan de sortie a été testé, et pas seulement rédigé.

Dans une autre entreprise de services financiers, Sarah, RSSI d’une plateforme fintech en forte croissance, ouvre une demande d’information préalable à l’audit pour une évaluation de conformité DORA. Les questions lui sont familières jusqu’à la section consacrée aux prestataires tiers de services TIC qui soutiennent des fonctions critiques ou importantes. Les auditeurs ne demandent pas si l’entreprise dispose d’une politique fournisseurs. Ils demandent des stratégies de sortie documentées, testées et viables.

Son attention se porte immédiatement sur le principal prestataire cloud qui héberge la plateforme, puis sur le prestataire de services de sécurité managés (MSSP) qui assure la surveillance continue des menaces. Que se passe-t-il si le prestataire cloud subit une perturbation géopolitique ? Si le MSSP est acquis par un concurrent ? Si un prestataire SaaS critique devient insolvable, met fin au service ou perd la confiance des clients après un incident majeur ?

Dans de nombreuses entreprises, la réponse inconfortable est la même. Il existe une appréciation du risque fournisseur, un plan de continuité d’activité, un dossier contractuel, un inventaire cloud et peut-être un rapport de sauvegarde. Mais il n’existe pas de stratégie de sortie TIC DORA vis-à-vis des prestataires tiers, unique et prête pour l’audit, reliant la criticité métier, les droits contractuels, la portabilité technique, les plans de continuité, les éléments de preuve de sauvegarde, les obligations de protection des données et l’approbation de la direction.

DORA modifie la posture de gestion des fournisseurs. En vertu du Règlement (UE) 2022/2554, les entités financières doivent gérer le risque lié aux prestataires tiers TIC dans le cadre de gestion des risques liés aux TIC. Elles demeurent pleinement responsables de la conformité, tiennent un registre des contrats de services TIC, distinguent les dispositifs TIC soutenant des fonctions critiques ou importantes, évaluent les risques de concentration et de sous-traitance, et maintiennent des stratégies de sortie pour les dépendances critiques vis-à-vis de prestataires tiers TIC. DORA s’applique depuis le 17 janvier 2025 et fixe des exigences uniformes dans l’UE pour la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience, le partage d’informations et la gestion des risques liés aux prestataires tiers TIC pour un large éventail d’entités financières.

Une stratégie de sortie DORA n’est pas un paragraphe dans un contrat fournisseur. C’est un système de contrôle. Elle doit être gouvernée, soumise à une appréciation des risques, techniquement réalisable, contractuellement opposable, testée, étayée par des éléments de preuve et améliorée en continu.

L’approche de Clarysec combine Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur Zenith Blueprint, des modèles de politiques d’entreprise et Zenith Controls : le guide de conformité croisée Zenith Controls afin de transformer cette question du lundi matin en réponse préparée.

Pourquoi les stratégies de sortie DORA échouent lors des audits réels

La plupart des défaillances des stratégies de sortie TIC DORA sont structurelles avant d’être techniques. L’organisation a un responsable fournisseurs, mais pas de propriétaire du risque clairement désigné. Elle dispose de tâches de sauvegarde, mais pas d’éléments de preuve de restauration. Elle a un questionnaire de diligence raisonnable fournisseur, mais aucune décision documentée indiquant si le prestataire soutient une fonction critique ou importante. Elle dispose d’un libellé contractuel sur la résiliation, mais pas de période de transition alignée sur le plan de continuité d’activité.

DORA impose de relier ces éléments. Article 28 définit les principes généraux de la gestion des risques liés aux prestataires tiers TIC, notamment la nécessité de gérer le risque associé aux prestataires tiers de services TIC tout au long du cycle de vie et de maintenir des stratégies de sortie appropriées. Article 30 fixe les exigences contractuelles détaillées applicables aux services TIC soutenant des fonctions critiques ou importantes, notamment les descriptions de service, les lieux de traitement des données, les protections de sécurité, les droits d’accès et d’audit, l’assistance en cas d’incident, la coopération avec les autorités compétentes et les droits de résiliation.

Le règlement est également proportionné. Articles 4 et 16 permettent à certaines petites entités ou entités exemptées d’appliquer un cadre simplifié de gestion des risques liés aux TIC. Mais simplifié ne signifie pas non documenté. Les petites entités financières doivent toujours disposer d’une gestion documentée des risques liés aux TIC, d’une surveillance continue, de systèmes résilients, d’une identification rapide des incidents TIC, de l’identification des principales dépendances vis-à-vis de prestataires tiers TIC, de sauvegardes et de restauration, de continuité d’activité, de réponse et de rétablissement, de tests, de retours d’expérience et de formation.

Une petite fintech ne peut pas dire : « Nous sommes trop petits pour planifier une sortie. » Elle peut dire : « Notre stratégie de sortie DORA est adaptée à notre taille, à notre profil de risque et à la complexité du service. » La différence tient aux éléments de preuve.

Pour les entités qui entrent également dans le champ d’application national de NIS2, DORA agit comme l’acte juridique de l’Union propre au secteur pour les obligations de cybersécurité qui se chevauchent dans le secteur financier. NIS2 reste pertinente dans l’écosystème plus large, en particulier pour les prestataires de services managés, les prestataires de services de sécurité managés, les prestataires cloud, les centres de données et les entités d’infrastructure numérique. NIS2 Article 21 renforce les mêmes thèmes : analyse des risques, gestion des incidents, continuité d’activité, sécurité de la chaîne d’approvisionnement, acquisition sécurisée, évaluation de l’efficacité, formation, cryptographie, contrôle d’accès, gestion des actifs et authentification.

Les autorités de supervision, les clients, les auditeurs et les conseils d’administration peuvent formuler la question différemment, mais l’enjeu central reste le même : pouvez-vous quitter un prestataire TIC critique sans perdre la maîtrise de la continuité de service, des données, des éléments de preuve ou de l’impact client ?

Intégrer la stratégie de sortie au SMSI

ISO/IEC 27001:2022 fournit l’ossature du système de management pour la planification des sorties DORA.

Les clauses 4.1 à 4.4 exigent que l’organisation définisse son contexte, ses parties intéressées, ses exigences légales, réglementaires et contractuelles, le domaine d’application du SMSI, les interfaces, les dépendances et les processus. C’est à ce stade qu’une entité financière identifie DORA, les engagements clients, les attentes en matière d’externalisation, les dépendances cloud, les obligations de protection des données, les sous-traitants et les services TIC inclus dans le périmètre du SMSI.

Les clauses 5.1 à 5.3 exigent le leadership, la politique, les ressources, l’attribution des rôles et des responsabilités. Cela s’aligne sur le modèle de gouvernance de DORA, dans lequel l’organe de direction définit, approuve, supervise et demeure responsable de la gestion des risques liés aux TIC, y compris la continuité d’activité TIC, les plans de réponse et de rétablissement, les plans d’audit TIC, les budgets, la stratégie de résilience et la politique de gestion des risques liés aux prestataires tiers TIC.

Les clauses 6.1.1 à 6.1.3 transforment la planification des sorties en traitement des risques. L’organisation définit les critères de risque, réalise des appréciations des risques répétables, identifie les risques pour la confidentialité, l’intégrité et la disponibilité, désigne les propriétaires de risques, évalue les conséquences et la vraisemblance, sélectionne les options de traitement, compare les contrôles avec l’Annexe A, produit une Déclaration d’applicabilité, prépare un plan de traitement des risques et obtient l’approbation du propriétaire du risque ainsi que l’acceptation du risque résiduel.

La clause 8.1 exige ensuite la planification et la maîtrise opérationnelles. L’organisation doit planifier, mettre en œuvre et maîtriser les processus du SMSI, conserver des informations documentées démontrant que les processus ont été exécutés comme prévu, gérer les changements et maîtriser les processus, produits ou services fournis par des tiers et pertinents pour le SMSI.

ISO/IEC 27005:2022 renforce cette approche. La clause 6.2 recommande aux organisations d’identifier les exigences des parties intéressées, notamment les contrôles de l’Annexe A ISO/IEC 27001:2022, les normes sectorielles, les réglementations nationales et internationales, les règles internes, les exigences contractuelles et les contrôles existants issus de traitements de risques antérieurs. Les clauses 6.4.1 à 6.4.3 expliquent que les critères de risque doivent prendre en compte les aspects juridiques et réglementaires, les relations avec les fournisseurs, la vie privée, les impacts opérationnels, les violations contractuelles, les opérations de tiers et les conséquences réputationnelles. Les clauses 8.2 à 8.6 soutiennent une bibliothèque de contrôles et un plan de traitement pouvant combiner l’Annexe A ISO/IEC 27001:2022 avec DORA, NIS2, GDPR, les engagements clients et les politiques internes.

Le modèle opérationnel est simple : un inventaire des exigences, un registre des risques fournisseurs, une Déclaration d’applicabilité, un plan de traitement des risques et un dossier d’éléments de preuve pour chaque scénario de sortie critique.

Les contrôles ISO/IEC 27001:2022 qui ancrent la planification des sorties DORA

Les stratégies de sortie DORA deviennent prêtes pour l’audit lorsque la gouvernance des fournisseurs, la portabilité cloud, la planification de la continuité et les éléments de preuve de sauvegarde sont traités comme une chaîne de contrôles intégrée.

Zenith Controls de Clarysec cartographie les contrôles de l’Annexe A ISO/IEC 27001:2022 avec les attributs de contrôle, les éléments de preuve d’audit et les attentes de conformité croisée. Il ne s’agit pas d’un cadre de contrôle distinct. C’est le guide de conformité croisée de Clarysec pour comprendre comment les contrôles ISO/IEC 27001:2022 soutiennent les résultats d’audit, réglementaires et opérationnels.

Pour une stratégie de sortie TIC DORA vis-à-vis des prestataires tiers, la piste d’audit doit montrer que :

• Le fournisseur est classifié et relié aux processus opérationnels.
• Le service est évalué afin de déterminer s’il soutient une fonction critique ou importante.
• Le risque de sortie est enregistré avec un propriétaire du risque responsable.
• Les clauses contractuelles soutiennent la transition, l’accès, l’audit, la restitution des données, la suppression des données, la coopération et la continuité.
• La portabilité cloud et l’interopérabilité ont été validées.
• Les sauvegardes et les tests de restauration démontrent la capacité de récupération.
• La substitution temporaire ou le traitement alternatif a été documenté.
• Les résultats des tests de sortie ont été revus, ont fait l’objet de remédiations et ont été communiqués à la direction.

Le langage contractuel est le premier contrôle de continuité

Un contrat doit être le premier contrôle de continuité, et non un obstacle à la continuité. Si le prestataire peut résilier rapidement, retarder les exports, restreindre l’accès aux journaux, facturer des frais de transition non définis ou refuser le support de migration, la stratégie de sortie est fragile.

Dans Zenith Blueprint, la phase Controls in Action, Étape 23, Contrôle 5.20, explique que les accords avec les fournisseurs doivent inclure les exigences pratiques de sécurité qui rendent la sortie possible :

Les principaux domaines généralement traités dans les accords avec les fournisseurs incluent :

✓ Les obligations de confidentialité, notamment le périmètre, la durée et les restrictions de divulgation à des tiers ;

✓ Les responsabilités de contrôle d’accès, par exemple qui peut accéder à vos données, comment les identifiants sont gérés et quelle surveillance est en place ;

✓ Les mesures techniques et organisationnelles de protection des données, de chiffrement, de transmission sécurisée, de sauvegarde et d’engagements de disponibilité ;

✓ Les délais et protocoles de notification des incidents, souvent avec des échéances définies ;

✓ Le droit d’audit, notamment la fréquence, le périmètre et l’accès aux éléments de preuve pertinents ;

✓ Les contrôles des sous-traitants, exigeant que votre fournisseur répercute des obligations de sécurité équivalentes à ses partenaires en aval ;

✓ Les dispositions de fin de contrat, telles que la restitution ou la destruction des données, la récupération des actifs et la désactivation des comptes.

Cette liste fait le lien entre les attentes contractuelles de DORA Article 30 et le contrôle A.5.20 de l’Annexe A ISO/IEC 27001:2022.

Le langage des politiques d’entreprise de Clarysec traduit ce principe de manière opérationnelle. Dans la Politique de gestion des risques de dépendance vis-à-vis des fournisseurs Politique de gestion des risques de dépendance vis-à-vis des fournisseurs, section « Exigences de mise en œuvre », clause 6.4.3, il est indiqué :

Solutions de secours techniques : assurer la portabilité et l’interopérabilité des données afin de soutenir la transition de service si nécessaire, par exemple au moyen de sauvegardes régulières dans des formats standard à partir d’un prestataire SaaS pour permettre la migration.

La même politique, clause 6.8.2, exige :

Un droit à l’assistance à la transition, sous forme de clause d’assistance à la sortie, lorsqu’un changement de prestataire est nécessaire, y compris la continuité du service pendant une période de transition définie.

Cette clause détermine souvent si une stratégie de sortie résiste à l’audit. Elle transforme la sortie d’un événement en rupture brutale en transition maîtrisée.

Pour les petites entités, la 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.6, exige :

Des conditions de résiliation, y compris la restitution sécurisée ou la destruction des données

Pour les environnements d’entreprise, la Politique de sécurité des tiers et des fournisseurs Politique de sécurité des tiers et des fournisseurs, section « Exigences de mise en œuvre de la politique », clause 6.5.1.2, exige :

La restitution ou la destruction certifiée de toutes les informations appartenant à l’organisation

Ces exigences de politique doivent être traçables directement vers les clauses contractuelles, les procédures fournisseurs, les runbooks de sortie et les éléments de preuve d’audit.

Sortie cloud : testez la portabilité avant d’en avoir besoin

Les services cloud sont le point où les stratégies de sortie DORA deviennent souvent floues. L’entreprise suppose qu’elle peut exporter les données, mais personne n’a testé le format. Elle suppose que la suppression aura lieu, mais le modèle de conservation du prestataire inclut des sauvegardes et du stockage répliqué. Elle suppose qu’un prestataire alternatif peut recevoir les données, mais les schémas, les intégrations d’identité, les clés de chiffrement, les secrets, les journaux, les interfaces de programmation (API) et les limitations de débit rendent la migration plus lente que ne le permet la tolérance d’impact.

Le contrôle A.5.23 de l’Annexe A ISO/IEC 27001:2022 traite ce problème de cycle de vie en exigeant des contrôles de sécurité de l’information pour l’acquisition, l’utilisation, la gestion et la sortie des services cloud.

La Politique d’utilisation du cloud – PME Politique d’utilisation du cloud – PME de Clarysec, section « Exigences de mise en œuvre de la politique », clause 6.3.4, exige :

La confirmation de la capacité d’export des données avant l’intégration, par exemple pour éviter l’enfermement propriétaire

La clause 6.3.5 exige :

La confirmation des procédures de suppression sécurisée avant la clôture du compte

Ces exigences relèvent du début du cycle de vie fournisseur. N’attendez pas la résiliation pour demander si les données peuvent être exportées. N’attendez pas la clôture du compte pour demander si des éléments de preuve de suppression existent.

Un test pratique de sortie cloud DORA doit inclure :

1. Exporter un jeu de données représentatif dans le format convenu.
2. Valider l’exhaustivité, l’intégrité, les horodatages, les métadonnées et les contrôles d’accès.
3. Importer le jeu de données dans un environnement de préproduction ou un outil alternatif.
4. Confirmer la gestion des clés de chiffrement et la rotation des secrets.
5. Confirmer l’export des journaux et la conservation de la piste d’audit.
6. Documenter les procédures de suppression du prestataire, y compris la conservation des sauvegardes et la certification de suppression.
7. Enregistrer les problèmes, les actions de remédiation, les propriétaires et les échéances.
8. Mettre à jour l’appréciation du risque fournisseur, la Déclaration d’applicabilité et le plan de sortie.

La portabilité n’est pas une promesse d’achat. C’est une capacité testée.

Un sprint d’une semaine pour un plan de sortie DORA prêt pour l’audit

Prenons l’exemple d’un établissement de paiement utilisant un prestataire SaaS d’analyse de fraude. Le prestataire ingère des données de transaction, des identifiants clients, des données de télémétrie des appareils, des signaux comportementaux, des règles de fraude, des scores de sortie et des notes de dossier. Le service soutient un processus critique de détection de la fraude. L’entreprise utilise également un entrepôt de données cloud pour stocker les résultats analytiques exportés.

Le RSSI souhaite une stratégie de sortie TIC DORA vis-à-vis de ce tiers capable de résister à l’audit interne et à la revue de supervision. Un sprint d’une semaine peut mettre en évidence les lacunes et construire la chaîne d’éléments de preuve.

Jour 1 : classifier le fournisseur et définir le scénario de sortie

À l’aide de Zenith Blueprint, phase Controls in Action, Étape 23, éléments d’action pour les contrôles 5.19 à 5.37, l’équipe commence par revoir et classifier le portefeuille fournisseurs :

Compilez une liste complète des fournisseurs et prestataires de services actuels (5.19), puis classez-les selon leur accès aux systèmes, aux données ou au contrôle opérationnel. Pour chaque fournisseur classifié, vérifiez que les attentes de sécurité sont clairement intégrées dans les contrats (5.20), y compris les obligations de confidentialité, d’accès, de notification des incidents et de conformité.

Le fournisseur est classifié comme critique parce qu’il soutient une fonction critique ou importante, traite des données opérationnelles sensibles et affecte les résultats de surveillance des transactions.

L’équipe définit trois déclencheurs de sortie :

• Insolvabilité du prestataire ou arrêt du service.
• Violation significative de la sécurité ou perte de confiance.
• Migration stratégique visant à réduire le risque de concentration.

Jour 2 : constituer l’inventaire des exigences et l’enregistrement du risque

L’équipe crée un inventaire unique des exigences couvrant le risque lié aux prestataires tiers TIC au titre de DORA, les contrôles fournisseurs et cloud ISO/IEC 27001:2022, les obligations GDPR relatives aux données à caractère personnel, les engagements contractuels clients et l’appétence au risque interne.

Au titre de GDPR, l’entreprise confirme si les identifiants de transaction, les identifiants d’appareils, les signaux de localisation et les analyses comportementales se rapportent à des personnes identifiées ou identifiables. Les principes de GDPR Article 5, notamment l’intégrité, la confidentialité, la limitation de la conservation et la responsabilité, deviennent une partie des exigences relatives aux éléments de preuve de sortie. Si la sortie implique un transfert vers un nouveau prestataire, la base légale, la finalité, la minimisation, la conservation, les clauses applicables au sous-traitant de traitement de données et les mesures de protection doivent être documentées.

L’enregistrement du risque comprend les éléments suivants :

Jour 3 : corriger les lacunes contractuelles

Les équipes juridique et achats comparent le contrat aux clauses fournisseurs de Clarysec. Elles ajoutent l’assistance à la transition, la continuité du service pendant une période de transition définie, l’accès aux éléments de preuve et aux audits, la notification des sous-traitants, le format d’export des données, la certification de suppression sécurisée, la coopération en cas d’incident et les engagements de délai de reprise.

La Politique de continuité d’activité et de reprise après sinistre Politique de continuité d’activité et de reprise après sinistre, section « Exigences de mise en œuvre de la politique », clause 6.5.1, indique :

Les contrats avec les fournisseurs critiques doivent inclure des obligations de continuité et des engagements de délai de reprise.

Pour les PME, la Politique de continuité d’activité et de reprise après sinistre – PME Politique de continuité d’activité et de reprise après sinistre – PME, section « Traitement des risques et exceptions », clause 7.2.1.4, exige des équipes qu’elles :

documentent les plans temporaires de substitution de fournisseurs ou de partenaires

Cette clause transforme « nous migrerons » en solution de secours actionnable : quel prestataire, quel contournement interne, quel processus manuel, quel extrait de données, quel propriétaire et quel circuit d’approbation.

Jour 4 : tester la portabilité des données et la capacité de récupération des sauvegardes

L’équipe technologique exporte les règles de fraude, les données de dossiers, les scores de transactions, les journaux, la configuration, la documentation des interfaces de programmation (API) et les listes de contrôle d’accès utilisateurs. Elle teste si les données peuvent être restaurées ou réutilisées dans un environnement maîtrisé.

La Politique de sauvegarde et de restauration – PME Politique de sauvegarde et de restauration – PME, section « Exigences de gouvernance », clause 5.3.3, exige :

Des tests de restauration sont réalisés au moins trimestriellement, et les résultats sont documentés afin de vérifier la capacité de récupération

La Politique de sauvegarde et de restauration Politique de sauvegarde et de restauration d’entreprise, section « Application et conformité », clause 8.3.1, ajoute :

Auditer périodiquement les journaux de sauvegarde, les paramètres de configuration et les résultats des tests

Dans Zenith Blueprint, phase Controls in Action, Étape 19, Contrôle 8.13, Clarysec explique pourquoi ce point est essentiel :

Les tests de restauration sont le domaine où la plupart des organisations échouent. Une sauvegarde qui ne peut pas être restaurée à temps, voire pas du tout, est un passif, pas un actif. Planifiez régulièrement des exercices de restauration, même partiels, et documentez le résultat.

L’équipe découvre que les notes de dossiers exportées n’incluent pas les pièces jointes et que les limitations de débit des API rendent un export complet trop lent pour l’objectif de reprise défini. Le problème est journalisé, attribué et corrigé par un avenant contractuel et une refonte technique de l’export.

Jour 5 : exécuter l’exercice sur table de sortie et la revue des éléments de preuve

L’équipe réalise un exercice sur table : le fournisseur annonce une résiliation dans 90 jours après un incident majeur. Les opérations doivent poursuivre la surveillance de la fraude pendant la migration des données.

Dans Zenith Blueprint, phase Controls in Action, Étape 23, Contrôle 5.30, Clarysec explique la norme de test :

La préparation des TIC commence bien avant qu’une perturbation ne survienne. Elle implique d’identifier les systèmes critiques, de comprendre leurs interdépendances et de les cartographier avec les processus opérationnels.

La même section ajoute :

Les objectifs de délai de reprise (RTO) et les objectifs de point de reprise (RPO) définis dans le plan de continuité d’activité doivent se refléter dans les configurations techniques, les contrats et la conception de l’infrastructure.

Le dossier d’éléments de preuve inclut la classification du fournisseur, l’appréciation des risques, les clauses contractuelles, le runbook de sortie, les résultats d’export des données, les éléments de preuve de restauration de sauvegarde, la procédure de suppression, l’évaluation d’un prestataire alternatif, les comptes rendus de l’exercice sur table, le journal de remédiation, l’approbation de la direction et la décision relative au risque résiduel.

Le RSSI peut désormais répondre à la question du conseil d’administration avec des éléments de preuve, et non avec de l’optimisme.

Conformité croisée : un plan de sortie, plusieurs lectures d’audit

Une stratégie de sortie DORA robuste réduit les travaux de conformité dupliqués entre ISO/IEC 27001:2022, NIS2, GDPR, NIST et les attentes de gouvernance COBIT 2019.

L’essentiel n’est pas qu’un cadre en remplace un autre. La valeur tient au fait qu’un SMSI bien construit permet à l’organisation de générer une fois les éléments de preuve et de les réutiliser intelligemment.

Zenith Controls de Clarysec aide les équipes à se préparer à ces lectures d’audit en reliant les contrôles ISO/IEC 27001:2022 aux éléments de preuve d’audit et aux attentes inter-cadres.

Une défaillance fréquente en audit est la fragmentation des éléments de preuve. Le responsable fournisseurs détient le contrat. L’IT détient les journaux de sauvegarde. La direction juridique détient l’accord de traitement des données. La fonction risques détient l’appréciation. La conformité détient la cartographie réglementaire. Personne ne détient l’histoire complète.

Clarysec résout ce problème en concevant le dossier d’éléments de preuve autour du scénario de sortie. Chaque document répond à une question d’audit : quel service fait l’objet de la sortie, pourquoi il est critique, quelles données et quels systèmes sont affectés, qui porte le risque, quels droits contractuels rendent la sortie possible, quels mécanismes techniques rendent la migration possible, quels dispositifs de continuité maintiennent l’activité, quel test prouve que le plan fonctionne, quels problèmes ont été corrigés et qui a approuvé le risque résiduel.

La checklist Clarysec pour les stratégies de sortie DORA

Utilisez cette checklist pour transformer une stratégie de sortie TIC DORA vis-à-vis des prestataires tiers d’un simple document en un ensemble de contrôles auditables.

Transformer la planification de sortie en contrôle de résilience prêt pour le conseil d’administration

Si votre stratégie de sortie DORA se limite à une clause contractuelle, elle n’est pas prête. Si votre sauvegarde n’a jamais été restaurée, elle n’est pas prête. Si votre prestataire cloud peut exporter les données mais que personne n’a validé leur exhaustivité, elle n’est pas prête. Si votre conseil d’administration ne peut pas voir la décision relative au risque résiduel, elle n’est pas prête.

Clarysec aide les RSSI, responsables conformité, auditeurs et propriétaires métier à élaborer des stratégies de sortie TIC DORA vis-à-vis des prestataires tiers qui sont pratiques, proportionnées et prêtes pour l’audit. Nous combinons Zenith Blueprint Zenith Blueprint pour l’ordonnancement de la mise en œuvre, Zenith Controls Zenith Controls pour la cartographie de conformité croisée, et des modèles de politiques tels que la Politique de gestion des risques de dépendance vis-à-vis des fournisseurs Politique de gestion des risques de dépendance vis-à-vis des fournisseurs, la Politique d’utilisation du cloud – PME Politique d’utilisation du cloud – PME, la Politique de sécurité des tiers et des fournisseurs – PME Politique de sécurité des tiers et des fournisseurs – PME et la Politique de continuité d’activité et de reprise après sinistre Politique de continuité d’activité et de reprise après sinistre afin de créer une chaîne complète reliant les contrôles aux éléments de preuve.

Votre prochaine étape est simple et à forte valeur : sélectionnez cette semaine un fournisseur TIC critique. Classifiez-le, revoyez son contrat, testez un export de données, vérifiez une restauration, documentez un plan de substitution et créez un dossier d’éléments de preuve.

Ce seul exercice montrera si votre stratégie de sortie DORA constitue une véritable capacité de résilience ou simplement un document destiné à échouer lors d’un audit.