Construire une stratégie de sauvegarde : la méthode et le modèle

Avoir des sauvegardes ne dit rien de la capacité à restaurer. Entre les deux se trouve une stratégie : des engagements fixés par ceux qui subiront l’interruption, des scénarios qui séparent la panne de l’attaque, des preuves produites avant le jour où l’on en a besoin. Voici la méthode, et le modèle de document qui l’accompagne, à télécharger et à adapter.

Introduction

Posez la question dans n’importe quelle DSI : « Avez-vous des sauvegardes ? » La réponse sera oui. Posez ensuite celle-ci : « Si l’ensemble de vos serveurs était chiffré cette nuit, à quelle heure, et dans quel état, vos données métier seraient-elles de nouveau disponibles ? » La réponse devient une discussion. Et c’est dans cette discussion que se loge le risque.

Les chiffres disent la même chose. Dans l’enquête que Sophos publie chaque année auprès d’organisations victimes de rançongiciel, la part de celles qui ont récupéré leurs données grâce à leurs sauvegardes est tombée à 54 % dans l’édition 2025, son plus bas niveau en six ans, contre 70 % en 2022. L’édition précédente montrait pourquoi : dans 94 % des attaques, les assaillants avaient tenté de compromettre les sauvegardes, et ils y étaient parvenus dans 57 % des cas. Les organisations dont les sauvegardes avaient été touchées payaient la rançon presque deux fois plus souvent (67 % contre 36 %) et supportaient un coût de reprise médian huit fois supérieur. Ces enquêtes sont déclaratives et conduites pour un éditeur ; leurs ordres de grandeur, stables d’une année à l’autre, suffisent pourtant à fixer le sujet.

Le défaut, dans la plupart des cas, n’est pas technique. Les outils savent copier, dédupliquer, chiffrer, verrouiller. Ce qui manque, c’est la couche de décision qui relie ces outils au besoin : qui a fixé la perte de données acceptable, pour quel scénario, avec quelle preuve que l’engagement tient ? C’est l’objet d’une stratégie de sauvegarde. Les épisodes 014 et 016 de Plan R ont traité des architectures (3-2-1, immuabilité, isolement). Celui-ci traite de la méthode qui les rend utiles.

1. Politique, stratégie, plan : où se situe le document qui manque

La documentation de sauvegarde s’organise en étages. Les confondre est la première cause des stratégies qui n’en sont pas.

L’étage le plus souvent absent est celui du milieu. Sans lui, le plan de sauvegarde est écrit par l’outil : on sauvegarde ce que l’outil sait sauvegarder, à la fréquence que la fenêtre nocturne permet, et la rétention découle de la capacité disponible. Le niveau de protection reflète alors la technique en place, pas le besoin.

Une stratégie apporte trois choses que les autres étages ne donnent pas :

• des engagements opposables : une perte de données maximale et une durée d’interruption maximale, par scénario et par contexte, validées par les métiers ;
• un partage explicite des responsabilités : les données appartiennent aux métiers, les supports à l’organisation, et la responsabilité de leur sécurisation ne se délègue pas, même quand l’exploitation est confiée à un prestataire ;
• un dispositif de preuve : ce qui démontre, avant l’incident, que les engagements sont tenables.

Dans le vocabulaire d’ISO 22301, cet étage correspond aux « stratégies et solutions de continuité » (§ 8.3), qui découlent de l’analyse d’impact et de l’appréciation des risques (§ 8.2). La sauvegarde n’est pas un sujet d’infrastructure qui touche la continuité ; c’est une solution de continuité qui mobilise l’infrastructure.

2. Ce que dit l’état de l’art

Les référentiels ne parlent pas tous le même langage, mais ils convergent. Le tableau ci-dessous en donne la lecture utile pour construire une stratégie.

Trois remarques de lecture.

La définition du 3-2-1 n’est pas la même partout. La formulation courante dit : trois copies, deux supports, une copie hors site. Le guide de l’ANSSI dit : trois copies (la production et deux sauvegardes), sur des supports différents, dont une hors ligne. La différence n’est pas de détail : une copie hors site mais joignable par le réseau reste à portée d’un attaquant. La variante 3-2-1-1-0, répandue chez les éditeurs, ajoute une copie immuable ou hors ligne et zéro erreur aux vérifications de restauration.

