Comment les fournisseurs de services gérés peuvent mettre en place un processus de décision événementielle conforme à la norme ISO 27001 et auditable, capable de résister à tout audit.

Pourquoi les équipes SOC/NOC des MSP ont-elles des difficultés à prendre des décisions concernant les événements ?

Les équipes SOC et NOC des fournisseurs de services gérés (MSP) peinent à prendre des décisions concernant les incidents, car elles s'appuient sur le jugement individuel plutôt que sur un processus partagé et reproductible. Sous la pression constante des alertes, les analystes improvisent pour déterminer quels signaux sont pertinents, qui doit intervenir et dans quel délai. En l'absence de définitions, de critères et d'enregistrements clairs, un même problème est traité différemment à chaque équipe, les clients reçoivent des informations contradictoires et il est difficile de présenter des éléments fiables aux auditeurs ISO 27001.

Les équipes SOC et NOC des fournisseurs de services gérés (MSP) s'appuient souvent sur des individus exceptionnels plutôt que sur une démarche décisionnelle cohérente et documentée. Sous pression, les analystes doivent déterminer, parmi des milliers d'alertes quotidiennes, lesquelles sont réellement importantes, qui doit intervenir et dans quel délai. Lorsque la logique de décision repose sur des critères subjectifs plutôt que sur des critères partagés, les résultats deviennent fragiles et très difficiles à expliquer aux clients ou à justifier lors d'audits.

Des décisions calmes et cohérentes valent mieux que des interventions d'urgence parfois brillantes.

Le déluge d'alertes et la culture de « l'analyste héros »

Le déluge d'alertes et la culture de « l'analyste héros » apparaissent lorsque les analystes s'appuient sur des raccourcis personnels plutôt que sur des règles convenues. Dans un SOC mutualisé, les journaux et les alarmes de chaque client se confondent en un flux unique, si bien que le personnel expérimenté finit par décider instinctivement quels signaux sont fiables et lesquels ignorer. Cela permet certes de maintenir la continuité des opérations, mais vous expose à des risques en cas de départ de personnel, de pic de charge de travail ou de demande de justificatifs par les auditeurs.

Dans un SOC mutualisé classique, le flux d'alertes provenant des SIEM, des outils de sécurité des terminaux, des passerelles de messagerie, des pare-feu et des plateformes de surveillance des performances est incessant. Avec le temps, les analystes expérimentés développent des automatismes leur permettant de distinguer les signaux fiables de ceux à ignorer. Si cela assure la continuité des opérations, la véritable logique de décision repose sur quelques personnes et quelques notes griffonnées sur des post-it.

Ce schéma est généralement repérable lorsque :

Les différentes équipes traitent le même type d'alerte de manière sensiblement différente.
Les billets sont ballottés d'une file d'attente à l'autre car personne ne s'accorde sur la nature d'une alerte : incident, problème de santé ou bruit.
Les incidents évités de justesse apparaissent dans les analyses post-mortem lorsqu'un événement initialement négligé s'avère grave par la suite.

Ce type de logique implicite peut fonctionner tant que les bonnes personnes sont en poste, mais elle est fragile. La perte d'un analyste clé, une forte augmentation du volume d'alertes ou de nouvelles exigences réglementaires peuvent immédiatement révéler ses failles.

Les coûts cachés des décisions incohérentes

Les coûts cachés des décisions incohérentes se traduisent par des efforts gaspillés, des clients désorientés et une difficulté à démontrer les améliorations à la direction et aux auditeurs. Les analystes perdent du temps à traquer des événements mineurs en raison de critères vagues, tandis que les problèmes réels sont signalés tardivement ou de manière inégale. Les clients reçoivent des réponses différentes selon la personne qui répond au téléphone, et les délais de préavis des SLA ne sont pas les mêmes pour un même scénario, ce qui mine la confiance et rend les conclusions d'audit plus difficiles à étayer.

La majorité des organisations citées dans le rapport 2025 sur l'état de la sécurité de l'information déclarent avoir été touchées par au moins un incident de sécurité lié à un tiers ou à un fournisseur au cours de l'année précédente.

L'incohérence dans la prise de décision en cas d'incident se manifeste rarement par une défaillance catastrophique unique ; elle engendre des pertes de valeur et accroît les risques à tous les niveaux. Les analystes perdent du temps à examiner des incidents mineurs en raison de critères imprécis. Les clients reçoivent des réponses différentes selon l'interlocuteur. Les SLA ne sont pas respectés car le moment de déclenchement du décompte est flou. Par ailleurs, il est difficile d'évaluer l'amélioration réelle des opérations de sécurité.

Le coût humain est également un facteur important. Si vos meilleurs éléments sont constamment occupés à gérer des alertes ambiguës, ils finissent par s'épuiser, démissionner ou se désintéresser des projets d'amélioration. Vous vous retrouvez alors encore plus dépendant de l'appréciation ponctuelle d'un nombre réduit de personnes, ce qui complique considérablement la mise en œuvre de la norme ISO 27001.

Pourquoi cela est particulièrement important pour la norme ISO 27001:2022 A.5.25

L’annexe A.5.25 de la norme ISO 27001:2022 est importante car elle vous oblige à transformer la gestion informelle des événements en un processus décisionnel défini et auditable. Le libellé de l’annexe A de la norme ISO/IEC 27001:2022 exige explicitement que vous évaluiez les événements liés à la sécurité de l’information et que vous décidiez s’ils doivent être traités comme des incidents, en utilisant des critères et des enregistrements définis plutôt qu’un jugement purement ad hoc.

Selon l'enquête 2025 d'ISMS.online, les clients attendent de plus en plus des fournisseurs qu'ils s'alignent sur des cadres formels tels que l'ISO 27001, l'ISO 27701, le RGPD, Cyber Essentials, SOC 2 et les normes émergentes en matière d'IA plutôt que de se fier à des déclarations informelles de bonnes pratiques.

L’annexe A.5.25 porte précisément sur cette étape décisionnelle : le moment où un événement de sécurité potentiel est évalué et où il est décidé s’il s’agit d’un incident de sécurité de l’information. Pour un fournisseur de services gérés (MSP), cette décision n’est pas qu’un simple choix technique ; elle a un impact déterminant :

Déclenchement ou non des obligations de notification contractuelles et réglementaires.
Avec quelle rapidité les clients sont informés et impliqués.
Quels sont les processus internes appliqués et quelles équipes sont impliquées ?
Quels documents subsistent ultérieurement pour attester du soin apporté et de la constance de la manipulation ?

Ce contrôle s'inscrit dans la continuité des autres contrôles de gestion des incidents de l'annexe A, qui couvrent la préparation, la réponse, l'apprentissage et la documentation. Au sein de cette catégorie, le contrôle A.5.25 définit les critères, les rôles et les enregistrements qui relient la détection à la gestion formelle de l'incident ; c'est pourquoi les auditeurs examinent attentivement la manière dont vous prenez et documentez cette décision.

Si votre approche actuelle de la gestion des événements repose sur l'intuition et l'héroïsme, la norme A.5.25 révélera rapidement ses faiblesses. Le même travail qui vous prépare à un audit rend également votre SOC et votre NOC plus sereins, plus prévisibles et plus efficaces.

Demander demo

Que requiert réellement l'annexe A.5.25 de la norme ISO 27001:2022 dans un contexte MSP ?

L'annexe A.5.25 de la norme ISO 27001:2022 exige une évaluation systématique des événements liés à la sécurité de l'information et la détermination de leur nature (incidents ou non) selon des critères, des rôles et des enregistrements définis. Dans le contexte d'un fournisseur de services gérés (MSP), cela implique de traduire un énoncé de contrôle concis en politiques, flux de travail et artefacts concrets, applicables à plusieurs environnements et outils. Ce contrôle, bien que paraissant anodin sur le papier, a des implications majeures en matière d'assurance, de reporting et de gestion des questions pointues des clients et des auditeurs.

En pratique, la norme A.5.25 exige des fournisseurs de services gérés (MSP) qu'ils intègrent un processus d'évaluation des événements cohérent et reproductible dans leurs opérations quotidiennes. Vous devez être en mesure de démontrer que les événements pertinents sont visibles dans le processus décisionnel, que le personnel utilise des critères convenus pour les classer et que vous conservez une trace écrite des décisions prises et de leurs justifications. Pour la certification ISO 27001 et les audits clients, cette traçabilité est souvent aussi importante qu'une simple réponse technique. Les recommandations relatives à la gestion des incidents, telles que la publication spéciale 800-61 du NIST, insistent également sur la documentation des processus et la constitution de preuves tout au long du cycle de vie d'un incident, et non pas seulement sur des corrections techniques isolées, ce qui renforce l'importance accordée à la traçabilité.

Presque toutes les organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online considèrent l'obtention ou le maintien de certifications de sécurité telles que l'ISO 27001 et le SOC 2 comme une priorité essentielle pour les années à venir.

Le contrôle principal en langage clair

En clair, le principe fondamental du contrôle est que chaque incident de sécurité pertinent doit être évalué selon des critères convenus et catégorisé de manière cohérente. Vous devez démontrer que les incidents sont visibles dans le processus décisionnel, que le personnel sait appliquer ces critères et que vous pouvez justifier les décisions prises. Autrement dit, vous devez garantir une visibilité claire, des critères précis, des personnes compétentes et des enregistrements pour chaque incident important.

