Analyse d’impact sur l’activité pour ISO 27001, NIS2 et DORA

La question d’audit qui révèle la véritable lacune de continuité

Nous sommes lundi matin, et Maria, RSSI d’une FinTech en forte croissance, prépare une réunion du comité des risques du conseil d’administration. L’objet est bref : « Préparation DORA et NIS2 : revue de la BIA ».

Son équipe a constitué ce que la plupart des dirigeants s’attendent à voir. Il existe un SMSI certifié ISO/IEC 27001:2022, des procédures opérationnelles de réponse aux incidents, des captures d’écran de sauvegardes, des rapports de vulnérabilités, des questionnaires fournisseurs, des schémas d’architecture cloud et un registre des risques à jour. Les grands comptes envoient des questionnaires NIS2. Les clients du secteur financier intègrent des clauses DORA dans les contrats. L’audit de surveillance ISO/IEC 27001:2022 a lieu dans seulement un mois.

Puis l’auditeur externe pose la question qui change la dynamique de la salle :

« Si votre plateforme d’intégration client est indisponible pendant 18 heures, quels services réglementés sont affectés, quels fournisseurs sont impliqués, quelle est la priorité de reprise approuvée et où se trouvent les éléments de preuve attestant que l’entreprise a accepté le RTO et le RPO ? »

La salle se tait.

Le calendrier de sauvegarde indique une chose. Le plan de reprise après sinistre en indique une autre. Le contrat fournisseur inclut un accord de niveau de service (SLA) de disponibilité, mais aucun élément de preuve de test de reprise. Le registre des risques mentionne la disponibilité, mais n’explique pas pourquoi un service doit être rétabli plus vite qu’un autre. La direction a approuvé la politique de sécurité, mais pas l’impact métier de l’indisponibilité.

C’est le problème de l’analyse d’impact sur l’activité en 2026.

Une analyse d’impact sur l’activité, ou BIA, n’est plus une feuille de calcul annexée à un plan de continuité. Elle constitue le lien probant entre les services métier, les actifs TIC, les fournisseurs, les priorités de reprise, les RTO/RPO, les seuils d’incident, les tests de résilience et la responsabilité du conseil d’administration. Pour les organisations qui alignent ISO/IEC 27001:2022 avec la continuité NIS2 et la résilience TIC DORA, la BIA est le point où la conformité devient opérationnelle.

Les organisations les plus matures disposent déjà de nombreux contrôles appropriés. Leur faiblesse réside dans la traçabilité. La BIA transforme des éléments de preuve dispersés en un récit compatible avec les exigences d’audit : ce qui compte, pourquoi cela compte, sous quel délai cela doit être rétabli, quelles dépendances le soutiennent, ce qui a été testé, ce qui a échoué, ce qui a été amélioré et qui a approuvé le risque résiduel.

Pourquoi les anciennes feuilles de calcul BIA sont désormais un passif

NIS2 et DORA ont relevé le niveau d’exigence en matière de conformité de la continuité. Ils ne traitent pas la continuité d’activité, la reprise après sinistre, la réponse aux incidents, la résilience des fournisseurs et la gouvernance comme des documents séparés. Ils exigent que ces éléments fonctionnent comme un système unique.

Pour les entités NIS2, Article 21 exige des mesures techniques, opérationnelles et organisationnelles pour gérer les risques pesant sur les réseaux et les systèmes d’information, et pour prévenir ou réduire au minimum l’impact des incidents sur les destinataires des services et sur d’autres services. Les mesures minimales comprennent l’analyse des risques, la gestion des incidents, la continuité d’activité incluant la gestion des sauvegardes, la reprise après sinistre et la gestion de crise, la sécurité de la chaîne d’approvisionnement, le traitement des vulnérabilités, l’évaluation de l’efficacité des contrôles, la formation, la cryptographie, la sécurité des ressources humaines, le contrôle d’accès, la gestion des actifs, l’authentification multifacteur (MFA) et les communications sécurisées.

