Votre service de gestion des incidents est-il prêt pour un audit ? A.5.24 Principes essentiels de la norme ISO 27001

Pourquoi la préparation aux incidents des fournisseurs de services gérés est défaillante en 2025

De nombreux fournisseurs de services gérés (MSP) continuent de considérer la gestion des incidents comme de l'improvisation plutôt que comme une capacité documentée et reproductible qu'ils peuvent justifier lors d'un contrôle. Lorsque votre historique d'incidents se résume à des captures d'écran, des conversations en ligne et des tickets inachevés, vous ne pouvez pas démontrer que vous planifiez, contrôlez et auditez les incidents de manière cohérente. Cette lacune devient flagrante lorsqu'un client, un assureur ou un auditeur demande une chronologie précise, les décisions prises et des preuves du respect des obligations contractuelles et réglementaires.

Les incidents échouent rarement à cause de la technologie ; ils échouent parce que la préparation et les responsabilités n'ont jamais été clairement définies.

Dans notre enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information, seule une organisation sur cinq environ a déclaré n'avoir subi aucune perte de données au cours de l'année précédente.

Chaos opérationnel dans la gestion quotidienne des incidents

Le chaos opérationnel survient lorsque la gestion des incidents s'articule autour des personnes et des outils, au lieu de reposer sur une conception délibérée, documentée et comprise de tous. Les tickets du quotidien peuvent sembler gérables, mais un incident de sécurité majeur révèle des lacunes en matière de responsabilité, de priorités et de communication qui existaient déjà, mais n'avaient jamais été mises à l'épreuve en situation réelle.

Les problèmes liés aux incidents des fournisseurs de services gérés (MSP) suivent souvent un schéma familier :

Propriété fragmentée : – La surveillance, le confinement et les mises à jour des clients sont assurés par différentes équipes, sans responsable unique.
Chaos des billets : – Les incidents de sécurité partagent les mêmes files d'attente que les pannes courantes, utilisant des catégories improvisées et des priorités incohérentes.
Dérive contractuelle : – Les SLA et les calendriers de sécurité promettent des schémas de réponse que votre pratique quotidienne ne reflète plus.
Confusion liée à la multi-location : – Les plateformes partagées génèrent des problèmes qui affectent plusieurs clients, et pourtant vous les traitez comme des événements isolés.
Apprentissage faible : – Les leçons tirées des incidents majeurs sont rarement intégrées aux manuels de procédures, aux outils ou aux contrats.

Ce schéma rend difficile de prouver ce qui s'est réellement passé, qui a pris quelles décisions et si vous avez respecté vos obligations contractuelles. Il a également pour conséquence que chaque incident majeur semble inédit, même lorsque la cause profonde est connue et aurait pu être gérée plus efficacement avec une meilleure préparation et une conception plus claire.

Les clients, les assureurs et les organismes de réglementation partent désormais du principe que votre gestion des incidents est définie, simulée et documentée, et non improvisée en situation de crise. Les directives réglementaires relatives à la sécurité et aux données personnelles insistent de plus en plus sur des processus documentés et testés, ainsi que sur des enregistrements clairs démontrant comment les incidents ont été gérés, et non pas seulement qu'ils ont été reconnus. Ils attendent de voir comment vous coordonnez le travail technique, la prise de décision et la communication entre les équipes et les utilisateurs, sans avoir recours à des actions héroïques ou à des conjectures lorsqu'un problème grave survient.

Les entreprises clientes, les assureurs cyber et les organismes de réglementation exigent de plus en plus que la gestion des incidents soit définie, répétée et documentée, et non improvisée au dernier moment. Les rapports sectoriels sur les violations de données et les menaces mettent régulièrement en lumière des lacunes en matière de préparation et de communication, ce qui incite les parties prenantes à exiger de leurs fournisseurs une gestion des incidents mieux documentée. Elles attendent de vous que vous démontriez votre capacité à coordonner le travail technique, la prise de décision et la communication entre les équipes et les utilisateurs, sans avoir recours à des actions individuelles exceptionnelles. Le contrôle A.5.24 de la norme ISO/IEC 27001:2022 concrétise ces attentes et fournit un langage utilisé par les auditeurs externes lors de l'évaluation de vos compétences. Ce contrôle met l'accent sur la planification, la préparation et la répartition claire des responsabilités en cas d'incidents de sécurité de l'information, offrant ainsi aux auditeurs et aux évaluateurs un point de référence commun pour l'examen des fournisseurs de services gérés (MSP).

Concrètement, cela signifie qu'on vous demandera tôt ou tard de prouver que vous disposez d'une politique et de procédures documentées en matière de gestion des incidents, que votre personnel connaît ses rôles et suit des procédures cohérentes lors de ces incidents, et que vous pouvez produire des comptes rendus cohérents des actions, des approbations et des communications. Si vous ne pouvez pas le faire aujourd'hui sans difficulté, le problème ne se limite pas à la conformité ; il peut facilement engendrer un problème de confiance plus important, compromettant les renouvellements de contrats, les recommandations et l'assurabilité.

Comment la norme A.5.24 révèle les lacunes en matière de préparation des fournisseurs de services gérés

L'analyse A.5.24 permet de déterminer si votre dispositif de gestion des incidents est réellement conçu et reproductible, ou s'il ne s'agit que d'un ensemble disparate de tickets et de bonnes intentions chez de nombreux clients. Pour les fournisseurs de services gérés (MSP), ce contrôle vérifie si vos opérations réelles correspondent aux exigences de votre politique et si vous pouvez expliquer clairement votre démarche à des personnes extérieures qui ne connaissent pas votre environnement.

L'exigence A.5.24 impose de définir, d'établir et de communiquer en amont les processus, les rôles et les responsabilités en matière de gestion des incidents, puis de démontrer leur application. Les descriptions de ce contrôle insistent systématiquement sur la nécessité de disposer de processus documentés, d'une responsabilité clairement définie et de preuves de leur application concrète, plutôt que de s'appuyer sur des pratiques informelles. Pour les fournisseurs de services gérés (MSP), il ne s'agit pas d'une simple formalité administrative ; c'est un test permettant de vérifier si vos pratiques de gestion des incidents en situation réelle résistent à un examen approfondi auprès de nombreux clients simultanément et peuvent être expliquées clairement à des tiers.

Une façon simple d'évaluer votre situation actuelle consiste à vous poser trois questions :

Pourriez-vous montrer à un auditeur où les rôles, les processus et les responsabilités liés aux incidents sont documentés et approuvés ?
Pourriez-vous expliquer à un client stratégique un incident récent en utilisant un document unique et cohérent comme source de vérité ?
Pourriez-vous démontrer que les leçons tirées du dernier incident majeur ont modifié les procédures, les outils ou les contrats ?

Si la réponse est « pas vraiment », il vous reste du travail à faire. L’avantage est que les mêmes fondements qui comblent l’écart de l’A.5.24 réduisent également le chaos, améliorent les marges et facilitent l’assurance et l’achat de vos services, surtout si vous pouvez expliquer votre approche en termes simples et justifiables.

Demander demo

Ce qu'exige réellement la norme ISO 27001:2022 A.5.24

La norme ISO 27001:2022, paragraphe 5.24, exige la mise en œuvre d'un véritable cadre de gestion des incidents, et non la simple possession d'un document intitulé « plan de réponse aux incidents ». Pour un fournisseur de services gérés (MSP), ce cadre doit être opérationnel pour de nombreux clients et plateformes, tout en restant suffisamment simple pour être compris par le personnel et évalué par les auditeurs. Le contrôle consiste concrètement à vérifier votre capacité à décrire vos intentions, vos méthodes de travail, les personnes impliquées et la manière dont vous justifiez a posteriori les actions entreprises.

Presque tous les répondants à notre enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information ont cité l'obtention ou le maintien de certifications de sécurité telles que l'ISO 27001 ou le SOC 2 comme une priorité organisationnelle absolue.

La norme A.5.24 va bien au-delà d'une simple demande de « plan de réponse aux incidents » générique ; elle exige un cadre opérationnel que vous puissiez expliquer, mettre en œuvre et justifier en situation de crise. Pour un fournisseur de services gérés (MSP), ce cadre doit être applicable à de nombreux clients, différentes technologies et divers types de contrats, sans devenir ingérable ni se déconnecter de la réalité. Il constitue la base de votre démonstration de préparation, et non un simple document à cocher pour satisfaire ponctuellement à un audit.

Les quatre couches pratiques de l'A.5.24 pour les MSP

Vous pouvez simplifier la norme A.5.24 pour vos équipes en la structurant autour de quatre niveaux pratiques : gouvernance, processus, capacités et preuves. La gouvernance définit l’intention et l’autorité ; le processus définit le cycle de vie ; les capacités fournissent les ressources humaines et les outils ; les preuves attestent du respect effectif du plan. Ensemble, ces éléments constituent une liste de contrôle simple, à l’image de la façon dont les auditeurs et les clients stratégiques évaluent votre préparation aux incidents.

La norme A.5.24 est plus facile à comprendre si on la décompose en quatre niveaux : gouvernance, processus, capacités et preuves. Ensemble, ils décrivent ce que vous comptez faire, comment vous le faites, qui le fait et comment vous le justifiez ultérieurement, soit précisément la manière dont les auditeurs et les clients stratégiques vous évalueront.

Étape 1 – Établir une gouvernance et une responsabilité claires

Définissez une politique de gestion des incidents, son périmètre, ses définitions et les rôles désignés avec les pouvoirs délégués afin que les décisions ne soient pas bloquées.