En résumé, la section A.5.25 stipule que vous devez évaluer les événements liés à la sécurité de l'information et déterminer s'ils doivent être qualifiés d'incidents de sécurité de l'information. À y regarder de plus près, cela implique quatre obligations spécifiques :

Les événements doivent être visible au processus de décision, sans qu'il soit perdu dans les journaux ou ignoré.
Il doit y avoir critères que le personnel peut utiliser pour prendre des décisions cohérentes.
Il doit y avoir personnes avec l'autorité et la formation nécessaires pour prendre ces décisions.
Il doit y avoir Articles de ce qui a été décidé et pourquoi.

Votre véritable défi n’est pas de comprendre cette phrase ; c’est d’intégrer ces quatre obligations dans un modèle opérationnel complexe à locataires multiples sans tout ralentir ni semer la confusion chez les clients.

Comment le point A.5.25 s'intègre-t-il au reste de la gestion des incidents ?

Le point A.5.25 concerne l'ensemble de la gestion des incidents et constitue le lien essentiel entre la détection et la réponse structurée. Il est directement lié aux contrôles relatifs à la préparation, à la réponse, à l'apprentissage et à la collecte de preuves. Les auditeurs s'attendent donc à une traçabilité claire, de l'alerte initiale jusqu'au compte rendu d'incident et aux améliorations apportées. Si cette traçabilité est interrompue, votre argumentation paraîtra fragile, même si certaines corrections techniques se sont avérées efficaces.

A.5.25 n'est pas isolé. Il se situe entre :

Planification et préparation, étapes essentielles pour s'assurer de disposer du personnel, des outils et des moyens de communication nécessaires pour gérer les incidents.
Réagir aux incidents, c'est-à-dire ce que vous faites concrètement une fois qu'un incident est déclaré.
Tirer des enseignements des incidents, notamment par le biais d’examens post-incident, d’améliorations et d’analyses des tendances.
Collecte des preuves, en veillant à ce que les journaux, les tickets et les artefacts soient utilisables sur le plan juridique et opérationnel.

Du point de vue de l'auditeur, un événement doit être traçable tout au long de cette chaîne : de sa détection initiale à son évaluation et sa classification (A.5.25), en passant par la réponse apportée (A.5.26), et enfin jusqu'aux enseignements tirés et aux preuves (A.5.27 et A.5.28). Les travaux de cartographie des normes menés par des organismes tels que l'ENISA renforcent cette vision du cycle de vie en alignant les contrôles relatifs aux incidents de la norme ISO 27001 sur un parcours unique, de la détection aux enseignements tirés.

Si cette chaîne de transmission se rompt au moment de l'évaluation et de la décision, votre récit ne tiendra pas la route, même si certaines réponses individuelles étaient techniquement correctes.

Voici à quoi cela ressemble dans un MSP multi-locataire

Dans un MSP mutualisé, la norme A.5.25 doit être suffisamment robuste pour gérer différents clients, outils et cadres réglementaires sans se fragmenter en une multitude de processus sur mesure. Il vous faut une structure standard pour l'évaluation des événements, sur laquelle s'ajoutent des paramètres spécifiques à chaque locataire. Clients et auditeurs s'attendront à ce que vous démontriez la cohérence et l'équité des décisions prises pour l'ensemble des locataires, même en cas de différences de SLA, de tolérance au risque et d'exigences réglementaires.

Dans l'enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information, environ 41 % des organisations ont déclaré que la gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs constituaient l'un de leurs principaux défis en matière de sécurité de l'information.

Pour les MSP, la norme A.5.25 doit composer avec des réalités telles que :

Chaque client a un appétit pour le risque et des SLA différents.
Un outil partagé qui centralise les alertes hétérogènes provenant de nombreux locataires dans des files d'attente communes.
Équipes réparties sur différents fuseaux horaires et quarts de travail.
Obligations réglementaires et contractuelles qui varient selon le secteur et la zone géographique.

Votre implémentation doit donc répondre à des questions comme :

Quels événements sont concernés par l'évaluation A.5.25, et lesquels sont filtrés plus tôt ?
Qui décide si un événement affectant plusieurs locataires constitue un seul incident, plusieurs incidents ou simplement un bruit de fond ?
Comment prouver que les décisions ont été prises de manière cohérente, même lorsque différents clients sont concernés ?

La norme ne répond pas à ces questions, mais les clients et les auditeurs, eux, le feront. Une bonne conception de la norme A.5.25 permet de rendre ces décisions explicites, cohérentes et justifiables.

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 événements, incidents et faiblesses pour les opérations et les SLA des MSP

La mise en œuvre de la norme A.5.25 est efficace lorsque tous les membres de votre SOC et NOC partagent des définitions claires et fondées sur les risques des événements, incidents et vulnérabilités, conformes à vos contrats et SLA. Sans ce langage commun, aucun flux de travail, outil ou manuel d'exploitation ne peut garantir des décisions cohérentes, et il vous sera difficile d'expliquer ou de justifier vos choix auprès de vos clients, auditeurs et de votre propre direction.

Pour une mise en œuvre efficace de la clause A.5.25, il est indispensable de définir clairement et de manière partagée les termes « événement », « incident » et « faiblesse », en fonction de votre environnement et de vos contrats. Sans cela, aucun processus décisionnel ni outil ne pourra garantir des résultats cohérents. Ces définitions doivent également reposer sur une analyse des risques et ne pas se limiter aux libellés des outils ou aux arguments marketing des fournisseurs.

Des définitions fondées sur les risques qui fonctionnent dans les opérations réelles

Les définitions fondées sur les risques sont efficaces en situation réelle car elles établissent un lien entre les événements techniques et leurs impacts et obligations métier, et non pas seulement avec la terminologie des outils. En structurant les événements, les incidents et les faiblesses autour des obligations de confidentialité, d'intégrité, de disponibilité et de conformité, vous fournissez aux analystes des critères applicables de manière cohérente à différents environnements et technologies. Ceci constitue une base solide pour vos procédures A.5.25 et pour l'assurance au niveau des clauses de la norme ISO 27001.

De nombreux fournisseurs de services gérés trouvent les définitions de travail suivantes utiles :

Événement lié à la sécurité de l'information : toute occurrence observable dans un système, un service ou un réseau pouvant avoir une incidence sur la sécurité de l'information, comme une alerte SIEM, une connexion inhabituelle, un courriel suspect ou un pic de trafic.
Incident de sécurité informatique : un événement ou une série d'événements qui ont compromis, ou sont susceptibles de compromettre, la confidentialité, l'intégrité ou la disponibilité des informations ou des services, ou qui déclenchent des obligations légales, réglementaires ou contractuelles.
La faiblesse: une vulnérabilité ou une déficience de contrôle révélée au cours des opérations (par exemple, un accès mal configuré, des correctifs manquants ou une journalisation inadéquate) qui peut ne pas encore constituer un incident actif, mais qui augmente la probabilité ou l'impact d'incidents futurs.

Le tableau ci-dessous résume les différences entre ces trois termes et leur application dans les opérations des fournisseurs de services gérés.

Long	Définition dans votre contexte MSP	Exemple typique
événement de sécurité de l'information	Événement observable pertinent pour la sécurité, susceptible d'avoir ou non un impact réel	Alerte SIEM, connexion inhabituelle, courriel suspect
Incident de sécurité de l'information	Événement ou série d'événements qui compromettent, ou sont susceptibles de compromettre, les fonctions de la CIA ou de chauffeur	Activité de ransomware sur un serveur clé
Faiblesse	Déficience ou vulnérabilité des systèmes de contrôle qui augmente la probabilité ou l'impact d'incidents futurs	Comptes d'administrateur partagés, correctifs manquants, journalisation insuffisante

Ces distinctions sont importantes car chaque situation doit suivre un processus différent. Les événements peuvent se limiter à une simple surveillance, les incidents peuvent déclencher des procédures d'intervention et des notifications, et les faiblesses peuvent être intégrées à la gestion des risques, des changements ou des problèmes plutôt que d'encombrer les files d'attente de gestion des incidents.

Élaborer des définitions tenant compte des besoins des locataires

Les définitions deviennent véritablement utiles lorsqu'elles peuvent être appliquées de manière cohérente à des clients présentant des profils de risque et des exigences réglementaires différents. Il vous faut une taxonomie de base que vos analystes maîtrisent une seule fois, puis des échelles de gravité adaptables et des exemples spécifiques à chaque client. Ainsi, chacun comprendra comment un même type d'événement se manifeste différemment dans une banque soumise à une réglementation stricte et chez un petit commerçant. C'est également ce qu'attendent les clients et les auditeurs lorsqu'ils vous interrogent sur la manière dont vous adaptez vos services à leurs risques.

Dans un fournisseur de services gérés mutualisé, les clients vont des petites entreprises aux profils d'impact modestes aux entités fortement réglementées où la moindre erreur peut avoir des conséquences graves. Il est donc impossible d'utiliser une seule matrice de gravité pour tous les clients sans risquer de fausser les données. Parallèlement, il est inenvisageable de mettre en place des systèmes sur mesure, totalement différents pour chaque client.

Un compromis pratique consiste à :