NIS2 Article 20 place le sujet au niveau du conseil d’administration. Les organes de direction doivent approuver les mesures de gestion des risques de cybersécurité, en superviser la mise en œuvre et peuvent être tenus responsables en cas de manquement. Un RTO de quatre heures non étayé n’est donc pas seulement une incohérence technique. C’est une faiblesse de gouvernance.

DORA s’applique depuis le 17 janvier 2025 et crée un cadre uniforme de l’UE pour la gestion des risques TIC, le signalement des incidents, les tests de résilience opérationnelle numérique, la gestion des risques liés aux prestataires tiers de services TIC, les exigences contractuelles et la supervision des prestataires tiers critiques de services TIC. Pour les entités financières, et pour les fournisseurs technologiques qui les soutiennent contractuellement, DORA transforme la résilience opérationnelle en exigence structurée d’éléments de preuve.

DORA Articles 5 et 6 exigent une gouvernance et un cadre documenté de gestion des risques TIC. Les Articles 7 à 14 couvrent les systèmes TIC fiables et résilients, l’identification des actifs et des dépendances, la protection, la détection, la continuité d’activité TIC, la sauvegarde, la restauration, le rétablissement, le retour d’expérience post-incident, la sensibilisation, la formation et la communication de crise. Les Articles 24 à 26 imposent des tests de résilience opérationnelle numérique aux entités financières autres que les microentreprises. Les Articles 28 à 30 formalisent le risque lié aux prestataires tiers TIC, les registres des contrats de services TIC, les stratégies de sortie, les niveaux de service, les droits d’audit et d’accès, ainsi que les exigences de continuité.

ISO/IEC 27001:2022 fournit l’ossature du système de management. Ses clauses imposent à l’organisation de définir le contexte, les parties intéressées, les obligations légales et contractuelles, le domaine d’application, le leadership, la politique, les rôles, l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité, la planification opérationnelle, l’évaluation des performances et l’amélioration continue.

Le maillon manquant est souvent la BIA. Sans elle, les plans de continuité ne sont pas clairement fondés sur les risques, les objectifs de sauvegarde ne sont pas approuvés par les métiers, les fournisseurs ne sont pas reliés aux services critiques et la direction ne peut pas démontrer de manière fiable que les décisions de résilience ont été éclairées par l’impact métier.

La BIA comme plan de contrôle des éléments de preuve de résilience

Une BIA défendable répond à sept questions que les auditeurs, autorités de régulation, clients et conseils d’administration posent de plus en plus :

1. Quels services métier sont critiques ?
2. Quels actifs TIC, référentiels de données, personnes, fournisseurs et services généraux soutiennent chaque service ?
3. Quel est l’impact opérationnel, financier, juridique, contractuel, client, sécurité des personnes et réputationnel d’une interruption au fil du temps ?
4. Quelle est la durée maximale admissible d’interruption, ou MTD ?
5. Quels sont l’objectif de temps de reprise approuvé, ou RTO, et l’objectif de point de reprise, ou RPO ?
6. Les dispositifs de sauvegarde, de redondance, de cloud, de fournisseurs, de dotation et de communication rendent-ils ces objectifs atteignables ?
7. L’organisation a-t-elle testé le chemin de reprise et revu les résultats ?

La Politique de continuité d’activité et de reprise après sinistre d’entreprise de Clarysec P32 Politique de continuité d’activité et de reprise après sinistre énonce clairement l’exigence :

L’analyse d’impact sur l’activité (BIA) doit être réalisée au moins une fois par an pour toutes les unités métier critiques et revue en cas de changements significatifs affectant les systèmes, processus ou dépendances. Les résultats de la BIA doivent définir : 5.2.1. Durée maximale admissible d’interruption (MTD) 5.2.2. Objectifs de temps de reprise (RTO) 5.2.3. Objectifs de point de reprise (RPO) 5.2.4. Dépendances critiques (systèmes, fournisseurs, personnel)

Cette clause donne aux auditeurs un point de départ pratique. Elle évite également l’échec courant où le plan de continuité d’activité, le plan de reprise après sinistre, le calendrier de sauvegarde, le registre des fournisseurs et le processus de réponse aux incidents utilisent chacun une définition différente de « critique ».

La même politique exige une approche de management intégrée :

