Plan de Traitement des Risques (RTP) ISO 27001 : Excel [6.1.3]

Le Plan de Traitement des Risques (RTP) est le document opérationnel qui transforme les décisions d'appréciation des risques en actions concrètes, planifiées et budgétisées. Exigé explicitement par la clause 6.1.3 — Traitement des risques de sécurité de l'information de la norme ISO/IEC 27001:2022, le RTP est la passerelle entre l'analyse théorique des risques et leur gestion effective sur le terrain. Là où le registre des risques photographie l'état de la menace et évalue la criticité, le RTP répond à la question suivante : "Concrètement, que faisons-nous, qui le fait, quand, avec quels moyens ?". C'est le document que les auditeurs de certification examinent en priorité lors du Stage 2 pour vérifier que la démarche ISO 27001 n'est pas purement documentaire mais bien ancrée dans la réalité opérationnelle. Ce template Excel, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, couvre les quatre options de traitement du risque définies par la norme (Réduire, Transférer, Éviter, Accepter), intègre le suivi de l'avancement de chaque action avec indicateurs de progression, calcule automatiquement le risque résiduel attendu après mise en œuvre, et inclut un tableau de bord de pilotage pour la revue de direction. Il s'adresse aux RSSI qui pilotent la mise en œuvre des contrôles de sécurité, aux chefs de projet en charge du déploiement des mesures, aux directions générales qui valident les budgets de sécurité, et aux auditeurs internes qui vérifient l'effectivité des actions planifiées. Le RTP est indissociable du registre des risques et du Statement of Applicability (SoA) — ces trois documents forment le triptyque fondamental de tout SMSI certifiable. Chaque action du RTP doit être justifiée par un risque du registre, et chaque contrôle implémenté doit figurer dans le SoA. Cette cohérence documentaire est la première chose vérifiée par les auditeurs BSI, AFNOR, Bureau Veritas ou Lloyd's Register.

Contexte réglementaire et normatif

La clause 6.1.3 d'ISO/IEC 27001:2022 impose à l'organisation de produire un plan de traitement des risques, de le faire approuver par les propriétaires de risques, d'obtenir l'acceptation des risques résiduels par la direction, et de conserver des informations documentées sur les résultats du traitement. Ces quatre exigences sont les points de contrôle directs lors de l'audit de certification.

