8.1 Plan de reprise (RC.RP)
Objectif de la catégorie
Cette catégorie vise à garantir que l’organisation dispose d’un plan formel et testé de reprise après incident, permettant de restaurer rapidement les capacités opérationnelles.
Warning
Le plus grand danger après un incident majeur n’est pas l’attaque… mais l’improvisation qui suit.
RC.RP-01 : Élaboration du plan de reprise
- Le Plan de Reprise Informatique (PRI) contient :
- Objectifs (RTO/RPO), périmètre, ressources nécessaires
- Procédures techniques détaillées
- Acteurs impliqués et scénarios envisagés
- Coordination avec :
- Plan de Continuité d’Activité (PCA)
- Plan de gestion de crise (PGC)
RC.RP-02 : Attribution des rôles
- Équipe PRI formellement désignée :
- Responsable de la reprise
- Référents techniques (réseau, systèmes, cloud…)
- Lien avec les métiers
- Fiches de poste opérationnelles disponibles même hors ligne
RC.RP-03 : Test et validation régulière du PRI
- Types de tests :
- Table-top (papier), tests techniques à blanc, bascule réelle
- Périmètre croissant :
- D’abord SI non critique, puis SI métier, puis environnement complet
- Rythme recommandé : au moins 1 fois par an
Example
Un PRA non testé depuis 3 ans n’est pas un PRA… mais une hypothèse.
RC.RP-04 : Mise à jour en fonction du contexte
- Mise à jour du PRI en cas de :
- Changement d’infrastructure (nouveau SI, cloud…)
- Reconfiguration des flux
- Retour d’expérience (incident réel ou simulation)
RC.RP-05 : Communication autour du PRI
- Communication interne :
- Rôles, attentes, consignes claires
- Communication externe :
- Autorités (en cas de sinistre déclaré)
- Clients impactés (engagement contractuel)
- Formation minimale des acteurs impliqués
Synthèse opérationnelle
| Élément | Bonnes pratiques |
|---|---|
| Plan PRI | Détail technique clair + validation direction |
| Rôles | Fiches accessibles hors ligne |
| Tests | Tous les 6-12 mois, tous périmètres |
| Mise à jour | Après incident ou changement d’infra |
| Communication | Interne + vers les clients si nécessaire |