L’organisation doit maintenir un système de management de la continuité d’activité (BCMS) intégré, aligné sur ISO 22301 et ISO/IEC 27001, assurant l’intégration des éléments suivants : 5.1.1. Analyse d’impact sur l’activité (BIA) 5.1.2. Appréciation des risques de sécurité pour les menaces pesant sur la continuité 5.1.3. Plans de continuité d’activité (PCA) 5.1.4. Plans de reprise après sinistre TIC (DRP) 5.1.5. Programmes de tests et d’exercices 5.1.6. Documentation et amélioration continue

C’est la différence entre une conformité par liste de contrôle et une résilience compatible avec les exigences d’audit. La BIA n’est pas un document ponctuel. Elle devient une composante de la chaîne d’éléments de preuve du SMSI et du BCMS.

Comment ISO/IEC 27001:2022 transforme la BIA en éléments de preuve vérifiables en audit

ISO/IEC 27001:2022 n’impose pas à chaque organisation d’utiliser l’expression « analyse d’impact sur l’activité » dans chaque clause, mais ses exigences rendent les éléments de preuve BIA extrêmement utiles.

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 réglementaires, les exigences contractuelles, les interfaces, les dépendances et le domaine d’application du SMSI. Une BIA est souvent l’élément de preuve le plus pratique pour ces interfaces et dépendances. Elle montre quel service cloud, prestataire de paiement, fournisseur d’identité, opérateur télécom, service managé de sécurité, centre de données ou équipe de support externalisée permet de délivrer un service critique.

Les clauses 5.1 à 5.3 exigent le leadership de la direction, l’allocation de ressources, la communication, l’attribution des rôles et le reporting. Une BIA donne à la direction une base métier pour les investissements de continuité. Sans elle, les objectifs RTO et RPO sont des souhaits techniques, pas des exigences métier approuvées.

Les clauses 6.1.1 à 6.1.3 exigent une appréciation et un traitement des risques de sécurité de l’information répétables. L’organisation doit identifier les risques pesant sur la confidentialité, l’intégrité et la disponibilité, analyser les conséquences et la vraisemblance, déterminer les niveaux de risque, prioriser le traitement, sélectionner les contrôles, comparer les contrôles sélectionnés avec l’Annexe A, produire une Déclaration d’applicabilité, créer un plan de traitement des risques et obtenir l’approbation du propriétaire du risque. Une BIA renforce le volet « conséquences » de l’appréciation des risques. Elle explique pourquoi une indisponibilité de deux heures d’un système est tolérable, alors que la même durée pour un autre système entraîne un préjudice client, une exposition réglementaire, une violation contractuelle ou un impact sévère sur le chiffre d’affaires.

L’Annexe A fournit le catalogue des contrôles. Pour la BIA et la continuité, les contrôles de l’Annexe A ISO/IEC 27001:2022 les plus pertinents sont notamment :

Dans Zenith Controls : le guide de conformité transverse Zenith Controls, Clarysec présente le contrôle ISO/IEC 27002:2022 5.30, préparation des TIC à la continuité d’activité, comme un contrôle correctif centré sur la disponibilité, rattaché à la fonction cybersécurité Respond, à la capacité opérationnelle de continuité et au domaine de sécurité de la résilience. Le contrôle 5.29, sécurité de l’information pendant une perturbation, est présenté comme préventif et correctif, protégeant la confidentialité, l’intégrité et la disponibilité. Le contrôle 8.13, sauvegarde de l’information, est présenté comme correctif, soutenant l’intégrité et la disponibilité par la reprise.

Cette distinction est essentielle. Une BIA ne doit pas seulement demander : « Pouvons-nous restaurer ? » Elle doit aussi demander : « Pouvons-nous rester sécurisés pendant une perturbation ? » Lors d’un événement de rançongiciel, d’une panne cloud, d’une défaillance fournisseur ou d’un incident de centre de données, l’organisation a toujours besoin de contrôle d’accès, de journalisation, de surveillance, de conservation des éléments de preuve, de communications sécurisées et de mesures de protection de la vie privée.

Le modèle pratique d’éléments de preuve BIA

Une BIA solide relie le langage métier aux éléments probants techniques. Clarysec structure généralement le modèle d’éléments de preuve en cinq couches.