Maintenir un taxonomie de base des types d'événements et d'incidents communs à tous les locataires.
Définir niveaux de gravité en utilisant l'impact commercial et l'urgence, tels que critique, élevé, moyen et faible, d'une manière qui peut être calibrée pour chaque locataire.
Pour chaque locataire, précisez comment ces niveaux de gravité correspondent à leurs propres termes tels que « incident majeur », « violation de données » ou « interruption de service », et comment cela affecte les SLA et les notifications.

Ces décisions d'étalonnage doivent être explicitement documentées, convenues lors de l'intégration et réexaminées en fonction de l'évolution des profils de risque ou de la réglementation.

Traiter les faiblesses séparément mais de manière cohérente

Le traitement distinct mais cohérent des faiblesses permet d'éviter de transformer la file d'attente des incidents en un backlog d'amélioration, tout en traitant les problèmes systémiques. Les analystes ont besoin d'un moyen clair de signaler les faiblesses découvertes lors du tri et de les intégrer aux processus de gestion des risques ou de changement. Lorsque ces enregistrements de faiblesses sont liés aux évaluations A.5.25, vous pouvez démontrer aux auditeurs que vous tirez des enseignements des événements plutôt que de simplement clôturer les tickets.

Les faiblesses passent souvent inaperçues car elles ne nécessitent pas d'intervention immédiate. Une mise en œuvre A.5.25 bien conçue considère les faiblesses comme des résultats à part entière de l'évaluation des événements, au même titre que les incidents et les événements bénins. Cela signifie que vous :

Fournir aux analystes un moyen clair de signaler les « faiblesses identifiées » lors du triage.
Intégrez les points faibles dans la gestion des risques, des problèmes ou des changements en leur attribuant la priorité appropriée.
Veillez à ce que les faiblesses découvertes lors des incidents soient visibles dans votre registre des risques et vos plans d'amélioration du SMSI.

Cette séparation permet de maintenir les files d'attente d'incidents exemptes de tâches d'amélioration de longue durée, tout en garantissant que les problèmes systémiques soient détectés et traités.

Intégrer les définitions dans les outils et les conversations

Les définitions ne modifient les comportements que si elles figurent dans les outils et les échanges quotidiens des analystes. Formulaires de tickets, tableaux de bord, manuels d'exploitation et rapports clients doivent tous aborder les événements, les incidents et les points faibles de manière uniforme. En intégrant ce vocabulaire, vous facilitez la formation des nouveaux collaborateurs, la comparaison des performances entre les différents utilisateurs et vous répondez aux questions d'audit avec assurance et cohérence.

Vous pouvez renforcer les définitions en :

Les intégrer dans des modèles de billets et des champs obligatoires.
Les utiliser dans des tableaux de bord et des rapports, plutôt que dans des catégories spécifiques à un outil.
Former les équipes SOC, NOC et commerciales à l'aide d'exemples réels où la classification était ambiguë.

Avec le temps, ce vocabulaire commun devient la base d'une prise de décision cohérente et vérifiable, et de conversations plus fluides avec les clients sur ce qui s'est passé et pourquoi.

Conception d'un flux de décision SOC conforme à la norme A.5.25

Un flux de décision SOC conforme à la norme A.5.25 est un processus structuré que suit chaque événement concerné, de sa détection initiale à un résultat clair et documenté. Ce flux doit être suffisamment simple pour être appliqué même sous pression, tout en étant suffisamment complet pour garantir une classification, une escalade et une collecte de preuves cohérentes entre les différents utilisateurs et les équipes. Un flux bien conçu permet de réduire les incidents, d'améliorer la réactivité et de faciliter les échanges relatifs à l'assurance qualité ISO 27001.

Un processus décisionnel aligné offre aux analystes une méthode reproductible pour passer du signal au résultat, même en cas de forte activité. Chaque étape répond à une question précise concernant l'événement : est-il réel ? Est-il important ? Quelles sont les prochaines étapes ? En décrivant clairement ces étapes dans des manuels d'exploitation et en les intégrant à vos outils, vous créez un système de décision robuste face aux changements de personnel, aux pics d'activité et aux contrôles externes.

Un flux simple « du signal à la décision » divise l’analyse en étapes claires, permettant aux analystes de toujours savoir à quelle question ils doivent répondre. Chaque étape précise si le signal est authentique, s’il est pertinent pour le client et quelles sont les actions à entreprendre. En consignant ces étapes dans des procédures opérationnelles et en les intégrant aux tickets d’incident, vous créez un moteur de décision prévisible, facile à former et auditable.

Pour un fournisseur de services gérés, le flux SOC pratique se compose généralement d'un nombre restreint d'étapes cohérentes. Chaque étape répond à une question précise : ce signal est-il réel, est-il important et quelle est la prochaine étape ? En explicitant ces étapes, vous offrez aux analystes un chemin fiable à travers le bruit et l'ambiguïté.

Étape 1 – Détection

Une alerte, une corrélation de journal, un rapport d'utilisateur ou un signal de surveillance apparaît et est enregistré comme un événement potentiel de sécurité de l'information.

Étape 2 – Validation

Vous confirmez rapidement si le signal est authentique et non un test, un doublon ou une alerte manifestement erronée.

Étape 3 – Enrichissement

Vous ajoutez du contexte comme la criticité de l'actif, l'identité de l'utilisateur, les modifications récentes et les événements similaires pour ce locataire.

Étape 4 – Évaluation par rapport aux critères

Vous évaluez l'impact, la probabilité, la portée et toutes les implications juridiques, réglementaires ou contractuelles par rapport aux seuils convenus.

Étape 5 – Décision

Vous classez l'événement comme bénin, sous surveillance, incident de sécurité de l'information ou faille de sécurité en utilisant les critères documentés.

Étape 6 – Routage et action

Vous orientez le dossier vers le processus ou la procédure appropriée, comme la réponse aux incidents, la surveillance, la gestion des risques ou la clôture.

Chacune de ces étapes doit être clairement décrite dans les procédures opérationnelles et reflétée dans les tickets ou les dossiers. Pour les locataires à haut risque, des approbations supplémentaires peuvent être requises lors de la prise de décision, comme la validation d'un analyste senior ou d'un architecte de sécurité d'astreinte.

Mesures de protection pour gérer les faux positifs et les faux négatifs

Des garde-fous pour gérer les faux positifs et les faux négatifs sécurisent votre flux de travail en définissant la conduite à tenir lorsque les informations sont incomplètes ou ambiguës. Vous décidez quand il est préférable de traiter une situation comme un incident, quand l'automatisation peut clôturer les alertes sans risque et quand de nouvelles informations doivent déclencher une réévaluation. Ces règles vous aident à expliquer pourquoi des événements apparemment similaires ont reçu un traitement différent selon le contexte.

Aucun processus décisionnel n'est parfait, mais vous pouvez réduire les risques en explicitant votre seuil de tolérance. Par exemple :

Définir les situations dans lesquelles l'incertitude doit être levée afin de traiter un événement comme un incident, notamment lorsque des données réglementées peuvent être impliquées.
Préciser quels événements de faible gravité peuvent être automatiquement clôturés après des vérifications spécifiques et lesquels doivent toujours être examinés par une personne.
Définir des attentes en matière de réévaluation lorsque de nouvelles informations apparaissent, telles que des renseignements ultérieurs sur les menaces reliant un événement d'apparence bénigne à une campagne active.

Ces garde-fous doivent être visibles pour les analystes dans les manuels de procédures et, idéalement, intégrés aux règles d'automatisation et aux flux de travail des tickets, afin qu'ils soient appliqués de manière cohérente plutôt que d'être réinventés à chaque changement d'équipe.

Rôles, niveaux et matrice RACI

Les rôles, les niveaux hiérarchiques et une matrice RACI permettent de traduire votre flux de travail en responsabilités quotidiennes, stables malgré les changements d'équipe et le roulement du personnel. Il est essentiel de définir clairement quels niveaux d'analystes sont habilités à prendre les décisions finales (A.5.25), quand une escalade est obligatoire et comment les responsabilités sont réparties lorsqu'un incident concerne plusieurs utilisateurs. Cette structure est un point central des audits ISO 27001 ; la documenter clairement est donc judicieux et permet d'éviter toute confusion lors d'incidents réels.

Dans de nombreux SOC de fournisseurs de services gérés (MSP), les analystes de niveau 1 se concentrent sur la validation et l'enrichissement initial, tandis que les niveaux 2 et 3 gèrent les évaluations complexes et coordonnent les incidents. Concernant le point A.5.25, il est essentiel de bien comprendre les éléments suivants :

Quels niveaux sont autorisés à prendre les décisions finales concernant les événements et les incidents, et dans quelles circonstances ?
Lorsque l'escalade est obligatoire, par exemple en cas de suspicion de compromission de systèmes hautement sensibles.
Comment les responsabilités sont partagées lorsque des incidents concernent plusieurs locataires.

Une simple matrice RACI couvrant l'évaluation des événements et la prise de décision peut éviter toute confusion, notamment lors des quarts de nuit ou des pics d'activité importants.

