Preuves exploitables en matière d'enquêtes médico-légales pour les fournisseurs de services gérés : Explication de la norme ISO 27001 A.5.28

De « il suffit de le réparer » à « le prouver » : pourquoi les fournisseurs de services gérés ont besoin de preuves exploitables par l’analyse forensique

Des preuves exploitables en cas d'incident permettent de constituer automatiquement un enregistrement clair et irréfutable des tickets, journaux et communications quotidiens de votre fournisseur de services gérés (MSP) dès qu'un incident est mis en cause. Au lieu de simplement affirmer « faites-nous confiance, nous avons agi correctement », vous pouvez démontrer qui a fait quoi, quand, avec quelles autorisations, sur quels systèmes et dans le cadre des obligations contractuelles définies.

En cas de litige, la partie qui a un dossier plus clair est souvent en position de force.

Des preuves exploitables en cas d'incident permettent de transformer les données opérationnelles quotidiennes de votre fournisseur de services gérés en un récit solide, capable de résister à l'examen minutieux des clients, des assureurs et des organismes de réglementation. En cas de litige, la partie disposant de documents plus clairs et cohérents est généralement en position de force, et cette position se construit bien avant que le problème ne survienne.

La plupart des fournisseurs de services gérés accumulent déjà une quantité considérable de données opérationnelles. Tickets d'assistance, alertes de gestion et de surveillance à distance (RMM), événements de gestion des informations et des événements de sécurité (SIEM), enregistrements d'e-mails et conversations instantanées sont créés pour quasiment chaque problème. Pourtant, lorsqu'un incident grave survient, la direction constate souvent que ces données ne permettent pas de reconstituer un récit cohérent. Les chronologies sont incomplètes, les actions ne sont pas documentées et les approbations clés ne sont conservées que dans les boîtes de réception ou les outils de messagerie instantanée.

La majorité des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont déclaré avoir subi au moins un incident de sécurité lié à un tiers ou à un fournisseur au cours de l'année écoulée. Pour les fournisseurs de services gérés (MSP), cela signifie que leur capacité à justifier la manière dont ils ont géré les problèmes liés aux fournisseurs et aux plateformes est désormais scrutée de près.

Cet écart devient douloureusement visible à trois moments :

Un client important conteste votre version d'un incident
Un assureur spécialisé en cyber-risques demande des preuves détaillées avant de procéder au paiement d'une indemnisation.
Un auditeur ou un organisme de réglementation vous demande comment vous savez que vous avez respecté vos obligations.

Quand on prend du recul et qu'on analyse ces situations, on se rend compte qu'il ne s'agit pas de débats techniques, mais de faits. Et l'organisation qui peut fournir un compte rendu clair et actuel détermine généralement l'issue de cette discussion.

Si votre équipe a déjà passé des jours à reconstituer un événement à partir de billets épars, de captures d'écran et de fichiers d'exportation, vous avez déjà constaté les conséquences d'une mauvaise gestion des preuves. Factures réduites, relations tendues et discussions délicates avec les conseils d'administration en découlent souvent. À terme, ces incidents érodent vos marges et nuisent à votre réputation de prestataire de confiance.

Être prêt pour l'analyse forensique ne signifie pas transformer votre fournisseur de services gérés en un laboratoire d'analyse forensique numérique complet. Il s'agit plutôt d'organiser vos méthodes de travail habituelles afin que, lorsque vous avez besoin de preuves, celles-ci soient déjà disponibles : structurées, traçables, fiables et proportionnées. La norme ISO 27001:2022, contrôle A.5.28, « Collecte des preuves », formalise cette exigence. Les résumés pratiques du contrôle A.5.28, tels que les explications de contrôles indépendants, insistent sur l'importance d'une identification, d'une collecte et d'une conservation planifiées et fiables des preuves au sein d'un système de management de la sécurité de l'information (SMSI). Il s'agit de considérer les preuves comme un élément planifié, et non comme une ressource à trouver dans l'urgence.

Lorsque vous pensez à votre propre organisation, une question de départ utile est simple : si vous deviez informer demain l’équipe juridique d’un client sur un incident critique survenu il y a six mois, pourriez-vous vous fier uniquement à vos tickets et journaux existants, ou devriez-vous vous fier à la mémoire des gens ?

Le coût caché des enregistrements d'incidents lacunaires

Des rapports d'incidents incomplets nuisent insidieusement aux profits et à la confiance, même si personne ne les considère encore comme des « preuves ». En tant que dirigeant d'un fournisseur de services gérés (MSP), vous le ressentez par une augmentation des pertes sur créances, des délais de résolution plus longs et des échanges plus défensifs avec les clients et les assureurs après les incidents.

Les preuves insuffisantes apparaissent rarement comme un poste de dépense dans votre compte de résultat, mais elles érodent inexorablement la rentabilité et la confiance. Le temps consacré à reconstituer les incidents est du temps perdu pour apporter de la valeur aux clients, améliorer les services ou développer de nouvelles activités. Chaque « geste commercial » entrepris parce qu'aucune des parties ne peut prouver sa version des faits grève des marges que vous pensiez sûres.

Il existe également un coût d'opportunité. De nombreux fournisseurs de services gérés (MSP) promettent une « surveillance 24 h/24 et 7 j/7 » et une « sécurité proactive » dans leurs offres, mais ne peuvent étayer ces promesses par des données fiables et vérifiables. Il leur est donc plus difficile de conquérir des clients sensibles à la sécurité dans les secteurs réglementés, ou de justifier des prix plus élevés pour des services à haute assurance. Les clients potentiels des secteurs financier, de la santé ou public demandent de plus en plus des preuves concrètes plutôt que des explications.

L'enquête 2025 d'ISMS.online révèle que les clients attendent de plus en plus des fournisseurs qu'ils se conforment à des référentiels formels tels que les normes ISO 27001, ISO 27701, RGPD, Cyber Essentials ou SOC 2, plutôt que de se fier à de simples « bonnes pratiques ». Cette exigence renforce la pression sur les fournisseurs de services gérés (MSP) qui souhaitent vendre leurs services sur des marchés réglementés ou sensibles à la sécurité, en s'appuyant sur leur gestion rigoureuse des incidents et leur expertise en matière de preuves.

Des registres d'incidents plus complets changent la donne. Présenter à un client une chronologie précise et structurée, étayée par des preuves, facilite grandement les échanges délicats. Vous pouvez ainsi démontrer votre diligence raisonnable, souligner les limites contractuelles et expliquer comment les décisions ont été prises et mises en œuvre. Les assureurs et les auditeurs sont également plus enclins à faire confiance à un prestataire capable de produire rapidement des registres cohérents.

Si, en tant que propriétaire ou directeur général, vous acceptez régulièrement des radiations après des incidents parce que les faits ne sont pas clairs, c'est un signe évident que vos pratiques en matière de preuves vous coûtent à la fois des profits et un pouvoir de négociation.

Que signifie réellement « prêt pour l'analyse forensique » pour un fournisseur de services gérés (MSP) ?

Pour un fournisseur de services gérés (MSP), la capacité d'analyse forensique consiste à reconstituer rapidement et de manière convaincante les incidents importants sur l'ensemble des plateformes de ses clients, en s'appuyant sur les preuves issues de ses outils courants. Il s'agit moins de disposer de kits d'analyse forensique spécialisés que de concevoir ses opérations courantes de manière à recueillir des preuves, notamment dans un environnement mutualisé où l'on interagit avec de nombreux clients et fournisseurs.

Environ 41 % des répondants à l'enquête ISMS.online de 2025 ont déclaré que la gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs constituent un défi majeur en matière de sécurité de l'information. Pour les fournisseurs de services gérés (MSP), il est donc d'autant plus important que leurs tickets et journaux d'incidents puissent retracer précisément la manière dont ils ont traité les problèmes sur les plateformes cloud, chez les différents fournisseurs et avec les outils utilisés.

Deux idées fondamentales sous-tendent cette démarche. Premièrement, il s'agit de déterminer à l'avance les types de preuves pertinentes pour les incidents les plus fréquents : failles de sécurité, compromission de messagerie professionnelle, pannes, pertes de données, erreurs d'accès, etc. Cela implique d'anticiper les tickets, journaux, e-mails et approbations nécessaires pour répondre aux questions pointues des clients, des assureurs ou des organismes de réglementation.

Deuxièmement, vous concevez vos outils et processus de manière à ce que ces preuves soient générées, enregistrées et conservées par défaut. Les analystes n'ont pas besoin de mémoriser des règles complexes en pleine intervention ; le centre de services, le système de surveillance et la plateforme de documentation les guident dans la collecte des informations nécessaires. Par exemple, un modèle de notification de compromission suspectée peut demander de manière systématique des références aux journaux, des approbations et des notifications aux clients.

Ainsi, la norme A.5.28 n'est pas une exigence de conformité abstraite. Elle incite à passer d'une approche passive (« corriger et oublier ») à une approche proactive (« corriger, documenter et être prêt à le prouver ») pour chaque aspect de votre activité de fournisseur de services gérés, y compris la gestion des plateformes cloud tierces et des responsabilités partagées.

Une simple comparaison permet de rendre la différence concrète :

Aspect	Gestion des incidents ad hoc	Gestion des incidents prête pour l'analyse médico-légale
Billets	Notes en texte libre, champs incohérents	Champs structurés, échéanciers cohérents, propriétaires clairement identifiés
Journaux	Exportations dispersées, extraites au besoin	Rétention pré-planifiée, emplacements connus, référencée
Approbations et décisions	Enfoui dans les e-mails ou les discussions	Résumé dans le ticket, lié aux approbateurs désignés
plateformes tierces	Chaque cas est traité individuellement.	Des règles claires sur les données capturées à partir de chaque système clé
Résultat des litiges	S'appuyant sur la mémoire et la négociation	Appuyé par des actions documentées et des artefacts préservés