Ce modèle d’éléments de preuve fonctionne parce qu’il suit la logique des auditeurs. Ils demandent d’abord ce qui est critique. Ils demandent ensuite ce qui le soutient. Puis ils demandent qui a approuvé l’objectif de reprise. Ils vérifient ensuite si les dispositifs techniques et fournisseurs permettent d’atteindre cet objectif. Enfin, ils demandent si l’organisation a testé et amélioré la capacité.

NIST CSF 2.0 est utile comme couche de communication. Sa méthode de profils CSF encourage les organisations à définir le périmètre, collecter des intrants tels que les politiques, les priorités de risque de l’organisation, les registres BIA, les exigences de cybersécurité, les normes, les procédures, les mesures de protection et les rôles métier, créer des profils actuel et cible, analyser les écarts, produire un plan d’action priorisé, mettre en œuvre ce plan et actualiser le profil. C’est presque exactement la manière dont une BIA doit alimenter une feuille de route de conformité transverse.

Un exercice BIA d’une semaine qui crée de véritables éléments de preuve

Supposons qu’un prestataire SaaS soutienne des clients de services financiers. Sa plateforme prend en charge l’intégration des clients, la vérification documentaire et les notifications clients. Il n’est pas lui-même une banque, mais ses clients envoient des demandes contractuelles liées à DORA et des questionnaires fournisseurs NIS2.

Un exercice ciblé d’une semaine peut produire rapidement des éléments de preuve utiles.

Jour 1 : identifier les services critiques et les fenêtres d’impact

Commencez par les services, pas par les serveurs. Impliquez les propriétaires métier, l’informatique, la sécurité, le juridique, le support, la Protection des données et la gestion des fournisseurs.

Ce cadrage est important. Les autorités de régulation et les clients reconnaissent les services et les fonctions. Les applications comptent parce qu’elles soutiennent ces services.

Jour 2 : cartographier les dépendances

Pour chaque service, cartographiez les applications, bases de données, infrastructures, services cloud, fournisseurs d’identité, dispositifs de surveillance, outils de sauvegarde, personnes, fournisseurs et services généraux de soutien.

C’est ici que la BIA commence à produire de la valeur. Elle révèle le chemin de reprise invisible, y compris les dépendances souvent omises dans un plan technique de reprise après sinistre.

Jour 3 : approuver la MTD, le RTO et le RPO

Le propriétaire métier propose la MTD. L’informatique et la sécurité valident si les RTO et RPO proposés sont techniquement atteignables. La direction approuve les objectifs finaux.

Pour les petites organisations, la Politique de continuité d’activité et de reprise après sinistre - PME de Clarysec P32S Politique de continuité d’activité et de reprise après sinistre - PME apporte la même discipline dans un langage plus simple. Elle exige des plans PCA/DRP qui définissent l’approche de rétablissement des fonctions essentielles :

Le Directeur général (DG) doit approuver et maintenir des plans de continuité d’activité et de reprise après sinistre (PCA/DRP) qui définissent clairement l’approche de l’organisation pour rétablir les fonctions essentielles.

Elle exige également que le plan inclue :

les services et systèmes priorisés (fonctions métier critiques)

Et :

les objectifs de temps de reprise (RTO) et les objectifs de point de reprise (RPO) pour chaque système

L’enjeu n’est pas de produire une documentation excessive. L’enjeu est la traçabilité, l’approbation et les éléments de preuve montrant que les objectifs de reprise reposent sur un impact métier réel.

Jour 4 : réconcilier les sauvegardes avec l’impact métier

De nombreuses organisations échouent ici. La BIA peut fixer un RPO de quatre heures alors que les sauvegardes s’exécutent toutes les 24 heures. Ou l’outil de sauvegarde protège les bases de données de production, mais pas la configuration, les secrets, les référentiels d’infrastructure-as-code, le stockage objet, les enregistrements DNS, les paramètres d’identité ou la configuration de la passerelle API.

La Politique de sauvegarde et de restauration de Clarysec P15 Politique de sauvegarde et de restauration exige un calendrier maître de sauvegarde relié aux résultats de la BIA :