Tester le flux de travail en situation de stress permet de vérifier sa robustesse face à la pression réelle, et pas seulement sur des schémas bien conçus. Les exercices de scénarios, les tests d'intrusion et les simulations de pics d'alertes montrent si les analystes suivent les étapes convenues, si l'automatisation fonctionne correctement et si les enregistrements de décisions restent complets. Les enseignements tirés de ces exercices doivent alimenter directement les ajustements apportés aux critères, à la formation et aux outils.

Il est facile de concevoir un flux de travail efficace sur papier ; il est plus difficile de le maintenir opérationnel lors d’une véritable attaque. Les exercices sur table, les simulations d’attaques de type « red team » ou les simulations de vagues d’hameçonnage à grande échelle sont d’excellents moyens de vérifier si :

Les analystes suivent les étapes ou recourent à l'improvisation.
L'automatisation fonctionne comme prévu.
Les enregistrements de décisions restent complets même en cas de pics d'activité.

Les résultats de ces exercices devraient permettre d'ajuster directement vos critères, votre formation et vos outils. C'est cette boucle de rétroaction continue qui transforme la clause A.5.25, d'une disposition statique, en un atout opérationnel évolutif.

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 des opérations NOC, des flux ITIL et des voies d'escalade

L'intégration des opérations NOC, des flux de type ITIL et des procédures d'escalade garantit que la prise de décision A.5.25 contribue à la santé globale du service au lieu de la compromettre. Les incidents de sécurité étant souvent liés à des problèmes de performance, votre SOC et votre NOC doivent partager des règles concernant la responsabilité, l'escalade et la communication. En intégrant A.5.25 à la gestion des services, vous réduisez les frictions, évitez les actions contradictoires et facilitez la communication d'informations complètes aux clients et aux auditeurs.

Les incidents de sécurité sont rarement indépendants des performances des services. Pour les fournisseurs de services gérés (MSP), le centre d'opérations réseau (NOC) et le centre d'opérations de sécurité (SOC) sont les deux faces d'une même pièce : l'un est axé sur la disponibilité et les performances, l'autre sur la sécurité. La prise de décision A.5.25 doit s'inscrire pleinement dans ce contexte plus large de gestion des services afin d'éviter de corriger des problèmes de sécurité tout en interrompant involontairement les services.

Clarification de la propriété entre le SOC et le NOC

Clarifier la répartition des responsabilités entre le SOC et le NOC commence par identifier l'origine des événements et l'équipe responsable. Il est important de savoir quelles alertes proviennent de la surveillance traditionnelle des performances, lesquelles des outils de sécurité et lesquelles concernent les deux. Une fois cette répartition établie, vous pouvez définir quand un événement NOC doit déclencher une évaluation de sécurité et quand un événement SOC doit déclencher une analyse d'impact sur les services.

Un point de départ judicieux consiste à cartographier le flux actuel des événements à travers vos processus de gestion des services informatiques :

Quels sont les événements qui arrivent via la surveillance traditionnelle et qui appartiennent au NOC ?
Lesquels proviennent des outils de sécurité et appartiennent au SOC ?
Lesquelles sont ambiguës, affectant à la fois les performances et la sécurité ?

Une fois les flux compris, vous pouvez définir des règles telles que :

Lorsqu'un événement lié à l'état du service doit déclencher une évaluation de sécurité, par exemple des échecs d'authentification répétés ou des pics de trafic inexpliqués.
Lorsqu'un événement de sécurité doit déclencher une évaluation d'impact sur le service, par exemple des règles de blocage strictes ou des mesures de confinement.

Cette cartographie vous aide à identifier précisément où les évaluations A.5.25 doivent avoir lieu et qui est responsable à chaque étape.

Élaboration d'une matrice d'escalade et de communication

Une matrice d'escalade et de communication transforme vos critères de décision en actions prévisibles pour vos équipes internes et vos clients. Elle associe les catégories et la gravité des événements aux personnes à notifier, à la rapidité de la notification et aux canaux utilisés. Une fois la matrice validée par vos clients, vous évitez de sur-communiquer les problèmes mineurs et de sous--communiquer les problèmes graves, et vous pouvez démontrer aux auditeurs que votre processus est systématique et non improvisé.

Différents niveaux de gravité et contextes requièrent différentes procédures d'escalade. Par exemple :

Un incident grave impliquant une perte potentielle de données peut nécessiter une notification immédiate au responsable de la sécurité du client, au gestionnaire des incidents du fournisseur de services gérés et, dans certains secteurs, aux équipes réglementaires.
Un incident de gravité moyenne affectant un système non critique peut ne nécessiter qu'une escalade au sein du SOC et une note d'état de routine au client.

Vous pouvez consigner ces tendances dans une matrice d'escalade simple qui associe les niveaux de gravité, les types d'événements et les attentes en matière de communication. Une fois cette matrice validée avec les clients et les équipes internes, les analystes n'auront plus à deviner qui impliquer ni à quel moment il convient d'accroître la visibilité.

Une matrice claire favorise également une meilleure discipline de communication. Lorsque chacun comprend qu'une classification particulière déclenche automatiquement certaines notifications, on réduit le risque de surcommunication et de silence préjudiciable.

Respect des SLA et des échéanciers réglementaires

Le respect des SLA et des échéances réglementaires garantit que votre processus de décision est conforme aux engagements contractuels et aux obligations légales. Il est essentiel de définir clairement le point de départ des délais des SLA, les décisions qui déclenchent les notifications clients et les seuils réglementaires à partir desquels un événement atteint ces seuils. Ces règles doivent figurer dans les manuels d'exploitation et les contrats afin d'éviter toute incertitude chez les analystes, notamment en situation de forte pression.

Une forte majorité des personnes interrogées dans le cadre de l'enquête 2025 sur l'état de la sécurité de l'information affirment que la rapidité et le volume des changements réglementaires rendent la conformité beaucoup plus difficile à maintenir.

Les SLA incluent souvent des engagements de temps de réponse en fonction de la gravité, tandis que la réglementation peut imposer des délais de notification spécifiques pour certains types d'incidents. Votre processus de décision en matière d'événements doit donc prendre en compte les éléments suivants :

Démarrez les minuteurs SLA au moment opportun, par exemple entre la détection initiale et l'incident confirmé.
Distinguer clairement les événements d'information interne des incidents à déclarer.
Déclencher les notifications réglementaires uniquement lorsque les seuils sont atteints, mais toujours en temps voulu.

Ces attentes doivent être intégrées aux procédures opérationnelles et aux contrats afin d'éviter toute incertitude pour les analystes et de garantir que les clients sachent à quoi s'attendre. Cela permet également d'éviter que les équipes SOC et NOC ne travaillent en opposition lorsque des décisions urgentes doivent être prises.

Utiliser des exercices conjoints pour affiner le modèle

Les exercices conjoints entre le SOC et le NOC permettent de vérifier la robustesse de votre modèle intégré face à des scénarios réalistes. En analysant des incidents qui débutent par des problèmes de performance et se transforment en problèmes de sécurité, ou inversement, vous identifiez les lacunes en matière de responsabilité, de communication et d'escalade. Chaque leçon vous offre l'opportunité d'affiner les points de décision, les matrices et la formation A.5.25 afin qu'ils reflètent au mieux votre mode de prestation de services.

La meilleure façon de valider l'intégration SOC-NOC est d'étudier ensemble des scénarios réalistes. Ceux-ci pourraient inclure :

Une perte soudaine de disponibilité qui s'avère être le résultat d'une attaque par déni de service.
Une modification du renforcement de la sécurité qui provoque de manière inattendue une interruption de service critique.
Un problème chez un fournisseur de services cloud affectant plusieurs locataires simultanément.

Au fil de vos exercices, identifiez les points d'ombre concernant la responsabilité, la communication ou la prise de décision, et intégrez ces enseignements à vos matrices, procédures et formations. Progressivement, vous aurez ainsi la certitude que les évaluations A.5.25 ne sont pas réalisées isolément, mais bien intégrées à votre mode de fonctionnement.

Outils, automatisation et capture de preuves pour les environnements multi-locataires A.5.25

L'outillage, l'automatisation et la collecte de preuves sont les éléments clés du succès ou de l'échec de votre conception A.5.25 au quotidien. Vous avez besoin d'une suite d'outils cohérente où les événements sont consignés dans un dossier, où l'automatisation soutient le jugement humain sans le remplacer et où les preuves sont collectées automatiquement au fur et à mesure du travail. Lorsque vos outils sont alignés sur vos processus, vous générez naturellement les preuves nécessaires aux audits ISO 27001 et clients, et non pas après coup.

Même la meilleure conception de processus échouera si vos outils ne sont pas adaptés. Pour A.5.25 au sein d'un MSP, le défi consiste à connecter les plateformes SIEM, SOAR, de surveillance et ITSM de manière à permettre des décisions cohérentes et une capture automatique des preuves pour tous les clients, sans contraindre les analystes à dupliquer leur travail.

Lorsque vos outils prennent en charge le flux de travail, les preuves apparaissent comme un sous-produit, et non comme une réflexion après coup.

Choisir un « dossier officiel »

Choisir un système de référence consiste à déterminer quel système conserve l'historique officiel de chaque événement et de son issue. Pour de nombreux fournisseurs de services gérés (MSP), le centre de services ou l'outil de gestion des incidents constitue un choix naturel comme système de référence principal, car il prend déjà en charge la gestion des responsabilités, des flux de travail et des rapports, et les bonnes pratiques de gestion des services informatiques le considèrent comme tel.

