Plan de Continuité d'Activité (PCA) : Modèle Word [ISO 22301/27001]

Le Plan de Continuité d'Activité (PCA) est le document opérationnel qui définit comment votre organisation maintient ou reprend ses activités critiques lors d'une perturbation majeure. Fondé sur les résultats du Business Impact Analysis (BIA), il est exigé par la norme ISO 22301:2019 (clause 8.4) et par le contrôle A.5.29 d'ISO 27001:2022 (continuité de la sécurité de l'information). La directive NIS 2, en vigueur depuis octobre 2024, renforce l'obligation de disposer d'un PCA formalisé pour les entités essentielles et importantes. Le PCA couvre plusieurs dimensions essentielles : la gouvernance de crise (qui décide, qui communique, qui coordonne), les scénarios de crise documentés (cyberattaque, panne d'infrastructure, indisponibilité RH, pandémie, sinistre physique), les procédures de bascule vers les modes dégradés, les mesures de continuité par processus (solutions de contournement manuelles, recours à des tiers), les Plans de Reprise d'Activité (PRA) par domaine, et le programme de tests et d'exercices. Ce modèle Word, élaboré par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001 et ISO 22301, structure un PCA complet de 15 à 20 pages adapté aux organisations de taille intermédiaire. Il intègre une organisation de gestion de crise avec rôles et responsabilités, des procédures de communication de crise (interne et externe), et un plan de tests annuel. Le PCA ne doit pas être un document figé sur une étagère — il doit être testé régulièrement, mis à jour annuellement, et connu de toutes les personnes qui auront à le mettre en œuvre lors d'une crise réelle.

Contexte réglementaire et normatif

ISO 22301:2019 — Clause 8.4 : Plans de continuité d'activité

La clause 8.4 d'ISO 22301 impose à l'organisation d'établir, documenter, mettre en œuvre et tenir à jour des procédures de continuité d'activité. Ces procédures doivent notamment définir comment l'organisation répondra à un incident perturbateur et maintenera ses activités à un niveau minimum acceptable (MBCO), comment elle reprendra ses activités à un niveau normal, et comment elle communiquera en interne et avec les parties prenantes externes. La norme impose également de définir l'organisation de gestion de crise avec des rôles et responsabilités clairs, et de planifier des exercices réguliers pour tester l'efficacité des procédures.

ISO/IEC 27001:2022 — Contrôles A.5.29 et A.5.30

Le contrôle A.5.29 (Continuité de la sécurité de l'information) exige que l'organisation planifie comment maintenir un niveau approprié de sécurité de l'information lors des perturbations. Cela implique d'intégrer les exigences de sécurité de l'information dans les procédures de continuité d'activité. Le contrôle A.5.30 (ICT readiness for business continuity) complète A.5.29 en exigeant de planifier et tester la disponibilité des ressources ICT en fonction des objectifs de continuité. Ensemble, ces deux contrôles créent un pont explicite entre la gestion de la sécurité de l'information et la continuité d'activité.

Directive NIS 2 — Article 21 : Mesures de gestion de risques

NIS 2 impose aux entités essentielles et importantes de l'UE de mettre en place "la continuité des activités, comme la gestion des sauvegardes et la reprise après sinistre, et la gestion des crises". La France a transposé cette directive. Les entités concernées doivent disposer d'un PCA formalisé, testé, et incluant des procédures de gestion de crise cyber. L'ANSSI peut auditer la conformité à ces exigences.

Structure détaillée du modèle PCA

Section 1 — Présentation et gouvernance du PCA

Objet et périmètre du PCA, politique de continuité d'activité (engagement de la direction), définitions et acronymes, historique des révisions, processus d'approbation et de révision, et références normatives et réglementaires. Cette section établit le cadre juridique et organisationnel du PCA.

Section 2 — Synthèse du BIA

Résumé des résultats du Business Impact Analysis : classement des processus métier critiques par niveau de criticité, seuils RTO/RPO/MTPD par processus, dépendances systèmes et fournisseurs critiques, et périodes de criticité particulière. Cette section est le lien formel entre l'analyse (BIA) et l'action (PCA).

Section 3 — Organisation de gestion de crise (CGC)

Organigramme de crise avec rôles et responsabilités, critères de déclenchement du PCA, procédure d'activation et d'escalade, annuaire de crise (contacts clés avec numéros d'urgence), cellule de crise (composition, lieu de réunion alternatif, outils de communication de crise), et procédure de désactivation du PCA et retour à la normale. L'organisation de gestion de crise doit être connue de tous les membres de la cellule avant qu'une crise ne survienne.

Section 4 — Scénarios de crise et procédures de continuité

Pour chaque scénario de crise identifié, une fiche de procédure détaillée couvrant les étapes de réponse immédiate, les actions de continuité (modes dégradés, solutions de contournement), les ressources nécessaires, les contacts à prévenir, et les critères de passage en mode reprise. Les principaux scénarios à couvrir : cyberattaque (ransomware, DDoS), panne d'infrastructure (datacenter, cloud, réseau), indisponibilité RH massive (pandémie, grève, accident), sinistre physique (incendie, inondation, panne électrique prolongée), et défaillance d'un fournisseur critique.

Section 5 — Plans de Reprise d'Activité (PRA)

Procédures détaillées de reprise pour chaque processus ou système critique : prérequis de reprise, séquence d'actions de reprise étape par étape, temps de reprise attendu, critères de validation de la reprise, et retour au mode normal. Ces procédures doivent être suffisamment détaillées pour être exécutables par un technicien compétent sans connaissance préalable du système, et testées régulièrement pour garantir leur fiabilité.

Section 6 — Communication de crise

Plan de communication interne (collaborateurs, direction, CA) et externe (clients, fournisseurs, partenaires, régulateurs, médias). Procédures de communication adaptées à chaque scénario de crise, messages pré-rédigés (templates d'emails, communiqués de presse), porte-parole désignés, et gestion des réseaux sociaux en cas de crise médiatisée.

Section 7 — Programme de tests et exercices

Plan annuel des tests et exercices PCA : tests techniques (restauration depuis backup, bascule sur site secondaire), revues documentaires (vérification cohérence PCA/BIA), exercices sur table (simulation de crise en salle), exercices de simulation complets (activation de la cellule de crise), et exercices grandeur nature. Pour chaque test/exercice : objectif, périmètre, date prévue, participants, scénario, et critères de succès.

Guide d'utilisation étape par étape

1. Partir du BIA pour définir les priorités du PCA : le PCA doit couvrir en priorité les processus identifiés comme critiques dans le BIA. Ne cherchez pas à couvrir 100% des processus dans un premier temps — concentrez-vous sur ceux dont l'interruption aurait les impacts les plus graves.
2. Constituer la cellule de gestion de crise : identifiez les membres de la cellule de crise (DG, DSI, RSSI, DRH, DAF, Direction communication) avec leurs suppléants, et assurez-vous que chacun connaît son rôle avant qu'une crise ne survienne. Organisez une réunion de présentation du PCA aux membres de la cellule.
3. Rédiger les fiches de procédure scénario par scénario : pour chaque scénario de crise, rédigez une fiche de procédure step-by-step. Impliquez les équipes opérationnelles concernées (équipes IT pour les scénarios cyber/infra, RH pour les scénarios pandémie/RH, etc.) — ce sont eux qui exécuteront ces procédures en situation réelle.
4. Documenter les solutions de contournement manuelles : pour les processus critiques, documentez comment ils peuvent fonctionner en mode dégradé manuel si les systèmes informatiques sont indisponibles. Ces procédures "papier" sont souvent négligées mais cruciales lors d'une cyberattaque qui immobilise les SI.
5. Tester le PCA avant la prochaine crise : un PCA non testé est un PCA non fiable. Planifiez au minimum un test documentaire annuel (revue cohérence) et un exercice sur table annuel. Pour les processus les plus critiques, planifiez un test de reprise technique tous les 2 ans.
6. Mettre à jour le PCA annuellement et lors de changements majeurs : le PCA devient obsolète rapidement lors d'une réorganisation, d'un déménagement, d'un changement de fournisseur critique, ou d'une migration SI. Définissez un processus de mise à jour avec un responsable (généralement le RSSI ou le responsable continuité) et une date de révision annuelle.
7. Intégrer la sécurité de l'information dans le PCA : en lien avec A.5.29, assurez-vous que les procédures de continuité maintiennent un niveau minimal de sécurité. Par exemple, l'utilisation d'outils de communication alternatifs en crise (WhatsApp, Telegram) doit être encadrée pour éviter des fuites d'informations sensibles.
8. Articuler le PCA avec le plan de gestion de crise cyber : la cyberattaque est aujourd'hui l'un des scénarios de crise les plus fréquents. Votre PCA doit inclure des procédures spécifiques au scénario ransomware/cyberattaque majeure, articulées avec votre procédure de gestion des incidents (A.5.24-28).

Tableau des contrôles — Checklist PCA ISO 22301 / ISO 27001

Points de vigilance pour l'audit de certification

1. PCA jamais testé : un PCA non testé n'a aucune valeur opérationnelle et sera identifié comme une non-conformité lors d'un audit ISO 22301. Remédiation : planifiez immédiatement un exercice sur table (demi-journée avec la cellule de crise) et documentez-le — c'est le minimum requis.
2. Annuaire de crise périmé : si les numéros d'urgence sont ceux de collaborateurs partis ou de fournisseurs changés, le PCA ne peut pas être activé efficacement. Remédiation : mettez à jour l'annuaire de crise trimestriellement et stockez-le dans un endroit accessible offline (copie papier, clé USB chiffrée).
3. PCA inaccessible lors d'une crise SI : si le PCA est stocké uniquement sur le réseau interne, il est inaccessible lors d'une cyberattaque ou d'une panne réseau. Remédiation : conservez une copie offline du PCA (clé USB chiffrée, copie papier en coffre-fort) et assurez-vous que les membres de la cellule peuvent y accéder sans connexion réseau.
4. Absence de scénario cyberattaque : de nombreux PCA historiques ne couvrent que les sinistres physiques et les pannes IT. Ne pas avoir de procédure pour une attaque ransomware est une lacune critique en 2025. Remédiation : ajoutez explicitement un scénario "cyberattaque majeure" avec des procédures de confinement, de communication aux autorités (ANSSI), et de reprise sans les systèmes compromis.

Questions fréquentes

Quelle est la différence entre le PCA et le Plan de Reprise d'Activité (PRA) ?

Le PCA (Plan de Continuité d'Activité) est l'ensemble du dispositif de continuité — il couvre la prévention des crises, la réponse en phase de crise (mode dégradé), et la reprise après crise. Il inclut la gouvernance, les procédures de communication, les modes dégradés, et les plans de reprise. Le PRA (Plan de Reprise d'Activité) est spécifiquement la partie du PCA qui décrit comment reprendre les activités après un incident — c'est la composante "reprise" du PCA. En pratique, le PCA est le document cadre et les PRA sont des annexes techniques (un PRA par domaine ou système critique). Pour le SI, on parle souvent de ITDRP (IT Disaster Recovery Plan) qui est le PRA IT. Cette terminologie varie selon les organisations : certaines utilisent PCA pour l'ensemble (continuité + reprise) et PRA comme synonyme du volet IT, d'autres font la distinction PCA (organisationnel/RH) vs PRA (IT). ISO 22301 utilise le terme générique "Business Continuity Plan" qui recouvre l'ensemble de ces dimensions.

Comment intégrer le scénario cyberattaque dans le PCA ?

La cyberattaque — en particulier le ransomware — est devenu le scénario de crise le plus fréquent pour les organisations. L'intégrer correctement dans le PCA nécessite plusieurs éléments spécifiques. Premièrement, des procédures de confinement d'urgence : comment isoler les systèmes compromis pour limiter la propagation, qui a l'autorité de couper l'accès réseau, quelles sont les étapes dans les 30 premières minutes. Deuxièmement, des modes dégradés "sans SI" : si l'ensemble du SI est compromis et chiffré, comment les processus critiques peuvent-ils continuer à fonctionner (procédures manuelles, accès aux sauvegardes offline, recours à des outils cloud non compromis). Troisièmement, des procédures de communication spécifiques : notification ANSSI sous 24h pour les OIV/OSE/entités NIS 2, notification CNIL sous 72h si données personnelles concernées, communication clients, et gestion de la communication médias. Quatrièmement, la reprise dans un environnement sain : procédures de reconstruction du SI depuis des sauvegardes propres, ordre de priorité de reprise des systèmes, et tests de non-reinfection avant remise en production.

Quelle fréquence minimale pour les exercices PCA ?

ISO 22301 (clause 8.5) n'impose pas de fréquence minimale précise pour les exercices, mais exige qu'ils soient suffisamment réguliers pour s'assurer de l'efficacité des procédures. En pratique, la doctrine courante est la suivante : au minimum un exercice sur table (simulation en salle avec la cellule de crise) par an, un test de restauration depuis backup par trimestre (avec rapport), un exercice de simulation complet (mobilisation de toute la cellule de crise) tous les 2 ans, et un exercice grandeur nature (activation réelle des procédures) tous les 3-5 ans pour les organisations les plus matures. Pour les entités soumises à NIS 2 ou DORA, les exigences sont plus strictes et des tests spécifiques (TLPT pour DORA) peuvent être requis. Documentez systématiquement chaque exercice avec un rapport incluant le scénario, les participants, les constats, et les actions correctives identifiées. Ces rapports sont des preuves essentielles lors d'un audit de certification ISO 22301 ou d'une inspection NIS 2.

Comment maintenir le PCA à jour avec une équipe limitée ?

Le maintien à jour d'un PCA est souvent négligé car perçu comme une charge administrative. Plusieurs pratiques permettent de l'automatiser ou de le minimiser. Désignez un propriétaire unique du PCA (généralement le RSSI ou un responsable continuité) qui est chargé de sa mise à jour et de sa validation annuelle. Intégrez une clause de déclenchement de révision automatique dans votre processus de gestion des changements (A.8.32) : tout changement majeur (nouveau SI critique, réorganisation, changement de fournisseur critique) doit déclencher une révision du PCA. Créez une liste de contrôle annuelle de révision du PCA (une dizaine de questions sur les changements intervenus dans l'année) qui peut être remplie en moins d'une heure. Faites valider les mises à jour par la direction dans le cadre de la revue de direction annuelle — cela garantit leur engagement et évite une révision dédiée. Enfin, considérez un outil de gestion de la continuité d'activité (BCM software) pour les organisations dont le PCA est complexe — ces outils automatisent les rappels de révision et facilitent la documentation des exercices.

Comment articuler PCA et plan de gestion de crise RGPD ?

Le RGPD impose à l'article 33 de notifier la CNIL dans un délai de 72 heures en cas de violation de données à caractère personnel susceptible d'engendrer un risque pour les droits et libertés des personnes. Cette obligation s'applique en cas d'incident de sécurité (cyberattaque, perte d'un support, erreur humaine) et doit donc être intégrée dans le PCA au niveau de la procédure de communication de crise. Votre PCA doit inclure une "checklist RGPD en cas de crise" qui précise : qui est responsable d'évaluer si l'incident constitue une violation de données au sens du RGPD (généralement le DPO ou le RSSI), quel est le seuil de déclenchement de la notification CNIL (toute violation avec risque pour les personnes), comment compléter le formulaire de notification CNIL, et les informations à préparer (nature de la violation, catégories et nombre de personnes concernées, conséquences probables, mesures prises). Notez que le délai de 72h court à partir du moment où l'organisation a "pris connaissance" de la violation — ce qui peut être antérieur à la résolution complète de l'incident. Assurez-vous donc que les procédures de crise prévoient une évaluation RGPD dès les premières heures de l'incident.

Pour aller plus loin

• BIA Business Impact Analysis — Template Excel ISO 22301/27001
• Procédure de gestion des incidents ISO 27001 (A.5.24-28)
• Registre des sous-traitants ISO 27001 / ISO 27036
• Gap Analysis ISO 27001:2022 — 93 contrôles [outil Excel]
• Notre service d'accompagnement ISO 27001 complet