Un calendrier maître de sauvegarde doit être maintenu et revu annuellement. Il doit préciser : 5.1.1 La fréquence des sauvegardes (par exemple, sauvegardes incrémentales quotidiennes et sauvegardes complètes hebdomadaires) 5.1.2 Les périodes de conservation par système ou type de données 5.1.3 Les exigences de chiffrement et les détails d’emplacement de stockage 5.1.4 Les objectifs RTO/RPO reliés aux résultats de l’analyse d’impact sur l’activité

Cette clause est précieuse en audit. Elle impose que la conception des sauvegardes reflète l’impact métier, et non la seule commodité de stockage.

Jour 5 : tester un chemin de reprise et ouvrir des actions correctives

Ne testez pas tout en une fois. Choisissez un service critique et exécutez un test de reprise ciblé. Restaurez la base de données. Reconstruisez la configuration applicative. Validez l’authentification. Confirmez que les journaux sont disponibles. Vérifiez la capacité de notification client. Consignez le temps écoulé, la perte de données, les défauts, les décisions et les actions correctives.

Dans Zenith Blueprint : feuille de route d’audit en 30 étapes Zenith Blueprint, la phase Contrôles en action, étape 23, traite des contrôles organisationnels, notamment la préparation des TIC à la continuité d’activité. Elle pose la question que toute équipe d’audit devrait poser :

Vos systèmes peuvent-ils soutenir vos objectifs de continuité d’activité lorsque les lumières vacillent, que les réseaux tombent ou qu’un sinistre survient ?

La même étape donne une instruction pratique :

Vérifiez que les objectifs de temps de reprise (RTO) et les objectifs de point de reprise (RPO) des systèmes critiques sont alignés sur les attentes de continuité d’activité (5.30). Réalisez au moins un test technique de reprise ou une simulation de basculement et documentez les résultats.

C’est la différence entre disposer d’une BIA et disposer d’éléments de preuve BIA défendables. L’objectif n’est pas seulement documenté. Il est testé.

Cartographier les éléments de preuve BIA vers NIS2, DORA, GDPR, NIST et COBIT 2019

Une BIA bien construite devient un actif de conformité transverse. Un même ensemble d’éléments de preuve peut répondre à de nombreuses questions.

GDPR est souvent négligé dans les discussions BIA. Pourtant, GDPR Article 5 exige que les données à caractère personnel soient traitées avec intégrité et confidentialité, notamment protégées contre la perte, la destruction ou les dommages accidentels au moyen de mesures techniques ou organisationnelles appropriées. La responsabilité impose au responsable du traitement de démontrer la conformité. Si une plateforme de données à caractère personnel ne peut pas être restaurée dans un délai approuvé et testé, le risque pour la vie privée affecte la disponibilité, l’intégrité, l’évaluation des violations et la confiance des clients.

Le signalement des incidents NIS2 ajoute une autre dimension. Article 23 exige que les incidents significatifs soient notifiés sans retard indu, avec notamment une alerte précoce dans les 24 heures, une notification d’incident dans les 72 heures et un rapport final dans le mois. Une BIA aide à classer la gravité parce qu’elle définit les services affectés, les destinataires des services, la perturbation opérationnelle et l’impact transfrontalier potentiel.

La classification des incidents DORA prend également en compte les clients ou transactions affectés, la durée, l’étendue géographique, les pertes de données, la criticité des services affectés et l’impact économique. Ce sont des champs BIA. Si la BIA est faible, la classification des incidents devient subjective au pire moment possible.

La continuité des fournisseurs : le point de rencontre entre la BIA et la réalité contractuelle

Pour NIS2 et DORA, la continuité des fournisseurs n’est plus optionnelle. NIS2 Article 21 inclut la sécurité de la chaîne d’approvisionnement et exige de prendre en compte les vulnérabilités des fournisseurs, la qualité et la résilience des produits, les pratiques de cybersécurité des fournisseurs et les procédures de développement sécurisé. DORA exige que le risque lié aux prestataires tiers TIC soit géré dans le cadre de gestion des risques TIC, notamment au moyen de registres des contrats de services TIC, de diligences préalables, de la gestion du risque de concentration, de stratégies de sortie, de droits d’audit et d’accès, d’assistance en cas d’incident, de niveaux de service et d’exigences de continuité.