Vous devez déterminer quel système fait foi pour les décisions relatives aux événements. Pour la plupart des fournisseurs de services gérés (MSP), il s'agit du système de gestion des services ou de l'outil de gestion des incidents, car il prend déjà en charge la gestion des responsabilités, les flux de travail et les rapports. Une fois ce choix effectué, vous pouvez :

S'assurer que chaque alerte pertinente donne lieu à un dossier ou est liée à un dossier existant.
Stockez la classification, la gravité, la décision et la justification dans des champs structurés.
Associez les dossiers aux actifs, aux locataires et aux services via vos données de configuration.

Les autres outils restent importants, mais la couche ITSM devient l'endroit où les clients et les auditeurs peuvent voir ce que vous avez réellement décidé et fait, plutôt que de devoir rassembler des informations provenant de sources disparates.

Une plateforme ISMS dédiée, telle qu'ISMS.online, peut se positionner au-dessus de ces systèmes, facilitant la liaison entre les politiques, les procédures opérationnelles, les risques, les incidents et les actions d'amélioration et les tickets déjà utilisés par votre SOC et votre NOC. Ainsi, l'objectif de contrôle, la réalité opérationnelle et les éléments probants d'audit restent alignés. Le guide public d'ISMS.online, disponible à l'annexe A.5.25, illustre comment ce type de plateforme peut être superposé aux outils opérationnels pour offrir une vision cohérente de la mise en œuvre des contrôles.

Concilier automatisation et jugement humain

L’équilibre entre automatisation et jugement humain consiste à utiliser des outils pour accélérer les étapes sûres tout en maintenant le contrôle des décisions à fort impact sous la responsabilité d’experts. L’enrichissement des données, la corrélation et la gestion des faux positifs manifestes sont des exemples pertinents d’automatisation. Les décisions susceptibles d’entraîner des notifications réglementaires, des incidents majeurs ou des sanctions contractuelles doivent rester du ressort de l’humain, avec des procédures d’approbation clairement documentées conformément à la norme ISO 27001 A.5.25 et aux contrôles associés.

L'automatisation est essentielle à l'échelle d'un fournisseur de services gérés, mais elle doit être utilisée à bon escient. Voici quelques exemples de candidats à l'automatisation :

Étapes d'enrichissement, telles que l'extraction des détails des actifs ou des historiques de modifications récentes.
Déduplication et corrélation des alertes répétées.
Clôture automatique des alertes à faible risque répondant à des critères strictement définis.

Les décisions ayant un impact significatif sur l'activité ou la réglementation doivent rester sous contrôle humain, éventuellement avec des approbations supplémentaires. Vos procédures d'automatisation et vos règles de surveillance doivent clairement refléter ces limites, afin que le personnel fasse confiance à l'automatisation plutôt que de la contester ou de la contourner sous pression.

Concevoir une logique prenant en compte les besoins des locataires

Concevoir une logique adaptée aux locataires permet de standardiser la structure tout en personnalisant le comportement pour chaque client. Vous utilisez des flux de travail et des champs communs, mais paramétrez les seuils, les cibles de notification et le calendrier par locataire ou groupe de locataires. Ainsi, les analystes peuvent appliquer le même processus A.5.25 à tous les locataires tout en respectant les différents SLA, obligations réglementaires et profils d'impact.

Comme vos clients sont différents, vous ne pouvez pas appliquer les mêmes seuils et les mêmes procédures partout. Considérez plutôt :

Utilisation de règles paramétrées permettant de définir des seuils de gravité, des cibles de notification et un calendrier pour chaque locataire.
Regrouper les locataires par profil, par exemple à forte réglementation, à criticité moyenne et à faible risque, afin de simplifier la gestion tout en respectant les différences.
Centraliser les paramètres spécifiques à chaque locataire afin que les analystes sachent avec quoi ils travaillent.

Cette approche permet de standardiser la structure et la terminologie tout en adaptant le comportement aux besoins de chaque client, ce qui correspond souvent aux attentes des auditeurs et des entreprises clientes vis-à-vis d'un fournisseur de services gérés (MSP) mature.

Automatiser la collecte de preuves

L'automatisation de la collecte de preuves est l'un des atouts majeurs d'un outil bien conçu. La configuration des champs obligatoires, des horodatages et des liens permet à chaque évaluation A.5.25 de laisser une trace écrite, sans que les analystes aient à rédiger de rapports supplémentaires. Ainsi, lors d'un audit ISO 27001 ou d'un examen client exigeant, il est possible d'extraire ces enregistrements et de les analyser sereinement, plutôt que de reconstituer les décisions à partir de mémoire et de fichiers épars.

L’un des principaux avantages d’une suite d’outils bien intégrée est que les preuves A.5.25 deviennent un sous-produit naturel des opérations. Cela signifie :

Les champs de décision sont obligatoires dans les tickets avant leur clôture ou leur escalade.
Les horodatages indiquent le moment où les évaluations et les décisions ont été prises.
Il existe des liens entre les événements, les incidents, les faiblesses, les changements et les enregistrements de problèmes.

Les principes de gouvernance de la sécurité, notamment les lignes directrices de l'OCDE pour la sécurité des systèmes et réseaux d'information, insistent sur l'importance d'intégrer la journalisation, la responsabilisation et l'auditabilité aux processus quotidiens plutôt que de les traiter comme des tâches de reporting distinctes. Ainsi, pour démontrer ultérieurement la conformité ou reconstituer un parcours de décision, il est possible d'extraire les données sans avoir à se fier à la mémoire manuelle ou à des tableurs ad hoc. Il est également important d'imaginer combien cela devient plus simple lorsque les enregistrements de décisions sont centralisés dans un système de gestion de la sécurité de l'information (SGSI) intégré, au lieu d'être dispersés dans différents fichiers et systèmes.

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

Documentation, indicateurs et récit d'audit pour A.5.25

La documentation, les indicateurs et les récits d'audit permettent de rendre vos pratiques A.5.25 concrètes et compréhensibles. Vous avez besoin d'un ensemble cohérent de politiques, de procédures et de manuels d'exploitation alignés sur vos flux de travail réels, ainsi que d'indicateurs révélant la rapidité et la qualité de vos décisions. En les associant à des analyses de cas claires, vous rassurez vos clients, auditeurs et parties prenantes quant à la réalité et à l'amélioration continue de votre processus décisionnel.

Une fois vos définitions, flux de travail et outils en place, il est essentiel de les rendre visibles et vérifiables par le biais de documentation et d'indicateurs. La norme A.5.25 concerne autant la capacité à démontrer vos actions que leur réalisation, notamment face à des clients exigeants et des auditeurs externes.

Construire un ensemble de documentation cohérent

Une documentation cohérente illustre la mise en œuvre de la norme A.5.25, de la politique aux incidents concrets, au lieu de se limiter à un document unique et isolé. Elle doit permettre de se référer à une politique, une procédure, des manuels d'exploitation, une matrice RACI, une taxonomie et des exemples d'enregistrements qui présentent tous la même démarche. Le fait de centraliser et d'harmoniser ces éléments simplifie considérablement la certification ISO 27001 et les vérifications préalables à l'assurance qualité.

Une documentation MSP typique pour la version A.5.25 comprend :

Une politique de gestion des incidents de sécurité de l'information qui définit l'objectif et la portée généraux.
Une procédure spécifique décrivant comment les incidents liés à la sécurité de l'information sont évalués et pris en compte.
Manuels d'exploitation des SOC et NOC qui montrent comment la procédure est appliquée dans les opérations quotidiennes.
Une matrice RACI pour l'évaluation et la prise de décision concernant les événements.
Une taxonomie et un système de gravité avec des critères clairs et des exemples.
Exemples de dossiers complétés illustrant le processus en action.

Un exemple concret, même bref, peut donner vie à ces documents. Par exemple, vous pourriez montrer comment une alerte de connexion suspecte provenant du SIEM a été validée, enrichie, qualifiée d'incident en raison d'une potentielle fuite de données, transmise au client dans les délais convenus, puis clôturée, les enseignements étant consignés dans votre registre des risques.

Ces documents doivent être cohérents entre eux et avec les pratiques réelles des outils et des équipes. Leur centralisation dans un système unique de gestion de la sécurité de l'information facilite la mise à jour des versions, le déploiement des mises à jour et la démonstration du contrôle aux clients et aux auditeurs.

Une plateforme ISMS comme ISMS.online peut vous aider à stocker ce matériel en un seul endroit, à lier chaque document au contrôle et au processus pertinents et à montrer comment les politiques, les procédures, les tickets et les améliorations soutiennent tous vos obligations A.5.25.

Choisir et utiliser les bons indicateurs

Les bons indicateurs permettent de vérifier si votre processus A.5.25 est opportun, cohérent et efficace, et non pas simplement surchargé. Vous avez besoin de mesures telles que le délai entre la détection et la décision, le pourcentage d'événements évalués dans les limites cibles, les taux de reclassement et les points faibles identifiés. Ces données étayent les revues de direction selon la norme ISO 27001 et rassurent vos clients quant au bon fonctionnement de votre système de décision.