La norme ISO/IEC 27005:2022 (gestion des risques de sécurité de l'information) fournit le cadre méthodologique détaillé pour le processus de traitement. Elle distingue les options de traitement, les critères de sélection des mesures, et les modalités de communication aux parties prenantes concernées.

Plusieurs référentiels imposent des exigences analogues ou complémentaires :

• Directive NIS 2 (Article 21) : les mesures de gestion des risques cybersécurité doivent être documentées et démontrables, avec une responsabilité explicite des dirigeants. Le RTP ISO 27001 constitue une base solide pour répondre à ces exigences. Voir notre article sur la conformité NIS 2.
• EBIOS Risk Manager (ANSSI) : l'atelier 5 d'EBIOS RM est consacré au traitement des risques et produit un document très proche du RTP ISO 27001. Les deux méthodes sont alignées et ce template est compatible avec les outputs EBIOS RM.
• RGPD (Article 32) : les mesures techniques et organisationnelles de sécurité des traitements doivent être documentées et révisées. Le RTP ISO 27001 peut intégrer les actions de mise en conformité RGPD liées à la sécurité.
• Référentiel ANSSI Guide d'hygiène informatique : les 42 mesures d'hygiène informatique peuvent être intégrées comme mesures de traitement dans le RTP, avec une référence croisée vers les contrôles Annexe A correspondants.
• PCI-DSS v4.0 : les plans de remédiation exigés par PCI-DSS pour les non-conformités identifiées lors des audits QSA sont structurés comme un RTP. Un RTP ISO 27001 bien conçu facilite la conformité PCI-DSS simultanée.

Structure détaillée du template

Onglet 1 — Tableau de bord RTP

Vue synthétique de l'avancement global du plan de traitement : nombre total d'actions, répartition par statut (Non démarré / En cours / Terminé / En retard), pourcentage d'avancement global, top 5 des actions en retard, répartition budgétaire par domaine de contrôle. Ces indicateurs alimentent directement la revue de direction (clause 9.3) et permettent au RSSI de piloter le portefeuille d'actions de sécurité.

Onglet 2 — Plan de traitement (feuille principale)

Cœur du document. Chaque ligne représente une action de traitement avec les colonnes : identifiant unique (lien vers registre des risques), risque source, option de traitement sélectionnée, description de l'action, contrôle Annexe A associé, responsable de l'action (owner), parties prenantes impliquées, date de début prévue, date de fin prévue, ressources nécessaires (jours-homme, budget), statut d'avancement, date de clôture réelle, preuve de mise en œuvre, impact attendu sur la criticité résiduelle, criticité résiduelle après action, et commentaires libres.

Onglet 3 — Matrice de priorisation

Aide à prioriser les actions de traitement selon deux axes : l'urgence (criticité brute du risque associé) et la facilité de mise en œuvre (ratio impact/effort). Les actions dans le quadrant "Haute criticité / Faible effort" sont des victoires rapides (quick wins) à déployer en priorité. Elles démontrent la dynamique du projet lors du Stage 1 de l'audit de certification.

Onglet 4 — Suivi budgétaire

Tableau de suivi des dépenses de sécurité par catégorie (solutions techniques, formations, audit externe, consulting, licences). Permet de justifier le budget sécurité devant la direction et de calculer le ROI des investissements de sécurité en termes de réduction de la criticité des risques.

Onglet 5 — Journal des décisions

Historique des décisions importantes prises dans le cadre du traitement des risques : acceptation formelle de risques résiduels élevés, changements d'options de traitement, report d'actions avec justification. Ce journal est la mémoire du processus décisionnel, indispensable pour démontrer la maturité du SMSI en audit.

Guide d'utilisation étape par étape

Étape 1 — Importation depuis le registre des risques

Le RTP se nourrit directement du registre des risques. Pour chaque risque dont la criticité brute dépasse le seuil d'acceptation défini, créez une ou plusieurs lignes dans le RTP. Un même risque peut nécessiter plusieurs actions de traitement (par exemple : déployer un MFA + former les utilisateurs + mettre à jour la politique d'accès). Conservez l'identifiant du risque source pour maintenir la traçabilité entre les deux documents. Utilisez les fonctions de liaison entre fichiers Excel pour maintenir cette cohérence dynamiquement.

Étape 2 — Choix de l'option de traitement

Pour chaque risque, sélectionnez l'option de traitement dans le menu déroulant : Réduire (mise en place de contrôles de sécurité), Transférer (assurance cyber, externalisation), Éviter (abandon de l'activité génératrice du risque), Accepter (assumer le risque résiduel avec validation formelle). La plupart des actions seront de type "Réduire" — associez chacune à un ou plusieurs contrôles de l'Annexe A ISO 27001:2022 pour justifier le choix dans le SoA.

Étape 3 — Définition des actions concrètes

Pour chaque option "Réduire", décrivez précisément l'action à mener : pas "améliorer la sécurité des mots de passe" mais "Déployer un gestionnaire de mots de passe d'entreprise (KeePass Enterprise ou Bitwarden for Business) sur l'ensemble du parc et former tous les utilisateurs d'ici le 31/03/2026". La précision de la description de l'action est un critère d'évaluation de maturité pour les auditeurs — une action vague suggère un plan non opérationnel.

Étape 4 — Affectation des responsables

Chaque action doit avoir un unique propriétaire (owner) nommément identifié, responsable de son exécution et de son reporting. Évitez les propriétaires collectifs ("l'équipe IT") — un propriétaire individuel est beaucoup plus efficace pour l'accountability. Les propriétaires d'actions n'ont pas à être des membres de l'équipe sécurité : un responsable RH peut être propriétaire d'une action de formation, un responsable IT d'une action de patching.

Étape 5 — Planification et budgétisation

Assignez une date de début et une date de fin réalistes à chaque action. Les actions critiques (sur risques à criticité élevée) doivent avoir les délais les plus courts. Estimez les ressources nécessaires (jours-homme internes, budget externe) et faites valider le budget consolidé par la direction. La clause 7.1 d'ISO 27001 exige que les ressources nécessaires au SMSI soient déterminées et mises à disposition — le RTP budgété en est la démonstration documentaire.

Étape 6 — Calcul du risque résiduel attendu