Le règlement 2024/2690 dépasse son périmètre. Il ne s’applique qu’à certaines catégories d’entités (fournisseurs de cloud, de centres de données, de services gérés et de sécurité gérés, registres et DNS, notamment). Mais sa section 4.2 est l’une des listes d’exigences les plus détaillées qu’un texte européen consacre à la sauvegarde ; elle sert de grille de lecture à toute organisation, y compris celles dont la transposition nationale de NIS 2 n’était pas achevée à l’été 2026, comme la France.

Tous convergent vers six invariants. Un périmètre fondé sur l’appréciation des risques ; des objectifs de reprise décidés à l’avance ; au moins une copie hors d’atteinte du système qu’elle protège ; des accès et un chiffrement proportionnés à la sensibilité des données ; des tests de restauration documentés ; une revue périodique. Une stratégie qui couvre ces six points satisfait l’essentiel des textes ci-dessus. Le modèle proposé en fin d’article les couvre, et sa table de correspondance (§ 4.3) permet de le démontrer.

3. La méthode en huit étapes

Étape 1 — Poser un vocabulaire commun avant toute chose

Une stratégie de sauvegarde échoue plus souvent sur un malentendu que sur une panne. Le responsable métier qui entend « nous avons une réplication » comprend « mes données sont protégées ». L’architecte, lui, sait qu’une réplication recopie fidèlement une corruption ou un chiffrement. Tant que les mots ne sont pas fixés, les engagements ne veulent rien dire.

Quatre distinctions sont indispensables.

• Données vivantes et données mortes. Les premières résident sur leur support d’origine (actives, historiques, archivées) ; les secondes sont leurs copies (synchrones, asynchrones, isolées). La distinction entre données actives et historiques est un levier de coût sous-estimé : une donnée qui n’évolue plus n’a besoin que d’une sauvegarde unique. L’isoler réduit le volume copié chaque nuit, donc la fenêtre, la capacité et la facture.
• Sauvegarde et archivage. La sauvegarde produit des copies temporaires destinées à la restauration ; l’archivage déplace une donnée vers un support dédié pour satisfaire une obligation de conservation. Une version de sauvegarde âgée de trois ans n’est pas une archive.
• Haute disponibilité et sauvegarde. Un dispositif actif-actif garantit une perte de données nulle face à une panne matérielle. Face à une altération logique, il n’offre aucune protection.
• Restauration, reconstruction, reconstitution. Restaurer, c’est remettre des données dans leur état antérieur. Reconstruire, c’est réinstaller un système sain, socles techniques compris. Reconstituer, c’est rejouer des flux métier pour combler une perte que les sauvegardes ne couvrent pas. Une cyberattaque sérieuse mobilise les trois.

Ce vocabulaire occupe tout un chapitre du modèle. Ce n’est pas du remplissage : c’est la condition pour que les chapitres suivants soient lus de la même façon par tous.

Étape 2 — Partir de l’analyse d’impact, et décomposer les délais

Les objectifs de sauvegarde ne s’inventent pas en salle machine. Ils sortent de l’analyse d’impact sur l’activité (BIA), qui identifie les activités prioritaires, leurs dépendances (applications, données, prestataires, flux) et le délai au-delà duquel leur interruption devient inacceptable. ISO 22301 en fait le point de départ de toute solution de continuité ; la spécification technique ISO/TS 22317 en détaille la conduite. Une stratégie de sauvegarde écrite sans BIA fixe des délais à l’aveugle.

De cette analyse découle une chaîne de délais, qu’il faut garder dans l’ordre :

Une précision de vocabulaire s’impose. En France, le sigle DMIA désigne tantôt la durée tolérable (c’est le sens retenu par le lexique du Club de la continuité d’activité), tantôt l’objectif de reprise (c’est l’usage courant en exploitation, et celui du modèle). Il en va de même pour la PDMA. Le modèle emploie DMIA et PDMA au sens d’engagements de la DSI, équivalents du RTO et du RPO informatiques, et le dit dans ses définitions. L’essentiel est qu’une organisation choisisse un sens et s’y tienne : deux interlocuteurs qui mettent deux sens sous le même sigle signent un engagement que personne ne tiendra.