Les indicateurs relatifs à l'A.5.25 devraient privilégier la qualité et la rapidité des décisions, et non leur simple volume. Les politiques de gestion des incidents des organismes internationaux, comme celle des Nations Unies, mettent également l'accent sur la qualité et la rapidité de la réponse plutôt que sur le simple décompte des incidents traités, ce qui correspond à cette approche.

Voici quelques exemples utiles :

Délai entre la détection de l'événement et la décision de classification.
Pourcentage d'événements évalués dans les délais internes convenus.
Taux de reclassement, par exemple d'événements ultérieurement requalifiés en incidents.
Taux de faux positifs par type d'événement et par locataire.
Nombre et types de faiblesses identifiées lors de l'évaluation de l'événement.

Le tableau ci-dessous illustre comment quelques indicateurs clés permettent de prendre différentes décisions.

Métrique	Ce que ça montre	Comment l'utiliser
délai entre la détection et la décision	Rapidité d'évaluation	Vérifier les capacités et affiner les garde-fous et les plans d'action
Pourcentage évalué dans les délais impartis	Discipline de processus	Responsabiliser les équipes et justifier les demandes de ressources
Taux de reclassement	Qualité de la décision initiale	Identifier les lacunes en matière de formation ou de critères
Faiblesses identifiées par les évaluations	Des pistes d'amélioration ont été identifiées lors du triage	Alimenter les programmes de gestion des risques et du changement

Vous pouvez présenter ces indicateurs lors des revues de direction et les utiliser pour prioriser les améliorations en matière de formation, de procédures et d'outils. Ils constituent également un moyen efficace de démontrer aux clients et aux auditeurs que votre processus décisionnel est fonctionnel et évolutif. Il est judicieux de tester ces mesures dans votre propre environnement, par le biais d'analyses de scénarios et de rétrospectives, avant d'investir massivement dans de nouveaux outils ou des changements majeurs de processus.

Présenter un audit clair et l'histoire du client

Un compte rendu d'audit clair, accompagné d'un témoignage client, illustre des exemples concrets, de la détection à l'analyse, en s'appuyant sur la documentation et les indicateurs que vous avez déjà développés. Vous démontrez comment un événement a été repéré, évalué selon la norme A.5.25, classifié, traité et examiné. Lorsque ces récits correspondent à vos procédures documentées et aux données de vos outils, les auditeurs et les clients sont bien plus enclins à faire confiance à votre système de contrôle.

Les auditeurs et les clients exigeants souhaitent souvent voir des exemples concrets, et non de simples politiques et graphiques. Il est utile de préparer une structure narrative standard applicable à des cas réels, comme par exemple :

Qu'a-t-on détecté et comment ?
Comment a-t-elle été validée et enrichie ?
Comment a-t-il été évalué par rapport à vos critères ?
Quelle décision a été prise, par qui et quand ?
Quelles actions ont suivi, et quel en a été le résultat ?
Qu’a-t-on appris et qu’est-ce qui a changé par la suite ?

Grâce à une documentation et des données bien structurées, vous pouvez illustrer avec assurance un ou deux exemples concrets, démontrant ainsi que la norme A.5.25 est intégrée à vos opérations et non pas simplement un document théorique. Au fil du temps, cette approche narrative renforce la confiance et facilite les audits et les évaluations clients ultérieurs.

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

ISMS.online vous aide à transformer la clause A.5.25, souvent abstraite, en un cadre de décision pratique et auditable, utilisable au quotidien par votre SOC et votre NOC. En centralisant les politiques, les procédures opérationnelles, les risques, les incidents et les actions d'amélioration dans un seul système de gestion de la sécurité de l'information (SGSI), vous pouvez les lier directement aux tickets et aux justificatifs déjà générés par vos équipes. Ainsi, vos objectifs de contrôle, vos opérations et votre processus d'audit restent parfaitement alignés.

Lors d'une démonstration ISMS.online, vous découvrez comment les objectifs de la politique, les flux de travail opérationnels et les preuves d'audit s'articulent au sein d'un environnement unique et structuré. La session explique généralement comment les définitions, les rôles, les critères de décision et les enregistrements d'incidents sont présentés côte à côte, vous permettant ainsi de retracer précisément le parcours d'un événement, de sa détection à son évaluation, jusqu'à son aboutissement, sans avoir à consulter plusieurs documents ou feuilles de calcul.

Ce que vous verrez dans une démo ISMS.online

Lors d'une démonstration sur ISMS.online, vous découvrirez comment votre processus A.5.25 peut être centralisé et organisé, au lieu d'être dispersé dans des fichiers et des outils. La session relie les politiques, les procédures, les tickets et les améliorations, vous permettant ainsi de suivre une décision concrète, du signal à la mise en œuvre. Vous obtiendrez ainsi une vision réaliste de la façon dont les objectifs de contrôle, les activités du SOC et du NOC, ainsi que les preuves d'audit peuvent rester alignés.

Vous pouvez également constater comment ce même environnement prend en charge d'autres contrôles de l'Annexe A, des revues de direction et une amélioration continue, de sorte que votre travail A.5.25 ne reste pas isolé.

Qui tire le plus grand profit d'une démonstration d'ISMS.online

Les personnes qui tirent le plus grand profit d'une démonstration d'ISMS.online sont celles qui jonglent actuellement entre conformité, opérations de sécurité et attentes clients, avec un temps limité et des outils dispersés. Il s'agit souvent des responsables SOC et NOC, des propriétaires de SMSI, des responsables de la conformité et des dirigeants de MSP qui doivent présenter aux clients et aux auditeurs un système de contrôle cohérent. Visualiser leurs flux de travail A.5.25 existants intégrés à un SMSI structuré permet à chacun de ces acteurs de comprendre où les efforts sont gaspillés et où la cohérence peut être renforcée.

Réunir un petit groupe interfonctionnel à la session facilite également le repérage des succès rapides et la définition d'une voie d'adoption réaliste.

Comment ISMS.online soutient la prise de décision A.5.25

ISMS.online facilite la prise de décision A.5.25 en plaçant les critères, les responsabilités et les enregistrements au cœur de la plateforme, au lieu de les noyer dans des fichiers épars. Vous pouvez y gérer votre procédure A.5.25, la lier aux manuels d'exploitation des SOC et NOC, définir les personnes habilitées à qualifier les événements d'incidents et joindre les tickets et les rapports d'incidents comme preuves. Vous disposez ainsi d'un catalogue évolutif de vos méthodes d'évaluation et de décision concernant les événements pour vos différents locataires et services.

Si vous accordez de l'importance à une prise de décision sereine, cohérente et vérifiable concernant les événements, que vous pouvez expliquer sans stress à vos clients et auditeurs, ISMS.online est prêt à vous aider à explorer ce à quoi cela pourrait ressembler dans votre propre environnement MSP.

Demander demo

Foire aux questions

Comment la norme ISO 27001:2022 A.5.25 change-t-elle réellement la façon dont votre SOC et votre NOC prennent des décisions ?

La norme ISO 27001:2022, paragraphe A.5.25, exige que votre SOC et votre NOC passent d'une approche où « la décision revient à la personne de garde » à une approche où… système de décision reproductible et explicable Vous pourrez vous défendre auprès des clients, des auditeurs et des organismes de réglementation. Au lieu d'un triage au cas par cas, vous devrez définir comment les événements sont évalués, qui est habilité à les classer et comment ces décisions sont consignées, examinées et améliorées.

Quel est l'impact pratique sur le travail quotidien des SOC et des NOC ?

Au quotidien, le protocole A.5.25 se situe entre la télémétrie brute et la gestion formelle des incidents :

Avant A.5.25 : Chaque analyste interprète les alertes différemment, en fonction de son expérience personnelle et de la pression qu'il subit.
Avec A.5.25 correctement conçu : Chaque alerte concernée suit le même chemin de décision court, du signal au résultat, avec des critères et des rôles clairement définis.

Pour un fournisseur de services gérés multi-locataires, cela affecte :

Comment les schémas similaires sont traités pour différents locataires et différents quarts de travail.
Avec quelle rapidité les analystes peuvent-ils justifier « aucun incident » plutôt que « notifier le client/l’autorité de régulation » ?
La crédibilité de vos opérations de sécurité dans les appels d'offres, les avis clients et les audits.

Lorsque vous créez A.5.25 colonne vertébrale de votre couche de triageVous réduisez ainsi le bruit, accélérez l'intégration et diminuez le risque de décisions incohérentes qui pourraient ultérieurement se traduire par des conclusions d'audit gênantes.

Comment devez-vous ajuster les rôles et les pouvoirs en vertu de l'article A.5.25 ?

A.5.25 fonctionne mieux lorsque vous précisez clairement qui peut :

Déterminer si une alerte relève du champ d'application de l'évaluation.
Classer quelque chose comme un événement, une faiblesse ou un incident.
Clôturer le dossier ou en réduire la gravité.
Approuver les dérogations ou les exceptions.

L'intégration de ces informations dans une matrice RACI concise rassure vos analystes et prévient les conflits délicats en pleine période de travail. Elle indique également aux auditeurs et aux clients que les décisions ne sont pas prises par hasard ou par commodité.

Comment une plateforme ISMS telle que ISMS.online renforce-t-elle ce contrôle ?