Pour chaque action de traitement, estimez la criticité résiduelle attendue après mise en œuvre complète. Cette estimation doit être réaliste : une action de formation réduit la vraisemblance mais pas l'impact ; un firewall réduit la vraisemblance des attaques réseau ; un plan de continuité réduit l'impact mais pas la vraisemblance. La somme des réductions attendues doit ramener le risque résiduel sous le seuil d'acceptation ou justifier une acceptation formelle.

Étape 7 — Approbation formelle

Le RTP finalisé doit être approuvé formellement par la direction générale (clause 6.1.3e). Cette approbation inclut l'acceptation des risques résiduels restant au-dessus du seuil d'acceptation. Conservez la preuve de cette approbation (signature sur le document, email d'approbation, PV de réunion) — c'est une evidence critique en audit. En pratique, cette approbation est souvent réalisée lors de la revue de direction (clause 9.3).

Étape 8 — Suivi et reporting mensuel

Le tableau de bord (onglet 1) doit être mis à jour mensuellement par les propriétaires d'actions. Le RSSI consolide les avancées et produit un rapport synthétique pour la direction. Les actions en retard font l'objet d'une escalade formelle avec plan de rattrapage. Ce suivi régulier est la preuve concrète que le RTP est un outil de pilotage vivant et non un document figé.

Tableau des contrôles / checklist complète

Checklist de 30 points de contrôle pour valider la conformité du RTP lors d'un audit ISO 27001 :

Points de vigilance pour l'audit de certification

Piège 1 — RTP théorique sans preuve de mise en œuvre

Le RTP liste de belles actions mais les auditeurs du Stage 2 demandent les preuves de réalisation : captures d'écran, logs, politiques signées, comptes rendus de formation, factures de prestataires. Sans evidence, l'action n'est pas considérée comme complète. Remédiation : intégrez une colonne "Preuve de mise en œuvre" avec les références documentaires pour chaque action clôturée.

Piège 2 — Trop d'actions "Accepter" sans validation formelle

Si la majorité des risques élevés est traitée par l'option "Accepter" sans validation formelle de la direction, l'auditeur questionnera la réalité de la démarche de sécurité. L'acceptation d'un risque élevé doit être une exception justifiée et documentée, pas la règle. Remédiation : limitez les acceptations de risques élevés, obtenez une validation signée de la direction pour chaque exception, et documentez la justification dans le journal des décisions.

Piège 3 — Actions sans propriétaire ou avec "RSSI" systématique

Un RTP où le RSSI est propriétaire de toutes les actions est irréaliste — personne ne peut être responsable de 50 actions simultanément. Cela suggère aussi que les autres membres de l'organisation ne sont pas impliqués dans la démarche de sécurité. Remédiation : distribuez la propriété des actions selon les domaines de compétence et faites valider les rôles par les managers concernés.

Piège 4 — Incohérence entre le RTP et le SoA

Si une action du RTP référence le contrôle A.8.5 (authentification sécurisée) mais que le SoA indique ce contrôle comme "Non applicable", c'est une contradiction directe que l'auditeur signalera. Remédiation : vérifiez systématiquement la cohérence RTP-SoA avant l'audit, en utilisant l'onglet de liaison fourni dans ce template.

Piège 5 — Délais irréalistes non tenus

Un RTP avec des actions planifiées pour "T+1 mois" mais toujours non terminées 12 mois plus tard démontre un dysfonctionnement grave du processus. L'auditeur verra dans l'historique que les délais n'ont jamais été respectés. Remédiation : définissez des délais réalistes dès le départ, escaladez formellement les retards, et mettez à jour les dates cibles avec justification plutôt que de laisser les échéances expirées sans commentaire.

Piège 6 — Absence de budget formel

Un RTP sans budget alloué est un plan sans engagement de la direction. La clause 7.1 impose que les ressources nécessaires soient déterminées et fournies. Sans budget, impossible de démontrer que la direction soutient réellement le SMSI. Remédiation : faites approuver un budget annuel de sécurité par la direction et incluez la référence budgétaire dans le RTP.

Intégration dans le SMSI

Le RTP occupe une position centrale dans l'architecture documentaire du SMSI :

• En entrée — Registre des risques (6.1.2) : chaque action du RTP est justifiée par un risque du registre. La traçabilité bidirectionnelle est essentielle.
• En entrée — Statement of Applicability : les contrôles sélectionnés dans le SoA déterminent les actions de mise en œuvre dans le RTP.
• En sortie — Preuves de mise en œuvre : chaque action clôturée génère des preuves (politiques, configurations, formations) qui alimentent les dossiers d'audit.
• En sortie — Revue de direction (9.3) : l'avancement du RTP est un input obligatoire de la revue de direction. La direction valide les reports d'actions et les ajustements de priorité.
• En boucle — Audit interne (9.2) : l'audit interne vérifie l'efficacité des contrôles implémentés et génère des non-conformités qui s'intègrent comme nouvelles actions dans le RTP.
• En boucle — Gestion des incidents (A.5.24-26) : les incidents de sécurité peuvent révéler des failles dans les mesures de traitement et générer des actions correctives dans le RTP.

Bonnes pratiques terrain

Priorisez les quick wins pour démontrer la dynamique : avant l'audit Stage 1, assurez-vous d'avoir clôturé au minimum 30% des actions, en ciblant en priorité les actions à fort impact et faible effort. Cela démontre que la démarche est opérationnelle et pas seulement documentaire.

Utilisez des outils de gestion de projet pour le suivi : si votre organisation utilise déjà Jira, Asana ou Microsoft Planner, intégrez les actions du RTP dans votre outil de gestion de projet existant. Cela facilite le suivi au quotidien et la collecte des preuves. Le template Excel reste la référence documentaire officielle pour l'audit.

Impliquez les propriétaires d'actions dans la rédaction : les actions rédigées sans consultation des propriétaires sont souvent irréalistes ou inadaptées au contexte technique. Organisez des ateliers de travail avec les équipes IT, RH et métier pour co-construire les actions de traitement.

Distinguez actions d'implémentation et actions de vérification : pour chaque mesure de sécurité déployée, prévoyez aussi une action de vérification de son efficacité (test de pénétration, campagne de phishing simulée, revue des logs). Sans vérification, impossible de confirmer que la criticité résiduelle est bien celle attendue.

Communiquez régulièrement sur l'avancement : un rapport mensuel de 1 page sur l'avancement du RTP, envoyé à la direction et aux propriétaires d'actions, maintient l'engagement de tous et prévient les dérives. Cette communication régulière est aussi une preuve de la vivacité du processus de management.

FAQ

Quelle est la différence entre le RTP et le plan d'action SMSI ?

Les termes "Plan de Traitement des Risques (RTP)" et "Plan d'action SMSI" sont souvent confondus mais couvrent des périmètres différents. Le RTP (clause 6.1.3) est strictement centré sur le traitement des risques identifiés lors de l'appréciation : pour chaque risque inacceptable, il liste les actions de réduction, transfert, évitement ou acceptation. Le plan d'action SMSI est plus large : il peut inclure les actions issues des non-conformités d'audit, les actions d'amélioration continue (clause 10.2), les actions de mise en conformité réglementaire, et les projets de développement du SMSI. Dans de nombreuses organisations, les deux documents sont fusionnés en un seul plan d'action global, avec des colonnes permettant d'identifier l'origine de chaque action (risque, audit, incident, amélioration). Cette approche est parfaitement acceptable pour les auditeurs, tant que la traçabilité vers les risques du registre est maintenue pour les actions issues du RTP.

Combien d'actions minimum doit contenir un RTP ?

Il n'y a pas de nombre minimum imposé — cela dépend directement du nombre de risques inacceptables identifiés dans le registre des risques et de la maturité initiale du dispositif de sécurité. Pour une organisation débutant sa démarche ISO 27001 avec un niveau de maturité faible, 50 à 150 actions dans le RTP est courant lors de la première certification. Pour un renouvellement (surveillance ou recertification 3 ans), le RTP peut ne contenir que 10 à 30 actions si le SMSI est mature et les risques bien maîtrisés. Ce qui compte pour l'auditeur, c'est la cohérence : chaque risque inacceptable du registre doit avoir au moins une action dans le RTP, et chaque action doit être justifiée par un risque. Un RTP avec trop peu d'actions par rapport au nombre de risques identifiés sera questionné, de même qu'un RTP avec des actions sans lien avec les risques du registre.

Le RTP doit-il être mis à jour uniquement annuellement ?

Non. Le RTP est un document vivant qui doit être mis à jour en continu : chaque action clôturée est marquée "Terminé" avec la date de clôture et les preuves référencées, chaque action en retard est escaladée et sa date cible mise à jour, tout nouveau risque identifié en cours d'année génère de nouvelles actions. La mise à jour annuelle formelle coincide avec la révision du registre des risques et la revue de direction — c'est le moment de réviser les priorités et d'intégrer les nouvelles menaces. Mais le suivi opérationnel doit être mensuel au minimum. L'auditeur examinera les dates de mise à jour du document et questionnera tout registre qui n'aurait pas été modifié depuis plus de 6 mois — cela suggèrerait que le processus n'est pas opérationnel.

Comment gérer les actions de traitement qui concernent plusieurs risques ?

Il est fréquent qu'une même mesure de sécurité traite simultanément plusieurs risques. Par exemple, le déploiement d'un MFA peut réduire le risque de compromission de comptes par phishing, de vol d'identifiants et d'accès non autorisé par un ex-employé. Dans ce cas, deux approches sont possibles : créer une ligne d'action unique dans le RTP avec plusieurs risques référencés en source (approche recommandée — plus lisible), ou dupliquer l'action pour chaque risque traité avec une note de renvoi (approche plus verbeuse mais plus traçable). Quelle que soit l'approche, assurez-vous que tous les risques traités par une même action sont bien référencés, pour ne pas créer de "risques orphelins" dans le registre qui sembleraient non traités. La priorisation des actions multi-risques est aussi plus facile : leur impact combiné sur la réduction globale du risque justifie souvent de les placer en tête des priorités.

Comment démontrer l'efficacité des mesures de traitement ?

Démontrer l'efficacité des contrôles mis en œuvre est l'un des défis majeurs de la surveillance du SMSI (clause 9.1). Pour chaque action clôturée dans le RTP, vous devez être capable de démontrer que la mesure fonctionne comme prévu et que la criticité résiduelle est bien celle qui était anticipée. Les méthodes de vérification varient selon le type de contrôle : pour les contrôles techniques (pare-feu, antivirus, MFA), les logs et rapports de sécurité constituent les preuves. Pour les contrôles procéduraux (politique de sécurité, procédure), une revue documentaire et des interviews démontrent leur application. Pour les contrôles humains (formations), les taux de participation et les résultats de tests de phishing mesurent l'efficacité. Documentez la méthode de vérification pour chaque action dans la colonne dédiée, et réalisez des mesures périodiques plutôt qu'une seule mesure au moment de la clôture.

Que faire si une action de traitement est impossible à réaliser dans les délais ?

Les retards dans le RTP sont inévitables dans tout projet de certification. L'important n'est pas l'absence de retards mais la manière dont ils sont gérés. Procédure recommandée : dès qu'un retard est constaté, le propriétaire de l'action le signale au RSSI avec une explication et une nouvelle date cible réaliste. Le RSSI documente le retard dans le journal des décisions avec la justification et la nouvelle échéance. Si le risque associé est critique et que le délai est significatif, une mesure compensatoire provisoire doit être mise en place (mesure palliative). L'auditeur sera indulgent face à des retards bien documentés et gérés, mais pas face à des retards ignorés ou dissimulés. Préparez une explication claire pour chaque action non terminée à la date de l'audit — les auditeurs comprennent les contraintes opérationnelles tant qu'ils voient une gestion active du problème.

Le RTP doit-il être communiqué à tous les collaborateurs ?

Non — le RTP contient des informations sensibles sur les vulnérabilités et les risques de l'organisation, et doit être classifié comme document confidentiel à diffusion restreinte. Seules les personnes ayant besoin de l'information pour accomplir leurs missions doivent y avoir accès : RSSI, direction générale, propriétaires d'actions, auditeurs internes, consultants sous NDA. Pour les collaborateurs non impliqués dans le projet de certification, une communication sur les actions de sécurité qui les impactent directement (nouvelle politique de mot de passe, formation obligatoire) est préférable à la diffusion du RTP complet. Le plan de communication SMSI (clause 7.4) définit quelles informations sont communiquées à quelles parties prenantes — les résultats agrégés du RTP (pourcentage d'avancement, budget consommé) peuvent être partagés plus largement que le détail des actions.