Reste à voir comment l’engagement se consomme réellement pendant un sinistre. La durée d’indisponibilité effective d’une donnée se décompose en six phases :

Deux règles découlent de cette décomposition.

La première concerne la décision. Quand le déclenchement du secours appartient au métier, la durée de sa délibération sort de l’engagement de la DSI, et il faut l’écrire. Sans cette exclusion, l’hésitation à décider est imputée à l’exploitation, et l’engagement est réputé non tenu pour une raison qui n’a rien de technique.

La seconde concerne la fixation des seuils. Le délai acceptable doit être fixé par celui qui subira l’interruption, pas par celui qui paiera la protection. Quand les deux se confondent, on obtient invariablement le délai qui justifie le budget déjà décidé.

La phase 1 appelle enfin une précision que les méthodes anciennes ignoraient. Dans un scénario de cyberattaque, la dernière sauvegarde réussie n’est pas forcément la dernière sauvegarde saine : l’attaquant a pu séjourner des semaines dans le système avant d’agir. La PDMA effective dépend alors de la profondeur de rétention et de la capacité à dater la compromission.

Étape 3 — Modéliser les indisponibilités en séparant le physique du logique

C’est l’étape qui a le plus d’effet sur la qualité de la stratégie, et la plus souvent escamotée. Le modèle croise deux axes, la nature de l’altération et son étendue, et en tire cinq scénarios :

S’y ajoute le fonctionnement nominal dégradé, où un incident touche une ressource sans interrompre les applications, par exemple la perte d’une partie des sauvegardes elles-mêmes.

L’intérêt de ce croisement tient en une phrase : la haute disponibilité couvre la ligne physique ; sur la ligne logique, elle propage l’altération. Tant que les deux familles sont confondues, la réplication passe pour une sauvegarde et les engagements de restauration sont surestimés. Les séparer oblige à poser la seule question qui compte en 2026 : que se passe-t-il quand l’altération est logique et globale ?

Pour chaque scénario, le modèle demande trois réponses : que fait-on pendant le sinistre, comment revient-on au mode nominal, comment éprouve-t-on le dispositif. Un scénario auquel on ne sait pas répondre sur ce troisième point n’est pas couvert ; il est espéré.

Deux règles s’ajoutent, que les méthodes classiques formulent rarement.

Une destruction simultanée des sauvegardes sur plusieurs sites se traite comme un indicateur de compromission jusqu’à preuve du contraire. C’est la phase de préparation typique d’une attaque par rançongiciel.

En indisponibilité logique globale, restaurer est une décision de crise, pas un geste d’exploitation. Restaurer trop tôt, c’est réinjecter la compromission, effacer les traces dont l’enquête a besoin et, parfois, contrevenir aux conditions du contrat de cyberassurance. La stratégie doit donc dire qui décide : la cellule de crise, sur avis de l’équipe de réponse à incident, et non l’équipe de sauvegarde seule. Les notifications réglementaires et la relation avec l’assureur relèvent du dispositif de gestion de crise ; la stratégie de sauvegarde doit simplement s’y raccorder.

Étape 4 — Construire une offre par défaut, et faire payer l’exception

Le point de départ habituel est une négociation au cas par cas. Chaque métier demande « la meilleure protection possible », l’infrastructure répond par ce qu’elle sait déjà faire, et le résultat est un patchwork d’engagements implicites que personne ne peut tenir ni vérifier.

La structure proposée sort de ce face-à-face en deux temps.

Une offre générale de sauvegarde (OGS) s’applique par défaut à toutes les données du système d’information, sans demande préalable. Elle fixe, par scénario et par contexte (production, hors production), une PDMA et une DMIA. Elle dit aussi comment ces engagements sont validés, comment les données sont sécurisées et comment les incidents de sauvegarde sont gérés. Aucune donnée n’est hors offre : l’absence d’expression de besoin n’est pas une absence de protection.