Lorsqu'on compare ces deux approches, la différence fondamentale est simple : le traitement ad hoc vous oblige à vous fier à votre mémoire, tandis que le traitement conforme aux normes d'analyse forensique vous permet de vous appuyer sur des preuves irréfutables. Les fournisseurs de services gérés (MSP) qui adoptent ces normes transforment les données opérationnelles quotidiennes en un atout stratégique plutôt qu'en un ensemble disparate et fragile.

Si vous ne pouvez pas établir une chronologie complète des incidents majeurs du dernier trimestre en une journée, c'est un signe clair que votre préparation en matière d'enquêtes médico-légales et vos pratiques A.5.28 nécessitent une attention particulière.

Demander demo

Ce que demande réellement la norme ISO 27001 A.5.28 « Collecte de preuves »

La norme A.5.28 exige de votre organisation qu'elle identifie, collecte et conserve les informations susceptibles de servir de preuves, de manière planifiée et fiable, et non par intuition. Concrètement, cela signifie savoir quand un incident justifie un traitement de niveau probatoire, quelles données seront extraites de votre infrastructure MSP et comment ces enregistrements seront protégés afin de garantir leur intégrité.

La norme ISO 27001:2022, contrôle A.5.28, exige que vous disposiez de méthodes claires et documentées pour identifier, collecter, acquérir et conserver les informations susceptibles de servir de preuves en cas d'événements ou d'incidents de sécurité. En d'autres termes, elle vous invite à anticiper : déterminer les éléments pouvant servir de preuves, planifier leur collecte et les protéger afin de garantir leur fiabilité.

Étant donné que le texte normatif officiel est soumis à licence, il est courant que les organisations s'appuient sur des résumés professionnels et des guides de mise en œuvre. Les explications de l'annexe A et les résumés des contrôles A.5.28, largement utilisés, aident les praticiens à comprendre l'objectif du contrôle sans avoir à reproduire l'intégralité de la norme.

Ces documents, ainsi que les résumés destinés aux praticiens, mettent systématiquement en évidence quatre attentes sous-jacentes à la norme A.5.28 :

vous savez quand Une manipulation de qualité probante est nécessaire
vous savez est ce que nous faisons quel type d'information est considéré comme une preuve dans votre contexte
vous savez pour qui est autorisé à s'en occuper et how ils devraient le faire
Vous pourrez ultérieurement démontrer que les preuves ont été recueillies et conservées correctement.

Pour les fournisseurs de services gérés (MSP), cela signifie adapter la norme A.5.28 aux réalités des environnements mutualisés. Les données peuvent se trouver dans votre outil d'automatisation des services professionnels (PSA), votre solution RMM, votre SIEM, votre plateforme d'identité, vos systèmes de sauvegarde, vos passerelles de messagerie, etc. Ce contrôle ne vous demande pas de tout collecter indéfiniment. Il vous demande simplement d'être méthodique et cohérent quant aux éléments les plus importants et à leurs raisons.

Si vous ne pouvez pas expliquer ce qui compte comme preuve dans votre environnement et qui en est responsable, votre mise en œuvre de l'A.5.28 n'est pas prête à être examinée.

Ces informations sont d'ordre général et ne constituent pas un avis juridique. Pour toute décision relative à des cas particuliers, des contrats ou des obligations réglementaires, veuillez consulter des professionnels qualifiés en droit et en conformité.

Pour un fournisseur de services gérés (MSP), les quatre verbes A.5.28 – identifier, collecter, acquérir et préserver – se traduisent par des comportements spécifiques pour vos équipes lors de la gestion des incidents. Plus ces comportements sont clairement décrits, plus il est facile de les mettre en œuvre, de les tester et de les auditer.

Lorsqu'on traduit A.5.28 en langage courant, quatre verbes ressortent : identifier, collecter, acquérir, préserverEnsemble, ils expliquent comment transformer un incident chaotique en un compte rendu défendable plutôt qu'en notes et souvenirs épars.

Identifier: Cela signifie reconnaître qu'un événement, un ticket ou un élément de preuve particulier peut avoir une valeur probante. Par exemple, une règle de boîte aux lettres suspecte, une tentative de connexion privilégiée infructueuse ou une plainte d'un client concernant un accès inattendu peuvent constituer des sources de preuves.
Collecte: Cela englobe la collecte d'informations pertinentes pendant le déroulement d'un incident. Il peut s'agir, par exemple, de joindre des extraits de journaux à un ticket, de sauvegarder une copie d'un courriel malveillant ou d'exporter un instantané de la configuration avant d'y apporter des modifications.
Acquérir: Elle est souvent utilisée en criminalistique numérique pour des opérations de capture plus formelles, comme la prise d'une image forensique d'un serveur ou l'exportation contrôlée d'un grand ensemble de journaux. Les fournisseurs de services gérés peuvent faire appel à des partenaires spécialisés dans les affaires à forts enjeux.
Préserver: Il s'agit de préserver l'intégrité des preuves dans le temps. Une fois recueillies, elles doivent être stockées en toute sécurité, avec un contrôle d'accès et un suivi des modifications, afin de pouvoir démontrer ultérieurement qu'elles n'ont pas été altérées de manière inappropriée.

En pratique, les auditeurs vérifieront deux choses. Premièrement, que vous ayez des procédures documentées expliquant comment ces verbes s'appliquent dans votre environnement. Deuxièmement, que vous puissiez fournir des exemples concrets : tickets, archives de journaux, captures d'écran et rapports démontrant que ces procédures ont été suivies lors d'incidents réels.

Où se situe A.5.28 dans le cycle de vie d'un incident

La collecte de preuves constitue une étape du cycle de vie global d'un incident, qui s'étend de la planification et la détection jusqu'à l'analyse et l'amélioration. Pour les fournisseurs de services gérés (MSP), ce cycle de vie doit s'appliquer à de nombreux clients tout en respectant les contrats et le contexte réglementaire de chacun.

Les résumés des contrôles de l'annexe A montrent que, dans l'édition 2022 de la norme ISO 27001, le contrôle A.5.28 figure aux côtés des contrôles relatifs à la planification, la gestion, l'analyse et le signalement des incidents. La collecte de preuves fait partie intégrante de ce cycle de vie et doit être visible à chaque étape, et non ajoutée a posteriori.

Étape 1 – Planifier la gestion des incidents et des preuves

Vous définissez la classification des incidents, les responsables à chaque étape et les personnes qui décident du recours à des procédures de traitement des preuves. Cette planification instaure un cadre qui permet de garder son calme lorsque les incidents deviennent stressants.

Étape 2 – Détecter et évaluer les événements par rapport à ces plans

Vous détectez et hiérarchisez les événements, déterminez lesquels constituent de véritables incidents et identifiez ceux qui nécessitent une documentation plus approfondie et la collecte de preuves. Des critères clairs aident les équipes à reconnaître le moment où un problème courant devient un élément de preuve potentiel.

Étape 3 – Répondre tout en recueillant les informations clés

Vous prenez des mesures techniques et commerciales pour contenir et résoudre l'incident, tout en veillant à ce que le ticket, les journaux et les approbations soient consignés au fur et à mesure. Les preuves doivent s'accumuler en même temps que la réponse, et non être ajoutées précipitamment après coup.

Étape 4 – Recueillir et conserver correctement les preuves

Vous collectez et stockez les éléments pertinents conformément à la section A.5.28, dans des lieux et selon des contrôles d'accès convenus, afin de garantir leur intégrité ultérieurement. À ce stade, vous transformez les données opérationnelles en un élément de preuve recevable en cas de litige.

Étape 5 – Analyser les incidents et améliorer vos contrôles

Vous utilisez les éléments de preuve pour analyser les événements, démontrer votre diligence raisonnable et optimiser vos contrôles, processus et contrats. Les séances de retour d'expérience sont bien plus efficaces lorsqu'elles s'appuient sur des documents fiables plutôt que sur des souvenirs partiels.

Pour les fournisseurs de services gérés (MSP), le ticket d'assistance est souvent l'élément central qui relie ces différentes étapes. Concevoir ce ticket pour qu'il prenne en charge la norme A.5.28 représente donc l'une des modifications les plus importantes que vous puissiez apporter, car cela offre à chaque technicien un espace familier pour consigner les informations essentielles.

Si vous ne pouvez pas démontrer rapidement comment un incident majeur récent a évolué à travers ces cinq étapes, il est peu probable que votre collecte de preuves résiste à un litige ou à un audit.

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

Traduction de A.5.28 en préparation médico-légale MSP

Pour un fournisseur de services gérés (MSP), la capacité d'analyse forensique implique de pouvoir reconstituer rapidement et de manière convaincante les incidents importants survenus chez tous ses clients, en s'appuyant sur les preuves issues de ses outils et contrats habituels. La norme A.5.28 constitue le lien essentiel qui relie cette capacité à son système de gestion de la sécurité de l'information conforme à la norme ISO 27001 et aux engagements pris dans son catalogue de services.