La Politique de continuité d’activité et de reprise après sinistre d’entreprise exige :

Dépendances vis-à-vis des tiers et de la chaîne d’approvisionnement 6.5.1. Les contrats avec les fournisseurs critiques doivent inclure des obligations de continuité et des engagements de temps de reprise. 6.5.2. Les prestataires de services clés doivent, sur demande, démontrer la réalisation de tests périodiques de continuité et leur participation aux exercices d’incident.

La version PME exige également :

des points de contact de continuité fournisseur

Ce petit champ peut être décisif lors d’un incident réel. Si votre plan de reprise indique « contacter le support du fournisseur cloud », mais que personne ne connaît le circuit d’escalade, la référence contractuelle, le processus de qualification de la gravité ou le contact hors heures ouvrées, le RTO est fictif.

Ce tableau ne remplace pas la gestion du risque fournisseur. Il rend le risque fournisseur opérationnel.

Comment les auditeurs testeront votre BIA

Un auditeur ISO/IEC 27001:2022 commencera généralement par le domaine d’application, le contexte, l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité, les contrôles de l’Annexe A, les informations documentées, la planification opérationnelle, l’évaluation des performances et l’amélioration. Il comparera la BIA à l’appréciation des risques et à la SoA. Si A.5.30, A.5.29 ou A.8.13 sont inclus, il demandera des éléments de preuve de mise en œuvre et de tests.

Un examinateur DORA se concentrera sur les fonctions critiques ou importantes, les actifs TIC, les dépendances vis-à-vis de prestataires tiers TIC, les tests de résilience, la classification des incidents, les exigences contractuelles, les stratégies de sortie et la supervision par l’organe de direction. Il attendra que la BIA soit alignée sur le cadre de gestion des risques TIC, la stratégie de résilience opérationnelle numérique, les plans de continuité d’activité TIC, les plans de réponse et de rétablissement et le programme de tests.

Un superviseur NIS2 demandera les mesures de continuité d’activité, la gestion des sauvegardes, la reprise après sinistre, la gestion de crise, la sécurité de la chaîne d’approvisionnement, l’approbation de la gouvernance et la capacité de signalement des incidents significatifs. La BIA doit prouver que ces mesures reposent sur l’impact des services et sur des priorités approuvées.

Un évaluateur NIST CSF 2.0 demandera comment la BIA alimente le profil actuel, le profil cible, l’analyse des écarts et le plan d’action. Il examinera les résultats Govern relatifs aux décisions juridiques, réglementaires, contractuelles, de risque, de rôle, de politique, de supervision et de risque fournisseur. Il examinera également les résultats Identify, Protect, Detect, Respond et Recover.

Un auditeur COBIT 2019 ou de type ISACA se concentrera généralement sur la gouvernance. Qui est propriétaire du service ? Qui a accepté le risque ? Les objectifs sont-ils alignés sur les objectifs de l’entreprise ? Les fournisseurs sont-ils surveillés ? Les bénéfices, les risques et les ressources sont-ils équilibrés ? Les actions correctives sont-elles suivies jusqu’à clôture ?

La Politique d’audit et de surveillance de la conformité de Clarysec Politique d’audit et de surveillance de la conformité intègre la BIA dans le cycle de planification d’audit :

Un plan d’audit fondé sur les risques doit être élaboré et approuvé annuellement, en tenant compte : 5.2.1 Des résultats des appréciations des risques les plus récentes et de l’analyse d’impact sur l’activité (BIA) 5.2.2 Des constats d’audit précédents et du statut des actions correctives 5.2.3 Des changements dans les processus, l’infrastructure informatique, les systèmes ou les fournisseurs 5.2.4 Des obligations externes telles que DORA Article 25 ou les contrats clients

C’est une étape de maturité que de nombreuses organisations négligent. La BIA ne doit pas rester en dehors de l’assurance. Elle doit piloter le plan d’audit.

Défaillances BIA courantes observées lors d’évaluations réelles