Étape 2 – Décrire un processus simple et reproductible

Définir comment les événements deviennent des incidents et comment ils évoluent à travers des étapes de cycle de vie définies que le personnel peut suivre.

Étape 3 – Développer et former les capacités de soutien

Fournir aux personnes, aux outils et aux informations la structure dont elles ont besoin pour exécuter le processus de manière fiable auprès de tous les locataires.

Étape 4 – Recueillir des preuves que les incidents sont gérés

Veillez à ce que les incidents laissent une trace écrite détaillée des chronologies, des décisions, des actions et des enseignements tirés, que vous puissiez montrer à d'autres.

En matière de gouvernance, il vous faut une politique de gestion des incidents approuvée, une définition claire de ce qui constitue un « événement » et de ce qui devient un « incident », ainsi que des rôles clairement identifiés, tels que responsable de la gestion des incidents, responsable technique, responsable de la communication et interlocuteur client. Ces rôles doivent disposer de l'autorité nécessaire pour agir rapidement et être reconnus par vos équipes et vos clients.

Un processus désigne un cycle de vie documenté, reconnu et appliqué. Il comprend généralement les étapes suivantes : détection et signalement, évaluation et classification, confinement et éradication, rétablissement et vérification, et enseignements tirés. La norme s’attache moins à la précision des appellations qu’à la documentation, à la communication et à l’application cohérente du processus, afin d’éviter toute improvisation.

Les compétences reposent sur les personnes et les outils. Les analystes et les ingénieurs doivent comprendre le processus et leur rôle au sein de celui-ci. Les systèmes de surveillance et de gestion des incidents doivent faciliter le cycle de vie des projets et non l'entraver. Des communications pré-approuvées, des critères de décision clairs et un accès aux journaux et aux sources de preuves permettent d'assurer la cohérence de ces éléments au quotidien.

L'importance des preuves est souvent sous-estimée par les fournisseurs de services gérés (MSP). Il est essentiel de conserver des enregistrements d'incidents horodatés, détaillant les actions et les approbations, les comptes rendus d'exercices et de formations, les conclusions des analyses post-incident et les discussions de la direction sur les tendances et l'efficacité des incidents. Des plateformes comme ISMS.online facilitent la structuration et l'harmonisation de ces éléments au sein du système de gestion de la sécurité de l'information (SGSI), permettant ainsi leur production rapide en cas de besoin. Notre guide, disponible à l'annexe A.5.24, porte sur la structuration des politiques, des matrices RACI et des enregistrements d'incidents dans un SGSI centralisé, garantissant ainsi la disponibilité de cette traçabilité pour les analyses internes et externes.

En pratique, cette vision à quatre niveaux vous offre une liste de contrôle simple : politiques et rôles en place, processus défini, capacité activée et preuves recueillies. Lorsque vous pouvez cocher ces quatre cases de manière fiable, la norme A.5.24 s’apparente davantage à la description de vos opérations courantes qu’à une exigence externe.

Comment A.5.24 s'intègre au reste de votre système de gestion de l'information (SGSI)

Le point A.5.24 intègre la planification et la préparation aux incidents au système global de gestion de la sécurité de l'information ; il ne s'agit donc pas d'une tâche isolée. Les auditeurs et les clients vérifieront que votre politique de gestion des incidents, vos évaluations des risques, votre gestion des fournisseurs et votre plan de continuité d'activité présentent une vision cohérente de votre traitement des incidents et des pannes de sécurité.

Le point A.5.24 n'est pas un contrôle isolé ; il concerne la quasi-totalité de votre système de gestion de la sécurité de l'information. C'est important, car les auditeurs et les clients recherchent la cohérence, et non un simple document soigné, aussi parfait soit-il.

Environ 41 % des organisations interrogées dans le cadre de notre enquête 2025 ISMS.online sur l'état de la sécurité de l'information ont déclaré que la gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs constituent l'un de leurs plus grands défis en matière de sécurité de l'information.

Il est lié à d'autres contrôles relatifs aux incidents concernant l'évaluation, la réponse et l'apprentissage. Les contrôles de journalisation et de surveillance facilitent la détection et la collecte de preuves. Les contrôles de continuité d'activité et de fournisseurs influencent la manière dont vous gérez les interruptions de service et les défaillances de tiers. Les clauses fondamentales du SMSI relatives aux compétences, à la sensibilisation, à l'évaluation des performances et à l'amélioration déterminent comment vous formez le personnel, mesurez les résultats et perfectionnez le système au fil du temps.

Pour les fournisseurs de services gérés (MSP), le véritable changement consiste à ne plus se demander « Avons-nous une politique de gestion des incidents ? » mais plutôt « Pourrions-nous justifier notre capacité de gestion des incidents, sur le papier et en pratique, auprès d'un auditeur, d'un organisme de réglementation et d'un client stratégique ? ». Considérée sous cet angle, la norme A.5.24 devient le pilier de votre démarche de démonstration de préparation, et non plus une simple case à cocher. Elle permet également d'instaurer un dialogue constructif sur les responsabilités de chacun lorsqu'un incident implique à la fois votre entreprise et vos clients.

Transformer A.5.24 en un cadre de travail commun à tous les clients

Un cadre A.5.24 opérationnel pour un fournisseur de services gérés (MSP) doit proposer un socle commun à tous les clients, tout en respectant les responsabilités et obligations réglementaires propres à chaque client. Concevoir ce modèle « socle et variations » une seule fois, puis le réappliquer à chaque client, évite de devoir repenser la gestion des incidents pour chaque contrat et réduit le risque de dérives ingérables.

Étant donné que vous gérez de nombreuses organisations, il est impossible de concevoir un cadre de gestion des incidents différent pour chaque client et de garantir sa mise à jour constante. Vous définissez donc un modèle de base applicable à l'ensemble de votre portefeuille, puis vous adaptez les responsabilités et les procédures d'escalade à chaque client, en utilisant vos contrats pour refléter ces différences.

En pratique, cela se traduit par un ensemble standard de politiques et de procédures de gestion des incidents, ainsi que par des scénarios et des manuels d'exploitation réutilisables, le tout aligné sur la norme A.5.24 et les contrôles associés. Les dispositions spécifiques à chaque client, telles que les règles de notification ou les obligations réglementaires, viennent ensuite s'ajouter à ce socle commun. Une plateforme de gestion de la sécurité de l'information (SGSI) offre un environnement idéal pour ce modèle, en centralisant les politiques, les risques, les fournisseurs, la continuité d'activité et la gestion des incidents, garantissant ainsi la cohérence des mises à jour et des révisions pour tous vos clients.

Une fois ce cadre partagé en place, l'étape logique suivante consiste à définir précisément la répartition des responsabilités entre votre équipe et chaque client ; c'est là qu'interviennent des rôles clairs, des matrices RACI et des limites définies.

ISMS.online vous donne une longueur d'avance de 81 % dès votre connexion

La norme ISO 27001 simplifiée

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.

Commencer

Définition des rôles du fournisseur de services gérés (MSP) et du client, de la matrice RACI et des limites

Des rôles et des limites clairement définis entre votre fournisseur de services gérés (MSP) et chaque client sont tout aussi importants que le processus technique en cas d'incidents graves. Sans responsabilités clairement définies, vous risquez de ne pas respecter les délais réglementaires, de retarder le confinement et de créer des communications contradictoires qui nuisent à la confiance. L'article 5.24 exige que vous régliez ces questions avant qu'un incident ne survienne, et non lorsque la situation est déjà sous pression.

Chaque incident grave impliquant un client soulève les mêmes questions quant à la responsabilité des décisions, aux personnes habilitées à communiquer avec les parties prenantes externes et aux responsabilités réglementaires. Il est bien plus facile de répondre à ces questions si elles ont été tranchées en amont. La norme A.5.24 exige que ces points soient réglés avant que la situation ne dégénère, et non en pleine attaque, au milieu de débats sur les responsabilités. Des rôles clairement définis constituent le fondement d'une gestion efficace des incidents pour les fournisseurs de services gérés (MSP).

Pourquoi avez-vous besoin de rôles et de limites adaptés aux locataires ?

Des rôles et des limites clairement définis pour les locataires garantissent que votre équipe et votre client prennent des décisions au bon moment, avec le niveau d'autorité approprié et en ayant une compréhension partagée des responsabilités de chacun. Toute ambiguïté dans ces limites transforme rapidement un problème technique gérable en un problème de confiance qui nuit aux renouvellements de contrats et aux recommandations.

L'ambiguïté des rôles est l'un des moyens les plus rapides de transformer un incident gérable en crise de confiance. Si votre équipe part du principe que le client informera les autorités de réglementation, tandis que le client suppose que vous lui indiquerez quand le faire, des échéances importantes peuvent être manquées sans qu'aucune mesure ne soit prise. Si personne ne sait qui approuve les mesures de confinement perturbatrices, les ingénieurs hésitent, les discussions s'enlisent et les dégâts s'aggravent pendant que chacun attend des instructions.

Une matrice RACI (Responsable, Autorité, Consulté, Informé) adaptée au locataire offre une méthode simple et reproductible pour attribuer les rôles. Pour chaque phase du cycle de vie d'un incident, vous définissez l'activité dans votre contexte, les parties impliquées et le partage des responsabilités. Ce modèle alimente ensuite les contrats, les procédures et les guides de bonnes pratiques, garantissant ainsi la cohérence entre la réalité et la documentation et la connaissance des attentes de chaque partie.

Création d'une matrice RACI pratique entre un fournisseur de services gérés et un client