Un objectif pertinent en matière de criminalistique numérique est spécifique et mesurable. Par exemple : « Pour tout incident de sécurité prioritaire, nous pouvons fournir une chronologie complète, preuves à l’appui, dans les 24 heures suivant une demande d’un client, d’un assureur ou d’un organisme de réglementation. » Ce type d’énoncé offre un cadre concret pour la conception et l’évaluation des procédures, et correspond aux attentes de nombreuses entreprises clientes vis-à-vis de leurs fournisseurs de services gérés (MSP). Les recommandations relatives à la préparation à la criminalistique numérique pour les grandes organisations, telles que les analyses de consultants indépendants, insistent sur l’importance d’une gestion structurée et documentée des incidents par les prestataires de services.

Pour atteindre cet état, il faut aligner trois couches :

votre Documents du SMSI (politiques, procédures, évaluations des risques)
votre flux de travail opérationnels (service d'assistance, surveillance, gestion des changements, communication)
votre configuration de l'outil (champs de ticket, conservation des journaux, droits d'accès, automatisation)

Lorsque ces différents niveaux sont interconnectés, la démonstration du point A.5.28 devient beaucoup plus simple. Votre politique décrit les actions à entreprendre, vos processus guident le personnel dans leur mise en œuvre et vos outils produisent les preuves attestant de leur réalisation. Une plateforme de gestion de la sécurité de l'information (SGSI) centralisée, telle que ISMS.online, peut vous aider à maintenir la synchronisation de ces niveaux en associant vos politiques et procédures directement aux contrôles de l'annexe A et en les reliant aux incidents réels. Ce modèle d'utilisation d'une plateforme SGSI ou de réponse aux incidents centralisée pour connecter les politiques, les contrôles et les enregistrements d'incidents est largement préconisé dans les recommandations relatives aux plateformes de réponse aux incidents de sécurité.

La préparation aux enquêtes médico-légales transforme l'article A.5.28 d'une obligation de conformité en un atout commercial qui renforce à la fois la confiance et la force de négociation.

Établir des objectifs concrets de préparation médico-légale

Les objectifs de préparation aux enquêtes numériques doivent définir clairement la qualité et la rapidité avec lesquelles vous fournissez des preuves en cas d'incident, en fonction de votre clientèle et de votre profil de risque. Sans eux, il est difficile de déterminer si vos pratiques actuelles sont suffisantes ou si elles ne le sont que « jusqu'à ce qu'un incident grave survienne ».

En tant que dirigeant d'un fournisseur de services gérés (MSP), vous devez définir des objectifs de préparation aux enquêtes qui tiennent compte à la fois de votre profil de risque et de la composition de votre clientèle. Les objectifs pour un portefeuille composé exclusivement de petites entreprises différeront de ceux pour les clients des secteurs financier ou de la santé, qui sont soumis à un contrôle réglementaire et à un risque de litige.

Vous pourriez commencer par demander :

Pour quels clients ou lignes de services un échec en matière de preuves vous serait-il le plus préjudiciable ?
Quels types d'incidents présentent le risque le plus élevé de litiges ou de contrôle réglementaire ?
Dans la pratique, à quelle vitesse les clients, les assureurs ou les organismes de réglementation s'attendent-ils à obtenir des réponses ?

À partir de là, vous pouvez définir un petit nombre d'objectifs, tels que :

« Chaque incident de sécurité critique fait l’objet d’un journal d’actions complet et horodaté dans le ticket. »
« Pour certains types d’incidents, nous conservons les journaux d’incidents clés pendant au moins douze mois. »
« Les incidents à haut risque comprennent notamment un simple registre de traçabilité des artefacts exportés. »

Ces objectifs influencent ensuite la conception des contrôles. Ils déterminent les champs obligatoires dans les tickets, les journaux à centraliser, la durée de conservation des données et les cas nécessitant un traitement particulier. Ils servent également de point de référence lorsque les clients demandent : « Comment prouvez-vous ce qui s’est passé ? » ou « Dans quel délai pouvez-vous nous fournir les détails ? »

Intégrer A.5.28 dans votre SMSI

Intégrer la norme A.5.28 à votre SMSI implique d'intégrer les exigences en matière de preuves dans vos politiques, évaluations des risques, procédures et revues, plutôt que de les traiter comme une simple liste de contrôle. Une intégration réussie permet aux auditeurs et aux clients d'établir un lien clair entre l'intention écrite et les enregistrements d'incidents réels.

Une fois que vous savez ce que vous voulez que la préparation médico-légale permette d’accomplir, vous pouvez intégrer A.5.28 à votre ISMS de manière structurée, plutôt que de le traiter comme un contrôle autonome.

Les étapes typiques comprennent :

Mettre à jour votre procédure de gestion des incidents afin qu'elle fasse explicitement référence à l'identification, à la collecte et à la conservation des preuves.
créer une procédure de collecte de preuves dédiée qui explique les rôles, les déclencheurs et les étapes pour différents types d'incidents et profils de clients
Veillez à ce que votre évaluation des risques prenne en compte les risques liés aux preuves, tels que la journalisation incomplète ou les responsabilités floues vis-à-vis des fournisseurs de services cloud.
ajouter des contrôles et des activités de surveillance fondés sur des preuves à vos plans d'audit interne et de revue de direction

Une plateforme comme ISMS.online peut vous aider en centralisant ces politiques, en les associant aux contrôles de l'Annexe A, en attribuant les responsabilités et en suivant les améliorations. De nombreuses plateformes cloud et de conformité conformes à la norme ISO 27001 sont conçues pour centraliser les politiques, les correspondances de contrôles et les preuves de cette manière (par exemple, les présentations des fournisseurs de services cloud sur la norme ISO 27001 décrivent des schémas similaires).

Avec le temps, vous devriez être en mesure de sélectionner n'importe quel incident significatif de l'année écoulée et de démontrer comment l'exigence A.5.28 a été respectée : qui a identifié le besoin de preuves, quelles données ont été collectées, où elles sont stockées et comment leur intégrité est protégée. Vous pouvez également étendre cette approche à de nouveaux cadres, tels que la norme ISO 27701 relative à la protection de la vie privée ou les nouvelles recommandations en matière de gouvernance de l'IA, sans avoir à redéfinir votre logique de preuve à chaque fois.

Conception d'un modèle de centre de services et de billetterie adapté à l'analyse forensique

Un centre de services prêt pour l'analyse forensique permet à vos ingénieurs de traiter rapidement les incidents tout en créant des enregistrements conformes à la norme A.5.28 et à vos contrats. L'objectif est de transférer les efforts de la mémoire et des tâches manuelles vers des modèles, l'automatisation et des garde-fous au sein de votre plateforme PSA ou de gestion des services informatiques.

De manière générale, votre plateforme de billetterie doit prendre en charge trois éléments pour un travail nécessitant des données probantes :

déclenchement : documentation améliorée lorsqu'une affaire est sensible aux preuves
capture : l'information pertinente de manière constante, avec des valeurs par défaut utiles
protéger : le bilan face aux changements incontrôlés une fois que cela compte

Vous n'avez pas besoin de reconstruire votre outil PSA ou de gestion des services informatiques de A à Z. Une configuration bien pensée et quelques modifications ciblées des flux de travail peuvent faire une grande différence, surtout si vous les testez sur des incidents réels que vous avez gérés au cours de l'année écoulée.

Lorsque les enregistrements d'incidents sont façonnés par le système plutôt que par des habitudes individuelles, on se rapproche beaucoup plus de preuves reproductibles et prêtes pour un audit.

Déclenchement d'une gestion sensible aux preuves

Le déclenchement d'une procédure de traitement sensible aux preuves consiste à fournir aux techniciens de première ligne des règles simples et des repères visuels clairs afin qu'ils sachent quand un ticket de routine devient un cas susceptible d'être examiné des mois plus tard. Sans ces déclencheurs, les incidents importants sont documentés comme des incidents mineurs.

Tous les tickets ne nécessitent pas une analyse approfondie. La préparation aux enquêtes judiciaires repose sur une approche sélective et cohérente. Vous pouvez commencer par définir les types de tickets qui doivent être automatiquement traités comme des éléments de preuve importants. Il peut s'agir notamment des tickets suivants :

incidents de sécurité confirmés ou suspectés
événements de perte ou d'exposition de données
Pannes majeures affectant de nombreux utilisateurs ou des services critiques
les plaintes qui peuvent donner lieu à des litiges formels ou à des rapports réglementaires

Lorsqu'un tel ticket est créé ou reclassé, votre système peut :

appliquer un modèle spécifique avec des champs obligatoires supplémentaires
acheminer vers une file d'attente dédiée sous la supervision d'un responsable plus expérimenté.
Appliquer des règles plus strictes concernant les personnes autorisées à modifier les champs principaux
inviter le gestionnaire à joindre ou à lier des artefacts spécifiques, tels que des recherches dans les journaux ou des en-têtes d'e-mail.

En intégrant la sensibilité des preuves dans les paramètres du système, vous réduisez le risque que des cas importants soient traités comme de simples réinitialisations de mots de passe. Vous signalez également clairement aux responsables et aux garants de la sécurité qu'ils peuvent ainsi suivre et accompagner ces cas au fur et à mesure de leur évolution.

Si votre responsable de la sécurité ne peut pas facilement lister les tickets ouverts qui nécessitent des preuves aujourd'hui, vos déclencheurs et classifications sont probablement trop vagues.

Concevoir des flux de travail qui soutiennent les enquêtes, et pas seulement les SLA.

Les flux de travail facilitant les enquêtes permettent de conserver une trace claire et factuelle des actions et des décisions, tout en permettant aux ingénieurs de résoudre rapidement les problèmes. Ils simplifient la compréhension des événements (quand et pourquoi) sans avoir à parcourir des pages de notes non structurées.

