La continuité des activités assure le maintien des activités critiques de l'organisation en cas de perturbation. La reprise après sinistre restaure les technologies dont dépendent ces activités. Il ne s'agit pas d'approches concurrentes ni d'un seul et même document. La continuité est une discipline métier qui détermine ce qui doit rester opérationnel et comment. La reprise après sinistre est une discipline technique qui reconstruit les systèmes selon un ordre précis, en fonction des objectifs fixés par l'entreprise.
- Responsabilités différentes : la continuité relève généralement des opérations ou de la gestion des risques, la reprise d’activité du service informatique.
- Différents déclencheurs : la continuité s’active en cas d’impact sur l’activité, la reprise en cas de panne technique.
- Différentes définitions du succès : poursuite des travaux versus systèmes rétablis.
- Un seul ensemble de chiffres, tous deux issus de la même analyse d'impact sur l'activité.
- Les défaillances se produisent à la jonction entre eux, et non à l'intérieur de l'un ou l'autre.
En quoi la continuité des activités et la reprise après sinistre diffèrent-elles réellement ?
Interrogez la plupart des gens sur la continuité des activités par rapport à la reprise après sinistre, et la réponse sera souvent une question de périmètre : la continuité est globale, la reprise est technique. C’est vrai, mais cela s’avère peu utile pour déterminer qui rédige quoi. Une distinction plus pertinente consiste à définir les responsabilités de chaque discipline et ses sources d’information.
Un plan de continuité d'activité part des activités. Il s'agit d'identifier les activités essentielles à l'organisation, la durée d'interruption admissible avant que les conséquences ne deviennent graves, et les solutions de rechange à mettre en œuvre pendant ce temps. Il aboutit à un ensemble de décisions relatives aux priorités et aux solutions de contournement.
Un plan de reprise d'activité (PRA) part des systèmes. Il détermine ce qui doit être remis en service, et dans quel ordre, afin de respecter les délais de continuité convenus. Son résultat est un manuel d'exploitation. La vision d'ensemble de la manière dont ces éléments s'intègrent au sein d'une capacité unique est présentée dans la section consacrée à la continuité d'activité.
| Continuité de l'activité | Reprise après sinistre | |
|---|---|---|
| À qui appartient-il? | Un responsable des opérations, des risques ou de la continuité des activités, avec le soutien de la direction. | L'équipe informatique ou infrastructure est souvent la même qui gère la plateforme au quotidien. |
| Qu'est-ce qui le déclenche ? | L'impact sur l'activité atteint un seuil critique, quelle qu'en soit la cause, y compris les causes sans composante technique. | Une panne technique ou la perte d'un système, d'un site ou d'un ensemble de données. |
| Que signifie récupéré | Les activités essentielles sont à nouveau assurées aux clients, par tout moyen acceptable. | Les systèmes mentionnés sont opérationnels, accessibles et leur intégrité des données a été vérifiée. |
| D'où viennent les objectifs ? | L'analyse d'impact sur l'activité, validée par les personnes responsables de chaque activité. | Hérité de la continuité. La reprise ne fixe pas ses propres objectifs. |
| Ce que les auditeurs demandent | Preuves d'exercices impliquant l'entreprise et que les priorités reflètent les opérations actuelles. | Preuves de tests de restauration avec leurs résultats, et que les sauvegardes sont effectivement récupérables. |
| Le coût d'une erreur | Les travaux s'arrêtent alors même que les systèmes fonctionnent correctement, car personne n'a approuvé la méthode manuelle. | Les systèmes redémarrent dans un ordre qui fait que l'activité critique attend le plus longtemps. |
À qui appartient chaque plan, et pourquoi cela pose-t-il problème ?
La séparation des responsabilités est judicieuse. Les personnes qui connaissent les engagements clients essentiels ne sont pas celles qui connaissent la procédure de restauration d'un cluster de bases de données. Le problème ne réside pas dans la séparation elle-même, mais dans le fait que les deux parties travaillent souvent de manière isolée et ne découvrent l'incohérence qu'en cas d'incident.
Trois schémas se répètent. Le premier est un plan de reprise dont les objectifs n'ont fait l'objet d'aucun consensus au sein de l'entreprise, généralement définis en fonction des capacités de l'infrastructure plutôt que des besoins réels de l'activité. Le deuxième est un plan de continuité qui repose sur une solution de contournement manuelle, laquelle dépend implicitement du système défaillant. Le troisième est le plus fréquent : les deux plans existent, les deux sont techniquement valides, et aucun ne précise qui déclare un incident ni qui décide du retour à la normale.
La solution n'est pas une fusion. Il s'agit d'une interface définie : des objectifs partagés issus de l' analyse d'impact sur l'activité , une autorité unique pour déclencher et annuler une action, et un exercice conjoint au moins une fois par an où les deux parties sont présentes.
Il y a un enjeu plus important derrière tout cela.
Cette page aborde un aspect de la résilience des entreprises. Real Resilience — le cadre d'IO qui relie la sécurité, la confidentialité et la gouvernance de l'IA — offre une vision d'ensemble.
Où se fait le passage de relais entre les deux ?
La plupart des analyses post-incident qui mettent en cause un plan décrivent en réalité une transition qui n'a jamais été définie. La continuité et la reprise d'activité se déroulent en parallèle, et non successivement, et se rejoignent à quatre moments clés : la décision de déclencher le plan, le choix des actions à entreprendre pendant l'indisponibilité des systèmes, le moment où la technologie est déclarée de nouveau utilisable et la confirmation que l'activité est réellement rétablie et non simplement reconnectée.
Notez où commence la séquence. La détection est presque toujours technique, ce qui explique pourquoi tant d'organisations traitent l'incident comme un simple problème informatique et impliquent les métiers trop tard. Au moment où une décision de continuité d'activité s'impose, la fenêtre d'opportunité pour une solution de contournement efficace est souvent déjà fermée.
Que se passe-t-il durant les premières 24 heures ?
Les deux plans sont actifs simultanément, mais accomplissent des tâches différentes. Le fait de l'indiquer clairement constitue la page la plus importante des deux documents, car elle élimine toute attente quant à l'ordre d'action.
| Stage | La continuité est en train de se faire | La récupération se fait |
|---|---|---|
| Première heure | Déterminer quelles activités sont concernées et confirmer qui est habilité à invoquer cette autorité. | Déterminer l'étendue du problème, isoler la panne et vérifier si les sauvegardes sont intactes. |
| Deux à quatre heures | Mettre en place cette méthode de travail alternative et en informer le personnel et les clients. | Décider s'il faut réparer sur place ou basculer, et lancer la restauration. |
| De quatre à douze heures | Maintenir l'équipe en place pour assurer la continuité des opérations et suivre l'accumulation des tâches non effectuées. | Restauration dans l'ordre des dépendances et vérification des données au fur et à mesure du retour de chaque couche. |
| De douze à vingt-quatre heures | Gérer la fatigue, les passations de consignes et l'accumulation croissante de tâches que la solution de contournement ne peut absorber. | Récupérer les applications restantes et les tester sur des transactions réelles. |
| Au-delà de vingt-quatre heures | Décider du moment opportun pour se retirer, puis résorber l'arriéré par ordre de priorité. | Confirmation du service complet, rapprochement des données enregistrées pendant la mise en place de la solution de contournement. |
C’est à la dernière étape que la plupart des plans s’arrêtent, contrairement à la plupart des incidents réels. Le travail effectué manuellement doit ensuite être intégré aux systèmes, et un retard traité dans le mauvais ordre peut engendrer une seconde perturbation.
Avez-vous besoin des deux, ou un seul document suffit-il ?
Les petites organisations utilisent souvent un seul document, ce qui peut suffire pour une structure vraiment réduite. L'important n'est pas la taille, mais la capacité des deux publics à trouver rapidement les informations nécessaires, même sous pression. Un ingénieur qui restaure une base de données à trois heures du matin ne devrait pas avoir à consulter les communications clients, et un responsable des opérations qui met en place un processus manuel ne devrait pas être en train de parcourir les instructions de basculement. Le contenu du document de continuité, ainsi que la provenance des informations de chaque section, sont détaillés dans le plan de continuité d'activité.
Dès lors que l'un ou l'autre public a besoin de plus d'une ou deux pages, séparez les documents et assurez-vous qu'ils comportent des renvois. Les chiffres ne doivent jamais être dupliqués. Si le délai de reprise figure dans les deux documents et qu'ils divergent, les plans se contrediront précisément au moment où cela est le plus critique. Définissez les objectifs une seule fois, dans l'analyse d'impact, et faites-y référence partout ailleurs. Le détail du document technique est traité dans le plan de reprise après sinistre , et le niveau de scénario sous-jacent se trouve dans vos plans de contingence.
Si votre intérêt ici est spécifique au cadre, la comparaison avec un audit SOC 2 est traitée séparément dans ce que le SOC 2 exige en matière de continuité et de reprise.
Quelles normes couvrent chacune d'elles ?
Cette distinction apparaît dans les normes elles-mêmes, ce qui permet de vérifier la cohérence de leur portée. L'ISO 22301 spécifie un système de management de la continuité d'activité : il est certifiable et porte sur la capacité organisationnelle. L'ISO/IEC 27031 couvre la préparation des technologies de l'information et de la communication (TIC) pour la continuité d'activité, soit la couche de reprise. L'ISO 27001 les relie par l'Annexe A, où le contrôle 5.29 traite de la sécurité de l'information en cas de perturbation et le contrôle 5.30 de la préparation des TIC.
Le respect de ces normes ne fusionne pas les deux disciplines, mais il impose l'existence d'une interface. Un système de gestion doit démontrer que la préparation technique sert les priorités de l'entreprise, et c'est précisément ce point faible qui pose problème lorsque personne n'est tenu de le prouver.
La norme ISO 27001 simplifiée
Une avance de 81 % dès le premier jour
Nous avons fait le plus gros du travail pour vous, en vous offrant une avance de 81 % dès votre connexion. Il ne vous reste plus qu'à remplir les champs.
Quel rôle joue ce duo dans la résilience des entreprises ?
La continuité et la reprise répondent toutes deux à la même question : que se passe-t-il lorsqu’un système tombe en panne ? La résilience, quant à elle, répond à une question plus large. Il s’agit de la capacité à absorber tout type de changement, y compris les perturbations imprévues et les obligations qui n’existaient pas au moment de leur définition. Ces deux notions sont des composantes de la résilience, et non des substituts.
La boucle de résilience intègre la sécurité de l'information ( ISO 27001) , la protection des données ( ISO 27701) et la gouvernance de l'IA ( ISO 42001) au sein d'un système unique et interconnecté. La continuité et la reprise d'activité reposent sur les mêmes contrôles, offrant ainsi une perspective supplémentaire. Ce point de convergence est crucial : la gestion des accès, les sauvegardes et les contrôles fournisseurs nécessaires à un plan de reprise d'activité sont identiques à ceux requis par la solution de continuité ; leur maintenance unique profite donc aux deux. L'articulation de l'ensemble est décrite dans le cadre de résilience de l'entreprise.
Cela explique aussi pourquoi une panne peut devenir un problème de confidentialité en quelques heures. Restaurer un système à partir d'une sauvegarde ancienne peut rétablir des données dont l'effacement a été demandé, et une solution de contournement consistant à transférer les dossiers clients dans un tableur crée un processus non évalué. C'est en considérant la récupération comme un simple aspect technique que ces conséquences passent inaperçues.
Comment prouver que les deux fonctionnent ?
Personne ne vérifie si vous possédez deux documents. Les clients, les auditeurs et les organismes réglementés posent une question plus complexe : prouvez-moi que les deux documents sont fonctionnels, cohérents et qu’ils reflètent votre mode de fonctionnement actuel.
Cela implique de définir les objectifs actuels avec les preuves de leur approbation, de réaliser un test de reprise avec des résultats plutôt qu'une date prévue, de mener un exercice de simulation avec des participants identifiés, de compiler les conclusions des deux exercices et de finaliser les actions correctives. Cet exercice conjoint est l'élément le plus souvent absent, et pourtant, il constitue la seule preuve tangible de la transition. La démarche est décrite dans le document « Comment démontrer la résilience » , et le score de résilience fournit un point de référence.
Pourquoi choisir ISMS.online pour la continuité et la reprise d'activité ?
Le point de jonction entre ces deux plans pose autant un problème de documentation que de planification. ISMS.online permet aux deux parties de travailler à partir d'une source unique.
- Un ensemble d'objectifsLes délais de récupération sont centralisés et alimentent les deux plans, ce qui évite tout décalage.
- Plans liés aux contrôles sur lesquels ils s'appuientLes contrôles de sauvegarde, d'accès et de fournisseur associés à chaque plan sont visibles, de sorte qu'une faille dans l'un se répercute sur l'autre.
- Enregistrements d'exercices intégrés: planifier simultanément les tests de restauration technique et les exercices fonctionnels, consigner les résultats et suivre les actions dans le même système.
- Un seul ensemble de contrôles, chaque framework: mapper une seule fois et réutiliser pour les normes ISO 22301, ISO 27001, ISO 27701 et ISO 42001 plutôt que de maintenir des ensembles parallèles.
- Preuve sur demande: présenter un plan actuel avec un historique des tests, et non un document et une assurance.
- Propriété qui détient: les propriétaires désignés, les mandataires et les dates de révision des deux côtés lors du transfert.
- Conçu pour le marché britannique et les marchés réglementés.: conçu pour les organisations qui doivent faire preuve de résilience pour remporter et conserver des contrats.
Découvrez comment tout cela s'articule sur la plateforme de résilience d'entreprise , ou réservez une démonstration.
FAQ
La reprise après sinistre fait-elle partie de la continuité des activités ?
Oui, dans la mesure où la reprise d'activité sert les objectifs définis par la continuité d'activité. La continuité d'activité est une discipline plus large qui englobe toutes les activités critiques et toutes les causes de perturbation, y compris celles sans composante technique. La reprise d'activité en est la composante technologique. La reprise d'activité hérite des objectifs de la continuité d'activité plutôt que d'en définir de nouveaux ; c'est pourquoi un plan de reprise d'activité rédigé sans analyse d'impact sur l'activité tend à protéger en priorité les mauvais systèmes.
Peut-on avoir un plan de reprise après sinistre sans plan de continuité d'activité ?
C'est possible, et de nombreuses organisations le font, mais vous vous retrouvez alors à tâtonner quant à vos propres priorités. Sans une vision partagée des activités essentielles et de la durée acceptable de leur interruption, l'ordre de rétablissement est dicté par des considérations techniques. De plus, il ne prévoit aucune solution pour les perturbations non techniques, telles que la perte d'un site, d'un fournisseur clé ou du personnel assurant un processus critique.
À qui devrait appartenir chaque plan ?
La continuité des activités relève de la responsabilité de l'entreprise, généralement des opérations ou de la gestion des risques, avec un responsable exécutif qui s'engage sur les priorités. La reprise d'activité relève de la DSI ou de l'infrastructure. L'important n'est pas la hiérarchie, mais l'interface : une autorité désignée pour déclencher et arrêter les procédures, un ensemble partagé d'objectifs de reprise et un exercice conjoint où les deux parties sont présentes.
Les deux plans utilisent-ils le même RTO ?
Ils devraient utiliser les mêmes chiffres, issus d'une source unique. L'objectif de délai de reprise d'une activité est défini dans l'analyse d'impact sur l'activité et le plan technique est conçu pour l'atteindre, en tenant compte du fait que le retour en service d'un système ne signifie pas nécessairement que l'activité est livrable. Si les deux documents présentent chacun leur propre version de ce chiffre, ils finiront par diverger, et cette divergence apparaîtra lors d'un incident.
À quelle fréquence devrions-nous les faire faire de l'exercice ensemble ?
Au moins une fois par an, et après toute modification affectant le transfert de responsabilité : nouveau système critique, changement d’hébergement, réorganisation avec transfert de propriété ou incident réel. Des tests de restauration technique distincts peuvent et doivent être effectués plus fréquemment. L’exercice conjoint est celui qui teste l’interface ; par conséquent, un programme de tests techniques fréquents sans exercice conjoint laisse le point de défaillance le plus probable inexploré.