Une matrice RACI pratique pour la relation MSP-client repose sur un modèle générique qui reflète vos méthodes de travail actuelles, puis s'adapte à la criticité du client et à la réglementation sans en modifier la structure de base. Cela simplifie le travail de vos équipes tout en offrant aux responsables de compte la flexibilité nécessaire pour négocier les responsabilités spécifiques à chaque client lorsque cela s'avère pertinent.

Un bon point de départ est une matrice RACI générique pour un client « type », adaptée à la criticité et à la réglementation. Vous pouvez ensuite ajuster le modèle au cas par cas sans avoir à le recréer systématiquement, tout en conservant la même structure familière à vos équipes.

Un exemple narratif simple pourrait ressembler à ceci :

Phase d'incident	Rôle du client (résumé)	Rôle du MSP (résumé)
Détection et signalement	Reçoit et transmet les rapports des utilisateurs	Surveille les systèmes et transforme les alertes en tickets.
Triage et évaluation	Fournit un contexte d'impact commercial	Classifie et hiérarchise les événements et les incidents
Confinement	Approuve les actions perturbatrices	Propose et met en œuvre des mesures de confinement technique
Notification	Responsable des rapports réglementaires et publics	Fournit des détails techniques et des informations sur le calendrier
Les leçons apprises	Définit l'appétit pour le risque et les changements	Documente la cause profonde et propose des améliorations

L'essentiel n'est pas tant la formulation exacte que la clarification des points à clarifier. Aucune activité ne doit se dérouler dans un contexte où chaque partie présume tacitement que l'autre agira. Lors de la rédaction des descriptions de services, des SLA, des accords de niveau opérationnel et des supports d'intégration, cette matrice RACI doit être clairement visible afin que les promesses commerciales, la réalité opérationnelle et les attentes des clients soient alignées.

Gestion des organismes de réglementation, des preuves et des tiers

La gestion des organismes de réglementation, des preuves et des tiers exige bien plus que des formulations génériques dans vos contrats ; vous avez besoin de mécanismes de déclenchement, de décisions et de transferts spécifiques pour les situations où des délais et des normes juridiques s’appliquent. Bien définir ces mécanismes dans votre matrice RACI vous protège, vous et vos clients, lorsque des incidents attirent l’attention de tiers.

La plupart des organisations citées dans notre rapport 2025 d'ISMS.online sur l'état de la sécurité de l'information ont déclaré avoir été touchées par au moins un incident de sécurité lié à un tiers ou à un fournisseur au cours de l'année écoulée.

Certaines responsabilités nécessitent une attention particulière afin d'éviter les surprises en cas de crise, car des parties externes sont impliquées et les délais sont fixes.

Le respect des délais réglementaires est essentiel. Si un client impose des délais de notification légaux, vos contrats et procédures doivent préciser qui décide de la nécessité de déclarer un incident, qui déclenche le délai et qui soumet les notifications. Les recommandations publiques relatives au signalement des incidents insistent fréquemment sur l'importance de critères de notification clairs, de responsabilités définies et de délais convenus, notamment lorsque des délais légaux s'appliquent. Votre processus de gestion des incidents doit prévoir des mécanismes d'alerte pour déclencher ces décisions en temps voulu, ainsi que des procédures d'escalade clairement identifiées en cas de désaccord.

La question de la propriété des preuves est un autre sujet sensible. Il est indispensable de définir des accords sur le partage des journaux, captures d'écran et autres éléments de preuve, ainsi que sur le maintien de la chaîne de traçabilité. Traiter les données clients comme un simple outil de commodité interne ne résistera pas à un examen juridique ou réglementaire lorsque les enquêteurs s'interrogeront sur la manière dont vous les avez collectées et protégées.

Les prestataires tiers complexifient la gestion des incidents. Nombre d'entre eux impliquent des plateformes cloud, des fournisseurs SaaS ou des opérateurs. Votre matrice RACI doit préciser qui contacte quel prestataire, quelles informations sont transmises et comment ces interactions sont consignées dans votre système de gestion des incidents, afin de pouvoir démontrer votre diligence ultérieurement.

Les fonctions non techniques, telles que celles liées à la protection des données, aux affaires juridiques et aux ressources humaines, doivent également avoir une place définie dans le processus. Se contenter de les mentionner comme « nous les impliquerons si nécessaire » ne suffit pas ; il leur faut des conditions de déclenchement et des actions attendues afin que leur travail s’intègre harmonieusement à la réponse technique. Une fois ces limites clairement définies, vous pouvez les intégrer aux politiques, procédures, guides et manuels d’exploitation qui constituent votre bibliothèque de gestion des incidents.

Conception de politiques, de procédures, de guides et de manuels d'exploitation

Votre capacité de gestion des incidents ne sera applicable à l'ensemble de vos clients que si vous l'organisez comme une bibliothèque structurée et hiérarchisée de politiques, de procédures, de scénarios et de manuels d'exploitation, plutôt que comme un plan unique et complexe. Chaque niveau doit répondre à une question spécifique et être destiné à un public différent, allant des dirigeants qui approuvent la politique aux analystes qui suivent les manuels d'exploitation dans des délais serrés.

Pour un fournisseur de services gérés (MSP), une capacité efficace de gestion des incidents ne se résume pas à un simple document de « plan de réponse aux incidents » exhaustif. Il s'agit plutôt d'une bibliothèque concise et cohérente de politiques, de procédures, de guides et de manuels d'exploitation, utilisables par différents utilisateurs à différents niveaux de détail, et tous liés à la norme A.5.24 et à la matrice RACI de votre relation MSP-client. La conception réfléchie de cette bibliothèque vous permet d'adapter votre approche et de garantir sa crédibilité lors des évaluations.

Construire une petite bibliothèque structurée plutôt qu'un projet monstrueux

Une bibliothèque structurée en couches évite que votre documentation d'incidents ne devienne illisible et obsolète, car chaque document a une fonction et un public clairement définis. Les politiques définissent l'intention, les procédures définissent le cycle de vie, les playbooks définissent les scénarios et les runbooks définissent les étapes d'exécution. Ensemble, ils offrent à vos équipes et à vos auditeurs une vision cohérente de la manière dont vous gérez les incidents.

On peut concevoir la bibliothèque comme quatre niveaux répondant à différentes questions : pourquoi, quoi, comment et avec quels outils. La clarté de ces niveaux évite l’encombrement des documents et permet au personnel de trouver rapidement l’information nécessaire, même sous pression, en quelques secondes.

Étape 1 – Rédiger une politique de gestion des incidents concise

Définissez la portée, l'intention et les responsabilités de haut niveau dans une déclaration concise et approuvée, compréhensible par tous.

Étape 2 – Définir une procédure générique de gestion des incidents

Décrire les phases du cycle de vie, les points de décision et les règles d'escalade au niveau du processus, indépendamment des outils spécifiques.

Documentez les éléments déclencheurs, les objectifs, les rôles, les actions et les communications pour les scénarios courants auxquels vos clients sont réellement confrontés.

Étape 4 – Maintenir à jour les manuels techniques spécifiques à chaque outil

Afficher les actions étape par étape sur les plateformes spécifiques référencées par les playbooks, prêtes à être utilisées par les analystes et les ingénieurs.

La politique explique pourquoi les incidents sont gérés, leur périmètre et qui en est responsable. La procédure traduit cette intention en un cycle de vie cohérent et indique quand passer d'une phase à l'autre. Les playbooks transforment le processus générique en instructions concrètes et spécifiques à chaque scénario, que les analystes peuvent suivre. Les runbooks ancrent ces scénarios dans des outils réels afin que les ingénieurs n'aient pas à improviser les étapes techniques le jour J.

Choisir les premiers manuels de jeu qui comptent

Vos premiers guides de procédures doivent couvrir les incidents les plus probables et les plus dommageables pour votre clientèle, et non tous les scénarios théoriques. Se concentrer sur un petit nombre de cas à fort enjeu facilite la formation du personnel, l'amélioration des procédures par la pratique et la démonstration concrète d'une couverture efficace auprès des clients et des auditeurs.

Vous n'avez pas besoin de dizaines de scénarios pour commencer ; en réalité, une bibliothèque surchargée est plus difficile à maintenir et a moins de chances d'être utilisée. Il est plus efficace de rédiger quelques scénarios pertinents adaptés à votre clientèle et à votre environnement technologique, puis de les affiner par une utilisation concrète et des exercices structurés.

Les candidats idéaux pour l'élaboration de plans d'action MSP incluent souvent :

Logiciel malveillant ou rançongiciel sur un terminal géré chez un client typique.
Compromission de la messagerie professionnelle sur une plateforme de messagerie cloud standard.
Compromission d'un compte privilégié dans un annuaire ou une console cloud.
Activité suspecte sur une plateforme de gestion à distance partagée.
Dégradation des services multilocataires pouvant être liée à la sécurité.

Chaque procédure doit définir le déroulement de l'incident, les objectifs immédiats, les rôles de chacun, les décisions clés à prendre et les preuves à recueillir. Des modèles courts et uniformes facilitent leur gestion et leur utilisation par les analystes, même sous pression. Ils simplifient également l'intégration des nouveaux collaborateurs.

Les manuels d'exploitation précisent ensuite les spécificités de chaque outil, par exemple comment isoler un hôte dans un outil de détection de points de terminaison particulier ou comment exporter les journaux d'une plateforme cloud spécifique. Leur séparation des politiques et procédures évite des modifications constantes de ces dernières lors de changements d'outils ou de l'adoption de nouvelles plateformes pour différents segments de clients.

