Pourquoi les sauvegardes des fournisseurs de services gérés sont-elles soudainement soumises à une telle pression ?
Les fournisseurs de services gérés subissent une pression accrue car clients, organismes de réglementation et attaquants considèrent désormais les sauvegardes des journaux et des configurations comme une preuve essentielle de fiabilité. Il leur est demandé de prouver que ces ensembles de données sont protégés, restaurables et fiables en cas de problème, et non plus seulement que les serveurs sont remis en ligne.
Les histoires de sauvegarde réussies sont avant tout des histoires de confiance, et non de stockage.
Cet article fournit des informations générales sur la gouvernance des sauvegardes pour les fournisseurs de services gérés. Il ne constitue pas un avis juridique, réglementaire ou d'assurance ; vous devriez consulter un spécialiste avant de prendre des décisions importantes.
Ces dernières années, plusieurs incidents chez des fournisseurs de services ont révélé un même schéma. Un client subit une panne ou une compromission de système ; le fournisseur de services gérés (MSP) rétablit les serveurs critiques assez rapidement, mais les journaux et les données de configuration nécessaires pour comprendre, prouver et résoudre intégralement l’incident n’ont soit jamais été sauvegardés, soit se trouvaient sur le même support de stockage que celui qui a défailli. Des études de cas indépendantes sur des incidents chez des MSP mettent régulièrement en évidence ce schéma, montrant comment l’absence ou la destruction de journaux et de configurations transforme des pannes récupérables en crises de confiance persistantes. Un problème technique devient alors un problème de confiance. Les conseils d’administration et les responsables de la sécurité de vos clients demandent désormais explicitement : « En cas de problème, pouvez-vous nous montrer ce qui s’est passé et nous permettre de retrouver un état de fonctionnement optimal ? »
Les attentes ont augmenté en conséquence. Les clients présument souvent que chaque information importante que vous manipulez (journaux de sécurité, pistes d'audit SaaS, règles de pare-feu, configurations d'identité et infrastructure en tant que code) est sauvegardée, conservée et testée. À l'inverse, de nombreux fournisseurs de services gérés (MSP) considèrent encore les journaux et les configurations comme « éphémères » ou « reconstituables », concentrant leurs stratégies de sauvegarde officielles sur les serveurs de fichiers et les bases de données. Les enquêtes sectorielles sur les pratiques de sauvegarde des MSP et les attentes des clients, telles que les études sur les attentes en matière de sauvegarde pour les MSP, révèlent un écart constant entre ce que les clients croient être protégé et ce que les fournisseurs sauvegardent réellement. C'est cet écart qui est à l'origine des constats d'audit, des discussions tendues lors des revues trimestrielles d'activité (QBR) et des contrats perdus.
Les attaquants ont également appris à cibler directement les plateformes de sauvegarde et les journaux d'activité. Les équipes de ransomware tentent de désactiver ou de corrompre les tâches de sauvegarde, d'effacer les instantanés et de falsifier les journaux de sécurité. Les rapports de menaces concernant l'utilisation abusive des plateformes de sauvegarde, notamment les analyses portant sur les ransomwares ciblant les systèmes de sauvegarde, décrivent comment les attaquants se connectent aux consoles, suppriment les tâches de conservation et corrompent les archives avant de déclencher le chiffrement. Un statut « tout au vert » dans une console de sauvegarde est peu utile s'il peut être falsifié ou si les sauvegardes des journaux et de la configuration se trouvent dans la même zone d'impact (c'est-à-dire le périmètre des systèmes touchés par une panne ou une attaque) que l'environnement de production. Les clients et les auditeurs ont commencé à regarder au-delà des étiquettes des fournisseurs et exigent des preuves que les sauvegardes sont conçues et exploitées en tenant compte de ces menaces.
Les organismes de réglementation et les assureurs exercent une pression accrue. De nombreuses réglementations sectorielles et procédures de déclaration des incidents partent désormais du principe que les organisations peuvent reconstituer une période d'événements à partir des journaux et restaurer les services en utilisant les configurations sauvegardées. Les directives réglementaires relatives à la conservation des journaux et à la gestion des incidents, notamment les exigences en matière de réponse aux incidents concernant les données de journalisation, considèrent de plus en plus la capacité à rejouer les événements à partir des journaux et à reconstruire à partir des configurations sauvegardées comme une condition préalable essentielle. Lorsque vos clients externalisent leurs opérations auprès de vous, ils comptent sur votre capacité de sauvegarde pour respecter ces obligations. Leurs registres de risques internes mentionnent de plus en plus les sauvegardes tierces comme un poste de dépense, et les évaluations des risques liés aux fournisseurs examinent en détail la manière dont vous gérez les journaux, les configurations et les tests de restauration.
Dans l'enquête 2025 d'ISMS.online, environ 41 % des organisations ont cité la gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs comme l'un de leurs principaux défis en matière de sécurité.
Tout cela signifie que la sauvegarde n'est plus un domaine technique confidentiel. Elle fait désormais partie intégrante de la manière dont les clients évaluent votre fiabilité, dont les auditeurs évaluent la maturité de vos contrôles et dont votre conseil d'administration évalue votre exposition aux risques. Le contrôle A.8.13 de la norme ISO 27001:2022 – « Sauvegarde des informations » – est devenu l'un des principaux outils d'évaluation. Les commentaires relatifs à A.8.13 destinés aux prestataires de services, notamment les interprétations spécifiques à ce secteur, indiquent clairement que les clients, les auditeurs et les assureurs utilisent désormais ce contrôle pour évaluer la qualité de la préservation des informations nécessaires à la récupération et aux investigations par les fournisseurs de services gérés (MSP). Dans les sections suivantes, vous découvrirez les exigences concrètes de ce contrôle pour un MSP et comment les traduire en une norme de sauvegarde claire et défendable pour les journaux, les configurations et les systèmes opérationnels de vos clients.
Comment les sauvegardes sont-elles passées d'une simple tâche administrative à un enjeu stratégique pour les fournisseurs de services gérés ?
Les sauvegardes, autrefois considérées comme une simple tâche administrative, sont devenues un enjeu stratégique pour les fournisseurs de services gérés (MSP). En effet, la complexité croissante des infrastructures, les incidents publics et les exigences accrues des clients ont mis en évidence la dépendance des opérations de récupération et d'investigation à bien plus que de simples serveurs de fichiers. Ce qui était auparavant une tâche nocturne et discrète est désormais une discipline multiplateforme ayant un impact commercial direct.
Les sauvegardes étaient autrefois une tâche opérationnelle simple : exécution de tâches nocturnes, rotation des supports, envoi de copies hors site et, occasionnellement, test de restauration. Le périmètre était généralement clair – serveurs de fichiers, bases de données applicatives, éventuellement quelques machines virtuelles – et les clients posaient rarement de questions détaillées. L’environnement était plus simple, et les attentes l’étaient tout autant.
Aujourd'hui, votre infrastructure comprend probablement des équipements sur site, plusieurs clouds publics, des plateformes SaaS, des systèmes d'identité modernes, des outils de sécurité et une longue liste de périphériques de périphérie. Les journaux et les données de configuration sont répartis à de nombreux endroits : index SIEM, pare-feu et VPN, portails d'administration, systèmes de gestion de la configuration et référentiels de code. Nombre de ces systèmes sont désormais critiques pour l'activité. La perte de leur historique ou de leurs configurations de référence peut être aussi dommageable que la perte d'un partage de fichiers.
Dans le même temps, les clients sont devenus plus avertis. Ils font appel à leurs propres auditeurs, utilisent des questionnaires d'assurance cyber et définissent leurs propres normes internes. Lorsqu'ils demandent « Sauvegardez-vous tout ? », ils veulent rarement dire « Sauvegardez-vous le serveur de fichiers ? ». Ils veulent plutôt dire « Pouvez-vous nous permettre de reprendre nos activités en toute sécurité et prouver ce qui s'est passé en cas de problème ? ». C'est une question bien plus vaste et exigeante, et c'est précisément sur ce point que la norme A.8.13 vous invite à réfléchir.
Ce changement n'est pas seulement technique. Il modifie la façon dont les clients et les auditeurs vous évaluent. Les décisions relatives aux solutions de sauvegarde ont désormais une incidence sur les renouvellements, les scores de risque fournisseur et votre capacité à attirer des clients plus importants et soumis à une réglementation plus stricte.
Pourquoi les journaux et les configurations sont-ils si importants lors des pannes et des enquêtes ?
Les journaux et les configurations sont essentiels lors des pannes et des enquêtes, car ils permettent de répondre à deux questions fondamentales après un incident : que s’est-il passé et comment revenir en toute sécurité à l’état antérieur ? Sans eux, la récupération devient aléatoire et la confiance est difficile à rétablir.
Lorsqu'un incident grave survient (une attaque de ransomware, une erreur de configuration critique, une panne du cloud), deux questions prédominent pour vos clients et leurs parties prenantes :
- Dans combien de temps pourrons-nous revenir à un état sûr et fonctionnel ?
- Comment savoir ce qui s'est réellement passé ?
Les journaux d'activité constituent votre principale source pour répondre à la deuxième question. Ils indiquent quels comptes ont été utilisés, quelles adresses IP se sont connectées, quelles modifications ont été apportées et quels systèmes ont été sollicités. En cas d'absence ou d'incomplétude des journaux d'activité, il vous sera peut-être impossible de prouver l'ampleur d'une attaque, de convaincre les enquêteurs ou le conseil d'administration d'un client, ou de démontrer le respect des obligations réglementaires.
Les configurations sont essentielles pour répondre à la première question. Elles définissent comment les pare-feu filtrent le trafic, comment les systèmes d'identité contrôlent les accès, comment les VPN et les appliances SD-WAN acheminent les données, comment les plateformes SaaS appliquent les politiques de sécurité et comment les tâches de sauvegarde sont configurées. Si vous ne pouvez pas rétablir rapidement ces configurations de référence à partir d'un point de sauvegarde fonctionnel, chaque restauration devient une opération de reconstruction manuelle, lente et risquée, source de conjectures.
Dans de nombreux incidents graves, les données (fichiers, bases de données) étaient suffisamment récupérables. Le véritable préjudice résidait dans l'absence ou l'incohérence des journaux et des configurations. Les analyses forensiques post-incident, notamment celles portant sur la perte de configuration des pare-feu et les lacunes des journaux SIEM, révèlent souvent que l'absence de ces éléments a transformé des événements pourtant gérables en crises prolongées, à l'étendue incertaine et au rétablissement retardé. Pour les fournisseurs de services gérés (MSP), la norme A.8.13 vise en partie à garantir que cela ne se produise pas pour vos clients et à vous permettre de le prouver en cas de contrôle.
Les journaux et les configurations, traités comme des objets de sauvegarde de premier ordre, deviennent donc un élément central de votre stratégie de réponse aux incidents et d'assurance, et non plus de simples détails techniques en arrière-plan.
Demander demoQu’exige réellement la norme ISO 27001 A.8.13 des fournisseurs de services gérés (MSP) en matière de journaux et de configurations ?
La norme ISO 27001 A.8.13 exige que vous définissiez, mettiez en œuvre et démontriez un système de sauvegarde couvrant les informations, les logiciels et les systèmes, conformément à une politique convenue. Pour les fournisseurs de services gérés (MSP), cela inclut les journaux et les configurations des clients partout où ils sont nécessaires à la restauration, à la surveillance ou à la conformité, et pas seulement les données traditionnelles telles que les partages de fichiers et les bases de données.
Le rapport 2025 sur l'état de la sécurité de l'information indique que les clients attendent de plus en plus de leurs fournisseurs qu'ils s'alignent sur des cadres formels tels que l'ISO 27001, l'ISO 27701, le RGPD, Cyber Essentials et SOC 2.
La norme ISO 27001:2022, annexe A, contrôle A.8.13, stipule essentiellement que des copies de sauvegarde des informations, des logiciels et des systèmes doivent être conservées et testées régulièrement conformément à une politique de sauvegarde convenue, afin de permettre une restauration après une perte ou une interruption. Les interprétations de la norme axées sur les fournisseurs de services gérés (MSP), telles que les commentaires des fournisseurs de services sur le point A.8.13, reformulent cette exigence comme une nécessité de concevoir et de tester des dispositifs de sauvegarde capables de résister à des scénarios réalistes de panne et de menace, et non de se contenter de mesures théoriques. Pour un MSP, cette exigence s'applique aussi bien à ses propres informations qu'aux systèmes et données qu'il gère pour le compte de ses clients.
Concrètement, la norme A.8.13 exige que vous définissiez, documentiez et démontriez les éléments sauvegardés, la méthode de sauvegarde, la fréquence de sauvegarde, la durée de conservation, la protection des données et la preuve de leur restauration. Les journaux clients et les données de configuration sont concernés dès lors qu'ils sont nécessaires à la réalisation des objectifs de récupération convenus, aux exigences de surveillance de la sécurité ou aux obligations légales et réglementaires.
Pour concrétiser cela, il est utile de décomposer le contrôle en quatre questions :
- Portée: Quelles informations, quels logiciels et quels systèmes sont concernés par la sauvegarde, et pourquoi ?
- Opération: Comment les sauvegardes sont-elles effectuées, protégées et surveillées ?
- Test: Comment vérifiez-vous que les restaurations fonctionnent et atteignent les objectifs de récupération ?
- Preuve: Comment prouver aux auditeurs et aux clients que tout ce qui précède se produit réellement ?
Pour les fournisseurs de services gérés (MSP), il est nécessaire de répondre à ces questions à deux reprises : une fois pour leur propre système de gestion de la sécurité de l’information (SGSI) interne et une autre fois pour les services qu’ils fournissent à leurs clients. Si de nombreux processus et outils sous-jacents sont communs, les risques, les obligations et les attentes diffèrent. C’est pourquoi une interprétation spécifique aux MSP de la section A.8.13 est indispensable, plutôt que de se fier à des directives génériques destinées aux entreprises.
Une plateforme de gestion de la sécurité de l'information (GSSI) structurée, telle que ISMS.online, vous permet de lier les politiques A.8.13 aux actifs, aux risques et aux contrôles, garantissant ainsi la clarté et la traçabilité du périmètre et des responsabilités en matière de journaux et de configurations pour l'ensemble de votre clientèle. Si vous souhaitez centraliser ces exigences et assurer la cohérence des preuves, l'utilisation d'un tel système constitue souvent la solution la plus pratique.
Comment interpréter le point A.8.13 dans le contexte d'un MSP ?
Dans le contexte d'un MSP, vous devez traiter toutes les informations client nécessaires à la récupération, à la détection ou aux obligations légales comme faisant partie du champ d'application de A.8.13, aligner la sauvegarde avec les contrôles connexes tels que la journalisation et la gestion des changements, et documenter clairement les responsabilités partagées dans les politiques et les contrats.
Premièrement, considérez toute information que vous gérez pour vos clients et qui est nécessaire pour rétablir les services, détecter et enquêter sur les incidents ou satisfaire aux obligations formelles de conservation comme relevant du champ d'application de la section A.8.13. Cela comprend généralement :
- Journaux de sécurité provenant des pare-feu, des VPN, des terminaux, des outils de détection d'intrusion et des plateformes SIEM.
- Journaux système et applicatifs ayant une valeur probante ou opérationnelle pour les incidents ou les audits.
- Données de configuration pour les périphériques réseau, les outils de sécurité, les plateformes de virtualisation, les systèmes d'identité et les services SaaS critiques.
- Modèles et infrastructure-en-tant-que-code qui définissent les configurations et les bases de référence standard.
Pris ensemble, ces éléments constituent la base de votre capacité à prouver ce qui s'est passé et à reconstruire en toute sécurité.
Deuxièmement, il est important de noter que le point A.8.13 ne fonctionne pas de manière isolée. Il s'intègre aux contrôles relatifs à la journalisation, à la gestion des changements, au contrôle d'accès, à la continuité des activités et aux relations avec les fournisseurs. Par exemple :
- Les contrôles de journalisation vous obligent à conserver les journaux importants ; A.8.13 demande comment vous les restaurez après des pannes.
- Les contrôles de gestion des changements suivent les modifications de configuration ; A.8.13 préserve les versions connues pour être bonnes.
- Les contrôles de continuité des activités définissent les objectifs de reprise ; A.8.13 est une façon d’atteindre ces objectifs.
Cet alignement vous permet d'éviter les doublons et les attentes contradictoires entre les normes et les services.
Troisièmement, l'expression « politique de sauvegarde spécifique » est importante. Cela signifie qu'il ne faut pas dissimuler les exigences en matière de sauvegarde au sein d'une politique de sécurité de l'information générale. Vous devez disposer d'une politique ou d'une norme de sauvegarde dédiée qui fasse explicitement référence aux journaux et aux configurations, décrive les responsabilités et précise comment les exigences sont définies et appliquées.
Enfin, il est essentiel de clarifier la responsabilité partagée. Dans certains cas, les clients restent responsables de la sauvegarde des données dans certaines applications SaaS ou systèmes internes. Dans d'autres, vous gérez la plateforme, mais le client décide de la conservation des données et des sources de journaux spécifiques. La norme A.8.13 ne vous oblige pas à prendre en charge toutes les tâches de sauvegarde, mais elle exige que vous définissiez clairement les responsabilités de chacun, que vous formalisiez ces répartitions dans les contrats et les politiques, et que vous gériez les risques résiduels. Les analyses de la norme A.8.13 destinées aux fournisseurs de services gérés (MSP), notamment les notes interprétatives, insistent sur cette double obligation, tant pour votre propre système de gestion de la sécurité de l'information (SGSI) que pour les environnements que vous gérez.
Où se situent les journaux et les configurations des clients dans le périmètre de la sauvegarde ?
Les journaux et configurations clients font partie du périmètre de sauvegarde dès lors que leur perte compromettrait les objectifs de reprise d'activité, affaiblirait la surveillance de la sécurité ou enfreindrait les obligations légales et réglementaires. Ce périmètre doit être explicitement défini dans votre politique de sauvegarde et ne doit pas être présumé ni laissé à la discrétion des ingénieurs.
De nombreux fournisseurs de services gérés ont historiquement traité les journaux et les configurations comme des éléments distincts des sauvegardes :
- Les journaux étaient considérés comme des éléments résidant dans les SIEM ou les outils de surveillance, et non comme des objets de sauvegarde.
- Les configurations étaient considérées comme reproductibles à partir de la documentation ou des scripts, et non comme des données primaires nécessitant une sauvegarde.
Conformément à la section A.8.13, ces hypothèses ne sont plus valables. Si un flux de journaux ou un ensemble de configuration est nécessaire pour restaurer des services, enquêter sur des incidents, prouver la conformité ou atteindre les objectifs RPO/RTO convenus, il doit être explicitement inclus dans votre stratégie de sauvegarde.
Cela ne signifie pas que vous devez sauvegarder tous les journaux générés par chaque appareil pendant la même durée. Cela signifie que vous devriez :
- Identifiez les sources de journaux critiques pour la sécurité, les opérations et la conformité.
- Déterminez lesquels de ces éléments nécessitent une sauvegarde indépendante en plus de celle stockée sur le périphérique local ou dans le journal principal.
- Définissez les durées de conservation en fonction des risques, de la réglementation et des exigences des clients.
- Intégrez ces décisions dans votre politique de sauvegarde, vos inventaires d'actifs et vos descriptions de services.
Le fait de résumer clairement cela dans votre norme permet d'éviter les suppositions et les surprises lorsqu'un incident ou un audit survient.
La même logique s'applique aux configurations. Certains types de périphériques (pare-feu, passerelles VPN, commutateurs centraux, systèmes d'identité, plateformes de sauvegarde elles-mêmes) sont essentiels à la sécurité et à la continuité de service de vos clients. Leurs configurations doivent être sauvegardées, versionnées, protégées et testées périodiquement (restauration) avec autant de rigueur que n'importe quelle base de données.
La norme ISO 27001 simplifiée
Une avance de 81 % dès le premier jour
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.
Comment passer de « nous faisons des sauvegardes » à une norme de sauvegarde de référence ?
On passe de « nous effectuons des sauvegardes » à une norme de sauvegarde de référence en définissant une base de référence unique pour l'ensemble du MSP en matière de portée, de fréquence, de conservation, de protection, de tests et de preuves, puis en l'appliquant de manière cohérente à tous les clients avec des variations contrôlées pour les niveaux et les contrats.
Environ 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.
Pour vous conformer à la norme A.8.13 à grande échelle et réduire les risques commerciaux, vous devez abandonner les pratiques de sauvegarde ponctuelles et personnalisées au profit d'une norme de sauvegarde unique pour votre fournisseur de services gérés (MSP). Cette norme définit les exigences minimales en matière de sauvegarde et de test des informations, notamment les journaux et les configurations, pour l'ensemble des clients, et précise les paramètres pouvant varier selon le niveau de service ou le contrat.
Une norme de sauvegarde de référence n'est pas un simple argument marketing ; c'est un outil de gouvernance. Elle indique à vos ingénieurs leurs obligations, à vos équipes commerciales les promesses qu'elles peuvent tenir, à votre service de conformité les éléments à justifier et à vos clients les attentes qu'ils peuvent avoir.
À tout le moins, il devrait couvrir :
- Classes de portée et de données.
- Fréquence et méthodes de sauvegarde.
- Durée de conservation et règles de destruction.
- Mesures de protection telles que le chiffrement, le contrôle d'accès, la ségrégation et l'immuabilité.
- Surveillance et gestion des exceptions.
- Restauration des tests, y compris l'échantillonnage des journaux et des configurations.
- Exigences en matière de documentation et de preuves.
Une fois cette norme établie, vous pouvez la paramétrer pour chaque client : même structure, valeurs adaptées. L’utilisation d’une plateforme comme ISMS.online pour centraliser cette norme en tant que document contrôlé et la relier aux risques et aux contrôles facilite la cohérence entre la politique, sa mise en œuvre et les preuves. Si vous souhaitez que les ingénieurs, les auditeurs et les équipes commerciales puissent consulter les mêmes règles de sauvegarde, cette centralisation est souvent un choix pragmatique.
Pourquoi une norme de sauvegarde principale est-elle importante sur le plan commercial et opérationnel ?
Une norme de sauvegarde de référence est essentielle car elle réduit les angles morts, garantit une livraison reproductible et vous assure une position solide auprès des auditeurs et des clients. Sans elle, chaque client devient un cas unique, ce qui accroît les risques et les coûts.
En l'absence de norme commune, chaque client est traité individuellement. Les ingénieurs configurent les sauvegardes de manières légèrement différentes. Les commerciaux font des promesses au cas par cas. La documentation est éparpillée dans les tickets et reste souvent dans la tête des utilisateurs. Lors d'un audit ou d'un incident grave, vous risquez de constater que la couverture, la conservation et les tests des sauvegardes varient considérablement d'un client à l'autre, sans justification claire.
Cette incohérence comporte plusieurs risques :
- Cela augmente la probabilité qu'une source de journalisation ou un ensemble de configuration critique ait été complètement négligé.
- Cela rend plus difficile de prouver aux auditeurs ou aux assureurs que vous avez une approche délibérée et fondée sur les risques.
- Cela augmente les coûts opérationnels, car chaque exception doit être mémorisée et gérée manuellement.
- Cela vous expose à des accusations de traitement inéquitable si un client bénéficie d'une protection nettement supérieure à celle d'un autre sans justification documentée.
Une norme de référence vous offre un point de repère. Elle clarifie votre catalogue de services : chaque service géré inclut des exigences de sauvegarde définies. Elle simplifie les renouvellements et les revues trimestrielles : vous pouvez montrer aux clients comment leur niveau de service correspond aux capacités de sauvegarde. Elle renforce également la confiance de votre direction, qui a ainsi la certitude de ne pas faire peser de risques inégaux et latents sur l’ensemble de la clientèle.
Que doit contenir une norme de sauvegarde principale réaliste pour les fournisseurs de services gérés (MSP) ?
Une norme de sauvegarde réaliste définit, pour chaque type de données, la raison de la sauvegarde, la méthode de sauvegarde, la durée de conservation et la manière de prouver la restauration. Elle doit être suffisamment claire pour que les ingénieurs et les auditeurs puissent l'appliquer sans hésitation, et suffisamment simple à maintenir.
Lors de la rédaction de votre norme, privilégiez la clarté et l'applicabilité. Pour chaque classe de données (journaux de sécurité, journaux opérationnels, configurations, images système, bases de données), précisez :
- Objectif: Objectif de la sauvegarde de cette classe de données.
- Portée: Sources typiques incluses par défaut, et lorsque un accord explicite est requis.
- Fréquence : Fréquence des sauvegardes ou des exportations, exprimée en termes simples.
- Rétention: Périodes minimales et maximales, liées aux lois ou contrats le cas échéant.
- Protection: Chiffrement, contrôle d'accès, segmentation et toutes exigences d'immuabilité.
- Test: À quelle fréquence les restaurations sont-elles testées et à quoi ressemble le succès ?
- Preuve: Éléments attendus lors d'un audit, tels que les politiques, les configurations de tâches et des exemples de rapports.
L'intégration de cette norme dans un système de gestion de la sécurité de l'information (SGSI) tel que ISMS.online facilite la cohérence de l'ensemble des processus au fil de votre croissance. Vous pouvez la relier directement à l'annexe A.8.13, aux contrôles associés et aux services clients spécifiques, afin qu'une même infrastructure prenne en charge les ventes, la livraison et l'assurance qualité.
Une norme bien structurée devient également une liste de contrôle interne pour l'intégration de nouveaux services et plateformes, ce qui rend beaucoup plus difficile que des sources de journaux ou des configurations critiques passent entre les mailles du filet.
Comment rendre les objectifs RPO/RTO concrets pour les journaux, les configurations et les systèmes ?
Vous concrétisez les objectifs RPO et RTO en classant les données, en définissant un petit ensemble de niveaux réalistes et en testant si vos processus de sauvegarde et de restauration atteignent réellement ces objectifs pour les journaux, les configurations et les systèmes chez tous les clients.
L'objectif de point de récupération (RPO) et l'objectif de temps de récupération (RTO) sont essentiels à toute stratégie de sauvegarde sérieuse. Pour les fournisseurs de services gérés (MSP), le défi consiste à traduire ces concepts, initialement définis dans les politiques de sécurité, en comportements concrets et testables pour différents types de données client, notamment les journaux et les configurations.
Le RPO (Real Point Object) définit la quantité de données que vous pouvez vous permettre de perdre, exprimée en temps. Le RTO (Real Time Objectif) définit la durée maximale d'indisponibilité du système. Pour de nombreux clients, ces valeurs varient selon les applications, les environnements et les ensembles de données. Votre rôle consiste à concevoir un nombre restreint de niveaux de sauvegarde capables de répondre à ces exigences variées sans être submergés par la complexité.
Concernant les journaux et les configurations, il est souvent nécessaire d'accepter de ne pas traiter toutes les sources de la même manière. Certains journaux sont essentiels à la sécurité et doivent être quasi temps réel et conservés sur le long terme. D'autres sont utiles, mais non indispensables. Certaines configurations évoluent fréquemment et ont un impact important ; d'autres sont relativement stables. Vos objectifs de point de récupération (RPO) et de temps de récupération (RTO) doivent tenir compte de ces différences, et vos stratégies de sauvegarde doivent être adaptées.
Des objectifs clairs en matière de délais de récupération et de perte permettent de transformer les RPO et RTO en vagues promesses sur le papier, en cibles concrètes que vous pouvez définir et tester.
Pourquoi faut-il classer les données avant de définir les RPO et RTO ?
Vous devriez classer les données avant de définir le RPO et le RTO, car la classification vous permet d'appliquer quelques objectifs raisonnables à de nombreux systèmes au lieu de vous noyer dans des exceptions par source et des promesses irréalistes.
Si vous essayez de définir les valeurs RPO et RTO directement pour chaque système source, vous vous retrouverez submergé par les possibilités. Il est préférable de classer les données en quelques catégories pertinentes pour l'entreprise. Par exemple :
- Classe A : Preuves critiques en matière de sécurité et de conformité.
- Classe B : Journaux opérationnels et configurations nécessaires à la continuité.
- Classe C : Journaux et configurations à faible impact où la recréation est possible ou l'impact limité.
Une fois vos classes de données définies, vous pouvez leur attribuer des objectifs de RPO, de RTO et de conservation par défaut. Ces objectifs doivent reposer sur les cas d'utilisation des clients, les exigences réglementaires et vos capacités techniques, et non sur des intuitions. Vous pouvez ensuite les ajuster pour chaque client en cas de justification valable, grâce à un mécanisme d'exception formel.
Une manière simple de communiquer cela consiste à créer un tableau des classes et des cibles :
| classe de données | Niveau RPO/RTO typique | Exemples de conducteurs |
|---|---|---|
| Classe A | RPO ≤ 15 minutes, RTO ≤ 4 heures | Enquêtes de sécurité, registres de conformité |
| Classe B | RPO ≤ 4 heures, RTO ≤ 24 heures | Continuité des opérations essentielles |
| Classe C | RPO ≤ 24 heures, RTO ≤ 72 heures | Dépannage, charges de travail à faible impact |
Ce modèle peut être utilisé lors des discussions avec les clients et des séances de conception internes. Il offre aux ingénieurs un objectif clair pour chaque catégorie et fournit aux auditeurs un référentiel compréhensible pour les tests.
Comment faire pour que les objectifs RPO/RTO restent réalistes et atteignables ?
Vous garantissez la fiabilité des objectifs RPO et RTO en modélisant la capacité, en alignant les ventes sur l'ingénierie, en mesurant les performances réelles et en incluant des tests de restauration réalistes qui couvrent les journaux et les configurations, et pas seulement les charges de travail faciles.
Les chiffres RPO et RTO sont faciles à saisir, mais difficiles à atteindre. Pour éviter de faire des promesses excessives :
- Capacité et performances du modèle : Estimez les volumes de données par classe, le nombre de clients, les fenêtres de sauvegarde, la bande passante et le comportement du stockage à mesure que votre activité se développe.
- Aligner les équipes commerciales et d'ingénierie. N’offrir par défaut que les bandes RPO et RTO approuvées et acheminer les demandes plus strictes vers un processus d’examen et de validation.
- Mesurer les performances réelles. Suivi des RPO (âge de la dernière bonne copie) et des RTO (temps de restauration) atteints par niveau et par client, et correction des goulots d'étranglement.
- Le test rétablit de manière réaliste : Incluez les journaux et les configurations des environnements à fort impact dans vos exercices de restauration et enregistrez les temps de bout en bout.
Par exemple, pour les journaux de sécurité de classe A et les configurations de pare-feu, vous pouvez définir un RPO de quinze minutes et un RTO de quatre heures. Vous concevrez ensuite la collecte des journaux, les tâches d'archivage et les exportations de configuration pour respecter ces valeurs, et effectuerez des tests périodiques consistant à restaurer une configuration de pare-feu sur un appareil de laboratoire et à rejouer une journée de journaux dans un SIEM de test afin de confirmer que les objectifs sont réalistes.
Pour les clients, expliquez les objectifs de point de récupération (RPO) et de temps de récupération (RTO) à l'aide de scénarios plutôt que de simples chiffres. Par exemple : « Si ce pare-feu est mal configuré à 10 h, notre objectif est de restaurer sa configuration à partir d'une dernière copie valide datant de moins de 15 minutes et de le remettre en service avant 11 h. » Cela permet de clarifier les responsabilités et les compromis.
Une fois que vous disposez de plages RPO et RTO crédibles, l'étape suivante consiste à concevoir des architectures de sauvegarde capables de les fournir de manière cohérente à de nombreux locataires, et pas seulement dans un scénario de laboratoire unique.
Libérez-vous d'une montagne de feuilles de calcul
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é.
Comment concevoir des architectures de sauvegarde multi-locataires pour les journaux et les configurations ?
Vous concevez des architectures de sauvegarde multi-locataires en décidant où centraliser ou isoler, comment séparer les données client, comment capturer les configurations et comment préserver l'intégrité des journaux d'activité pour tous les locataires en utilisant des modèles qui équilibrent sécurité et efficacité.
En tant que fournisseur de services gérés (MSP), vous gérez rarement un environnement unique et bien organisé pour une seule organisation. Vous gérez un environnement mutualisé : de nombreux clients, de nombreuses plateformes et de nombreux outils. La norme A.8.13 ne vous indique pas comment concevoir l’architecture des sauvegardes dans ce contexte, mais elle exige que vous fournissiez et démontriez des sauvegardes fiables, sécurisées et testables pour tous les clients concernés.
Les questions architecturales fondamentales sont :
- Comment séparer les données client pour éviter une exposition entre locataires ou une suppression accidentelle ?
- Où centraliser pour plus d'efficacité, et où isoler pour plus de sécurité ?
- Comment capturer, protéger et versionner les données de configuration ?
- Comment garantir l'intégrité et la valeur probante des sauvegardes de journaux ?
- Comment surveillez-vous l'état de santé et l'état de préparation de l'ensemble de l'environnement ?
Vous n’avez pas besoin de revoir entièrement vos outils pour répondre à ces questions, mais vous avez besoin d’une conception réfléchie qui puisse être expliquée et défendue auprès des auditeurs et des clients.
Quels modèles favorisent une ségrégation sécurisée et des opérations efficaces ?
Les modèles multilocataires sécurisés et efficaces utilisent une séparation des données et des clés par locataire en plus d'outils et de pipelines partagés, ce qui vous permet d'équilibrer la sécurité avec une complexité gérable dans les opérations quotidiennes.
La plupart des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont déclaré avoir été touchées par au moins un incident de sécurité impliquant un tiers ou un fournisseur au cours de l'année écoulée.
La ségrégation et l'efficacité sont souvent contradictoires. Une ségrégation stricte incite à privilégier les instances par locataire et la séparation rigoureuse du stockage, des clés et des rôles d'administrateur. L'efficacité, quant à elle, favorise une infrastructure partagée, des pipelines centralisés et des outils communs. La plupart des fournisseurs de services gérés (MSP) optent finalement pour une approche hybride.
- Utilisez des clés de chiffrement par locataire et des référentiels logiquement séparés afin que la compromission d'un client ne puisse pas facilement affecter les sauvegardes d'un autre.
- Centralisez la collecte des journaux là où cela est pertinent, mais étiquetez et stockez les copies archivées de manière à préserver la clarté des limites entre les locataires.
- Distinguez la conservation des journaux opérationnels de celle des journaux de sécurité si vous avez besoin d'un contrôle plus strict sur les preuves.
- Minimisez et auditez les comptes à privilèges élevés qui peuvent modifier les tâches de sauvegarde ou supprimer des archives.
Quels que soient les modèles choisis, documentez-les dans des diagrammes d'architecture, des modèles de menaces et des manuels d'exploitation. Cette documentation constitue une preuve au titre de la norme A.8.13 et justifie vos affirmations concernant la « garantie de sauvegarde » auprès de vos clients.
Comment gérer la sauvegarde de la configuration dans un monde diversifié et fortement axé sur le cloud ?
Vous devriez gérer la sauvegarde de la configuration en traitant les configurations comme des objets de sauvegarde principaux, en automatisant les exportations, en les stockant en toute sécurité et en les incluant dans les tests de restauration, plutôt que de supposer qu'elles peuvent toujours être recréées à partir de scripts ou de la documentation.
La sauvegarde de la configuration est souvent le maillon faible de la reprise d'activité des fournisseurs de services gérés. Il est facile de supposer que les plateformes cloud et les appareils gérés conservent leurs propres politiques, ou que les scripts et les référentiels d'infrastructure en tant que code constituent une documentation « suffisante ». En pratique, vous devriez :
- Automatisez les exportations régulières ou les instantanés des configurations des systèmes et plateformes critiques.
- Stockez les exportations de configuration dans un stockage versionné, à accès contrôlé et idéalement immuable.
- Associez les versions de configuration aux enregistrements de gestion des modifications pour assurer la traçabilité et la restauration.
- Incluez les restaurations de configuration dans votre programme de tests, et pas seulement les restaurations complètes du système.
Considérez les artefacts de configuration comme des objets de sauvegarde de premier ordre, avec une classification des données, un RPO et un RTO, ainsi que des règles de conservation identiques à celles de toute autre classe. Ainsi, face à un incident complexe, vous pourrez dépasser la simple reconstruction manuelle et affirmer : « Nous pouvons restaurer le système à son état stable connu à ce moment précis, et voici la preuve. »
À mesure que votre infrastructure cloud s'étend, cette discipline vous protège également contre les modifications accidentelles des consoles des fournisseurs et garantit que les connaissances ne restent pas enfermées dans la tête de chaque ingénieur.
Comment prouver que les sauvegardes fonctionnent et constituer des pistes d'audit fiables ?
Vous prouvez l'efficacité des sauvegardes en combinant des politiques claires, une portée complète, des tâches surveillées, des tests de restauration significatifs et des preuves bien organisées, afin que les auditeurs et les clients puissent constater que la norme A.8.13 fonctionne en pratique, et pas seulement sur le papier.
Seule une organisation sur cinq environ, selon le rapport « État de la sécurité de l'information 2025 », a déclaré avoir totalement évité toute perte de données au cours de l'année écoulée.
Du point de vue d'un auditeur, une sauvegarde efficace des informations ne se limite pas à la configuration des outils. Il s'agit de pouvoir démontrer que :
- Vos politiques et normes existent et sont appliquées.
- Les systèmes et les données appropriés sont concernés.
- Les sauvegardes sont effectivement exécutées, surveillées et corrigées en cas de défaillance.
- Les restaurations sont testées et les tests répondent à des critères de réussite définis.
- Les preuves sont complètes, exactes et traçables.
Pour les fournisseurs de services gérés (MSP), ces éléments de preuve doivent être réutilisables lors des audits, des échanges avec les clients et des évaluations internes. Les constituer de A à Z à chaque fois est une tâche fastidieuse et source d'incohérences. Un dossier de preuves structuré pour la norme A.8.13 permet d'éviter ces problèmes et simplifie les évaluations futures.
Que doit contenir un pack de preuves A.8.13 pour les journaux, les configurations et les systèmes ?
Un dossier de preuves A.8.13 doit contenir les documents et enregistrements essentiels qui montrent ce qui est inclus dans le périmètre, comment les sauvegardes sont exécutées, comment les problèmes sont gérés et comment les restaurations sont testées, avec une couverture explicite des journaux et des configurations là où ils sont les plus importants.
Un dossier de preuves pratiques comprend généralement :
- Politiques et normes : Votre politique de sauvegarde principale et toutes les normes associées qui font explicitement référence aux journaux et aux configurations.
- Inventaires des actifs : Listes des systèmes, des sources de journaux et des référentiels de configuration dans le périmètre de sauvegarde, avec les classes de données et les niveaux RPO, RTO et de rétention attribués.
- Définitions des tâches de sauvegarde : Captures d'écran ou exportations montrant comment les tâches sont configurées pour des clients représentatifs : ce qui est inclus, où cela se passe, à quelle fréquence cela s'exécute.
- Surveillance et rapports : Exemples de rapports de sauvegarde et de tableaux de bord pour des périodes sélectionnées, montrant les taux de réussite, les échecs et la manière dont les exceptions sont gérées.
- Restaurer les enregistrements de test : Journaux et rapports des exercices de restauration, indiquant notamment les éléments restaurés, la durée de l'opération et si les objectifs ont été atteints.
- Enregistrements de modification : Preuve que les modifications de périmètre déclenchent des mises à jour de sauvegarde, ou que les exceptions sont enregistrées et approuvées.
Pour illustrer cela concrètement, prenons l'exemple d'un client représentatif. Votre dossier de preuves pourrait inclure la section pertinente de la politique de sauvegarde, la liste des actifs pour les pare-feu et le SIEM de ce client, la configuration des tâches d'exportation et d'archivage de ces journaux et configurations, un rapport de sauvegarde mensuel mettant en évidence les échecs et les corrections apportées, ainsi qu'un journal de test de restauration récent où une configuration de pare-feu et une journée de journaux ont été restaurées dans un environnement de laboratoire et validées.
Si vous utilisez ISMS.online, vous pouvez conserver ces éléments liés à A.8.13 et aux contrôles associés, ce qui vous permet de tout récupérer rapidement lorsqu'un auditeur ou un client exigeant demande des preuves, plutôt que de reconstruire l'histoire à partir de zéro à chaque fois.
Comment rendre les tests de restauration pertinents sans épuiser les ingénieurs ?
Vous donnez du sens aux tests de restauration en effectuant un échantillonnage judicieux, incluant les journaux et les configurations, en automatisant lorsque cela est possible et en réintégrant les résultats dans la conception, afin que les tests renforcent votre système au lieu de devenir une simple corvée.
Les tests de restauration constituent le point faible de nombreux systèmes de sauvegarde. Il est plus facile de démontrer que les tâches se sont exécutées que de prouver que les restaurations fonctionneront comme prévu. Pour des tests à la fois efficaces et durables :
- Définissez votre programme. Il n’est pas nécessaire de tester chaque client et chaque système tous les mois ; il suffit d’alterner par classe et par niveau.
- Inclure les journaux et les configurations : Ne limitez pas les tests aux images de serveur ou aux partages de fichiers ; couvrez les éléments de preuve les plus importants.
- Automatisez et enregistrez correctement : Utilisez des scripts et l'orchestration pour créer des environnements temporaires et capturer les temps d'exécution.
- Retour des résultats : Utilisez les résultats des tests pour améliorer l'architecture et ajuster les affirmations relatives au RPO et au RTO si nécessaire.
Par exemple, vous pourriez concevoir un test trimestriel consistant à restaurer la configuration du pare-feu d'un client clé et 24 heures de journaux de sécurité dans un environnement de laboratoire, à valider la configuration par rapport à votre configuration de référence et à vérifier que les journaux permettent à un analyste de reconstituer un scénario prédéfini. Les enregistrements de ce test renforcent à la fois votre confiance opérationnelle et votre préparation aux audits.
Au fil du temps, un programme de tests rigoureux mais réaliste devient l'une de vos meilleures garanties pour les clients, les assureurs et les organismes de réglementation.
Gérez toute votre conformité, en un seul endroit
ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.
Comment offrir une garantie de sauvegarde sans responsabilité illimitée ?
Vous offrez une garantie de secours en définissant clairement le périmètre de la garantie, les mesures de protection et de test mises en place, ainsi que les risques résiduels, plutôt que de promettre d'empêcher toute perte. Cette approche vous permet d'instaurer la confiance chez vos clients sans vous exposer à une responsabilité illimitée que vous ne pouvez pas véritablement maîtriser.
Les clients exigent de plus en plus une « garantie de sauvegarde » : l’assurance que leurs données, journaux et configurations seront récupérables dans les limites convenues, avec des preuves tangibles à l’appui. Les guides d’évaluation des promesses des fournisseurs de services gérés (MSP), tels que les guides d’évaluation de la garantie de sauvegarde, reflètent cette tendance en incitant les acheteurs à privilégier les normes documentées, les rapports de tests et les engagements clairs en matière de RPO/RTO plutôt que de vagues assurances. Parallèlement, il est déraisonnable d’accepter une responsabilité illimitée pour tous les scénarios possibles ou toutes les pertes de données. L’enjeu est de définir la garantie en termes de conception, de processus et de preuves, plutôt que par des garanties absolues.
L'assurance de sauvegarde, définie de manière raisonnable, signifie que vous pouvez répondre à des questions comme :
- Quels sont les éléments inclus dans la sauvegarde pour ce service et ce client, et pourquoi ?
- Quels sont les objectifs RPO, RTO et de rétention applicables ?
- Comment les sauvegardes sont-elles conçues, protégées et surveillées ?
- À quelle fréquence avez-vous testé les restaurations pour des systèmes comparables, et avec quels résultats ?
- Quels sont les risques résiduels qui subsistent, et à qui appartiennent-ils ?
Cela ne peut pas signifier honnêtement « nous promettons de ne jamais perdre aucun journal ni aucune configuration, jamais », ce qui serait irréaliste et non assurable. Vous vous positionnez plutôt comme un fournisseur doté d'un système robuste, étayé par des preuves et aux limites clairement définies.
Comment présenter la garantie de sauvegarde dans les conversations avec les clients ?
Vous définissez la garantie de sauvegarde en expliquant aux clients vos normes, vos classes de données et vos responsabilités en termes pratiques, en utilisant des scénarios réalistes plutôt que des garanties vagues ou des engagements sans limites.
Commencez par expliquer votre norme de sauvegarde principale et comment elle s'applique au client qui se trouve devant vous. Montrez-lui comment ses services s'intègrent à vos classes de données et à vos niveaux de sauvegarde, ce que cela signifie concrètement (par exemple : « journaux de pare-feu critiques : centralisation quasi temps réel, conservation pendant au moins 90 jours ; configurations de pare-feu : exportations quotidiennes et tests de restauration mensuels ») et indiquez les éventuelles différences.
Soyez explicite quant aux responsabilités partagées. Par exemple :
- Vous pouvez sauvegarder les journaux et les configurations de l'infrastructure principale, mais il incombe au client d'exporter et de sauvegarder certains journaux d'application des systèmes SaaS.
- Vous pouvez gérer la durée de conservation de certains flux de journaux, mais le client choisit cette durée en fonction de ses besoins internes et accepte les coûts de stockage et de performance associés.
Utilisez des exemples concrets et anonymisés autant que possible. Par exemple, décrivez un incident hypothétique où un compte compromis modifie les règles du pare-feu puis exfiltre des données. Expliquez quels journaux et configurations votre système de sauvegarde préserverait, à quelle vitesse ils pourraient être restaurés et quelles actions cela permettrait à l'équipe d'intervention conjointe d'entreprendre.
Surtout, évitez les promesses vagues. Au lieu de dire « nous sauvegardons toujours tout », dites plutôt « pour ce service, nous nous engageons à sauvegarder les données suivantes, selon ce calendrier, avec ces objectifs de conservation, surveillées de cette manière et testées à cette fréquence ». C'est à la fois plus honnête et plus convaincant.
Si vous souhaitez que ces engagements et scénarios soient étayés par un ensemble unique et cohérent de politiques et de preuves pour l'ensemble de votre clientèle, une plateforme ISMS comme ISMS.online peut vous fournir la structure dont vous avez besoin.
Comment traduire les garanties en contrats et en SLA ?
Vous traduisez les garanties en contrats en décrivant précisément la portée, le RPO, le RTO et les responsabilités, en les alignant sur votre norme et architecture de sauvegarde, et en utilisant des solutions qui reflètent ce que vous pouvez fournir et prouver de manière crédible.
Vos documents commerciaux doivent refléter vos réalités techniques. Des expressions vagues comme « sauvegardes conformes aux normes du secteur » ou « dans la mesure du possible » ne vous protègent guère, ni vous ni vos clients. À la place :
- Décrivez précisément la portée : Indiquez les systèmes, environnements, sources de journaux et types de configuration inclus. Précisez ce qui est exclu ou nécessite une inclusion explicite.
- Référence RPO, RTO et rétention : Utilisez les valeurs de vos niveaux de sauvegarde et associez-les aux services achetés.
- Définir les responsabilités. Précisez qui configure, surveille et maintient les sauvegardes ; qui doit signaler les changements ; et qui décide des politiques de conservation.
- Proposer des solutions réalistes. Évitez les clauses d'indemnisation sans limite de durée liées aux défaillances des sauvegardes. Privilégiez plutôt les crédits de service, la reprise des prestations et la coopération en cas d'incident.
- Se conformer aux politiques. Veillez à ce que vos contrats ne promettent pas plus que ce que votre politique et votre architecture de sauvegarde peuvent offrir.
Ce faisant, vous alignez les attentes découlant de l’article 8.13 sur des engagements juridiquement contraignants. Vous facilitez également la défense de votre position après un incident : vous pouvez vous référer au périmètre convenu, apporter la preuve de son respect et discuter en toute transparence des risques résiduels.
Réservez une démo avec ISMS.online dès aujourd'hui
ISMS.online vous aide à passer de simples suppositions concernant vos sauvegardes à un modèle de sauvegarde étayé par des preuves, auditable et commercialement viable, conforme à la norme ISO 27001 A.8.13 et aux contrôles associés. En utilisant un système de gestion de la sécurité de l'information (SGSI) unique pour définir votre norme de sauvegarde, l'associer à vos services et stocker vos preuves, vous facilitez grandement la démonstration à vos clients et auditeurs que votre dispositif est structuré, testé et maîtrisé.
Dans le rapport « État de la sécurité de l'information 2025 », la quasi-totalité des organisations 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.
Au sein d'un même environnement, vous pouvez centraliser votre norme de sauvegarde principale, la lier directement à l'annexe A.8.13 et aux contrôles associés, et l'associer à des services et clients spécifiques. Vos équipes de sécurité de l'information et de conformité bénéficient ainsi d'une vision claire de la mise en œuvre concrète des exigences de sauvegarde des journaux, des configurations et des systèmes. De plus, les auditeurs et les clients exigeants disposent d'une méthode structurée pour évaluer votre niveau de sécurité.
Pour les équipes techniques, la centralisation des plans de test et des résultats de restauration simplifie considérablement les opérations. Les ingénieurs n'ont plus besoin de jongler entre différents outils pour prouver qu'une configuration a bien été sauvegardée et restaurée dans les délais impartis. Ils peuvent consulter en un seul endroit les tests effectués, leurs résultats (positifs et négatifs) et les actions correctives mises en œuvre. Cela facilite à la fois les contrôles internes et les investigations externes.
Vous pouvez également générer des rapports personnalisés ou des vues contrôlées pour vos clients clés. Au lieu d'envoyer des captures d'écran par e-mail ou de créer des présentations sur mesure, vous pouvez présenter un récit cohérent de vos données de sauvegarde, basé sur les données en temps réel de votre système de gestion. Cela vous permet de répondre aux questions difficiles avec assurance, sans divulguer d'informations sensibles concernant d'autres clients ou votre fonctionnement interne.
Enfin, grâce aux fonctionnalités de gestion des flux de travail et des tâches, les actions liées aux sauvegardes (comme l'examen des exceptions, la mise à jour des règles de conservation ou la planification des tests de restauration) peuvent être attribuées, suivies et documentées. Ainsi, la boucle est bouclée entre la politique, sa mise en œuvre et sa validation, et votre système de sauvegarde devient un outil de contrôle dynamique, et non un simple document.
Si vous souhaitez découvrir comment une plateforme structurée peut faciliter la gestion de vos journaux clients, configurations et systèmes, une démonstration d'ISMS.online constitue une solution pratique. Elle vous permet de comparer votre couverture A.8.13 actuelle avec un modèle plus structuré et testable, et de déterminer si un système de gestion de l'information (SGII) centralisé vous aiderait à garantir une meilleure protection et une plus grande visibilité des données de sauvegarde pour vos clients et votre organisation.
Foire aux questions
Où la norme ISO 27001 A.8.13 trace-t-elle réellement la limite en matière de sauvegardes de journaux et de configurations pour les fournisseurs de services gérés ?
La norme ISO 27001 A.8.13 exige que les journaux et configurations clients soient considérés comme des actifs informationnels de premier ordre, nécessitant un système de sauvegarde conçu, documenté et testé. Ce système doit démontrer aux auditeurs précisément les données sauvegardées, leur fréquence, leur emplacement de stockage, leur protection et la manière dont les restaurations sont validées.
Comment un fournisseur de services gérés (MSP) doit-il définir la « sauvegarde des informations » pour les services gérés au quotidien ?
Pour un fournisseur de services gérés, la « sauvegarde des informations » ne se limite pas aux machines virtuelles ou aux systèmes de fichiers. Elle englobe toutes les données et tous les paramètres dont vous dépendez pour :
- Rétablir le service d'un client après une panne
- Enquêter sur un incident de sécurité présumé
- Consignez vos actions auprès d'un organisme de réglementation ou d'un tribunal.
- Prouvez que vous avez respecté vos obligations contractuelles.
Cela amène généralement les éléments suivants à entrer en ligne de compte :
- Journaux de sécurité provenant des pare-feu, VPN, EDR/AV, IDS/IPS et plateformes SIEM
- Journaux clés des applications et des plateformes nécessaires au dépannage ou à l'analyse forensique
- Données de configuration pour les commutateurs, routeurs, pare-feu et autres périphériques réseau
- Les plateformes d'annuaire et d'identité telles qu'Active Directory et Entra ID / Azure AD
- Exportations de configuration au niveau du locataire pour les principaux services SaaS et cloud
Pour chacun de ces points, un auditeur s'attendra à constater que vous avez :
- Nous avons déterminé et documenté les journaux et les ensembles de configuration pertinents pour la récupération et la traçabilité.
- Méthodes de sauvegarde ou de transfert définies (par exemple, pipelines SIEM, instantanés, exportations API)
- Définir les durées de conservation, les lieux de stockage et la propriété de ces décisions
- Mise en œuvre de contrôles techniques appropriés (cryptage, contrôle d'accès, ségrégation, parfois immuabilité)
- Des tests de restauration périodiques planifiés et enregistrés, incluant les journaux et les configurations, et pas seulement les serveurs.
Vous n'avez pas besoin d'une approche différente pour chaque client. Une norme de sauvegarde unique au sein de votre système de gestion de la sécurité de l'information (SGSI), qui identifie explicitement les journaux et les configurations comme des actifs concernés par la norme A.8.13, et qui établit des liens avec les périmètres, les tâches et les preuves de restauration spécifiques à chaque client, suffit généralement à satisfaire les auditeurs et à rassurer les clients les plus importants. ISMS.online vous facilite la tâche en centralisant cette norme, en associant la norme A.8.13 à votre ensemble de contrôles et en connectant les inventaires, les tâches de sauvegarde et les rapports de tests de chaque client. Ainsi, vos ingénieurs, votre équipe commerciale et vos auditeurs travaillent tous à partir d'une vue commune.
Comment un fournisseur de services gérés peut-il standardiser ses niveaux de sauvegarde lorsque chaque client souhaite des objectifs de RPO et de RTO différents ?
L'approche la plus durable consiste à concevoir un nombre restreint de niveaux de sauvegarde avec des objectifs de point de récupération (RPO), de temps de récupération (RTO) et des durées de rétention fixes, puis à affecter chaque système, source de journalisation et ensemble de configuration à l'un de ces niveaux pour chaque client. De cette manière, vous offrez un choix pertinent sans créer un modèle unique pour chaque service.
Comment traduire l'impact commercial en niveaux de sauvegarde concrets ?
Pour de nombreux fournisseurs de services gérés (MSP), une structure à trois niveaux constitue un point de départ viable :
- Niveau 1 – Plan de preuves et de contrôle :
Journaux de sécurité, configurations du réseau principal et du pare-feu, plateformes d'identité et autres composants du plan de contrôle
– RPO typique : de quelques minutes à une heure • RTO : quelques heures
- Niveau 2 – Données de continuité :
Journaux d'application et configurations ayant une incidence significative sur la disponibilité du service ou les revenus
– RPO typique : quelques heures • RTO : jour ouvrable suivant
- Niveau 3 – Journaux de support :
Journaux opérationnels de routine et systèmes à faible impact
– Délai de réponse type (RPO) : quotidien • Délai de traitement (RTO) : « au mieux » pour les enquêtes uniquement
Pour chaque niveau, vous devez définir, dans votre SMSI :
- Objectifs de recouvrement (RPO/RTO) et rétention minimale
- Mécanismes de sauvegarde autorisés (par exemple, transfert SIEM, exportations planifiées, instantanés d'images)
- Règles de stockage et de protection (région, chiffrement, ségrégation logique, immuabilité optionnelle)
- Exigences minimales de test de restauration auprès de votre clientèle
Vous associez ensuite les services, les journaux et les ensembles de configuration de chaque client à ces niveaux et vous intégrez cette association dans les contrats, les manuels d'exploitation et les plans de sécurité. Au lieu de promettre un RPO/RTO personnalisé par ressource, vous pouvez affirmer : « Ce service appartient au niveau 1, ce qui signifie… » et fournir des preuves concrètes à l'appui de cette affirmation.
La modélisation de ces niveaux et correspondances dans ISMS.online – et leur liaison directe à l'annexe A.8.13 – garantit que toute modification (par exemple, le passage du pare-feu d'un client du niveau 2 au niveau 1 après une analyse des risques) est rattachée à votre norme de sauvegarde, à votre définition de service et à votre dossier de preuves. Cette cohérence entre les promesses commerciales, les pratiques des ingénieurs et les constats des auditeurs fait souvent toute la différence entre un audit réussi et un audit difficile.
Quelles preuves spécifiques convainquent les auditeurs ISO 27001 que le contrôle A.8.13 d'un MSP est efficace ?
Les auditeurs souhaitent s'assurer que votre stratégie de sauvegarde des systèmes, des journaux et des configurations est intentionnelle, cohérente et éprouvée en pratique. Dans le cadre d'un audit par échantillonnage, cela implique généralement une combinaison de normes écrites, d'inventaires, d'exemples de configuration, de résultats de surveillance et de rapports de tests de restauration qui convergent tous vers la même conclusion.
Quels documents devez-vous préparer avant le début de l'audit ?
Lors d'une visite de surveillance ou de certification classique, vous pouvez vous attendre à des questions portant sur trois axes principaux :
- Conception et étendue :
- Une politique ou une norme de sauvegarde qui traite explicitement les journaux et les configurations comme des actifs informationnels au sens de la section A.8.13
- Un inventaire des services ou des clients indiquant les systèmes, les sources de journaux et les ensembles de configuration couverts, ainsi que leurs niveaux.
- Objectifs RPO/RTO documentés et règles de fidélisation par niveau ou par ligne de service
- Exploitation et surveillance :
- Exemples de définitions de tâches de sauvegarde (par exemple, configurations de pare-feu, exportations d'identité, pipelines SIEM, instantanés de base de données)
- Suivi des observations ou des rapports sur une période définie montrant la gestion des succès et des échecs, avec preuve de suivi.
- Enregistrements de modifications démontrant que de nouveaux services, locataires ou sources de journaux sont intégrés au périmètre de sauvegarde via un processus reproductible
- Efficacité et amélioration :
- Restaurez les enregistrements de test qui incluent les journaux et les configurations, et pas seulement les serveurs ou les bases de données.
- Notes ou actions suite à des évaluations où un test a échoué ou a mis en évidence une faiblesse, et où vous avez apporté des modifications en conséquence.
Les auditeurs savent généralement que des incidents et des échecs de production surviennent. Ce qu'ils recherchent, c'est une chaîne cohérente : le contrôle est défini, la conception est documentée, les tâches sont exécutées, les défaillances sont détectées et des tests de restauration réalistes sont effectués et suivis d'actions correctives.
Si ces informations sont dispersées dans différentes consoles, boîtes de réception et dossiers personnels, vous et votre équipe subirez des pressions constantes lorsqu'un auditeur demandera un échantillon. En revanche, si vous utilisez ISMS.online pour définir le contrôle A.8.13 une seule fois, joindre votre norme de sauvegarde, lier le périmètre et les échantillons de chaque client, et conserver un « dossier de preuves de sauvegarde » réutilisable, vous pourrez répondre à la plupart des demandes d'échantillonnage depuis un point unique et démontrer que la conformité à la norme A.8.13 est maîtrisée et non improvisée.
Comment un fournisseur de services gérés peut-il garantir une assurance de sauvegarde fiable à ses clients sans prendre de risques illimités ?
Vous fournissez des garanties de sauvegarde basées sur une conception, une surveillance et des tests rigoureux, dans un cadre clairement défini, et non en promettant l'absence totale de perte de données. Les clients sont généralement réceptifs aux engagements précis et vérifiables concernant le périmètre et les niveaux de récupération, étayés par des données actuelles, et se méfient davantage des garanties générales qu'il est impossible de tenir.
Comment construire un récit rassurant qui rassure les clients et soit durable pour vous ?
Une déclaration d'assurance pratique répond à quatre questions dans un langage simple :
- Ce que nous protégeons : Quels systèmes, sources de journaux et ensembles de configuration sont couverts pour chaque service géré ?
- Comment nous les protégeons : Le niveau de sauvegarde applicable, le RPO/RTO, les règles de conservation, les emplacements de stockage et les principaux contrôles techniques
- Comment nous restons honnêtes : Comment les tâches de sauvegarde sont surveillées, comment les incidents sont gérés et à quelle fréquence les restaurations sont testées
- Là où commence votre responsabilité : Les sources de données que vous devez exporter ou conserver, les choix réglementaires qui entraînent une conservation prolongée et les risques résiduels qui subsistent.
Vous pouvez consigner ces informations dans un bref aperçu standard de la sauvegarde et de la restauration, qui figure systématiquement dans les propositions, les calendriers de sécurité et les documents d'intégration. En parallèle, vos équipes tiennent à jour la cartographie des niveaux de sauvegarde, l'état des tâches en temps réel et les résumés des tests de restauration pour chaque client.
L'intégration de ces éléments dans ISMS.online et leur liaison à votre contrôle A.8.13 vous permettent de démontrer à vos prospects, clients actuels et, le cas échéant, à leurs auditeurs, que vos engagements publics correspondent au régime que vous appliquez réellement. Ce type d'assurance précise et étayée est généralement plus convaincant qu'une simple affirmation du type « vos données ne seront jamais perdues » et contribue également à protéger votre organisation en cas d'examen approfondi d'un incident ultérieur.
Quels modèles de conservation et de séparation sont pertinents pour les sauvegardes multi-locataires des journaux et des configurations ?
Pour la plupart des fournisseurs de services gérés (MSP), une solution efficace consiste à définir quelques paliers de rétention basés sur les risques et à les associer à une séparation logique stricte sur les plateformes de sauvegarde partagées. Cette approche répond généralement aux exigences de sécurité, de confidentialité et de conformité réglementaire, tout en laissant la possibilité d'exceptions contractuelles justifiées.
Comment concilier valeur de l'enquête, coût et confidentialité dans un environnement partagé ?
De nombreux fournisseurs optent pour une approche de ce type :
- Bandes de rétention :
- Une fenêtre par défaut telle que 90 jours des journaux de sécurité en ligne pour la plupart des locataires, à des fins d'opérations quotidiennes et d'enquêtes de base
- Rétention prolongée, par exemple 12 – 18 mois, pour les charges de travail à risque plus élevé ou réglementées telles que les paiements, les soins de santé ou les infrastructures critiques
- Durée de conservation plus courte pour les journaux d'opérations de faible valeur lorsque les coûts de stockage et les risques pour la confidentialité l'emportent sur les avantages liés à l'enquête
- Archives optionnelles à long terme pour des sources de « preuves » spécifiques que certains clients doivent conserver pour des raisons légales, contractuelles ou réglementaires
- Ségrégation et protection :
- Clés de chiffrement par locataire ou conteneurs de stockage, coffres-forts ou comptes logiquement séparés
- Des règles d'accès strictes garantissent que les ingénieurs et les analystes SOC ne voient que les données d'un seul client à la fois.
- Accès basé sur les rôles avec des rôles à privilèges minimaux pour les fonctions de support, d'exploitation et de surveillance
- Paramètres immuables ou à écriture unique pour les principaux supports de données où toute falsification ou suppression serait particulièrement dommageable
Du point de vue de la norme ISO 27001, l'important n'est pas seulement que ces mesures existent, mais que vous puissiez les décrire et les démontrer d'une manière qui soit compréhensible pour chaque locataire :
- Quels journaux et fichiers de configuration conservez-vous pour ce client ?
- Durée de conservation de chaque catégorie et lieux de conservation
- Comment la ségrégation et la protection sont mises en œuvre et contrôlées au fil du temps
Si vous modélisez cette conception dans ISMS.online – en utilisant une norme unique de conservation et de séparation mappée à A.8.13 et référencée aux périmètres individuels des clients – il devient beaucoup plus facile de justifier vos décisions auprès des auditeurs, des responsables de la protection de la vie privée et des clients et d’appliquer des changements cohérents lorsque la loi, la réglementation ou les contrats évoluent.
Comment transformer l'annexe A.8.13 en un service de sauvegarde géré clair et reproductible que les équipes commerciales et les auditeurs comprennent à la fois ?
Vous considérez A.8.13 comme la pierre angulaire d'un service de sauvegarde et de restauration géré, avec des packages nommés, des objectifs de point de restauration (RPO) et de temps de restauration (RTO) définis, des plages de rétention (y compris pour les journaux et les configurations) et un pack d'assurance standard, le tout géré par votre système de gestion de la sécurité de l'information (SGSI). Cela vous permet de passer de promesses ponctuelles à un catalogue de services stable, reconnu par les équipes commerciales, de livraison, les clients et les auditeurs.
À quoi ressemble un service de sauvegarde packagé et conforme à la norme A.8.13 dans le contexte d'un fournisseur de services gérés (MSP) ?
Une manière simple de structurer cela consiste à définir un petit ensemble de paquets tels que :
- Sauvegarde essentielle :
Serveurs principaux et configurations critiques ; couverture de journalisation limitée ; RPO/RTO et durée de conservation standard pour les clients de plus petite taille ou à faible risque
- Sauvegarde assurée :
Serveurs, journaux de sécurité plus complets et configurations à fort impact ; RPO/RTO plus rapides et durée de conservation des preuves plus longue pour les enquêtes et la conformité.
- Sauvegarde améliorée :
Couverture étendue des journaux, conservation prolongée, archives immuables et tests de restauration plus fréquents pour les clients réglementés ou à haut risque
Pour chaque paquet que vous documentez :
- Quels types de ressources sont concernés (systèmes, sources de journaux, ensembles de configuration) ?
- Niveau de sauvegarde applicable, RPO/RTO, durée de conservation et attentes en matière de stockage et de protection
- La répartition des responsabilités entre votre équipe et le client
- Les pratiques de surveillance et de test de restauration qui s'appliquent
- Comment ce package s'aligne sur l'annexe A.8.13 et les domaines connexes tels que la journalisation, la gestion des incidents et la continuité des activités
Vous alors :
- Capturez la norme de sauvegarde principale et ces définitions de package une seule fois dans ISMS.online
- Associez les contrats clients, les catalogues de services et les calendriers de sécurité au forfait correspondant.
- Maintenir un modèle standard de dossier de preuves que les ingénieurs et le personnel d'exploitation mettent à jour dans le cadre de leurs activités courantes.
À terme, cela vous assure un langage cohérent dans vos propositions et questionnaires de sécurité (« vous bénéficiez de notre niveau de sauvegarde garanti, qui comprend… »), une piste d'audit claire et réutilisable pour la norme ISO 27001 et une intégration bien plus simple pour les nouveaux membres de l'équipe. Votre organisation se positionne ainsi comme un fournisseur dont les engagements en matière de sauvegarde sont non seulement fiables, mais aussi rigoureusement contrôlés et reproductibles – l'impression que recherchent précisément les clients et auditeurs avertis lorsqu'ils s'interrogent sur vos pratiques concernant le point A.8.13.
Pour passer pragmatiquement de la théorie à la pratique, commencez par élaborer une norme de sauvegarde A.8.13 unique sur ISMS.online, définissez vos trois premiers niveaux ou forfaits et appliquez ce modèle à un client stratégique. Une fois ce modèle validé, son déploiement à l'ensemble de vos services gérés sera grandement facilité.