Des offres spécifiques (OSS) permettent à un métier d’obtenir davantage, mais seulement en mode projet : il exprime le besoin, l’architecture chiffre les moyens et leurs conséquences sur l’exploitation, le métier valide et budgète. Règle associée : une offre spécifique peut relever l’offre générale, jamais la réduire.

Le chiffrage à la charge du demandeur fait redescendre de lui-même les exigences de confort, sans qu’il soit besoin de les contester. Et la DSI cesse d’arbitrer seule entre des demandes qu’elle n’a pas les moyens de satisfaire.

Étape 5 — Dimensionner : fréquence, versions, rétention, profondeur

Une sauvegarde se caractérise au minimum par trois paramètres liés entre eux : sa fréquence, son nombre de versions et sa durée de rétention, qui est le produit des deux premiers. Un schéma dégressif, dense sur les derniers jours et espacé au-delà, couvre une longue période avec peu de versions. Le guide de l’ANSSI en donne un exemple : quinze jours de sauvegardes quotidiennes, un an de mensuelles, cinq ans d’annuelles.

Quatre points de vigilance guident le dimensionnement.

• La profondeur doit couvrir le délai de détection. Une corruption silencieuse découverte au bout de six semaines ne se répare pas avec trente jours de rétention. Le délai probable entre altération et détection est une donnée d’entrée, pas une conséquence.
• L’unité de temps préserve la cohérence. Un ensemble applicatif sauvegardé en plusieurs fois, à des heures différentes, se restaure en état incohérent. Les sauvegardes d’un même ensemble se prennent dans une même fenêtre, ou l’on accepte de corriger les données à la main après restauration.
• La sauvegarde post-incident n’est pas une sauvegarde périodique. Prendre une image après la correction d’un incident avec la procédure quotidienne fait tourner les versions et raccourcit la profondeur au moment précis où elle est la plus précieuse. Elle se prend par une procédure spécifique.
• La rétention a un plafond légal. Au-delà de sa durée de rétention, une sauvegarde est détruite, pour des raisons de confidentialité. Et la conservation de données personnelles dans les sauvegardes doit rester compatible avec les durées déclarées au registre des traitements. Une rétention de cinq ans se justifie ; elle ne se décrète pas.

Étape 6 — Protéger la sauvegarde elle-même

L’épisode 016 a détaillé l’immuabilité, l’isolement et la restauration en environnement sain. On n’y revient que pour ce qui relève de la stratégie, c’est-à-dire de la décision.

La stratégie doit trancher quatre questions, que l’architecture seule ne résout pas :

1. Qui peut supprimer une sauvegarde ? Si la réponse inclut un compte de l’annuaire de production, la sauvegarde tombera avec lui. L’ANSSI recommande des serveurs de sauvegarde hors du domaine de production et des comptes d’administration nominatifs et dédiés.
2. Où sont les clés ? Des sauvegardes chiffrées dont les clés résident dans l’infrastructure de sauvegarde deviennent illisibles quand cette infrastructure est perdue. Les clés se gèrent à part, et se sauvegardent elles aussi.
3. Que faut-il pour reconstruire ? Restaurer des données sur un système qui n’existe plus ne sert à rien. Images de référence, configurations, code d’infrastructure, secrets, documentation d’exploitation : tout ce qui permet de reconstruire doit être sauvegardé et isolé au même titre que les données.
4. Dans quel ordre repart-on ? L’ANSSI demande qu’un ordre de restauration soit défini à l’avance. Le modèle en propose un : l’infrastructure de sauvegarde et un poste d’administration sain d’abord, puis l’annuaire, le DNS et la PKI, les systèmes et hyperviseurs, les services transverses, les outils de pilotage de l’incident, et enfin les données métier selon les dépendances enregistrées dans la CMDB.

Étape 7 — Prouver avant d’en avoir besoin

Une sauvegarde non testée est une hypothèse. La stratégie organise la preuve à trois cadences.