Un système de gestion de la sécurité de l'information (SGSI) donne à la norme A.5.25 une place visible au sein de votre organisation. Système de gestion de la sécurité de l'information, au lieu de le disperser dans des e-mails et des manuels d'exploitation. Avec ISMS.online, vous pouvez :

Conservez la procédure A.5.25, la politique d'incident et le RACI SOC/NOC en un seul endroit.
Relier les événements et les faiblesses du monde réel aux contrôles, aux risques associés et aux mesures correctives.
Démontrez lors des revues de direction comment vous renforcez au fil du temps les critères de décision, la formation et l'automatisation.

Cela permet d'apaiser les échanges externes. Lorsqu'un client ou un auditeur demande : « Pourquoi avez-vous traité ces deux alertes différemment ? », vous pouvez l'accompagner en détaillant la procédure standard et le raisonnement décisionnel, sans avoir à jongler entre des systèmes disparates.

Comment définir les événements, les incidents et les faiblesses pour que le SOC et le NOC restent parfaitement alignés ?

Vous assurez l'alignement du SOC et du NOC en définissant les événements, les incidents et les faiblesses. un langage clair et axé sur l'impact Ces définitions, utilisables par tous sans vérification des numéros de clause, servent de référence pour les outils, les manuels d'exploitation, les contrats et les rapports ; elles doivent donc être pertinentes pour les analystes, les responsables de service et les clients.

Quelles définitions fonctionnent dans un environnement MSP mutualisé ?

Un modèle pratique adopté par de nombreux fournisseurs de services gérés (MSP) est le suivant :

Event: Tout élément observable susceptible d'affecter la sécurité, la disponibilité ou les performances.
Incident: Un événement ou une chaîne d'événements qui menace réellement confidentialité, intégrité, disponibilité ou obligations légales/contractuelles.
La faiblesse: Une lacune en matière de contrôle ou de processus que vous découvrez lors de la gestion d'événements ou d'incidents, qu'il se soit déjà produit ou non.

Enraciner ces termes dans impact et probabilité sur l'activité aide les analystes à prendre des décisions qui résistent à l'épreuve des relations avec les clients et les auditeurs. Lorsqu'un analyste signale un incident, cette étiquette doit avoir la même signification dans :

Votre file d'attente au service d'assistance.
Votre registre des incidents ISO 27001.
Le registre des risques ou le dossier de gouvernance de votre client.

Cette cohérence devient particulièrement importante lorsqu'une seule équipe opérationnelle prend en charge plusieurs régions, secteurs et régimes réglementaires.

Comment créer un glossaire que les gens utiliseront réellement ?

Les longs glossaires sont rarement lus. Commencez par un une seule page qui ne concerne que les termes qui font le plus souvent l'objet de débats :

Définitions du courant d'air en langage courant.
Testez-les avec le SOC, le NOC, les gestionnaires de comptes et au moins une partie prenante non technique.
Reformulez toutes les phrases qui suscitent la confusion ou le débat.

Intégrez ensuite ces définitions dans :

Catégories de tickets et options de gravité dans votre outil ITSM.
Contrats clients, SLA et accords de traitement des données.
Rapports trimestriels et rapports d'incidents.

Comme les mêmes termes apparaissent partout, le personnel et les clients finissent par les adopter instinctivement. Cela permet d'éviter les discussions houleuses sur la nature de l'incident et de se concentrer plutôt sur son impact et les mesures à prendre.

Comment ISMS.online peut-il vous aider à harmoniser votre terminologie ?

Lorsque tous vos éléments clés sont regroupés dans un seul système de gestion de l'information (SGSI), l'harmonisation linguistique est grandement simplifiée. ISMS.online vous permet de :

Maintenir un glossaire central qui sous-tend les politiques, les procédures, les risques et les rapports d'incidents.
Associez les définitions à des contrôles et des clauses spécifiques, afin que les utilisateurs puissent comprendre leur importance.
Veillez à harmoniser la terminologie entre les normes ISO 27001, ISO 27701 et les autres normes de l'annexe L que vous adoptez.

Cette cohérence est un signal discret mais puissant de maturité lorsque les auditeurs ou les clients comparent votre documentation à ce qu'ils voient dans vos outils opérationnels.

Vous transformez A.5.25 en quelque chose que les gens utilisent réellement en concevant un chemin de décision court et reproductible Il s'agit de suivre systématiquement chaque alerte pertinente, puis d'intégrer ce processus directement dans les outils utilisés par vos analystes. La politique doit décrire le processus ; les outils doivent le rendre aussi simple que possible.

À quoi ressemble concrètement un processus allant du signal à la décision ?

De nombreux fournisseurs de services gérés convergent vers un modèle tel que :

Détecter: L'outil déclenche un signal en fonction de règles ou de seuils comportementaux.
Valider: Un analyste ou un système automatisé vérifie si le signal est suffisamment fiable pour justifier une enquête.
Enrichir: Ajouter le contexte métier : locataire, actif, utilisateur, service, modifications récentes.
Évaluer: Évaluer l'impact probable et la rapidité de l'escalade sur la confidentialité, l'intégrité, la disponibilité et les obligations.
Décider: Étiquetez le cas (bénin, sous observation, faiblesse, incident).
Route: Attribuer à la bonne équipe avec la priorité appropriée, le SLA et le plan de communication adéquats.

Vous pouvez refléter cela dans vos formulaires de cas en :

Rendre obligatoires les champs de validation et d'enrichissement de base pour les nouveaux cas.
Utilisation de listes contrôlées pour les résultats liés à votre procédure A.5.25 et à votre politique en matière d'incidents.
Création de règles de routage qui acheminent les tickets vers les files d'attente et les groupes d'astreinte appropriés lorsque des combinaisons particulières d'impact et de probabilité apparaissent.

Cela permet de conserver un flux de travail suffisamment court pour être utilisé à 3 heures du matin, mais suffisamment structuré pour être visible. comment et pourquoi Vous avez pris chaque décision vous-même.

La rapidité est importante, mais l'apprentissage l'est tout autant. Un moyen simple de trouver un équilibre entre les deux consiste à :

Utilisez le chemins légers pour des schémas bien compris et à faible risque, souvent avec une automatisation accrue.
Utilisez le parcours de révision plus lourds pour les scénarios à fort impact, à forte incertitude ou sensibles à la réglementation, avec un double contrôle ou une approbation explicite.
Recueillez un petit nombre de mesures de la qualité des décisions (par exemple, le temps de classification, les taux de reclassement, les faiblesses découvertes) et discutez-en régulièrement lors des revues de direction.

Cela vous permet de maîtriser les temps de réponse tout en réduisant progressivement le bruit, les erreurs de classification et les occasions manquées de renforcer votre environnement.

Quelle est la place d'un système de gestion de la sécurité de l'information (SGSI) tel que ISMS.online dans ce contexte ?

Votre flux de travail est le moteurmais le SMSI est le gouverneur et journal de bord:

La procédure A.5.25, la matrice RACI et les critères de décision sont disponibles sur ISMS.online.
Les tickets et incidents réels sont rattachés à ces documents et aux risques qu'ils concernent.
Les actions correctives, les améliorations apportées à la formation et les décisions de réglage sont consignées et examinées.

Cela montre clairement que A.5.25 n'est pas seulement un organigramme interne, mais une partie contrôlée et auditable de votre système de gestion de la sécurité de l'information qui évolue de manière mesurée.

Comment intégrer la norme A.5.25 aux processus NOC et ITIL ainsi qu'aux SLA sans ajouter de bureaucratie frustrante ?

Vous tirez pleinement profit de A.5.25 lorsque améliore Au lieu de s'ajouter à vos flux de gestion des services informatiques existants comme une simple liste de contrôle supplémentaire, l'objectif est de proposer une vision cohérente du déroulement des événements, de la surveillance à l'évaluation de leur impact, jusqu'à leur résolution, en passant par la sécurité, les services et la continuité d'activité.

Comment aligner concrètement les flux SOC et NOC ?

Une approche pratique consiste à :

Cartographiez le parcours actuel des événements dans votre outil ITSM :

Quelles files d'attente gèrent les problèmes de disponibilité et de performance ?
Quelles files d'attente gèrent les événements de sécurité clairs ?
Où se produisent actuellement (ou n'ont pas lieu) les transferts entre le NOC et le SOC ?

Marquez les points où :

Un problème de service nécessite véritablement une analyse de sécurité au titre de l'A.5.25.
Un problème de sécurité a clairement des répercussions sur les SLA, les plans de continuité d'activité ou les rapports réglementaires.

À partir de là, vous pouvez construire un matrice d'escalade conjointe cela clarifie :

Lorsque le NOC doit faire appel au SOC pour la classification des événements et l'évaluation des risques.
Lorsque le SOC doit faire appel au NOC en raison d'un impact sur la capacité, le basculement ou la continuité.
Quelles combinaisons de résultats et de types de locataires déclenchent des communications spécifiques avec les clients ou des notifications aux organismes de réglementation ?

L'intégration de cette matrice dans votre système de gestion intégré, vos manuels d'exploitation et vos guides d'astreinte offre aux utilisateurs une voie claire à suivre, même en période de forte pression.

Comment la gestion intégrée de l'annexe L peut-elle vous aider dans ce cas ?

Si vous exploitez un Système de gestion intégré basé sur l'annexe LEn combinant la norme ISO 27001 avec des normes telles que l'ISO 20000-1 (gestion des services) et l'ISO 22301 (continuité d'activité), vous disposez déjà :