Maintenir des documents utilisables et conformes à la réalité

Votre documentation n'est utile que si elle reflète vos pratiques actuelles et si vos collaborateurs peuvent facilement la consulter en cas de besoin. Un contrôle des modifications simple, une attribution claire des responsabilités et une intégration aux outils quotidiens garantissent la cohérence de votre documentation avec les pratiques en vigueur et démontrent aux auditeurs que vous assurez la maintenance, et non la simple création, de vos documents relatifs aux incidents.

Les documents qui restent dans un dossier isolé et ne sont jamais modifiés se déconnectent rapidement des pratiques réelles, ce qui nuit à la fois à la préparation et à la crédibilité des audits. Pour maintenir votre bibliothèque à jour, mettez en place une procédure de gestion des changements simple et associez les mises à jour directement aux incidents et aux exercices.

Après des incidents ou exercices majeurs, analysez les documents utiles, ceux qui manquaient et ceux qui étaient inexacts. Mettez à jour les politiques, procédures, manuels et guides d'exploitation pertinents de manière réfléchie, en utilisant un système de contrôle de version et d'approbation simplifié. L'objectif est d'assurer la cohérence entre les directives écrites et les pratiques réelles sans noyer l'équipe sous la bureaucratie ni ralentir les changements essentiels.

Il est également utile d'intégrer ces documents là où le travail s'effectue. Lier les playbooks et les manuels d'exploitation directement aux tickets d'incident ou aux tableaux de bord SOC favorise grandement leur utilisation, plutôt que de laisser les utilisateurs effectuer des recherches dans un référentiel externe. ISMS.online et les plateformes similaires peuvent servir de colonne vertébrale, reliant vos politiques et procédures aux risques, aux fournisseurs, aux plans de continuité d'activité et aux enregistrements d'incidents, afin que le personnel dispose toujours de directives à jour. Une fois la bibliothèque en place, le prochain défi consiste à s'assurer que vos outils de gestion des tickets, de surveillance et de SOC reflètent bien cette conception.

Intégrez, développez et faites évoluer votre conformité, sans complications. IO vous offre la résilience et la confiance nécessaires pour croître en toute sécurité.

Réservez votre démo

Intégration de la norme A.5.24 aux opérations de billetterie, de surveillance et de SOC

L'article A.5.24 n'apporte de valeur que si la conception de votre gestion des incidents est intégrée aux outils utilisés quotidiennement par vos équipes. Pour la plupart des fournisseurs de services gérés (MSP), le centre de services ou la plateforme de gestion des services informatiques (ITSM) doit servir de système de référence pour les incidents, tandis que les outils de surveillance et de SOC y contribuent de manière prévisible. Lorsque ces outils reflètent vos processus, vos rôles et votre modèle de preuves, vous pouvez démontrer votre maîtrise des incidents au lieu de vous fier à des récits et à des souvenirs.

L'article A.5.24 n'apporte de valeur que s'il est intégré à vos outils quotidiens et aux méthodes de travail de vos équipes. Pour la plupart des fournisseurs de services gérés (MSP), le système de gestion des services informatiques (ITSM) ou le centre de services d'assistance doit servir de système de référence pour les incidents, les outils de surveillance et de centre opérationnel de sécurité (SOC) y alimentant les données de manière contrôlée. Les bonnes pratiques de gestion des incidents recommandent généralement un enregistrement unique et centralisé pour chaque incident, les systèmes de détection et les équipes d'intervention y contribuant plutôt que de tenir des journaux séparés et fragmentés. Lorsque ces outils reflètent vos processus et vos rôles, votre niveau de préparation devient une réalité tangible, et non une simple affirmation.

Faire de l'outil ITSM votre système d'enregistrement des incidents

En considérant votre plateforme ITSM comme le système de référence pour la gestion des incidents, vous garantissez que chaque événement important laisse une trace structurée que vous pouvez consulter et partager. Lorsque les catégories, les flux de travail et les champs sont alignés sur la norme A.5.24 et votre cycle de vie des incidents, vous n'avez plus besoin de courriels épars ni de journaux de discussion pour reconstituer le déroulement des faits ; le ticket lui-même devient le récit de référence pour les auditeurs et les clients.

Si les événements et incidents de sécurité sont éparpillés dans des échanges de courriels, des messageries instantanées et des documents informels, il est difficile de prouver la maîtrise de la situation ou de tirer des enseignements de l'expérience. En revanche, lorsque votre configuration ITSM est alignée sur votre processus de gestion des incidents, chaque événement important laisse une trace structurée que vous pouvez consulter et présenter aux clients, aux auditeurs et aux assureurs sans difficulté.

Étape 1 – Définir comment les alertes deviennent des incidents

Définir quelles alertes doivent ouvrir des tickets et comment les analystes confirment et classent les incidents avant leur escalade.

Étape 2 – Configurer les catégories, les priorités et les flux de travail

Configurez des catégories de sécurité, des niveaux de gravité et des états de cycle de vie dédiés qui reflètent votre processus documenté.

Étape 3 – Collecter des données structurées pour chaque incident

Ajoutez des champs et des modèles pour la source de détection, l'impact, les approbations, les communications et les leçons apprises.

Commencez par définir comment les alertes de surveillance sont intégrées à l'outil ITSM. Les systèmes de surveillance doivent soit créer automatiquement des tickets, soit alimenter une file d'attente de triage où les analystes décident d'ouvrir ou de mettre à jour les incidents. Une fois un incident confirmé, il doit être clairement identifié comme étant lié à la sécurité et se voir attribuer un niveau de gravité convenu, en fonction de son impact et de son urgence, afin d'assurer une réponse cohérente.

Configurez les catégories et les sous-types afin de distinguer les incidents de sécurité des problèmes de service courants. Définissez les états du cycle de vie (ouvert, triage, investigation, confinement, rétablissement, examen et fermé) et assurez-vous que les tickets y transitent de manière contrôlée. Ajoutez des champs et des modèles pour les données clés de l'article 5.24 (source de détection, actifs affectés, décisions importantes, approbations et communications) afin que les examinateurs puissent suivre le déroulement des événements en un coup d'œil.

Pour illustrer cela concrètement, imaginez une alerte de ransomware sur un poste de travail géré. L'outil de surveillance génère un événement qui ouvre un ticket « Incident de sécurité », pré-rempli avec la source, l'hôte affecté, la règle de détection et le niveau de gravité. Les analystes suivent ensuite un formulaire structuré pour consigner les décisions de priorisation, les actions de confinement, les notifications aux clients et les étapes finales de récupération, le tout dans un seul et même enregistrement. Le ticket ainsi créé se présente comme une chronologie, et non comme un puzzle.

Connexion de la surveillance, du SOC et des communications clients

Les outils de surveillance et de SOC nécessitent des procédures claires et documentées pour l'intégration à votre processus de gestion des incidents, afin que les alertes, les investigations et les mises à jour client restent cohérentes. L'objectif est un flux contrôlé où les systèmes techniques créent ou mettent à jour les tickets, les analystes les affinent et les escaladent, et les équipes commerciales communiquent de manière à ce que vous puissiez les retracer et les expliquer ultérieurement.

Côté supervision et SOC, il est essentiel d'avoir des flux clairs et explicites entre les alertes et les enregistrements. Les systèmes SIEM (Security Information and Event Management), les outils EDR (Endpoint Detection and Response), les plateformes de sécurité cloud et autres sources doivent créer ou mettre à jour les tickets selon des règles définies dans vos procédures et playbooks. L'optimisation de ces règles pour réduire les faux positifs et les doublons représente un gain d'efficacité et témoigne d'une réflexion approfondie sur la détection.

En cas d'incident grave, vous pouvez mettre en place un mécanisme de communication, comme un canal de discussion dédié à la cellule de crise ou des téléconférences planifiées. Les interventions, les décisions et les messages importants échangés lors de ces échanges doivent être consignés dans le rapport d'incident afin d'éviter d'avoir à les reconstituer ultérieurement à partir de transcriptions et de souvenirs, lorsqu'une personne demande une chronologie des événements.

La communication avec les clients doit suivre la même structure. Les changements de gravité doivent entraîner des changements d'état internes et, le cas échéant, des mises à jour externes via des pages de statut, des courriels ou des appels du gestionnaire de compte. L'utilisation de modèles de messages préapprouvés et de circuits d'approbation clairs réduit le risque de déclarations incohérentes ou trompeuses sous pression et permet de démontrer plus facilement que vous avez pris des mesures opportunes et réfléchies.

Tirer des enseignements de chaque incident pour améliorer le système

Vos outils et vos flux de travail doivent évoluer après chaque incident majeur afin de faciliter la gestion et la justification du suivant. Intégrer des phases d’« examen et d’amélioration » à votre processus transforme la norme A.5.24 en un moteur de maturité opérationnelle plutôt qu’en une simple obligation de conformité.

L'objectif de planification et de préparation du point A.5.24 n'est atteint que si vous utilisez les incidents pour améliorer votre système, au lieu de les traiter comme des problèmes ponctuels à résoudre. Cela implique de mettre en place un processus reproductible d'analyse des incidents et d'intégrer leurs conclusions dans un processus de changement dont vous pouvez suivre l'évolution.

Après chaque incident majeur, demandez-vous si les outils et les processus vous ont été utiles ou non. Disposiez-vous de toutes les informations nécessaires au même endroit ? Certaines étapes manuelles auraient-elles pu être automatisées ? Le ticket fourni relatait-il clairement le déroulement des événements, de la détection à la résolution, de manière à ce qu’une autre personne puisse le suivre ?