Au quotidien, des procédures « témoin » sauvegardent un échantillon représentatif de tous les types de données, le restaurent dans un espace de validation et le comparent à l’original. Un écart rend suspectes toutes les sauvegardes réalisées depuis le dernier témoin conforme.

Chaque année, deux niveaux d’épreuve se complètent. Des tests techniques éprouvent chaque scénario : bascule de site, restauration depuis les seules copies isolées, reconstruction de l’annuaire et d’une application critique. Et un exercice majeur, avec les métiers, change de scénario d’une année sur l’autre : bascule de site, restauration massive, cyber-reconstruction, exercice de crise sur table pour le scénario extrême. Compte tenu de la menace, le volet cyber-reconstruction ne devrait pas attendre son tour plus d’un an sur deux.

ISO 22301 (§ 8.5) ajoute trois exigences que l’on oublie volontiers : des objectifs et des critères de réussite fixés avant l’exercice, un rapport formalisé après, et un exercice supplémentaire lorsque le système d’information change de façon significative.

En continu, deux critères de tri simples tiennent en pratique :

• un traitement de sauvegarde prévu et non exécuté est un incident, qui ouvre un ticket comme les autres. Sans cette règle, les échecs silencieux s’accumulent jusqu’au jour où l’on découvre que la dernière sauvegarde exploitable date de trois semaines ;
• seuls les métiers valident le résultat d’un exercice. L’équipe qui restaure ne certifie pas sa propre restauration.

Le règlement 2024/2690 formule la même exigence en termes juridiques : tester régulièrement la restauration des copies, pour s’assurer qu’elles couvrent « les copies, les processus et les connaissances » nécessaires, documenter les résultats et corriger. Le mot important est le deuxième : un processus que personne n’a exécuté depuis deux ans n’existe que sur le papier.

Étape 8 — Gouverner et mesurer

La gouvernance vient en huitième position dans l’exposé ; elle vient en premier dans la mise en œuvre. Sans propriétaire nommé, la stratégie n’est pas appliquée ; sans comité, elle n’évolue pas ; sans indicateur, on ne sait pas si elle est respectée.

Le modèle définit dix rôles, des propriétaires métier à l’administrateur de sauvegardes, avec une matrice de responsabilités par activité. Les métiers y figurent en propre : ce sont eux qui valident les engagements, financent les offres spécifiques et certifient les exercices. Une matrice qui les omet décrit une stratégie de la DSI pour la DSI. Il organise une comitologie à trois niveaux, raccordée de préférence aux instances existantes plutôt qu’ajoutée à elles :

Il inclut enfin une matrice des risques propres à la stratégie elle-même. Les plus élevés ne sont pas techniques : retard de validation, défaut de suivi des incidents de sauvegarde, sécurisation pilotée par la technique plutôt que par le besoin. C’est une information utile à donner au comité de direction avant qu’il n’approuve le document.

La direction a d’ailleurs une décision qui lui revient en propre : le sinistre total, perte simultanée de toutes les données et de toutes leurs copies, est exclu du périmètre. Cette exclusion n’est pas une commodité de rédaction ; c’est une acceptation de risque, qui doit être formellement validée à ce niveau et revue chaque année.

Dernier point, que les audits relèvent souvent : la stratégie et les procédures de restauration doivent rester lisibles sans le système d’information. Une procédure de reconstruction rangée sur l’espace documentaire qui vient d’être chiffré n’existe plus au moment où l’on en a besoin. Une copie isolée, et une copie papier des procédures critiques, règlent la question.

4. Le modèle mis à disposition

D’où il vient

Le modèle est tiré d’une stratégie de sauvegarde, de restauration et de reconstruction que j’ai conçue en poste. Le document d’origine a été entièrement réécrit en marque blanche : aucun nom d’organisation, de site, de prestataire, d’outil interne ou de personne ; aucune architecture réelle ; aucun paramètre propre à l’organisation d’origine. Les valeurs chiffrées qui subsistent sont des valeurs d’illustration, signalées comme telles, et le schéma de rétention reprend l’exemple public de l’ANSSI.