Les mêmes faiblesses apparaissent régulièrement.

Premièrement, la BIA liste des applications, et non des services. Les clients et les autorités de régulation s’intéressent à la perturbation des services. Les applications comptent parce qu’elles soutiennent ces services.

Deuxièmement, les objectifs RTO et RPO sont copiés depuis des modèles. Un RTO de quatre heures peut sembler raisonnable jusqu’à ce qu’un test de restauration montre qu’il faut neuf heures pour reconstruire l’intégration d’identité, récupérer la configuration, restaurer les données, valider l’intégrité et réactiver la surveillance.

Troisièmement, les sauvegardes ne sont pas reliées à l’impact métier. La fréquence, la conservation, le chiffrement, l’emplacement de stockage, la priorité de restauration et les tests doivent refléter les objectifs de reprise approuvés.

Quatrièmement, les fournisseurs sont traités comme des éléments de questionnaire, et non comme des dépendances de reprise. Les engagements de continuité fournisseur, les contacts d’escalade, les éléments de preuve de reprise et la participation aux exercices d’incident doivent être rattachés aux services critiques.

Cinquièmement, l’approbation de la direction est absente. Sous NIS2 et DORA, la responsabilité de la direction est explicite. Sous ISO/IEC 27001:2022, le leadership, les rôles, l’approbation du propriétaire du risque et le reporting de performance sont des exigences centrales.

Sixièmement, les tests sont trop étroits. Restaurer un fichier est utile, mais cela ne prouve pas la reprise d’un service. Le chemin de reprise d’un service critique peut inclure DNS, l’identité, les secrets, l’infrastructure-as-code, les passerelles API, la surveillance, la journalisation, l’escalade fournisseur, la communication client et la revue Protection des données.

Le Zenith Blueprint, dans la phase Contrôles en action, étape 19, résume l’attente d’audit relative aux sauvegardes :

Testez-vous vos sauvegardes ?

La réponse doit être « oui, avec éléments de preuve », et ces éléments de preuve doivent être reliés à la BIA.

Le dossier d’éléments de preuve BIA prêt pour audit

Un programme BIA pratique doit produire un dossier d’éléments de preuve concis pouvant être utilisé pour les audits, les diligences clients, le reporting au conseil d’administration et l’amélioration de la résilience.

Ce dossier raconte une histoire cohérente. Il rend également la résilience mesurable.

Prochaine étape : transformer votre BIA en éléments de preuve de conformité

Maria n’a pas besoin d’une feuille de calcul plus volumineuse. Elle a besoin d’une chaîne d’éléments de preuve vivante.

Commencez par un service critique. Cartographiez ses actifs TIC, données, personnes, fournisseurs et services généraux. Approuvez la MTD, le RTO et le RPO. Réconciliez le calendrier de sauvegarde. Vérifiez les engagements de reprise des fournisseurs. Exécutez un test de reprise. Consignez les lacunes. Mettez à jour le plan de traitement des risques. Présentez le résultat à la direction.

Puis répétez.

Clarysec peut accélérer ce processus au moyen de la Politique de continuité d’activité et de reprise après sinistre, de la Politique de continuité d’activité et de reprise après sinistre - PME, de la Politique de sauvegarde et de restauration, de la Politique d’audit et de surveillance de la conformité, de Zenith Blueprint et de Zenith Controls.

Votre BIA ne doit pas être un document de placard créé pour un audit. Elle doit constituer la preuve opérationnelle que vos services les plus importants peuvent résister à une perturbation, satisfaire les attentes des clients et des autorités de régulation, et être rétablis dans les limites effectivement approuvées par votre direction.

Si votre organisation se prépare à un audit de surveillance ISO/IEC 27001:2022, à une assurance client NIS2, à des revues DORA de prestataires tiers TIC ou à un reporting de résilience au niveau du conseil d’administration, commencez par rendre la BIA défendable. Téléchargez les politiques de continuité et d’audit de Clarysec, consultez la feuille de route de mise en œuvre Zenith ou demandez une évaluation des éléments de preuve de résilience afin de transformer des contrôles dispersés en un récit unique compatible avec les exigences d’audit.