Les processus traditionnels des services d'assistance visent à rétablir le service le plus rapidement possible. Cela reste important. Cependant, si la conservation des preuves est également essentielle, le processus doit faciliter les investigations ultérieures et démontrer que vous avez respecté vos obligations envers vos clients et les organismes de réglementation.

Voici quelques exemples de modèles utiles :

veiller à ce que chaque changement de statut et chaque affectation soient consignés avec un horodatage et l'identité de l'utilisateur.
nécessitant un bref résumé des actions clés lorsque certains statuts sont atteints, tels que « maîtrisé », « résolu » ou « transmis au service juridique ».
verrouiller ou limiter les modifications aux champs critiques une fois qu'un dossier a franchi une étape définie, tout en autorisant l'ajout de notes et de pièces jointes.
fournir des macros ou des modèles pour les enquêtes courantes (par exemple, « suspicion d’hameçonnage » ou « accès non autorisé ») qui guident les analystes à travers les étapes et les questions appropriées

Il est également important de réfléchir aux communications. Si les décisions et approbations clés sont prises par messagerie instantanée, téléphone ou autres canaux parallèles, le flux de travail doit prévoir un moyen simple de les résumer ou de les consigner dans le ticket pendant que les événements sont encore frais dans les esprits. Sinon, des informations cruciales risquent de manquer au moment où vous en aurez le plus besoin ou lorsque le service juridique du client demandera un compte rendu complet.

Dès lors que les flux de travail facilitent les enquêtes au lieu de les compliquer, les ingénieurs sont beaucoup plus susceptibles de créer les documents dont vous avez besoin sans les percevoir comme une contrainte.

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

Éléments à collecter : champs des tickets, journaux et pièces jointes comme preuves

Les rapports d'incidents exploitables reposent sur des informations cohérentes et structurées, compréhensibles même par ceux qui n'étaient pas présents lors de l'incident. En tant que responsable des opérations ou de la sécurité d'un fournisseur de services gérés (MSP), vous souhaitez que vos collaborateurs puissent reprendre les tickets plusieurs mois plus tard et en comprendre clairement le déroulement, grâce à des éléments de preuve référencés plutôt qu'à des fichiers épars.

L’objectif n’est pas de créer un formulaire long et fastidieux pour chaque ticket. Il s’agit de déterminer les informations non négociables dans certains cas et de simplifier au maximum leur saisie pour vos équipes grâce à des modèles, des valeurs par défaut et des invites.

Structuration des tickets d'incident à valeur élevée

Les rapports d'incidents critiques doivent répondre aux questions essentielles concernant les personnes impliquées, les circonstances et votre intervention, sans faire appel à la mémoire ou à des suppositions. Si un nouvel ingénieur ou un auditeur externe ne parvient pas à comprendre le déroulement des faits, votre système présente des lacunes.

Dans les cas d'incidents nécessitant des preuves, certaines questions doivent toujours pouvoir être résolues à partir du seul rapport d'incident. Au minimum, cela inclut généralement :

qui a signalé le problème et quand
quand le problème a-t-il été observé pour la première fois et par qui ?
Quel client et quels systèmes ou services ont été affectés ?
quel a été l'impact au moment de la détection
qui a entrepris quelles actions, dans quel ordre et avec quels outils
qui ont approuvé des décisions importantes, telles que la désactivation des commandes ou la notification des clients
quand l'incident a été maîtrisé et clos, et pourquoi vous pensiez qu'il était sans danger de le faire

Bon nombre de ces informations peuvent être consignées dans des champs structurés : déclarant, client concerné, systèmes impactés (liés aux éléments de configuration), type d’incident, gravité, horodatage, etc. D’autres peuvent être saisies dans des champs de texte courts et ciblés, tels que « résumé des actions d’investigation » ou « résumé des communications avec le client ».

La standardisation de ces éléments présente des avantages indéniables. Elle allège la charge de travail des utilisateurs en matière de documentation, offre aux réviseurs une structure de travail uniforme et facilite l'extraction de données pour les audits, les indicateurs et les axes d'amélioration. Elle simplifie également la formation : il est possible de montrer aux nouveaux ingénieurs les bonnes pratiques en analysant des exemples de tickets bien structurés.

Associer les tickets aux artefacts techniques

Associer les tickets aux documents techniques vous permet de toujours savoir où trouver les journaux, captures d'écran et instantanés de configuration qui étayent votre récit. Les tickets racontent l'histoire ; les documents apportent les preuves qui la sous-tendent.

Les tickets constituent la trame narrative de votre dossier d'incident, mais ne sont pas les seules preuves. Les journaux, les captures d'écran, les instantanés de configuration, les traces de messages et autres éléments fournissent les détails techniques qui étayent le récit et peuvent être nécessaires pour satisfaire les assureurs ou les organismes de réglementation.

Une approche pratique consiste à définir, pour chaque type d'incident, un ensemble minimal d'éléments à référencer ou à joindre. Par exemple, en cas de suspicion de compromission de compte, les éléments suivants pourraient toujours être inclus :

journaux d'authentification du compte concerné sur une période définie
journaux d'actions administratives indiquant les réinitialisations de mot de passe ou les modifications d'accès
Journaux de la passerelle de messagerie ou de la boîte aux lettres pour les messages suspects
alertes de point de terminaison ou de détection-réponse relatives à l'appareil utilisé

Plutôt que d'intégrer les données brutes au ticket, vous pouvez stocker des versions canoniques dans vos systèmes de journalisation ou de documentation et y faire référence clairement dans le rapport d'incident. Cela peut se faire via des identifiants, des chemins d'accès aux dossiers ou une brève description de leur emplacement et de leur nom.

Pour les fichiers joints directement aux tickets, des mesures simples comme la conservation des noms de fichiers originaux, la gestion des versions et la limitation des droits de suppression ou de remplacement contribuent à garantir l'intégrité des preuves. Dans les cas les plus critiques, la génération et le stockage de hachages ou de sommes de contrôle pour les fichiers clés constituent une solution proportionnée pour renforcer les preuves sans surdimensionner systématiquement chaque ticket.

Si votre responsable de la sécurité ne peut pas rapidement indiquer les journaux et les artefacts qui étayent un ticket d'incident majeur, le lien entre les preuves narratives et techniques doit être revu.

Conservation, préservation et chaîne de traçabilité des journaux pour les fournisseurs de services gérés

Pour les fournisseurs de services gérés (MSP), la conservation des journaux et des preuves doit trouver un équilibre entre l'utilité pour les enquêtes, les obligations de confidentialité et les coûts de stockage, compte tenu du grand nombre de clients et de juridictions. Il est impossible de tout conserver indéfiniment, mais il est également impossible d'expliquer un incident des mois plus tard si des enregistrements cruciaux ont été écrasés après seulement quelques jours.

Les journaux et autres enregistrements générés automatiquement constituent souvent l'essentiel des preuves numériques. Pour les fournisseurs de services gérés (FSG), ces enregistrements peuvent provenir de nombreux systèmes et juridictions différents. La norme A.5.28 exige que vous les traitiez de manière à faciliter les enquêtes tout en respectant les limites légales et contractuelles.

Une approche utile consiste à poser quatre questions :

De quels journaux et artefacts avez-vous réellement besoin pour vos enquêtes ?
Combien de temps devez-vous les conserver, et pourquoi ?
Comment les protégerez-vous contre toute modification ou perte non autorisée ?
Comment allez-vous documenter qui a manipulé des preuves à haut risque et à quel moment ?

Des réponses claires à ces questions transforment un vague « nous conservons des journaux » en une stratégie de conservation des journaux et de préservation des preuves solide et justifiable, pouvant être expliquée aux clients, aux auditeurs et aux organismes de réglementation. Des données de journalisation manquantes ou non justifiables en cas d'examen approfondi ne vous aident pas ; elles vous desservent.

Concevoir une conservation des journaux qui soutienne réellement les enquêtes

Des politiques de conservation des journaux efficaces reposent sur des scénarios d'incidents réels et les exigences réglementaires, et non sur les paramètres par défaut des outils ou sur une vague intuition. Si les journaux que vous supprimez la semaine prochaine pourraient vous être utiles dans trois mois, votre stratégie de conservation n'est pas adaptée à votre niveau de risque.

Les durées de conservation par défaut des outils peuvent ne pas être adaptées à votre profil de risque spécifique. Les recommandations en matière de journalisation et d'analyse de sécurité préconisent généralement d'aligner la durée de conservation sur vos besoins d'enquête et de conformité réglementaire plutôt que de se fier uniquement aux paramètres par défaut des fournisseurs ; les guides de bonnes pratiques en matière de journalisation insistent sur ce point.

Une approche plus réfléchie commence par l'analyse des scénarios d'incidents et des obligations. Par exemple :

Si vous devez enquêter sur une activité malveillante présumée plusieurs semaines après qu'elle se soit produite, vous aurez besoin d'une durée de conservation plus longue pour les journaux d'identité et d'accès.
Si des contrats ou des réglementations vous obligent à informer les autorités ou les clients des incidents, vous pourriez avoir besoin de journaux d'événements pour les reconstituer des mois plus tard.
Si les lois sur la protection de la vie privée limitent la durée de conservation de certaines données personnelles, vous pourriez devoir regrouper ou anonymiser certaines informations plus tôt.

En fonction de ces facteurs, vous pouvez définir des règles de conservation de base pour chaque catégorie de journaux, avec des exceptions justifiées le cas échéant. Ces règles doivent être reflétées dans votre documentation SMSI, la configuration de vos outils et vos communications avec les clients. Elles peuvent varier d'un client à l'autre et d'un pays à l'autre ; il est donc essentiel de conserver une trace claire des règles de conservation applicables et de leur application.