La réécriture a aussi été l’occasion d’une mise à jour. Le document d’origine précédait plusieurs évolutions de la menace et des textes ; le modèle y ajoute la distinction entre dernière sauvegarde réussie et dernière sauvegarde saine, la règle 3-2-1-1-0 et la séparation des privilèges d’administration, l’environnement de restauration sain, la reconstruction des socles, les données hébergées en SaaS et en cloud public, une table de correspondance avec ISO 22301, ISO 27001, le NIST CSF 2.0, NIS 2, DORA et le RGPD, la place des métiers dans la gouvernance, le raccordement à la cellule de crise, des classes de criticité issues de l’analyse d’impact et la disponibilité de la documentation hors du système d’information. Ces ajouts sont signalés dans le texte.

Sa structure

Comment l’utiliser

Le document emploie trois types de marqueurs : {{…}} pour les éléments propres à l’organisation (nom, sites, prestataires, instances), [À VALIDER] pour une valeur par défaut raisonnable à confirmer avec les métiers, [À COMPLÉTER] pour un contenu à produire. L’annexe E recense vingt éléments à produire ou à arbitrer, avec un porteur suggéré pour chacun.

L’ordre d’adaptation compte davantage que la vitesse :

1. partir de l’analyse d’impact existante, ou la conduire si elle manque, et cartographier les sites, les environnements et les prestataires ;
2. faire valider par les métiers les engagements de PDMA et de DMIA, socle de tout le reste ;
3. nommer les titulaires des rôles et raccorder la comitologie aux instances existantes ;
4. produire le plan de sauvegarde détaillé à partir de l’existant, puis mesurer l’écart ;
5. construire la table de correspondance avec la PSSI.

Le modèle ne contient ni procédures opérationnelles ni choix d’outil. C’est voulu : ces deux éléments relèvent des équipes d’exploitation, à partir de l’analyse d’écart entre l’existant et la stratégie. Un document qui mélange la règle et son exécution devient obsolète à chaque changement d’outil.

Il est proposé en deux formats, à télécharger en tête de cette page : un fichier Word à modifier, un PDF à consulter. Il est publié sous licence Creative Commons Attribution – Pas d’utilisation commerciale – Partage dans les mêmes conditions : vous pouvez le copier, l’adapter et le diffuser, en citant la source, sans usage commercial, et en conservant la même licence.

L’Essentiel pour Agir

1. Vérifier l’étage manquant — cherchez, dans votre documentation, le document qui relie la politique de sauvegarde au plan de sauvegarde. S’il n’existe pas, le plan a été écrit par l’outil.
2. Poser la question du scénario logique global — demandez quelle PDMA et quelle DMIA sont tenables si toutes les données primaires sont chiffrées cette nuit, sauvegardes principales comprises. Faites distinguer la dernière sauvegarde réussie de la dernière sauvegarde saine.
3. Faire fixer les seuils par ceux qui subissent — adossez les engagements à l’analyse d’impact, faites-les valider par les responsables métier, et écrivez noir sur blanc que la durée de leur décision sort de l’engagement de la DSI.
4. Instaurer l’offre par défaut — aucune donnée hors offre, et toute exigence supérieure financée par le métier qui la demande.
5. Traiter chaque sauvegarde non exécutée comme un incident — c’est la règle la moins coûteuse du modèle et l’une des plus efficaces.
6. Sortir les clés et les moyens de reconstruction de l’infrastructure de sauvegarde — clés, images de référence, configurations et procédures doivent survivre à la perte de cette infrastructure, et rester lisibles sans le système d’information.
7. Partir du modèle plutôt que d’une page blanche — téléchargez-le, suivez l’ordre d’adaptation de l’annexe E, et commencez par la validation des engagements.

Conclusion

Une stratégie de sauvegarde n’est pas un document technique. C’est un contrat entre ceux qui subissent l’interruption, ceux qui l’évitent et ceux qui en répondent, écrit avant que la question ne se pose sous la contrainte. Les outils ont fait des progrès considérables ; la plupart des échecs de restauration relèvent désormais de décisions qui n’ont pas été prises.