Transformez ces réflexions en actions : ajustez les catégories, optimisez les flux de travail, modifiez les modèles, améliorez les procédures ou mettez à jour les contrats. Consignez les actions d’amélioration de manière à pouvoir en suivre la finalisation et les mentionner lors des réunions de revue de direction. Au fil du temps, cela transforme le point A.5.24, d’un simple contrôle statique, en un moteur d’amélioration continue pour vos opérations MSP et soulève naturellement des questions sur la conception et la protection des éléments de preuve sur lesquels reposent ces revues.

Preuves, journalisation et préparation aux enquêtes numériques pour les fournisseurs de services gérés multilocataires

La norme A.5.24 suppose que vous pouvez démontrer comment les incidents ont été gérés, et non pas simplement affirmer qu'ils l'ont été de manière appropriée. Pour les fournisseurs de services gérés (MSP), cela représente un défi, car il faut concilier la qualité des preuves, la séparation des locataires et les obligations de confidentialité pour de nombreux clients et fournisseurs, tout en maîtrisant les coûts. Un modèle de preuves structuré et documenté permet de transformer cet exercice d'équilibrage en une pratique reproductible, plutôt qu'en une course contre la montre. Les commentaires relatifs à ce contrôle soulignent souvent la nécessité de conserver des enregistrements et des éléments concrets démontrant la planification, la prise de décision et le suivi, et non de simples déclarations générales concernant une intervention.

Concevoir un modèle de preuves adapté à chaque locataire

Un modèle de preuves par locataire vous aide à éviter les angles morts et les fuites de données accidentelles en définissant les journaux et les artefacts collectés, leur emplacement et leur lien avec les enregistrements d'incidents. Lorsque ce modèle est compris de tous, vous pouvez répondre aux enquêtes avec assurance au lieu de devoir fouiller dans des archives non gérées.

Un modèle de preuves simple et documenté pour chaque client vous aide à éviter les lacunes et les divulgations accidentelles de données. Ce modèle doit préciser quels journaux et artefacts collecter, où ils sont stockés, comment les horloges sont synchronisées et comment les enregistrements sont liés aux incidents dans vos outils ITSM ou de gestion des cas.

Étape 1 – Lister les sources de journaux de frappe et d'événements par client

Identifiez les systèmes qui génèrent des enregistrements pertinents en matière de sécurité et comment y accéder rapidement.

Étape 2 – Définir les règles de stockage, de synchronisation horaire et de conservation

Documentez l'emplacement des données, la manière dont les horloges sont synchronisées et la durée de conservation de chaque type d'enregistrement.

Étape 3 – Relier les preuves aux dossiers d'incidents

Décrivez comment les journaux, les artefacts et les décisions sont associés aux tickets pour un examen et des audits ultérieurs.

Il n'est pas nécessaire de fournir un schéma détaillé pour chaque client, mais vous devez pouvoir expliquer, par exemple, que les journaux de sécurité des systèmes définis sont centralisés dans des référentiels ou des espaces de stockage bien définis, que les horloges sont synchronisées pour assurer la cohérence des chronologies entre les plateformes et que l'accès à ces espaces de stockage est contrôlé et consigné. Cette explication doit être conforme à vos politiques et à vos contrats.

Lier des preuves à des incidents peut être aussi simple que d'associer des extraits de journaux, des rapports ou des références à des référentiels spécifiques dans vos tickets ITSM. L'essentiel est que quelqu'un puisse ultérieurement reconstituer l'incident à partir de l'enregistrement sans avoir à parcourir des systèmes et des comptes entiers, et qu'il puisse comprendre pourquoi certaines décisions ont été prises à des moments précis.

Obtenir les droits de rétention, d'accès et de ségrégation

La conservation, l'accès et la séparation des données relatives aux incidents doivent concilier obligations légales, attentes des clients et impératifs opérationnels. Un volume excessif de données conservées trop longtemps accroît les risques ; à l'inverse, un volume insuffisant ou une suppression trop systématique des données vous empêchera de mener des enquêtes ou de démontrer votre diligence raisonnable en cas de contrôle.

Les décisions relatives à la conservation et à la suppression des données se situent à la croisée de la sécurité, de la confidentialité et des coûts. Conserver toutes les données trop longtemps accroît les risques et peut enfreindre les règles de confidentialité ; une suppression trop rapide vous empêche de répondre à des questions légitimes après un incident ou de contribuer aux procédures judiciaires.

Documentez vos choix concernant les différents types de données, tels que les journaux bruts, les événements agrégés et les éléments d'enquête. Indiquez les cas où une durée de conservation plus longue est appliquée pour des raisons réglementaires ou contractuelles, et définissez les déclencheurs qui étendent la conservation lors d'incidents spécifiques, comme les mises sous séquestre ou les enquêtes d'assurance. Expliquez comment et quand les données sont supprimées de manière sécurisée et assurez-vous que cette pratique est conforme à vos politiques et accords clients.

Dans un environnement multi-locataires, la ségrégation est aussi importante que la fidélisation. Vous souhaitez avoir la certitude que :

Les analystes qui enquêtent sur un client ne peuvent pas consulter négligemment les données d'un autre client.
Les actions administratives effectuées sur les journaux de bord et les systèmes de preuves sont elles-mêmes consignées et font l'objet d'un examen périodique.
Lorsque vous partagez des documents avec des clients, vous le faites en utilisant des canaux approuvés et sécurisés, dotés de contrôles d'accès clairs.

Ces exigences doivent figurer dans votre modèle de preuves et dans vos procédures opérationnelles. Si vous utilisez une plateforme de gestion de la sécurité de l'information (SGSI), vous pouvez souvent centraliser les références de preuves tout en conservant les données sous-jacentes dans des espaces de stockage techniques segmentés, ce qui vous permet de maintenir la séparation des données sans perdre la visibilité de leur emplacement.

Intégrer la collecte de preuves dans le travail quotidien

La collecte de preuves doit être intégrée aux activités quotidiennes de réponse aux incidents et non considérée comme une option secondaire si vous souhaitez obtenir des enregistrements fiables conformément à la norme A.5.24. En transformant les étapes clés de la collecte de preuves en cases à cocher dans les manuels de procédures, les guides d'exécution et les modèles de tickets, vous facilitez la tâche des analystes pour qu'ils agissent correctement même sous pression.

Il ne faut pas se préoccuper des preuves après la clôture d'un incident, mais pendant l'exécution des procédures et des scénarios en temps réel. Si la collecte de preuves est perçue comme une tâche supplémentaire, elle sera négligée sous la pression, et vous ne découvrirez le problème que lorsque des questions difficiles seront posées.

Pour éviter cela, concevez des procédures et des guides d'exécution de manière à ce que les actions clés incluent des étapes de preuve explicites. Par exemple, avant d'isoler un hôte, les analystes capturent des captures d'écran convenues ou exportent des journaux spécifiques ; après la réinitialisation des identifiants, ils consignent les comptes modifiés et la date ; lors de la notification d'un client, ils joignent la déclaration approuvée et indiquent qui l'a signée et à quelle heure.

Les incidents clos constituent d'excellents échantillons pour les audits. Sélectionnez-en périodiquement quelques-uns et examinez-les comme si vous étiez un auditeur, un organisme de réglementation ou un client stratégique. Demandez-vous si vous pouvez établir un calendrier complet, de la détection à la clôture, si la justification des actions clés est claire et si les preuves jointes satisferaient un auditeur externe. Si la réponse est négative, améliorez votre modèle de preuves, votre documentation et votre formation afin que le prochain incident similaire produise de meilleurs enregistrements et une analyse plus approfondie, jetant ainsi les bases d'exercices plus ciblés.

ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.

Réservez votre démo

Formation, exercices et intégration du SMSI dans les sections A.5.24 à A.5.30

La formation et les exercices transforment votre plan A.5.24 en une solution opérationnelle concrète, utilisable même en situation de crise. Pour un fournisseur de services gérés (MSP), cela implique d'associer des rôles spécifiques en cas d'incident à des formations adaptées, de s'entraîner à des scénarios réalistes avec tous les locataires et d'intégrer les enseignements tirés à votre système de gestion de la sécurité de l'information (SGSI) global afin que l'amélioration soit tangible et non pas simplement présumée.

Environ deux tiers des organisations interrogées dans le cadre de notre enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information ont déclaré que la rapidité et le volume des changements réglementaires rendent la conformité en matière de sécurité et de confidentialité plus difficile à maintenir.

Le point A.5.24 part du principe que vos procédures de gestion des incidents sont non seulement documentées, mais également comprises et mises en pratique par les personnes qui doivent les utiliser. Les recommandations des organismes de normalisation en matière de planification de la réponse aux incidents insistent régulièrement sur l'importance de la formation, des exercices et de la familiarisation du personnel avec les procédures, en complément essentiel de la documentation écrite. Pour les fournisseurs de services gérés (MSP), cela implique de développer des compétences spécifiques pour chaque rôle et d'organiser des exercices pour tester la conception et la réactivité de vos procédures auprès de différents clients et dans différents fuseaux horaires. La formation et les exercices permettent de combler l'écart entre des documents précis et la complexité des interventions en situation réelle.

Associer les rôles à la formation dont ils ont réellement besoin

Les différents rôles requièrent une formation adaptée pour identifier les facteurs déclencheurs d'incidents, appliquer les procédures et prendre les bonnes décisions. Associer ces rôles à des objectifs d'apprentissage concrets permet de cibler et de mesurer votre programme de formation, et démontre clairement que la norme A.5.24 est ancrée dans la pratique plutôt que purement théorique.