La centralisation des journaux, ou du moins la centralisation des informations sur l'emplacement des journaux de référence, est également essentielle. Lorsque les preuves sont dispersées entre pare-feu, serveurs, services cloud et terminaux sans structure d'organisation, il devient beaucoup plus difficile de répondre aux questions les plus élémentaires concernant les accès (qui a accédé à quoi et quand). Les recommandations relatives aux opérations de sécurité pour les plateformes SIEM et d'analyse préconisent l'utilisation de plateformes de journalisation centralisées ou de cartographies de journaux clairement documentées afin de réduire le temps d'investigation et le risque de perte de données cruciales, comme illustré dans les présentations des plateformes SIEM et d'analyse de sécurité.

Rendre la chaîne de traçabilité suffisamment simple à suivre

La chaîne de traçabilité retrace la manière dont les preuves ont été collectées, stockées, consultées et transférées au fil du temps. En criminalistique numérique formelle, cette chaîne peut être extrêmement détaillée. Pour les fournisseurs de services gérés (MSP), une version simplifiée suffit généralement, tout en étant capable de résister à un examen raisonnable en cas de litige ou d'audit.

L’essentiel est de se concentrer sur les éléments à fort enjeu : ceux susceptibles d’être utilisés dans le cadre de litiges, d’enquêtes réglementaires ou de procédures judiciaires. Pour ceux-ci, vous devez être en mesure de démontrer :

qui a décidé que les preuves devaient être recueillies
qui l'a effectivement collecté ou exporté, et quand
où il était initialement stocké et où il se trouve maintenant
qui y avaient accès tout au long du chemin

Vous n'avez pas besoin d'un système distinct pour cela. Il est courant d'enregistrer les informations de garde directement dans le ticket d'incident pour les exportations importantes et de veiller à ce que vos systèmes de stockage conservent des pistes d'audit de base concernant les accès et les modifications.

La principale qualité d'un registre de traçabilité est sa mise à jour systématique en cas de besoin. Si le processus est trop complexe, les ingénieurs risquent de le négliger sous la pression. Le meilleur moyen de garantir son application est de le simplifier au maximum, en précisant clairement ses conditions d'utilisation. Des analyses périodiques d'un petit échantillon d'incidents à haut risque permettront de vérifier rapidement l'efficacité de cette approche.

Si vos experts en sécurité ne peuvent pas expliquer qui a exporté des preuves clés concernant un incident récent très médiatisé et où elles se trouvent actuellement, votre approche actuelle en matière de chaîne de traçabilité est probablement trop informelle.

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

Preuves de gouvernance : politiques, rôles, formation et conformité juridique

La préparation aux enquêtes numériques n'est pas seulement un problème d'outils. C'est aussi un problème de gouvernance. En tant qu'équipe dirigeante d'un fournisseur de services gérés (MSP), vous donnez le ton quant à la gestion des preuves en définissant des politiques, des rôles et une supervision qui font des bonnes pratiques la norme plutôt qu'un effort exceptionnel en situation de crise.

La directive A.5.28 figure dans le cadre du contrôle organisationnel pour une raison bien précise : elle exige de la direction qu’elle assume la responsabilité du traitement des preuves. Cela implique d’harmoniser les aspects liés à la sécurité, aux questions juridiques, à la protection des données et aux opérations, et de ne pas laisser les décisions relatives aux preuves à la seule discrétion des ingénieurs sur le moment.

Élaboration d'un ensemble de politiques fondées sur des données probantes

Un fournisseur de services de santé qui privilégie une approche fondée sur des données probantes dispose d'un nombre restreint de politiques et de procédures qui se complètent plutôt que de s'opposer. Ces documents sont suffisamment concis pour être utilisés facilement, suffisamment clairs pour éviter les contradictions et suffisamment précis pour guider les équipes de première ligne.

Deux tiers des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont déclaré que la rapidité et l'ampleur des changements réglementaires rendent la conformité plus difficile à maintenir. Face à cette réalité, il est d'autant plus important que vos politiques de gestion des incidents, des preuves et de la protection des données soient harmonisées, afin que vos équipes, déjà très occupées, ne soient pas contraintes de chercher comment concilier des obligations contradictoires en cas de crise.

En général, vous aurez besoin d'au moins :

une politique et une procédure de gestion des incidents qui définissent comment les incidents sont identifiés, triés, traités et examinés
une procédure de collecte et de conservation des preuves qui explique comment la norme A.5.28 est appliquée dans différents scénarios
politiques de confidentialité et de conservation des données qui définissent les limites des données pouvant être collectées, la manière dont elles sont protégées et les conditions de leur suppression ou de leur anonymisation

Ces documents doivent se recouper. Par exemple, la procédure de gestion des incidents peut stipuler que certains types d'incidents déclenchent automatiquement la procédure de collecte de preuves. Cette dernière peut faire explicitement référence aux règles de confidentialité, aux contrats clients et aux critères d'escalade vers les responsables juridiques ou de la protection des données afin de limiter la collecte et la conservation des données personnelles.

Lorsque les politiques sont harmonisées, le personnel dispose de directives claires et cohérentes. Dans le cas contraire, les équipes sont contraintes d'improviser en situation de stress, moment où les erreurs et les oublis sont les plus fréquents. Une plateforme de gestion de la sécurité de l'information (GSSI) comme ISMS.online vous aide à maintenir cette harmonisation en centralisant les politiques, les contrôles, les incidents et les actions d'amélioration. De nombreuses plateformes cloud et de conformité conformes à la norme ISO 27001 sont conçues pour prendre en charge des modèles de centralisation et de cartographie similaires, tels que décrits dans les présentations de conformité à la norme ISO 27001 des fournisseurs.

Renforcement des compétences et supervision

Renforcer les compétences en matière de gestion des preuves et le contrôle implique de fournir aux ingénieurs des directives simples et pratiques sur les bonnes pratiques, puis de vérifier les incidents réels par rapport à cette norme. L'objectif est que la gestion des preuves soit perçue comme une pratique courante du génie des ingénieurs, et non comme une simple formalité de conformité.

Même les procédures les mieux conçues échoueront si elles ne sont pas comprises ou appliquées. La formation et le contrôle permettent de combler cette lacune. Il est essentiel que les ingénieurs et les gestionnaires considèrent la gestion des preuves comme une composante essentielle d'un service de qualité, et non comme une option.

Les analystes de première ligne et le personnel du service d'assistance n'ont pas besoin de devenir des experts en criminalistique numérique. Ils doivent toutefois savoir reconnaître quand un ticket de routine devient sensible en termes de preuves et connaître quelques règles claires à suivre et à ne pas suivre. Par exemple :

Veuillez rédiger des tickets factuels et axés sur les actions et les observations.
consigner les approbations et décisions clés dans le registre
Évitez toute spéculation et toute accusation dans le cadre de la procédure de preuve.
Ne modifiez ni ne supprimez les preuves une fois qu'elles ont été marquées comme telles sans suivre les étapes définies.

Une formation courte, basée sur des scénarios et intégrée au processus d'accueil et régulièrement mise à jour, est généralement plus efficace que de longues sessions théoriques. Vous pouvez utiliser des incidents réels (dont les détails sont anonymisés si nécessaire) pour illustrer ce qui constitue une preuve « acceptable » et une preuve « inadaptée ».

En matière de contrôle, il est possible d'intégrer la qualité des preuves aux structures existantes plutôt que d'en créer de nouvelles. Les comités de gestion des risques ou de sécurité peuvent examiner périodiquement un petit échantillon d'incidents importants, en veillant à l'exhaustivité et à la clarté des preuves. Les audits internes peuvent inclure des tests de conformité à la norme A.5.28, en utilisant des tickets et des journaux réels comme exemples et en assurant le suivi des résultats jusqu'à leur résolution.

Une plateforme de gestion de la sécurité de l'information (GSSI) centralisée, telle que ISMS.online, peut s'avérer utile en regroupant ces politiques, en enregistrant les formations du personnel clé et en assurant le suivi des actions découlant des audits. Elle offre des fonctionnalités similaires à celles d'autres plateformes de sécurité et de gestion des incidents, qui centralisent les politiques, les dossiers de formation et les actions correctives (par exemple, les plateformes de réponse aux incidents de sécurité). Ainsi, la gestion des preuves s'intègre à vos processus de gestion courants, et non plus à une activité ponctuelle et isolée. Il devient également plus aisé de démontrer aux clients, aux auditeurs et aux assureurs que vous gérez les preuves de manière systématique et non informelle.

Si votre équipe dirigeante n'a jamais examiné un dossier à haut risque en tenant compte de la « qualité des preuves », intégrer cet examen à votre processus de gouvernance est une prochaine étape simple et à fort impact.

Transformer A.5.28 en un atout reproductible avec ISMS.online

ISMS.online est conçu pour aider votre fournisseur de services gérés (MSP) à transformer le contrôle A.5.28 de la norme ISO 27001 en un atout durable en centralisant vos politiques, tickets et journaux dans un référentiel de preuves cohérent. En démontrant comment les incidents sont gérés, les preuves collectées et les améliorations suivies, vous renforcez votre conformité et vos relations commerciales. Cette approche s'inscrit dans la lignée des plateformes conformes à la norme ISO 27001 qui connectent les politiques, les contrôles et les documents relatifs aux incidents dans un système d'information unique, comme le préconisent les outils de gestion des incidents de sécurité et de conformité.