La méthode proposée ici n’a rien de révolutionnaire. Elle impose un ordre : le vocabulaire avant les engagements, les engagements avant les moyens, la preuve avant l’incident, la gouvernance avant tout. Le modèle qui l’accompagne n’est pas une solution clé en main. C’est un point de départ qui évite de redécouvrir, chapitre après chapitre, ce que d’autres ont déjà appris.

Le jour où il faudra restaurer, personne ne demandera si la stratégie était bien rédigée. On demandera à quelle heure les données reviennent, et dans quel état. Une bonne stratégie est celle qui permet de répondre à cette question la veille.

Bibliographie

Liens consultés le 26 septembre 2026.

ANSSI — Sauvegarde des systèmes d’information : les fondamentaux (ANSSI-BP-100, version 1.1, 27 novembre 2025)

https://messervices.cyber.gouv.fr/guides/sauvegarde-des-systemes-dinformation

Guide de référence en français : architecture, opérations, protection des données, virtualisation et externalisation des sauvegardes. Source de la définition « hors ligne » du 3-2-1, de l’exemple de rétention et de l’exigence d’un ordre de restauration.

Règlement d’exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 — annexe, section 4.2

https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AL_202402690

Modalités techniques et méthodologiques de NIS 2 pour certaines entités numériques. La section « Gestion des sauvegardes et des redondances » est la liste d’exigences la plus précise publiée par un texte européen. Citations traduites de la version anglaise.

Règlement (UE) 2022/2554 (DORA) — article 12

https://eur-lex.europa.eu/eli/reg/2022/2554/oj

Politiques et procédures de sauvegarde, procédures et méthodes de restauration et de rétablissement, pour les entités financières.

Directive (UE) 2022/2555 (NIS 2) — article 21

https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Mesures de gestion des risques, dont la continuité des activités et la gestion des sauvegardes (§ 2 c).

ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements

https://www.iso.org/standard/75106.html

Norme d’exigences du système de management de la continuité d’activité. Deuxième édition, octobre 2019, en cours de révision à la date de rédaction.

ISO/TS 22317:2021 — Guidelines for business impact analysis

https://www.iso.org/standard/79000.html

Spécification technique consacrée à la conduite de l’analyse d’impact sur l’activité.

Club de la Continuité d’Activité — Lexique structuré de la continuité d’activité (version 3, décembre 2012)

https://www.eptb-loire.fr/wp-content/uploads/2017/02/CCA_Lexique_Structure_CA.pdf

Référence de vocabulaire francophone. Rattache la DMIA à la durée d’interruption tolérable et la distingue du délai de reprise (RTO) ; document ancien, cité pour la terminologie.

ISO/IEC 27031:2025 — Information and communication technology readiness for business continuity

https://www.iso.org/standard/27031

Deuxième édition, mai 2025, qui remplace l’édition de 2011. Préparation des TIC à la continuité, y compris la dépendance aux services tiers.

NIST — Cybersecurity Framework 2.0, sous-catégorie PR.DS-11

https://csf.tools/reference/nist-cybersecurity-framework/v2-0/pr/pr-ds/pr-ds-11/

Résultat attendu et exemples de mise en œuvre : test annuel de restauration de tous les types de sources, copies hors ligne et hors site.

CISA — #StopRansomware Guide (septembre 2023)

https://www.cisa.gov/stopransomware/ransomware-guide

Recommandations sur les sauvegardes hors ligne et chiffrées, les images de référence et la conservation hors ligne des modèles d’infrastructure.

Sophos — The State of Ransomware 2025

https://www.sophos.com/en-us/press/press-releases/2025/06/nearly-half-companies-opt-pay-ransom-sophos-report-finds

Enquête auprès de 3 400 responsables informatiques et cybersécurité de 17 pays, conduite de janvier à mars 2025. Source de la part des organisations ayant restauré leurs données grâce aux sauvegardes (54 %).

Sophos — The impact of compromised backups on ransomware outcomes (2024)

https://www.sophos.com/en-us/blog/the-impact-of-compromised-backups-on-ransomware-outcomes

Analyse de 2 974 réponses recueillies début 2024 : tentatives et réussite de compromission des sauvegardes, effet sur le paiement de la rançon et sur le coût de reprise.