Structures de clauses courantes (contexte, leadership, planification, soutien, opération, performance, amélioration).
Des lieux naturels pour aligner les processus de gestion des incidents, de continuité et de changement.
Attentes partagées en matière de revue de direction, de documentation et d'amélioration continue.

Vous pouvez l'utiliser pour :

Harmoniser les catégories, les priorités et les règles d'escalade pour les incidents de sécurité, de service et de continuité.
Mener des analyses conjointes post-incident qui examinent conjointement l'impact opérationnel, l'expérience client et la posture de sécurité.
Démontrez aux auditeurs que le même événement du monde réel est reflété de manière cohérente dans plusieurs normes, et non traité différemment dans chaque silo.

Cela facilite, par conséquent, le maintien de la confiance avec les clients qui accordent autant d'importance à la disponibilité et à la résilience qu'à la sécurité pure.

Comment ISMS.online prend-il en charge la gestion intégrée autour de la norme A.5.25 ?

ISMS.online est conçu pour les organisations qui gèrent simultanément plusieurs normes de l'Annexe L. Concrètement, cela signifie que vous pouvez :

Placez votre procédure d'évaluation des événements A.5.25 à côté des processus de gestion des incidents et de continuité des services informatiques.
Réutiliser les rôles, les plans de communication et les actions d'amélioration pour l'ensemble des normes.
Démontrer, dans un seul espace, comment un événement s'est déroulé à travers les contrôles de sécurité, de service et de continuité.

Pour les fournisseurs de services gérés qui se présentent comme des partenaires stratégiques plutôt que comme de simples fournisseurs de produits de base, cette vision intégrée vous aide à démontrer que vos obligations envers vos clients sont remplies de manière coordonnée et transparente.

Quels outils et quelle automatisation permettent de mieux prendre en charge A.5.25 dans un MSP multi-locataire tout en protégeant le jugement humain ?

Le modèle le plus durable pour A.5.25 est celui où un système unique de « dossier d'enregistrement » Le système conserve l'historique de chaque événement important, tandis que les outils d'assistance l'alimentent en contexte et en automatisation. Les plateformes SIEM, SOAR, EDR et de surveillance effectuent le gros du travail de détection et d'enrichissement, mais votre capacité à justifier vos décisions repose sur le dossier d'enregistrement.

Comment structurer le « dossier officiel » autour de A.5.25 ?

Dans de nombreux fournisseurs de services gérés, l'existant module de centre de services ou de gestion des incidents est le meilleur candidat car il possède déjà :

Attribue les propriétaires et les équipes.
Suivi de l'état, horodatage et notes.
Regroupe les rapports de tous les locataires et lignes de service.

Vous pouvez configurer votre environnement de sorte que :

Chaque alerte concernée crée un dossier dans ce système ou y est rattachée.
Chaque cas capture la classification, la gravité, le locataire, le contexte de risque et le résultat requis par votre procédure A.5.25.
L'automatisation effectue des tâches sûres telles que la corrélation, la déduplication, la suppression du bruit et la fermeture pour les modèles bénins connus.

Par ailleurs, scénarios à fort impact, sensibles ou inhabituels Elles nécessitent toujours un examen ou une approbation humaine explicite avant que les décisions clés ne soient finalisées.

Pour différents locataires, vous maintenez un conception de flux de travail unique mais varient :

Seuils de gravité et d'escalade.
Destinataires et délais de notification.
Exigences d'approbation pour des activités telles que les actions visibles par le client ou les notifications aux organismes de réglementation.

Cela permet aux analystes de disposer d'un modèle mental cohérent tout en respectant la tolérance au risque et les engagements contractuels de chaque client.

Comment éviter de surautomatiser l'évaluation des événements ?

Il est tentant d'automatiser autant que possible. L'article A.5.25 vous incite à définir clairement les limites de l'automatisation :

Automatisation de soutien : enrichissement, corrélation, reconnaissance de modèles, fermeture automatisée des faux positifs sûrs et bien compris.
Zones réservées aux personnes : décisions ayant une incidence significative sur la confidentialité, l’intégrité, la disponibilité, les obligations légales ou la confiance des clients.

Dans vos dossiers, il doit être clairement indiqué quelles étapes ont été automatisées et lesquelles ont nécessité une intervention humaine, ainsi que l'identité de la personne ayant pris chaque décision. Cette transparence rassure les auditeurs et les clients, leur garantissant que vous n'utilisez pas une automatisation opaque pour prendre des décisions cruciales à leur insu.

Comment un système de gestion de la sécurité de l'information (SGSI) tel que ISMS.online vous aide-t-il à gérer l'automatisation ?

L'automatisation a autant besoin de gouvernance que les procédures humaines. ISMS.online vous aide à :

Les manuels de procédures et les règles d'automatisation constituent des contrôles formels, liés aux risques et aux exigences de l'annexe A.
Consignez les approbations, les résultats des tests et les plans de restauration lorsque vous modifiez les règles.
Intégrez les indicateurs opérationnels (par exemple, les taux de faux positifs, les détections manquées, les tendances de reclassement) dans les revues de direction et les actions d'amélioration.

Cela vous permet d’accroître l’automatisation là où elle est sûre, tout en démontrant, sur le papier et dans la pratique, que vous respectez l’esprit de l’article 5.25 et que vous maintenez la supervision humaine là où elle doit être.

Comment pouvez-vous prouver aux auditeurs et aux clients que vos décisions relatives aux événements A.5.25 sont cohérentes, opportunes et s'améliorent au fil du temps ?

Vous démontrez une mise en œuvre solide de A.5.25 en combinant un petit ensemble de documents cohérent, quelques indicateurs clairs ou une ou deux analyses de cas détailléesEnsemble, ces éléments démontrent que vous avez une approche définie, que vous la suivez dans vos opérations réelles et qu'elle s'améliore avec l'expérience.

Quels documents et preuves sont généralement bien perçus ?

Au lieu d'une politique à long terme, concentrez-vous sur un paquet serré qui reste synchronisé :

Une politique de gestion des incidents définissant votre approche globale et vos définitions.
Une procédure A.5.25 distincte expliquant comment les événements sont évalués et classés.
Des manuels d'exploitation SOC et NOC qui reflètent cette procédure dans un langage adapté aux équipes.
Une matrice RACI pour l'évaluation, l'escalade, la clôture et l'approbation.
Une taxonomie et un système de gravité alignés sur votre outil ITSM et vos contrats clients.
Un petit ensemble d'exemples d'enregistrements anonymisés (tickets, rapports d'incidents, journaux de faiblesses) qui utilisent tous le même langage et les mêmes catégories.

En plus de ces documents, choisissez quelques indicateurs axés sur la prise de décision, tels que :

Temps médian entre la détection et la première classification.
Pourcentage d’événements relevant du champ d’application de l’A.5.25 classés dans le délai imparti.
Pourcentage de décisions reclassées ultérieurement après examen.
Nombre de faiblesses identifiées lors du triage et proportion ayant mené à des actions d'amélioration menées à bien.

Ces chiffres indiquent aux auditeurs et aux clients que vous traitez le triage comme un processus géré, pas seulement une activité.

Comment transformer des exemples réels en histoires convaincantes ?

Choisissez un ou deux cas réels illustrant le fonctionnement du contrôle comme prévu :

Afficher le signal d'origine et son point d'apparition (outil et file d'attente).
Décrivez les étapes d'enrichissement et d'évaluation, en indiquant qui a fait quoi et quand.
Afficher la décision, le routage et toutes les notifications clients ou réglementaires.
Mettez en évidence les points faibles identifiés et les actions d'amélioration que vous avez consignées.
Indiquez où cette amélioration a été abordée lors d'une revue de direction ou d'un audit interne.

Lorsque ces récits correspondent à vos procédures écrites et à vos indicateurs, la plupart des questions relatives à l'équité, aux délais et à l'apprentissage deviennent beaucoup plus faciles à répondre.

Comment ISMS.online vous aide-t-il à présenter cette histoire de manière calme et crédible ?

ISMS.online centralise vos politiques, procédures, risques, incidents, audits et rapports d'amélioration. Ainsi, lorsqu'une personne vous interroge sur la norme A.5.25, vous pouvez :

Ouvrir le contrôle et la procédure.
Passez directement aux incidents liés, aux faiblesses et aux actions correctives.
Présenter les notes de revue de direction et les conclusions d'audit qui font référence au même contrôle.

Cette capacité à naviguer avec fluidité dans les preuves est souvent aussi convaincante que leur contenu lui-même. Elle indique que votre SOC et votre NOC fonctionnent au sein d'un environnement structuré. système de gestion intégré et gouvernéIl ne s'agit pas simplement d'un ensemble d'outils et de personnes héroïques, mais d'une solution qui donne aux clients, aux auditeurs et aux organismes de réglementation l'assurance que votre façon d'évaluer les événements aujourd'hui restera pertinente lorsqu'ils examineront vos décisions dans quelques mois ou quelques années.

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.25 Évaluation et décision relatives aux incidents de sécurité de l'information – MSP Socnocc Decisioning