Une formation générique de sensibilisation à la sécurité ne préparera pas vos équipes à la gestion des incidents multi-locataires, où les responsabilités s'étendent au-delà des frontières organisationnelles. Il est essentiel d'associer les rôles à des objectifs d'apprentissage concrets, puis de s'entraîner en s'appuyant sur vos procédures, manuels et outils réels afin que chacun puisse se projeter dans les scénarios.

Étape 1 – Identifier les rôles liés à l’incident au sein des équipes

Dressez la liste des analystes, ingénieurs, gestionnaires de comptes, responsables de la protection de la vie privée, juristes et décideurs de haut niveau qui interviennent dans les incidents.

Étape 2 – Définir ce que chaque rôle doit reconnaître et faire

Spécifiez les déclencheurs, les actions, les voies d'escalade et les responsabilités de communication pour chaque rôle, y compris le moment du passage de relais.

Utilisez des sessions courtes qui mettent en scène des incidents réalistes en utilisant vos outils réels et les flux de tickets réels.

Les analystes de première ligne et le personnel du service d'assistance doivent identifier les déclencheurs d'incidents, suivre les procédures établies et recueillir des preuves au fur et à mesure. Les ingénieurs doivent exécuter les procédures en toute sécurité, comprendre les options de confinement et savoir quand demander une escalade pour approbation. Les gestionnaires de comptes doivent savoir quand et comment communiquer avec les clients, notamment lors des phases initiales ambiguës. Les cadres supérieurs ont besoin de clarté quant aux situations qui requièrent leur intervention et aux décisions qu'ils pourraient avoir à prendre rapidement avec des informations incomplètes.

La formation est plus efficace lorsqu'elle utilise votre bibliothèque d'incidents et vos outils réels. La simulation d'un scénario de ransomware dans votre environnement de gestion des incidents et de surveillance réel est bien plus efficace qu'une présentation PowerPoint générique, car le personnel voit précisément les écrans, les champs et les flux de travail qu'il utilisera lors du prochain incident.

Concevoir un programme d'exercices qui semble réel

Un programme d'exercices doit permettre de tester à la fois vos équipes et votre conception en simulant des incidents réalistes et limités dans le temps, représentatifs de votre clientèle. En faisant varier les scénarios et les segments de clientèle, vous renforcez la confiance dans la robustesse de votre approche A.5.24 dans différentes conditions et vous démontrez que votre fournisseur de services gérés (MSP) prend la préparation au sérieux.

Variez trois dimensions pour que les exercices restent pertinents :

Type de scénario : – ransomware chez un client clé, compromission d'une plateforme de gestion partagée, suspicion de fuite de données ou mauvaise configuration du cloud.
Segment de clientèle : – clients réglementés versus clients non réglementés, ou comptes à criticité élevée versus moyenne.
Fréquence : – exercices internes trimestriels et exercices conjoints occasionnels avec certains clients présentant le risque le plus élevé.

Les exercices conjoints avec des clients importants peuvent s'avérer particulièrement efficaces. Ils permettent d'harmoniser les attentes, de tester les matrices RACI et de révéler les hypothèses contractuelles qui ne résistent pas à l'épreuve du terrain. Ils fournissent également aux auditeurs et aux comités de gestion des risques des preuves solides de votre engagement en matière de préparation dans les environnements partagés. Les exercices bien menés produisent généralement des comptes rendus, des rapports et des plans d'amélioration que les organismes de contrôle peuvent consulter comme preuves concrètes de la manière dont vous préparez et optimisez vos interventions.

Après chaque exercice, considérez-le comme un incident mineur. Notez ce qui a fonctionné, ce qui n'a pas fonctionné et ce qui doit être modifié dans les documents, les outils ou les accords. Suivez ces actions et intégrez-en un résumé à votre programme de revue de direction afin de démontrer une amélioration continue, et non une simple activité. Ce modèle relie directement le point A.5.24 aux clauses plus générales d'évaluation et d'amélioration des performances de votre SMSI.

Boucler la boucle dans votre système de gestion de l'information (SGSI)

La véritable valeur de la norme A.5.24 se révèle lorsque la planification des incidents, la formation et les exercices contribuent à la gestion des risques, au contrôle des fournisseurs et à la continuité des activités, renforçant ainsi l'ensemble de votre système de gestion de la sécurité de l'information (SGSI). Ce processus vous permet de démontrer que la préparation aux incidents fait partie intégrante de votre mode de fonctionnement et n'est pas une simple préoccupation technique.

Le point A.5.24 s'inscrit au même titre que d'autres mécanismes de contrôle liés aux incidents, tels que l'évaluation, la réponse, l'apprentissage et la continuité des activités, et tous contribuent à l'ensemble de votre système de gestion. Le recours à des exercices et à des formations pour alimenter ces mécanismes transforme la gestion des incidents en un moteur d'amélioration systémique plutôt qu'en un processus isolé.

Par exemple, les enseignements tirés des incidents et des exercices doivent éclairer les évaluations des risques, les évaluations des fournisseurs et les plans de continuité. Des problèmes récurrents sur une plateforme donnée peuvent entraîner des réévaluations des fournisseurs ou des changements technologiques. Des lacunes en matière de formation ou de prise de décision peuvent conduire à des modifications des programmes de formation et de sensibilisation, ou à des ajustements de vos matrices RACI et de vos règles d'escalade.

Centraliser les enregistrements d'incidents, les rapports d'exercices et les actions d'amélioration sur une plateforme comme ISMS.online permet de mettre en évidence ces liens. Cela facilite également la démonstration aux auditeurs de l'influence de votre planification et de votre préparation aux incidents sur le reste de votre système de gestion de la sécurité de l'information, et inversement, créant ainsi un lien naturel avec les discussions sur la manière dont la technologie peut soutenir vos objectifs A.5.24.

Réservez une démo avec ISMS.online dès aujourd'hui

ISMS.online vous aide à transformer la norme ISO 27001 A.5.24 d'un simple contrôle statique en une capacité de gestion des incidents opérationnelle et adaptée aux MSP, que vous pouvez mettre en œuvre et démontrer auprès de tous vos clients. En centralisant les politiques, les matrices RACI, les procédures, les enregistrements d'incidents, les preuves et les actions d'amélioration dans un environnement unique, vous disposez d'une infrastructure de gestion des incidents évolutive, adaptée à votre portefeuille et facile à expliquer aux clients, aux auditeurs et aux assureurs. L'organisation de la planification, des responsabilités et des enregistrements des incidents, conformément à l'annexe A.5.24, est spécifiquement conçue pour aider les MSP à démontrer leur planification et leur mise en œuvre en cas de questionnement.

Ce que vous retirez de la démonstration d'ISMS.online en action

Observer ISMS.online en action est le moyen le plus rapide de déterminer si une mise en œuvre structurée de la norme A.5.24 est adaptée au fonctionnement de votre MSP. Une analyse approfondie permet de retracer un incident réel, de sa détection à l'analyse des enseignements tirés, de visualiser l'emplacement des politiques et des matrices RACI, la cohérence des enregistrements d'incidents avec votre modèle de preuves et la manière dont les vues de gestion centralisent l'ensemble des informations pour la supervision et le reporting.

Une brève démonstration vous permet de tester l'impact d'une approche structurée de gestion des incidents sur vos incidents récents. Vous pouvez ainsi examiner la conformité des politiques et procédures de gestion des incidents avec la norme A.5.24, la mise en place des matrices RACI et des procédures d'intervention, le lien entre les enregistrements d'incidents, les preuves et les actions d'amélioration, et la centralisation de toutes ces informations par la direction. Cette vision d'ensemble facilite l'évaluation de la pertinence de cette approche pour la préparation aux incidents de votre fournisseur de services gérés.

Déterminer si ISMS.online est la solution adaptée

Choisir la bonne plateforme pour la norme A.5.24 revient avant tout à définir le niveau de préparation aux incidents que vous souhaitez offrir à vos équipes et à vos clients. Si vous recherchez une gestion des incidents auditable, évolutive pour plusieurs environnements et intégrée à votre système de gestion de la sécurité de l'information (SGSI) plutôt qu'ajoutée a posteriori, ISMS.online propose une solution pratique et conforme aux normes.

Choisissez ISMS.online si vous recherchez une solution de gestion des incidents auditable, adaptable à vos différents environnements et intégrée à votre système de gestion de la sécurité de l'information. Si vous accordez de l'importance à des audits indépendants, à des preuves structurées et à une source unique d'information fiable à présenter à vos clients, auditeurs et assureurs, nous sommes à votre disposition.

Une discussion portant sur un ou deux incidents réels, et sur la manière dont ils auraient pu se manifester au sein d'un système de gestion de la sécurité de l'information (SGSI) intégré, permettra de déterminer si cette approche constitue la base adéquate pour votre prochaine phase de croissance. Lorsque votre situation actuelle correspond aux lacunes décrites précédemment et que vous êtes prêt à renforcer le point A.5.24 en transformant le chaos des incidents en une capacité structurée et commercialement précieuse, ISMS.online est prêt à vous accompagner.

Demander demo

Foire aux questions

Comment un MSP doit-il interpréter la norme ISO 27001:2022 A.5.24 dans ses opérations quotidiennes ?