Presque toutes les organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont indiqué que l'obtention ou le maintien de certifications de sécurité telles que l'ISO 27001 ou le SOC 2 constituait une priorité absolue. Si vous pouvez établir un lien direct entre le point A.5.28 et votre méthode de documentation des incidents, vous serez bien mieux préparé(e) à maintenir ces certifications face à des situations d'examen concrètes.

Pour évaluer votre situation actuelle, une première étape utile consiste à analyser un incident récent et significatif et à comparer ses tickets, journaux et communications à une simple liste de contrôle A.5.28. Vous constaterez rapidement quels détails étaient faciles à trouver, lesquels ont nécessité des recherches approfondies et lesquels étaient totalement absents. Cet exercice permet de constater immédiatement, tant pour la direction que pour les ingénieurs, les avantages d'une approche plus structurée.

Évaluation de la maturité actuelle de vos preuves

L'évaluation de la maturité actuelle de vos dossiers de preuves commence par un examen honnête d'un incident réel à haut risque. Au lieu de deviner la qualité de vos dossiers, laissez un cas unique vous révéler la vérité.

Vous pouvez choisir un incident majeur de l'année dernière et vous poser quatre questions simples. Avez-vous pu consulter la chronologie complète, de la détection à la résolution ? Avez-vous pu retrouver les approbations et décisions clés ? Les journaux et les documents étaient-ils faciles à localiser et à comprendre ? Seriez-vous à l'aise de partager ce dossier avec l'équipe juridique d'un client ou un assureur ?

Si la réponse à l'une de ces questions est « pas vraiment », le problème est déjà évident. Cela ne signifie pas que votre équipe a mal performé ; cela signifie que votre système ne lui a pas fourni les éléments de preuve nécessaires au moment opportun.

ISMS.online peut vous aider à documenter ces constatations et à les relier directement au contrôle A.5.28, afin que les faiblesses deviennent des actions d'amélioration suivies plutôt que de vagues préoccupations que les gens oublient rapidement.

Planifiez vos premières améliorations A.5.28 avec ISMS.online

Planifier vos premières améliorations selon la norme A.5.28 est plus simple lorsque vous pouvez consulter les politiques, les contrôles et les incidents réels au même endroit. ISMS.online vous offre cette vue d'ensemble et la transforme en un plan d'amélioration concret plutôt qu'en une simple liste de souhaits théoriques.

Sur ISMS.online, vous pouvez :

Maintenez vos procédures de gestion des incidents et de collecte de preuves de manière contrôlée et vérifiable.
relier directement ces procédures aux contrôles de l'annexe A, notamment au point A.5.28 et aux contrôles de gestion des incidents connexes
consigner les incidents réels, les améliorations et les conclusions des audits internes par rapport à ces contrôles
Attribuer des actions et suivre les progrès réalisés pour combler les lacunes en matière de preuves entre les équipes et les clients

Conçu pour compléter, et non remplacer, vos outils PSA, RMM et de sécurité, ISMS.online assure la liaison entre vos enregistrements opérationnels et un système de preuves cohérent. Vos tickets, journaux et documents restent à leur place ; la plateforme vous aide à démontrer leur interdépendance et leur gouvernance, ce qui répond précisément aux attentes des auditeurs, des clients et des assureurs.

Dans de nombreux cas, une mise en œuvre ciblée sur quelques mois suffit à établir un niveau de préparation aux enquêtes numériques pour vos clients et types d'incidents les plus importants. Les programmes de préparation aux enquêtes numériques décrits dans les guides de conseil indépendants sont souvent structurés comme des projets à durée déterminée plutôt que comme des initiatives sans fin, un modèle utile à suivre.

Cette démarche de base comprend généralement l'harmonisation des politiques, la validation des modèles, la mise en place de procédures de traçabilité et la réalisation de contrôles réguliers. Une fois ces fondements établis, l'extension de cette approche à l'ensemble de votre clientèle devient beaucoup plus simple et moins perturbatrice.

Si vous souhaitez passer de l'espoir que vos enregistrements soient suffisants à la certitude de pouvoir prouver ce qui s'est passé, choisir ISMS.online comme partenaire pour votre certification ISO 27001 est une démarche concrète. Vous renforcez ainsi votre capacité à protéger votre entreprise, vos clients et vos équipes lors des analyses d'incidents les plus approfondies, et vous transformez l'article A.5.28 en une source de confiance plutôt qu'en une source d'inquiétude.

Demander demo

Foire aux questions

Qu’est-ce que la norme ISO 27001:2022 A.5.28 « Collecte de preuves » change concrètement pour un MSP ?

A.5.28 signifie que votre fournisseur de services gérés doit être capable de Il faut prouver ce qui s'est passé lors d'incidents graves, et non pas se contenter de s'en souvenir plus tard..

Concrètement, cela change votre quotidien dans quatre domaines :

À quel moment la gestion normale des incidents devient-elle « sensible aux preuves » ?

Il est nécessaire d'établir une distinction claire et partagée entre les demandes d'assistance courantes et les cas exigeant une réponse étayée par des preuves. Voici quelques exemples de déclencheurs :

Suspicion de fuite ou d'exfiltration de données pour tout client géré.
Compromission de la messagerie professionnelle ou prise de contrôle de compte.
Panne majeure ayant un impact contractuel ou financier.
Tentatives de fraude, abus d'accès privilégié ou utilisation abusive par un initié.
Tout incident susceptible d'intéresser les organismes de réglementation, les assureurs ou les avocats.

Une fois le déclencheur activé, l'incident est traité différemment : journalisation plus stricte, contrôle d'accès renforcé et gestion plus réfléchie des artefacts.

Qui est responsable des décisions relatives aux preuves dans votre MSP ?

A.5.28 suppose que vous savez Qui peut déclarer un incident sensible sur le plan des preuves et qui peut ensuite intervenir sur le terrain ?Cela signifie généralement :

Un rôle de responsabilité désigné (par exemple, responsable de service, responsable de sécurité d'astreinte) habilité à faire basculer un incident en mode sensible aux preuves.
Responsabilités clairement définies pour :
Déterminer quels artefacts doivent être collectés.
Approbation des actions destructives (reconstructions, effacement, réinitialisations de locataires).
Signature du document une fois le traitement des preuves relatif à cet incident terminé.

Ces rôles doivent être clairement définis dans votre système de gestion de la sécurité de l'information (SGSI), les descriptions de poste et les procédures de gestion des incidents – et non pas simplement « compris » par l'équipe.

Que signifie « suffisamment bon pour servir de preuve » dans la réalité de MSP ?

Vous ne mettez pas en place un laboratoire de police. Vous visez à obtenir des rapports d'incidents fiables pour une partie extérieure, car :

Le récit est cohérent : ce qui s'est passé, quand, à qui et sur quels systèmes, est clair.
Les décisions et approbations clés sont consignées dans les archives, et non pas noyées dans les conversations.
Les artefacts (journaux, exportations, captures d'écran) peuvent être localisés et reliés à l'incident.
Vous pouvez démontrer que les exportations sensibles n'ont pas été modifiées discrètement.

Cela ressemble généralement à ceci :

Indicateurs sensibles aux preuves dans votre PSA/ITSM.
Nombre minimal de preuves par scénario (par exemple, BEC, panne, activité administrative suspecte).
Sites d'exportation contrôlés avec accès restreint et mesures d'intégrité de base.

Comment une plateforme ISMS modifie-t-elle votre étage A.5.28 ?

Si vous tentez de gérer la norme A.5.28 uniquement au sein de votre organisme de sécurité et auprès de vos collaborateurs, elle se révèle rapidement inefficace face à un examen approfondi. Une plateforme de gestion de la sécurité de l'information (SGSI) comme ISMS.online vous permet de :

Documentez votre politique et procédure A.5.28 une seule fois, en langage clair.
Intégrez-le directement à la gestion des incidents, à la journalisation et aux contrôles de continuité.
Joindre des incidents réels comme preuves du fonctionnement au fil du temps.
Suivre les améliorations lorsque des lacunes sont constatées lors des évaluations.

Cela transforme le point A.5.28 de « nous pensons gérer les preuves de manière judicieuse » en « nous pouvons vous montrer comment nous décidons, collectons, protégeons et améliorons » – une conversation très différente avec les auditeurs, les clients et les assureurs.

Comment un fournisseur de services gérés peut-il rendre son service d'assistance « prêt pour l'analyse forensique » sans ralentir les ingénieurs ?

Votre service d'assistance est prêt pour l'analyse forensique lorsque Les tickets à haut risque sont automatiquement transformés en récits d'incidents structurés., tandis que le travail quotidien reste perçu comme léger et rapide par les ingénieurs.

L'objectif n'est pas de surcharger le traitement de chaque ticket. Il s'agit d'adopter des comportements plus judicieux uniquement lorsque les enjeux sont importants.

Comment les tickets doivent-ils se comporter une fois qu'une affaire est sensible aux preuves ?

Trois petites modifications de conception suffisent généralement : classification, structure et protection.

Classification – mode bascule avec un signal clair

Créez un petit ensemble de catégories ou d'indicateurs qui traitent automatiquement un ticket comme étant sensible aux preuves, tels que :

Incident de sécurité ou suspicion de violation.
Exposition de données ou événement portant atteinte à la vie privée.
Panne majeure affectant les SLA ou plusieurs clients.
Des plaintes susceptibles de donner lieu à des poursuites judiciaires ou réglementaires.

Une fois ces options sélectionnées, le système peut :

Exiger des champs et des pièces jointes supplémentaires.
Limiter les modifications aux champs principaux.
Déclencher des notifications pour les rôles de responsabilité.

Structure – transformer les notes en un récit d'incident exploitable

Pour les billets signalés, veuillez fournir :

Champs principaux obligatoires (client, systèmes impactés, gravité, délai de détection, responsable, type d'incident).
Un dédié calendrier section:
Heure (avec fuseau horaire).
Mesures prises.
Outil ou système utilisé.
Identifiants de référence (numéros d'alerte, de modification, d'exportation ou de dossier).
Pièces jointes ou liens vers les artefacts requis par scénario avant la clôture (par exemple, les journaux de connexion pour BEC ; les enregistrements de modifications et les graphiques de surveillance pour les pannes).

Cela fait du ticket la « première page » du récit de l'incident, avec des liens vers des données volumineuses au lieu d'essayer de tout condenser dans un seul enregistrement.

Protection – empêcher que l’histoire ne soit réécrite en catimini

Vous ne souhaitez pas que les horodatages et les approbations clés soient modifiés plusieurs jours plus tard. Une approche équilibrée consiste à :

Verrouillage ou versionnage des champs critiques après une période définie ou une fois l'approbation enregistrée.
Autoriser l'ajout libre de nouveaux commentaires et fichiers.
Consigner qui a autorisé toute correction des informations essentielles.

Le test d'utilisabilité est simple : une personne n'ayant pas participé à l'affaire pourrait-elle rouvrir le ticket six mois plus tard et comprendre ce qui s'est passé et qui a décidé de quoi en moins de dix minutes ?

Quel est le lien avec le point A.5.28 et votre SMSI ?

Le point A.5.28 ne concerne pas vraiment votre outil ; il concerne votre conception intentionnelle:

Votre système de gestion de la sécurité de l'information (SGSI) définit la politique relative aux changements de mode des tickets, aux modifications apportées par ce mode et aux rôles impliqués.
Votre service d'assistance exécute ces règles discrètement en arrière-plan.
Les analyses effectuées dans votre système de gestion de la sécurité de l'information (SMSI) permettent d'examiner de vrais tickets, de consigner les résultats et de piloter les modifications de modèles ou la mise en place de formations complémentaires.

ISMS.online est conçu précisément pour ce cycle : conception → exploitation → évaluation → amélioration. Si vous tentez de répondre à la question A.5.28 uniquement avec des captures d’écran et des descriptions du type « nous faisons généralement X », vous serez constamment en difficulté. Quelques jours de configuration de votre système de gestion de la sécurité des processus (PSA) et de mise en place de la gouvernance dans ISMS.online vous permettront de démontrer aux auditeurs que ce comportement est délibéré, reproductible et contrôlé.

Quels détails et artefacts liés à l'incident rendent réellement les preuves fournies par le MSP fiables ?

Les preuves sont fiables lorsqu'elles répond aux questions évidentes sans que vous ayez besoin d'être dans la pièce:

Que s'est-il passé et comment cela a-t-il été détecté ?
Quels clients et systèmes étaient concernés ?
Qui a fait quoi, avec quels outils, et qui l'a autorisé ?
Qu’est-ce qui a changé, et quand ?

Le simple déversement des journaux bruts ne suffit généralement pas. Une structuration minimale et un volume minimal de données cohérent par scénario sont généralement suffisants.

Que doit contenir au minimum tout rapport d'incident à fort impact ?

Pour les incidents impliquant des questions financières, des contrats ou la protection des données, votre modèle par défaut doit couvrir trois niveaux.

1. Champs de billetterie structurés

Définissez ces options comme obligatoires une fois qu'un billet est signalé comme présentant un risque plus élevé :

Délai de déclaration et de détection.
Client, contact principal et tous les identifiants contractuels (par exemple, ID du contrat, niveau SLA).
Systèmes ou services impactés (idéalement sélectionnés dans votre CMDB ou catalogue de services).
Niveau de gravité et résumé de l'impact en une phrase.
Type d’incident (par exemple BEC, ransomware, panne multi-locataire P1).
Responsable désigné et contact en cas d'escalade.

Cela permet de maintenir l'alignement de tous les cas sérieux avec le même modèle mental.

2. Chronologie des actions

Passez d'un champ de notes défilant unique à un journal simple et structuré :

Heure et fuseau horaire.
Mesures prises.
Outil ou système utilisé.
ID de référence (ID d'alerte, ticket de modification, référence d'exportation).

Cette chronologie devient souvent la base des briefings ultérieurs destinés aux clients, des demandes d'indemnisation des assureurs ou des rapports des organismes de réglementation.

3. Pointeurs d'artefacts

Plutôt que de surcharger les tickets, indiquez où se trouvent les données volumineuses :

Journaux d'identité et d'accès de votre annuaire, SSO ou VPN.
Alertes de point de terminaison et de serveur (EDR/AV/HIDS).
Passerelle de messagerie ou journaux de messagerie SaaS pour les cas d'hameçonnage et de fraude au président.
Capture des pare-feu et du réseau pour détecter les pannes ou les déplacements latéraux.
Instantanés de configuration et historiques de modifications avant/après les interventions clés.
Copies expurgées de charges utiles malveillantes ou de courriels suspects.
Captures d'écran pour les cas où les exportations ne sont pas disponibles.

Un court modèle comme « Journaux EDR pour l'hôte X, 09:00–12:00 2024‑07‑03, stockés dans Vault V‑0123 ; somme de contrôle XYZ » transforme une note vague en quelque chose auquel un tiers peut faire confiance.

Pour quelques scénarios à haut risque, convenir d'un dossier de preuves minimales (généralement pas plus de 8 à 12 éléments) et intégrez cela à vos processus de gestion des demandes d'assistance. Cela évite que les tickets importants ne se transforment en vagues transcriptions de chat et facilite grandement la justification de votre travail, même des mois plus tard.

Comment pouvez-vous le prouver aux auditeurs et aux clients ?

Écrire le modèle ne représente que la moitié du travail. A.5.28 exige que vous en démontriez le fonctionnement. Avec ISMS.online, vous pouvez :

Associer les dossiers de preuves minimales à A.5.28 et aux contrôles connexes de l'annexe A.
Joignez des exemples d'incidents qui correspondent (et qui ne correspondent pas) au modèle.
Suivez les actions d'amélioration lorsque vous repérez des lacunes récurrentes.

Au lieu de dire « nous avons pour objectif de collecter les journaux », vous pouvez présenter votre système de gestion de la sécurité de l'information (SGSI), décrire le processus et fournir des exemples concrets. C'est ce qui distingue une politique d'une explication crédible : les clients le remarquent lorsqu'ils choisissent un fournisseur de services gérés (MSP) auquel confier leurs systèmes les plus sensibles.

Comment les fournisseurs de services gérés (MSP) doivent-ils gérer la conservation des journaux et la chaîne de traçabilité pour que les preuves restent valables ultérieurement ?

La conservation des registres et la chaîne de traçabilité concernent pouvoir remonter suffisamment loin dans le temps et pouvoir prouver que vous n'avez pas falsifié les faits en catimini.

Si vous traitez les journaux comme jetables ou les exportations comme des fichiers occasionnels, A.5.28 sera difficile à prouver et difficile à croire.

Comment décider ce qu'il faut conserver et comment le protéger ?

Une approche pratique pour les MSP consiste à penser en trois étapes.

1. Regroupez les journaux en fonction de leur utilisation.

Par exemple :

Identité et accès : annuaire, SSO, VPN, passerelles d’accès privilégié.
Sécurité des points finaux et des serveurs : EDR, AV, HIDS.
Messagerie électronique et collaboration : passerelles de messagerie sécurisées, plateformes de messagerie SaaS, outils de chat.
Réseau et périmètre : pare-feu, proxys, concentrateurs VPN.
Activités administratives et de gestion des changements : journaux d’administration du cloud, pipelines CI/CD, outils d’infrastructure en tant que code.

Chaque groupe privilégie des questions légèrement différentes lors des enquêtes et des audits.

2. Établir des seuils de rétention de référence par groupe

Équilibrer trois contraintes :

Besoin opérationnel : jusqu'à quelle période remontent habituellement vos investigations (par exemple, les temps de séjour, les schémas de fraude).
Engagements envers les clients : Ce que vos contrats et SLA prévoient concernant le soutien aux enquêtes.
Règles réglementaires en matière de protection de la vie privée : où vous devez minimiser la conservation des données personnelles (par exemple, RGPD, CCPA).

Pour de nombreux environnements MSP sensibles à la sécurité, 6 – 12 mois Pour la gestion des journaux d'identité, de messagerie, de terminaux et d'administration, un délai de 10 minutes est un bon point de départ, même si certains cas particuliers peuvent nécessiter un délai plus long. Quel que soit votre choix, formalisez-le dans une politique de sécurité et configurez votre SIEM, votre système de stockage des journaux et vos sauvegardes pour l'appliquer, plutôt que de vous fier à la mémoire vive.

3. Ajouter des contrôles d'intégrité et d'accès simples

Vous n’avez pas besoin d’une solution WORM de niveau entreprise pour l’ensemble de votre système dès le premier jour, mais vous devriez :

Limiter les personnes autorisées à consulter et à exporter les journaux sensibles.
Privilégiez le stockage en mode ajout uniquement ou en écriture unique pour les archives à long terme.
Utilisez des sommes de contrôle ou des signatures pour les exportations et les archives en masse.
Consignez qui a exporté des lots importants, quand, d'où et où ils sont actuellement stockés.

Une brève annotation comme « M. Patel a exporté les journaux d'identité du locataire ACME du 15/06/2024 à 00:00–23:59, stockés dans le compartiment S3 « evidence-2024-06-ACME » ; accès : responsables SOC uniquement » peut suffire à montrer à un examinateur que vous prenez la chaîne de traçabilité au sérieux.

Où se situe un SMSI dans tout cela ?

Des notes éparses et des choix de conservation non documentés sont difficiles à justifier. Une plateforme de gestion de la sécurité de l'information (GSSI) comme ISMS.online vous permet de :

Documentez une seule fois vos familles de journaux, vos lignes de base de rétention et vos exceptions.
Reliez-les à la norme ISO 27001:2022 A.5.28, aux contrôles de journalisation associés de l'annexe A et à tous les cadres de l'annexe L que vous utilisez (par exemple, la norme ISO 22301 pour la continuité).
Joignez des exemples concrets d'exportation et des notes de révision comme preuves.
Suivez les modifications apportées aux règles de rétention ou aux outils afin de pouvoir expliquer l'historique.

Ainsi, si un client, un auditeur ou un organisme de réglementation vous demande pourquoi vous conservez (ou ne conservez plus) certains journaux, vous pourrez répondre par une réponse claire et conforme aux politiques en vigueur, au lieu d'un haussement d'épaules gêné.

Comment les équipes de fournisseurs de services gérés peuvent-elles développer des habitudes de « préparation aux preuves » sans transformer tout le monde en spécialistes en criminalistique numérique ?

Vous n'avez pas besoin que chaque ingénieur comprenne la jurisprudence. Vous avez besoin qu'ils… Laisser des tickets et des références qu'ils seraient heureux de défendre sous pression..

Si vous abordez la question sous l'angle de la culpabilisation ou du jargon réglementaire, l'engagement sera faible. En revanche, si vous insistez sur la nécessité d'éviter des problèmes futurs pour eux et pour les clients, la situation devient beaucoup plus simple.

À quoi ressemble une formation pratique et adaptée aux ingénieurs en matière de preuves ?

Les séances courtes et ciblées, axées sur vos propres incidents, sont les plus efficaces :

Montrez la douleur. Décrivez un incident anonymisé où une mauvaise documentation vous a nui : impact flou, échéancier confus, approbations manquantes. Demandez à l’équipe ce qui a rendu la situation difficile à gérer ou à expliquer.
Montrez le contraste. Comparez-le à un incident mieux documenté. Lequel préféreraient-ils présenter à un client, un assureur ou un organisme de réglementation sceptique ?
Adoptez un petit ensemble d'habitudes. Par exemple :
Notez toujours ce que vous avez fait, quand et avec quel outil, en utilisant des repères temporels clairs.
Consignez les décisions clés des clients et les approbations internes dans le ticket, et pas seulement dans le chat.
Les commentaires doivent rester factuels ; évitez les reproches ou les spéculations dans les documents permanents.
Utilisez l’indicateur ou la catégorie sensible aux preuves lorsque cela déclenche une réaction.

Vous pouvez renforcer cela en intégrant des micro-invites dans vos formulaires de messages d'intérêt public :

À côté du champ chronologique : « Rédigez ceci de manière à ce qu’un collègue puisse le comprendre dans six mois. »
À côté des pièces jointes : « Lien vers l’emplacement des journaux ; évitez de coller de longs extraits. »

Appuyez cela avec retour d'information léger et régulier:

Chaque mois, prélever un petit nombre de billets à risque élevé.
Évaluez-les par rapport à vos habitudes convenues et aux dossiers de preuves minimales requis.
Partagez des retours ciblés et mettez en avant les bons exemples lors des réunions d'équipe.

Comment prouver que ces habitudes sont réelles et non de simples illusions ?

Le point A.5.28 ne se contente pas de dire « nous organisons une formation annuelle ». Il vous sera demandé comment vous savez qu'elle est efficace. ISMS.online vous aide à répondre à cette question :

Stockage de la procédure A.5.28, des artefacts de formation et des registres de présence.
Intégrez les résultats récurrents de l'échantillonnage des tickets dans vos contrôles de gestion des incidents et de la journalisation.
Suivi des actions assignées (modifications des modèles, améliorations des déclencheurs ou de la conservation des journaux, formation supplémentaire) jusqu'à leur clôture.

Cela vous permet de suivre en temps réel l'évolution de la préparation des preuves en fonction des incidents et des examens réels. Lorsqu'on vous demande « comment vous assurez-vous que le personnel gère correctement les preuves ? », vous pouvez mettre en avant des pratiques concrètes, et non de simples promesses ; c'est précisément ce que recherchent les clients et les auditeurs exigeants.

Quels sont les aspects qu'un fournisseur de services gérés peut raisonnablement améliorer concernant la version A.5.28 et la préparation aux enquêtes numériques au cours des 90 prochains jours ?

En 90 jours, vous pouvez passer de « Nous espérons que nos disques sont suffisamment bons. » à « Nous avons constaté une tendance claire, documentée dans notre système de gestion de la sécurité de l'information (SGSI), et des incidents récents qui le démontrent. ».

Vous n'avez pas besoin d'une couverture parfaite ; vous avez besoin d'un petit nombre d'améliorations visibles et reproductibles, étayées par des exemples concrets.

À quoi ressemble un cycle d'amélioration A.5.28 ciblé de 90 jours ?

Une feuille de route réaliste pourrait ressembler à ceci :

Semaines 1 et 2 : Tirer les leçons d’un incident grave du passé

Choisissez un cas important – un incident de sécurité ou une panne ayant touché les principaux décideurs.
Examinez le ticket, les journaux et les échanges de courriels comme si vous étiez un examinateur externe.
Note:
Combien de temps faut-il pour comprendre ce qui s'est passé ?
Lorsque le récit est imprécis ou incomplet.
Quels artefacts étaient manquants ou difficiles à trouver ?
Consignez cela dans une brève note post-incident et enregistrez-le dans la section A.5.28 de votre SMSI.

Sélectionnez 2 à 3 scénarios qui inquiètent régulièrement vos clients :
Compromission de la messagerie professionnelle ou prise de contrôle de compte.
Activité suspecte nécessitant des privilèges élevés sur les plateformes cloud.
Panne majeure affectant plusieurs locataires.
Pour chacun, définissez :
Champs obligatoires sur le billet.
Artefacts requis (journaux, exportations, instantanés) et leur emplacement de stockage.
Mettez à jour les modèles et les flux de travail des annonces de services publics afin que les champs et les pièces jointes appropriés deviennent obligatoires lorsque les catégories ou les indicateurs pertinents sont sélectionnés.

Semaines 4 à 6 : Documenter une procédure concise pour A.5.28

Rédigez une procédure allégée qui explique :
Lorsqu'un incident devient sensible aux preuves.
Quels rôles définissent cela et qui en est responsable ?
Que faut-il collecter, où le stocker et pendant combien de temps le conserver ?
Comment les exportations importantes sont suivies pour garantir la chaîne de traçabilité.
Faites correspondre directement cela à la norme ISO 27001:2022 A.5.28, ainsi qu'aux contrôles connexes de l'annexe A pour la réponse aux incidents, la journalisation et, le cas échéant, la continuité des activités.

Semaines 6 à 8 : Former les personnes qui l’utiliseront réellement

Organisez une courte session à destination des ingénieurs, des responsables d'astreinte et des responsables du service d'assistance, en utilisant :
L'incident examiné (pour illustrer les conséquences néfastes des dossiers incomplets).
Modèles de tickets mis à jour (pour indiquer les changements).
Dossiers de preuves minimales (pour clarifier les attentes).
Mettez l'accent sur les changements concrets que cela peut engendrer pour eux et sur la manière dont cela les protège lors de futures discussions avec des clients ou des assureurs.

Semaines 8 à 12 : Présenter de nouveaux incidents et montrer les progrès réalisés

Quelques semaines après le déploiement, examinez quelques incidents susceptibles d'avoir déclenché les nouveaux schémas.
Vérifier:
Vérifier si les déclencheurs et les indicateurs appropriés ont été utilisés.
Si les éléments de preuve minimaux ont été recueillis.
Avec quelle rapidité une personne extérieure au dossier peut-elle le comprendre ?
Consignez les résultats et utilisez-les pour :
Ajuster les modèles et les astuces.
Cibler toute formation de suivi.
Mettez à jour votre procédure A.5.28 si nécessaire.

ISMS.online peut ancrer chaque étape de ce cycle :

La procédure A.5.28, l'examen initial de l'incident, les dossiers de preuves définis, le matériel de formation et les résultats d'échantillonnage se trouvent tous dans un seul environnement.
Les actions d'amélioration permettent d'obtenir des responsables, des échéances et une preuve d'achèvement.
Les liens vers les contrôles de l'annexe A et d'autres normes (telles que A.5.24–A.5.27 pour la gestion des incidents, les contrôles de journalisation A.8.x, ISO 22301 pour la continuité dans un IMS de type annexe L) montrent comment la gestion des preuves s'intègre dans votre système global.

Ainsi, lorsqu'un prospect, un auditeur ou un assureur vous demande : « Comment collectez-vous et protégez-vous les preuves ? », vous pouvez lui présenter un scénario clair sur 90 jours, où politiques, outils et incidents réels se rejoignent. Ce type de réponse concrète renforce votre conformité à la norme ISO 27001, rassure vos clients les plus importants et distingue discrètement votre fournisseur de services gérés (MSP) de ses concurrents qui s'appuient encore sur des notes d'incidents improvisées et de bonnes intentions.

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.28 Collecte de preuves – Préparation médico-légale et preuves liées aux contraventions de la MSP