La norme ISO 27001:2022, paragraphe 5.24, exige que votre fournisseur de services gérés (MSP) exécuter une capacité d'incident reproductibleIl ne s'agit pas simplement de stocker une « politique de gestion des incidents » dans votre SMSI. Concrètement, cela signifie concevoir, allouer les ressources, exploiter et tester régulièrement un cycle de vie des incidents, et pouvoir démontrer que des cas réels ont respecté cette conception.

Que signifie « planifié et préparé » pour un MSP ?

Pour un fournisseur de services gérés, le point A.5.24 se situe dans quatre domaines très visibles :

Conception: – une politique et une procédure documentée qui correspondent à votre système de gestion de la sécurité de l’information (SGSI) ou à votre système de gestion intégré (SGI) de l’annexe L, avec des définitions claires de ce qui constitue un « incident de sécurité de l’information » pour l’ensemble des locataires et des services.
Personnes: – des rôles nommés qui fonctionnent sur plusieurs fuseaux horaires et pour plusieurs locataires, avec des responsables pour la détection, le triage, le confinement, la communication, la récupération et l'examen.
Exécution: – un cycle de vie que les ingénieurs peuvent suivre sous pression sans avoir à parcourir SharePoint, généralement un flux simple allant de la détection → triage → confinement → récupération → examen.
Preuve: – un système d’archivage qui relie tous les éléments et montre comment les incidents réels ont évolué au cours de ce cycle de vie.

Si un auditeur ou un client important demande à votre équipe de revenir sur le dernier incident grave survenu chez un locataire clé, vous devriez être en mesure de :

Ouvrez un seul enregistrement d'incident dans votre outil ITSM pour ce locataire.
Afficher les horodatages, les changements d'état, la gravité et les rôles attribués.
Indiquez les clauses de politique, les RACI et l'alignement A.5.24.
Indiquez les changements intervenus par la suite : mesures correctives, mises à jour des procédures, formations ou modifications contractuelles.

Une gestion des incidents bien menée paraît ennuyeuse de l'extérieur, car les surprises ont déjà été éliminées dès sa conception.

Lorsque vous gérez ensemble votre politique, vos procédures, vos rôles et vos enregistrements d'incidents dans ISMS.online, vous pouvez démontrer que la norme A.5.24 est intégrée à votre SMSI ou à votre Annexe L du SMSI, plutôt que d'être un document annexe que vous dépoussiérez avant un audit externe.

Comment un MSP doit-il structurer les responsabilités en cas d'incident avec chaque client en vertu de l'A.5.24 ?

Conformément à la section A.5.24, vous devez traiter les responsabilités liées aux incidents comme une modèle partagé conçu par locataireIl ne s'agit pas d'une vague supposition enfouie dans des échanges de courriels. Les auditeurs et les clients professionnels rechercheront des signes indiquant que vous avez défini – et documenté – les rôles et responsabilités de chacun à chaque étape d'un incident, et que les deux parties reconnaissent cette répartition.

Comment concevoir un modèle de responsabilité partagée clair ?

Une méthode pratique qui fonctionne dans la plupart des environnements MSP est la suivante :

Commencez par une matrice RACI standard : qui correspond à votre flux d'incidents habituel : détection, triage, confinement, éradication, rétablissement, notification, communication et examen.
Définissez des valeurs par défaut raisonnables : pour vos services gérés, par exemple :
Votre fournisseur de services gérés (MSP) : responsable de la détection et du confinement des menaces au sein des plateformes et services gérés.
Le client : responsable des notifications réglementaires, des communications avec les clients et des décisions commerciales ayant une incidence sur ses propres opérations.
Partagé : fournir des preuves, convenir d’actions perturbatrices, définir ce qui est « important » ou « à notifier ».
Ajustement par locataire : au lieu de réinventer la roue :
Les secteurs à risque plus élevé ou réglementés (finance, santé, secteur public) peuvent avoir besoin d’engagements de notification plus rapides et de décisions plus conjointes.
Les équipes de sécurité internes les plus sophistiquées peuvent souhaiter davantage de contrôle ; les clients plus petits peuvent s’attendre à ce que vous gériez presque tout.

Ces RACI doivent se trouver là où les équipes les trouveront et les maintiendront – généralement au sein de votre ISMS ou IMS, liés à A.5.24, aux contrôles des fournisseurs tels que A.5.19 et aux descriptions de service pertinentes.

Comment rendre visibles les responsabilités partagées lors d'incidents réels ?

Une séparation conçue n'est utile que si elle apparaît dans les outils et les objets que les gens manipulent sous pression:

Contrats et SLA : Se référer au modèle d'incident partagé et définir les attentes en matière de délais de détection, de notification et de réponse.
Modèles de billets : inclure des champs tels que « Responsable de l'incident client », « Responsable des notifications réglementaires », « Approbateur des actions perturbatrices » et « Responsable de la communication ».
Livres de jeu : Indiquez clairement qui déclenche quelle décision, qui s'adresse à quel groupe de parties prenantes et quelles approbations sont requises à chaque étape.

Lorsque vous pouvez démontrer que la même conception partagée apparaît de manière cohérente dans les contrats, les matrices RACI, les champs de tickets, les manuels et un rapport d'incident récent spécifique au locataire, vous facilitez la confiance accordée à la norme A.5.24 par les auditeurs et les grands acheteurs, et vous la rendez beaucoup plus facile à suivre pour vos équipes auprès de centaines de clients.

De quels manuels d'intervention et de procédures d'exploitation un fournisseur de services gérés (MSP) a-t-il réellement besoin pour la version A.5.24 ?

A.5.24 ne récompense pas un wiki surchargé que personne n'ouvre à 2h du matin. Il s'attend à un ensemble restreint de manuels de jeu et de guides d'exécution qui couvrent vos menaces les plus probables, en adéquation avec les services que vous exploitez réellement et les outils que votre SOC et vos ingénieurs utilisent réellement.

La plupart des fournisseurs de services gérés (MSP) bénéficient d'une couverture solide grâce à 4 à 7 playbooks bien conçus et adaptés à leurs environnements gérés, par exemple :

Logiciels de rançon ou logiciels malveillants destructeurs : sur les points de terminaison ou les serveurs gérés.
Compromission de la messagerie professionnelle : – prise de contrôle de compte, lassitude face à l'authentification multifacteur, règles de transfert risquées.
Compromission de compte privilégié : – administrateurs, comptes de service, identités de secours.
Suspicion d'exfiltration de données : à partir d'un environnement cloud géré ou sur site.
Incident lié à une plateforme mutualisée : – lorsqu’un outil ou un service courant présente un dysfonctionnement et que la sécurité peut ou non en être la cause première.
Compromission d'un SaaS tiers : qui affecte plusieurs locataires via votre infrastructure gérée.

Chaque plan de jeu devrait répondre aux mêmes questions fondamentales :

Qu'est-ce qui déclenche généralement ce scénario ?
Qui dirige et qui apporte son soutien, au sein de votre organisation et du côté client ?
Comment évaluez-vous la gravité et quand décidez-vous de passer à l'étape supérieure ?
Quand et comment impliquer le client, les aspects juridiques et la protection de la vie privée ?
Quelles sont les autorisations requises avant des actions à fort impact telles que l'isolement ou l'effacement des données ?
Quelles informations doivent être consignées dans le rapport d'incident à chaque étape pour satisfaire à la section A.5.24 et aux contrôles connexes ?

Comment structurer et maintenir les manuels d'exploitation pour des outils spécifiques ?

Les manuels de jeu décrivent Qui fait quoi et quand ? au niveau des scénarios ; les manuels d'exploitation capturent how pour effectuer des actions spécifiques sur chaque plateforme :

Isoler un périphérique dans votre solution EDR ou de gestion des terminaux.
Verrouillage et réinitialisation des identités chez les principaux fournisseurs de cloud.
Capture d'instantanés de journaux et de télémétrie à partir d'un SIEM, d'un pare-feu ou d'un proxy.
Vérification et nettoyage des règles de boîte aux lettres et des destinations de transfert suspectes.

Conserver les politiques, les manuels et les guides d'exécution séparés mais réticulés L'accès à ISMS.online présente des avantages indéniables :

La gouvernance (formulation des politiques et des contrôles) reste stable malgré l'évolution technologique.
Les ingénieurs savent exactement où chercher la réponse à la question « quelle est la prochaine étape appropriée ? » plutôt que « quelle commande ou quel bouton de console dois-je utiliser ? ».
Vous pouvez montrer aux auditeurs une chaîne propre depuis le texte de politique A.5.24 → le manuel de scénario → le manuel spécifique à la plateforme → les tickets d'incident réels où ces artefacts ont été utilisés.

Si votre référentiel actuel est tentaculaire ou obsolète, commencer par une bibliothèque ciblée qui correspond à vos incidents les plus courants sera plus bénéfique pour A.5.24 – et pour vos clients – qu’une longue liste de documents rarement utilisés.

Comment un fournisseur de services gérés peut-il intégrer la norme A.5.24 dans ses opérations de billetterie, de surveillance et de SOC sans ralentir les ingénieurs ?

Vous intégrez A.5.24 au travail normal en Considérez votre registre d'incidents ITSM comme la seule source de vérité. et des outils de surveillance et de collaboration intégrés. Le rapport d'incident décrit l'ensemble des événements ; les consoles, les tableaux de bord et les messageries instantanées permettent d'en saisir les aspects techniques.

Que doit contenir un rapport d'incident conforme à la norme A.5.24 ?

Dans votre outil ITSM ou de centre de services, définissez un type d’« incident de sécurité de l’information » dédié qui reflète votre processus documenté :

Domaines principaux : pour le locataire, l'environnement, le service affecté, la gravité, la sensibilité des données et la pertinence réglementaire potentielle.
Flux d'état : qui reflète votre procédure (par exemple : Nouveau → Triage → Enquête → Confinement → Rétablissement → Examen → Clôturé).
Champs obligatoires et listes de contrôle : aux moments clés de transition :
Avant de conclure, une révision a-t-elle été effectuée ?
Si l'incident impliquait des données personnelles, la protection de la vie privée a-t-elle été consultée ?
Les délais de notification convenus ont-ils été respectés ?
Résumés et liens : pour:
Actions et approbations clés, qui a autorisé quoi et quand.
Communications avec les clients, y compris les canaux et les horaires.
Alertes, cas ou sources de journaux sous-jacents stockés ailleurs.

Les catégories et étiquettes spécifiques à la sécurité permettent de distinguer les incidents de sécurité des pannes générales. Il est ainsi beaucoup plus facile de rendre compte des tendances, de prouver sa conformité aux audits et d'améliorer l'ensemble de votre système de gestion de la sécurité de l'information.

Comment les outils de surveillance et de SOC s'intègrent-ils à cette architecture ?

Une fois que vous avez un type d'enregistrement et un flux clairement définis, vous décidez Quelles alertes doivent créer ou enrichir les enregistrements d'incidents ?, Tels que:

Détections à fort impact ou à haute fiabilité provenant d'outils SIEM, EDR ou de sécurité cloud générant automatiquement des tickets d'incident pré-remplis.
Les signaux de moindre gravité sont regroupés pour être examinés par des analystes, avec une voie de promotion facile vers le statut d’« incident » lorsque certains critères sont remplis.
Des intégrations qui ajoutent du contexte – utilisateurs ou appareils concernés, événements corrélés, éléments de preuve – au dossier principal plutôt que de laisser tout cela piégé dans des discussions ou des consoles individuelles.

Si votre équipe utilise le chat ou des passerelles virtuelles pendant la gestion en direct, un bref résumé des décisions et des approbations doit toujours être consigné dans le dossier d'incident afin de pouvoir démontrer votre maîtrise du dossier lorsqu'une personne l'examine des mois plus tard.

Lorsque vous concevez ce flux une fois, le connectez à A.5.24 et à ses contrôles associés dans ISMS.online, et formez votre SOC et votre centre de services à traiter l'enregistrement de l'incident comme « l'endroit où se trouve l'histoire », vous satisfaites le contrôle sans ajouter de surcharge bureaucratique pour les ingénieurs.

Quelles preuves un MSP doit-il conserver pour démontrer de manière convaincante sa préparation aux incidents pour la version A.5.24 ?

A.5.24 est généralement testé par incidents réels récentsIl ne s'agit pas de listes de contrôle théoriques. Les auditeurs, les assureurs et les grands clients sélectionneront généralement un ou deux cas et vous demanderont de démontrer comment ils se sont déroulés par rapport à votre procédure de gestion des incidents documentée.

À quoi ressemble un ensemble de preuves solides pour chaque incident ?

Pour chaque incident majeur – en particulier ceux impliquant des données sensibles ou une perturbation importante – vous devriez être en mesure de présenter :

Le rapport d'incident principal :
Horodatage, changements d'état et gravité.
Attribution des rôles et passation de consignes entre les équipes ou les quarts de travail.
Bref récit des événements et des raisons qui ont motivé les décisions clés.
Documents techniques associés :
Alertes SIEM ou EDR, identifiants de cas et exportations de synthèse.
Extraits de journaux pertinents ou notes d'analyse forensique, ou références à l'endroit où ces données sont conservées en toute sécurité.
Historique en relation avec le client :
Qui a été informé, quand et par quel canal ?
Comment vous avez respecté ou dépassé les délais de notification contractuels.
Tous les rapports de suivi ou comptes rendus de réunion partagés avec le client.
Résultats de l'examen et de l'amélioration :
Cause probable, facteurs contributifs et risque résiduel.
Actions correctives et d'amélioration spécifiques, avec responsables et échéances.
Des mises à jour ont été apportées aux manuels de procédures, aux contrats, aux modèles ou aux matrices RACI en conséquence.

Pour la plupart des fournisseurs de services gérés, le défi réside dans la cohérence plutôt que dans la quantité. Quelques pièces jointes et références bien choisies, étayant clairement le récit, valent bien plus que des dizaines de fichiers journaux non structurés.

Comment éviter d'être submergé par les preuves concernant de nombreux locataires et services ?

Vous gardez les preuves gérables en standardisation des modèles par segment de clientèle:

Définissez les sources de journaux et les sorties de surveillance sur lesquelles vous vous appuyez pour différents types de services (point de terminaison géré, location cloud, réseau).
Normaliser la manière dont ces éléments sont référencés ou joints dans les rapports d'incident.
Définissez des périodes de conservation et des contrôles d'accès conformes aux obligations légales et contractuelles de chaque segment.

Les examens périodiques des preuves – qui consistent à prendre au hasard un incident clos et à se demander « Une partie externe jugerait-elle cela complet et crédible ? » – font souvent ressortir de petites modifications de conception ayant des avantages considérables.

Lorsque vous gérez ensemble votre modèle de preuves d'incidents, les politiques connexes et les correspondances A.5.24 dans ISMS.online, vous pouvez montrer aux auditeurs et aux clients stratégiques que la préparation est cohérente et adaptée aux locataires, et non pas quelque chose que vous vous empressez de reconstruire lorsqu'un questionnaire ou une réclamation arrive.

Comment la formation et les exercices aident-ils un MSP à passer de la conformité sur papier à une réelle force en vertu de l'A.5.24 ?

L'entraînement et les exercices sont là où A.5.24 transforme la documentation en réflexesLe contrôle parle de planification et de préparation ; pour un MSP, cela signifie que les équipes, tous rôles confondus, ont pratiqué des incidents réalistes en utilisant vos outils, enregistrements et procédures réels, et non pas simplement lu une politique une fois par an.

Quelles approches de formation sont les plus efficaces pour les équipes MSP ?

Les sessions courtes et ciblées sont presque toujours plus efficaces que les longues présentations génériques :

Analystes et ingénieurs : Exécutez des simulations d'alertes dans votre système de surveillance, créez et mettez à jour des enregistrements d'incidents et suivez les procédures étape par étape jusqu'à ce que le processus devienne naturel.
Gestionnaires de comptes et responsables de services : S’entraîner à fournir des mises à jour clients urgentes lors d’une panne ou d’une compromission réaliste, en utilisant les informations qu’ils verraient dans les tickets et les tableaux de bord.
Collègues juristes, spécialistes de la protection de la vie privée et de la conformité : Entraînez-vous à prendre des décisions de notification avec des informations incomplètes, en vous basant sur ce qui est réellement consigné dans vos rapports et journaux d'incidents.
Dirigeants supérieurs : S’exercer à savoir quand intervenir, comment approuver rapidement les mesures de confinement perturbatrices et comment harmoniser les messages internes et externes.

Ces séances permettent de renforcer la confiance afin que, lorsqu'un événement grave touche un élément clé, les gens sachent exactement où chercher et quoi faire, plutôt que de perdre du temps à débattre des étapes de base.

Comment concevoir un programme d'exercices qui réponde aux exigences A.5.24 sans surcharger vos équipes ?

Vous n’avez pas besoin d’un programme de simulation de guerre élaboré ; un simple calendrier visible suffit souvent :

Des simulations internes au moins une fois par an pour vos scénarios à plus fort impact (par exemple, ransomware, compromission de messagerie professionnelle, panne majeure de plateforme).
Des exercices conjoints ponctuels avec des clients stratégiques ou réglementés, permettant de concrétiser les matrices RACI, les procédures d'escalade et les modèles de communication pour les deux parties.
De brefs comptes rendus après chaque exercice, comprenant :
Ce qui a bien fonctionné et qu'il convient de renforcer.
Là où les rôles, les informations ou les outils étaient confus ou lents.
Quelques améliorations concrètes apportées aux matrices RACI, aux manuels de procédures, aux modèles de tickets, à la journalisation ou aux contrats.

Ces actions d'amélioration doivent s'intégrer à vos mécanismes habituels de la norme ISO 27001 – plans de traitement des risques, registres des actions correctives, revues de direction – afin que vous puissiez démontrer une boucle complète allant de la conception aux tests jusqu'à l'amélioration.

En planifiant, en dispensant et en suivant ces sessions sur ISMS.online, en complément de votre politique A.5.24, de vos procédures et de vos rapports d'incidents, vous présentez un argumentaire clair aux auditeurs, aux autorités de réglementation et aux acheteurs : la préparation aux incidents est conçue, mise en pratique et renforcée dans le cadre de votre système de gestion de la sécurité de l'information, et non laissée au hasard. C'est précisément la position qu'un fournisseur de services gérés moderne souhaite occuper face à un incident grave ou à un client exigeant.

Nous sommes un leader dans notre domaine

Responsable régional - Hiver 2026 Royaume-Uni

Responsable régional - Hiver 2026 Marché intermédiaire UE

Responsable régional - Hiver 2026 Marché intermédiaire EMEA

« ISMS.Online, outil exceptionnel pour la conformité réglementaire »
— Jim M.

« Facilite les audits externes et relie de manière transparente tous les aspects de votre SMSI »
— Karen C.

« Solution innovante pour la gestion des accréditations ISO et autres »
— Ben H.

A.5.24 Planification et préparation de la gestion des incidents de sécurité de l'information – Préparation des fournisseurs de services gérés en cas d'incident