Présentation du MTCR : l’indicateur manquant pour la cyber-Recovery

Le MTCR mesure le temps nécessaire pour restaurer les systèmes et les données de manière « propre » – c’est-à-dire sans logiciel malveillant, sans corruption ni persistance – après une cyberattaque. 

Le RTO et le RPO mesurent respectivement le temps et la perte de données. Le MTCR, quant à lui, mesure la confiance. Une Recovery rapide n’a aucun sens si les menaces persistent. 

Elle nécessite de vérifier les sauvegardes, de rechercher les menaces cachées et de valider les charges de travail restaurées – ce qui est bien plus complexe qu’un simple basculement. 

Les attaquants corrompent de plus en plus souvent les sauvegardes et dissimulent leur présence, ce qui fait de l’identification des données saines la phase la plus longue de la Recovery. 

Il fournit aux dirigeants un indicateur réaliste de la qualité de la Recovery, ce qui permet des investissements et une préparation plus judicieux. 

Veuillez visionner la vidéo ici pour obtenir une transcription horodatée

Bienvenue à notre discussion sur une nouvelle façon d’envisager la cyber-résilience : le « Mean Time to Clean
Recovery » (MTCR).

Je suis accompagné de deux experts à l’origine de ce concept de MTCR : Darren Thomson, directeur technique sur le terrain chez
Commvault, qui travaille en étroite collaboration avec des organisations de tous les secteurs sur les stratégies de résilience et

stratégies, et Duncan Bradley, responsable de la pratique Sécurité et résilience pour le Royaume-Uni et l’Irlande chez Kyndryl
. Ils sont les auteurs du document de réflexion original sur le MTCR. Et

depuis des années, les entreprises évaluent le succès de la Recovery en fonction de la rapidité avec laquelle les systèmes peuvent être
restaurés.

Nous utilisons des acronymes tels que RTO et RPO : RTO (objectif de temps de reprise) et RPO (objectif de point
de reprise).

Mais dans le paysage actuel des menaces, nous savons que la rapidité à elle seule n’est pas synonyme de sécurité et ne garantit
pas le succès de Recovery.

Si les données que vous restaurez ne sont pas saines et fiables, vous risquez de transformer votre Recovery en
une nouvelle attaque.

Bonjour.

Je m’appelle Danielle Sheer, directrice de la confiance chez Commvault.

Je consacre une grande partie de mon temps à aider les conseils d’administration et les dirigeants à comprendre que le risque cybernétique va
de pair avec le risque métier.

Je suis ravie d’animer la discussion d’aujourd’hui et d’expliquer pourquoi ce nouveau concept, le MTCR,
n’est pas simplement un indicateur technique de plus, mais la norme métier qui a désormais sa place dans la

salle du conseil d’administration.

C’est parti.

Oui, merci Danielle.

Et merci pour cette excellente introduction.

En cette année 2025, au Royaume-Uni en particulier, mais aussi partout dans le monde,
notamment en Europe, nous avons assisté à une série d’attaques ciblées contre le secteur de la distribution.

Et nous avons pu constater de nos propres yeux à quel point il a été difficile pour ces commerçants de rester en
contact avec leurs clients et, surtout, de remettre leurs systèmes sur pied.

Cette année, j’ai été personnellement impliqué dans une attaque particulière qui a débuté vers la mi-avril
2025.

Et juste pour vous donner une petite idée du calendrier qu’a suivi cette entreprise
pour se remettre sur pied.

Au mois d’avril, il s’agissait essentiellement d’un incident lié à un rançongiciel.

Et pendant cette période, l’entreprise a fait un excellent travail pour, sinon mettre fin à cet
incident, du moins l’isoler et enrayer sa propagation.

Au cours du mois de mai, elle s’est attachée à confirmer la nature et l’ampleur de l’attaque, ce que
j’appelle son « rayon d’action ».

Et elle a commencé à communiquer à ce sujet.

Puis, de mai jusqu’au début du mois d’août, s’est déroulée la Recovery effective des systèmes.

En d’autres termes, cela a pris près de trois mois, jusqu’au mois d’août, puis il
n’y a eu qu’une reprise par étapes, une sorte d’approche progressive pour remettre les systèmes en service.

Alors pourquoi tout ce temps, vous savez, trois mois, pour remettre cette entreprise en
ligne ?

Eh bien, une grande partie de ce temps a été consacrée à la recherche des bonnes données, des données « propres ».

Des systèmes fiables sur lesquels l’entreprise pouvait compter pour renouer le contact avec ses
clients et générer à nouveau des revenus en tant que détaillant.

Et c’est justement cette période de trois mois qui illustre ce dont nous voulons parler
ici.

L’entreprise doit commencer à poser un autre type de questions au service
informatique afin d’en arriver à un stade où l’on puisse non seulement s’engager sur la rapidité avec laquelle

restaurer les systèmes,

mais aussi de s’engager sur la qualité de ces systèmes, c’est-à-dire sur leur « propreté
».

Sinon, je crains que nous continuions à constater qu’il faut généralement deux, trois,
voire parfois quatre ou cinq mois pour remettre les systèmes en ligne.

Vous savez, d’accord, c’est fascinant.

Vous nous avez donné matière à réflexion.

Duncan, permettez-moi maintenant de revenir au début.

Pouvez-vous nous donner la définition du MTCR ?

Expliquez-nous les cinq piliers et pourquoi c’est la bonne approche pour nous, dans ce
contexte, ce paysage de menaces, pour mesurer le succès de Recovery.

Oui, bien sûr, Danielle.

Je pense que c’est vraiment important.

Nous avons imaginé le concept de « Mean Time to Clean Recovery » (temps moyen de retour à la normale) afin d’en faire un indicateur
métier compréhensible pour l’entreprise.

Il s’agit du temps nécessaire pour que les systèmes soient à nouveau opérationnels, comme le disait Darren.

Avec des données intactes, et des systèmes capables de fonctionner et de reprendre leur activité.

La plupart des organisations se sont vraiment concentrées sur la disponibilité de leurs systèmes en ligne
sans comprendre que ces cyberattaques détruisent les données et les plateformes

qui sous-tendent ces opérations.

Ainsi, en cas de cyberincident nécessitant une reprise, il s’agit davantage de tout rétablir
depuis le premier jour jusqu’au point de Recovery,

environnement sain.

Cela prend souvent plusieurs jours, comme l’expliquait Darren dans son exemple du commerce de détail.

Il faut ensuite reconstruire tous vos services fondamentaux.

Il faut ensuite remettre vos plateformes en ligne, puis y restaurer des données
saines.

Et très souvent, avec les types d’attaques que nous observons, les données sont contaminées pendant
des jours, voire des semaines, avant l’attaque.

Vous devez donc examiner vos sauvegardes et réintégrer ces données saines dans l’environnement de production.

Ce MTCR (Mean Time to Clean Recovery, temps moyen de Recovery propre) est censé être un indicateur métier permettant de se poser la question suivante :

« Combien de temps pouvez-vous rester hors service ? »

Combien de temps seriez-vous hors service aujourd’hui si cet incident se produisait ?

Ce paramètre sert ensuite à inciter les services informatiques et de contrôle de la continuité à réduire ce délai
de Recovery.

En quoi le MTCR diffère-t-il des indicateurs traditionnels ?

On dirait qu’il regroupe en quelque sorte plusieurs mesures traditionnelles en une seule mesure plus globale.

Eh bien, je pense que c’est là qu’interviennent les objectifs de délai de reprise.

Combien de temps faut-il pour remettre ce système en ligne ?

Cela ne tient pas compte du type de données présentes sur cette plateforme.

Vous savez, on utilise généralement la disponibilité comme critère.

Combien de temps faut-il pour basculer du centre de données A vers le centre de données B, et comment réagir face à une
attaque traditionnelle contre l’infrastructure ?

La récupération des données est une opération bien plus complexe.

Il ne s’agit pas simplement de récupérer un ensemble de données.

Il s’agit de remettre la plateforme en ligne.

Ainsi, si l’on prend l’exemple des services d’identité, l’identité doit fonctionner avant que quiconque puisse
accéder aux données.

Le simple fait de mesurer le temps nécessaire pour remettre une base de données en service

ne signifie pas pour autant que ce processus métier sera à nouveau opérationnel.

Et ce système est vraiment conçu pour regrouper les différents piliers de ces systèmes que vous
devez remettre en ligne pour que le processus métier puisse fonctionner.

Et Danielle, si je peux me permettre, je pense que cela renvoie à un problème plus large.

Il est donc très facile de… euh… s’engager dans une discussion purement technique à ce sujet.

Et en effet, cela constitue à bien des égards un moyen d’évaluer l’organisation technique.

Mais je pense que cela renvoie à un problème organisationnel.

Ce que nous constatons sans cesse, c’est que l’un des problèmes culturels liés à la remise
en service des systèmes, et l’une des raisons pour lesquelles cela prend tant de temps dans de nombreux cas, comme ce fut le cas dans mon

exemple, c’est qu’en réalité, deux équipes doivent assumer une
part de responsabilité dans ce domaine.

Il y a bien sûr l’équipe d’infrastructure traditionnelle, celle dont les membres sont chargés
de Backup and Recovery ; ils ont clairement un rôle à jouer, mais ils ne sont plus les seuls.

Il y a également l’équipe de sécurité.

Une équipe capable de vous indiquer, grâce à l’analyse forensic par exemple, où se trouve la sauvegarde intacte, où se trouvent les
données intactes, dans quel état se trouvent les systèmes infectés : voilà ce qu’est une équipe de sécurité.

Ainsi, lorsque ces équipes ne collaborent pas sur Recovery, ou qu’elles parlent des langues différentes
, ou encore qu’elles n’utilisent pas les mêmes critères d’évaluation, un problème commence à se poser

et cela commence par la culture d’entreprise.

Une façon d’aborder cela consiste à comparer le RPO (objectif de temps de récupération)

Combien de temps cela va-t-il me prendre pour récupérer mes données ?

L’objectif de point de reprise (RPO) : de quelle quantité de données vais-je probablement avoir besoin ?

Et en combinant cela avec le domaine de la criminalistique, une discipline de la sécurité.

On obtient alors le MTCR.

Le « C » est donc essentiel.

La qualité de ces données est vraiment, vraiment cruciale.

Et le point de départ, dont nous discuterons sans doute, consiste simplement à laisser l’entreprise se poser
cette question.

« Combien de temps nous faut-il pour remettre nos systèmes en état ? »

Et ce que nous constatons chaque jour, c’est que cette question n’est pas si difficile à poser, mais qu’il
est très difficile d’y répondre, en particulier lorsqu’il existe un fossé culturel entre

les équipes de sécurité et d’infrastructure.

Je pense sincèrement que c’est là que réside tout le génie du MTCR : vous prenez un certain nombre de concepts très
techniques sur lesquels les équipes informatiques et de sécurité se mesurent, et vous les transformez en

un sujet dont on peut discuter avec les PDG et les conseils d’administration.

Pour reprendre votre exemple, Darren, celui d’un détaillant qui, à Noël, a été victime d’une cyberattaque
, comment utiliseriez-vous le MTCR si vous vous présentiez devant un conseil d’administration pour

expliquer ce qui s’est passé et comment se déroule le processus de Recovery ?

Eh bien, je vais commencer à répondre, puis je passerai la parole à Duncan pour qu’il
conclue, car une partie de ce document, dont Duncan était en grande partie responsable, concerne justement

le regroupement

des actifs qui se combinent pour former un service.

Mais je commencerai par dire qu’il y a quelques discussions qui doivent avoir lieu et qui, très
souvent, ne le sont pas.

L’une d’elles porte sur l’appétit pour le risque.

Alors, qui sommes-nous en tant qu’entreprise ?

De quel type d’entreprise s’agit-il ?

Un détaillant présente généralement une propension au risque faible à moyenne, quelque
part dans cette fourchette.

Mais cela doit être clairement défini afin que, par la suite, à mesure que nous commençons à comprendre les
risques qui nous entourent, nous puissions décider de ce qui est acceptable et de ce qui

devrait être pris en charge par notre assurance, par exemple, et ce qui doit absolument être
intégré.

Voilà donc le premier point à aborder.

La deuxième discussion porte ensuite sur la question suivante : quelle est la « société minimale viable » dans ce contexte ?

Il est tout à fait irréaliste de supposer qu’une organisation, quel que soit son budget, sera
capable de tout remettre sur pied rapidement.

Alors, qu’est-ce qui compte vraiment dans cette activité ?

C’est une discussion très, très approfondie et intéressante à avoir avec la plupart des entreprises.

La plupart des entreprises ne peuvent pas imaginer un monde sans informatique.

Elles ont donc beaucoup de mal à décortiquer leurs processus métier et à se demander à
quoi cela ressemblerait si l’on revenait au papier.

Mais cette réflexion doit avoir lieu.

Et cela nous amène à ce que nous appelons un MVC, une entreprise minimale viable.

C’est-à-dire : quels éléments étaient indispensables à l’époque, quelle que soit la période que nous
choisissons.

Quels sont les éléments sans lesquels cette entreprise ne fonctionnerait pas du tout, sans lesquels nous ne serions pas opérationnels ?

Et c’est une discussion très, très importante.

Ce que vous pouvez ensuite commencer à faire, c’est appliquer le concept du MTCR à l’entreprise minimale viable.

Je vais maintenant donner la parole à Duncan, qui pourra nous expliquer en quoi consiste un service.

Comment aborder cette question dans le contexte des services ?

Merci, Darren.

Et encore une fois, sans chercher à compliquer ni à approfondir trop les choses.

Le MTCR revient à mesurer le temps moyen de Recovery après une panne d’un processus métier,

un service métier critique qui, à son tour, contribue à la viabilité minimale globale de l’entreprise.

Il y aura donc plusieurs MTCR différents selon les processus métier.

Je discutais justement aujourd’hui avec une entreprise de biens de consommation courante, un brasseur, et
ils m’expliquaient que s’ils perdaient l’équivalent de quatre jours de données, ils devaient littéralement jeter

quatre jours de production de bière à l’égout, car ils ne peuvent pas prouver qu’elle est propre à la consommation et
ne peuvent donc pas la vendre.

Ce concept consiste donc à décortiquer ces processus métier, puis à utiliser ce
MTCR comme langage métier commun pour pouvoir ensuite dire : « Bon, au sein de mon processus, j’ai besoin

puis de constater : « Oh, ce processus repose sur plusieurs types d’applications différentes. »

Elles reposent toutes sur des services fondamentaux, tels que l’identité ou la possibilité pour les
clients de se connecter à la plateforme.

Vous disposez ensuite de vos systèmes backend, qu’ils soient dans le cloud ou sur site, de vos hyperviseurs,
de vos solutions cloud critiques.

Vos systèmes frontaux qui exécutent les applications proprement dites, puis vos systèmes
d’accès utilisateur : comment les utilisateurs accèdent-ils réellement à cette solution ? Est-ce via des PDA, des terminaux de point de vente

, etc. ?

Tous ces éléments doivent être disponibles pour que ce service métier puisse fonctionner.

Le MTCR est conçu pour que le chef d’entreprise en soit responsable.

La première étape de ce parcours consiste à réaliser une analyse comparative.

Quel est leur MTCR actuel ?

Combien de temps cela leur prendrait-il actuellement, même s’ils parvenaient à récupérer des données intactes ?

Car ce qui est choquant à l’heure actuelle, c’est que la plupart des organisations ne disposent
pas de la technologie nécessaire pour protéger leurs sauvegardes et être en mesure d’interroger

leurs sauvegardes pour en extraire des données saines, ce qui constitue le véritable problème métier que nous sommes là
pour résoudre.

C’est très intéressant.

Vous avez demandé : « Quel est le MTCR actuel ? »

Le MTCR n’est donc pas une mesure prise à la fin pour évaluer la qualité de notre récupération.

Le MTCR est mesuré à intervalles réguliers tout au long de l’attaque.

Et c’est probablement parce que

si l’on se précipite pour effectuer une Recovery, on risque en fait de causer davantage de dégâts.

Pouvez-vous nous en dire un peu plus à ce sujet ?

Oui, je peux tout à fait aborder ce sujet.

Mais avant cela, tu as soulevé un point vraiment intéressant,
qui mérite selon moi d’être approfondi.

Le MTCR n’est donc pas seulement un indicateur que l’on mesure tout au long de la Recovery après une attaque.

C’est quelque chose que l’on devrait mesurer avant même la violation.

C’est ce que j’appelle en quelque sorte « avant le coup ».

Lorsque nous présentons ce concept aux conseils d’administration, nous voyons cette idée se répandre
dans toute l’organisation.

Et la question se pose : qu’est-ce que le MTCR, par exemple, pour notre entreprise minimalement viable ?

On nous donne alors des réponses que l’on ne souhaite pas entendre, comme le fait que l’on ne sait pas ce qu’est une entreprise minimalement viable
.

Ou même si nous le savons, de manière réaliste, notre MTCR est probablement de quatre mois à l’heure actuelle.

Nous ne voulons pas entendre ces réponses, mais nous devons les entendre afin de pouvoir nous concentrer
sur l’amélioration.

Et c’est donc un point vraiment, vraiment important, je pense.

Et Darren, pour aller plus loin, je pense qu’il est essentiel pour l’entreprise de comprendre quel
est son délai de mise en place d’une entreprise minimale viable (MTCR) aujourd’hui, car cela permet ensuite d’orienter correctement son processus de gestion des risques.

Et ce n’est pas toujours une solution technologique qui permettra de réduire ce délai de mise en place d’un produit minimal viable (MTCR).

Très souvent, si l’entreprise sait qu’elle court le risque de se retrouver sans système
critique pendant

une certaine période, elle peut mettre en place un plan de continuité d’activité alternatif,
revenir au papier… Tu sais, c’est peut-être le pire des cas, Darren, mais, tu sais, à l’heure actuelle,

les entreprises ne comprennent pas les risques qu’elles couvrent.

Et ce MTCR est censé permettre au conseil d’administration de s’adresser au RSSI et à ses équipes
pour leur demander : « Combien de temps, de manière réaliste, le système sera-t-il hors service aujourd’hui ? »

Et ensuite, si ce chiffre est acceptable – j’ai mené plusieurs études de ce type
et on constate souvent…

souvent 28, 35 ou 42 jours.

L’entreprise est alors complètement horrifiée à l’idée de se retrouver sans services informatiques pendant tout
ce temps.

Mais elle n’a jamais imposé ces exigences au DSI ou au RSSI en leur disant : « Nous avons besoin que le
fonctionnement minimal de l’entreprise soit assuré, que ces ressources soient remises en ligne dans les 24 heures. »

Comment concevoir ces processus métier pour qu’ils soient rétablis en moins de 24 heures ?

Cela doit faire partie des exigences fonctionnelles ou non fonctionnelles de l’entreprise pour pouvoir dire : « Voici
nos exigences.

« Services informatiques, RSSI, pouvez-vous m’aider à les respecter ? »

Et pour revenir au point que j’ai soulevé plus tôt, d’ailleurs, hum, il est vraiment important de
comprendre que, d’une certaine manière, cette question ne peut même pas être posée à l’une ou l’autre de ces

équipes.

La seule façon d’obtenir une réponse qui ait du sens, même si
ce n’est pas celle que vous souhaitez, c’est que l’équipe chargée de l’infrastructure et l’équipe de sécurité

soient présentes pour y répondre.

Car aucune de ces équipes ne peut répondre seule à cette question.

Et cela, encore une fois, d’un point de vue culturel, est extrêmement important avant même d’aborder la question de
la technologie.

D’un point de vue culturel, ce que nous essayons de faire ici avec ce concept, c’est d’encourager un
comportement qui n’existe pas aujourd’hui.

C’est exact.

Vous essayez de briser les cloisonnements.

Ainsi, chaque organisation, qu’il s’agisse de l’équipe informatique, de l’équipe chargée de l’infrastructure ou de l’équipe SecOps, se dit : « Ma
partie fonctionne bien », mais toutes ces parties doivent travailler ensemble.

C’est pourquoi le MTCR les rassemble et les amène à réfléchir à ce

concept de risque dans l’environnement, car chacun a un rôle à jouer à cet égard.

Et puis je pense que c’est vraiment transformateur dans la mesure où cela donne à chacun de ces
responsables la capacité de se faire comprendre par un PDG ou un conseil d’administration et d’expliquer ce

ce qu’ils vivent réellement en termes de reprise et de risques d’entreprise, n’est-ce pas ?

Tout à fait, c’est génial.

Alors, quel est le lien avec les exigences simples ?

Ce n’est pas si simple, mais des exigences de conformité comme la DORA et la norme NIST 2.

Comment le MTCR s’inscrit-il dans ce cadre, le cas échéant ?

Eh bien, je vais commencer si ça te va, Duncan.

Voici donc ma réflexion initiale à ce sujet : tu sais, Danielle, toi et moi avons tous les deux parcouru
ces articles de la DORA à de nombreuses reprises ensemble et avons discuté de conformité.

L’une des tendances que l’on commence à observer dans le paysage de la conformité, qu’il s’agisse
de la DORA, de la norme NIST 2 ou d’autres réglementations mondiales, c’est d’une part cette notion de

résilience et ce qu’elle signifie par opposition à la sécurité, et d’autre part, les tests.

Avez-vous un plan ?

Avez-vous testé le plan de Recovery ?

Eh bien, je pense que cela renvoie directement à ce qui devrait servir de critère d’évaluation du plan.

Je crains un peu que bon nombre des réglementations que je constate, même les plus récentes
et celles en pleine évolution, fassent encore référence à des concepts tels que la reprise après sinistre.

Elles ne précisent toujours pas clairement ce qui doit être testé.

J’ai même vu quelques mentions de RPO-RTO.

Et donc, dans une certaine mesure, vous savez, c’est un concept important à mesure que les gens
commencent à se mettre en conformité et à adopter ce type de conformité qui repose fortement sur la résilience

.

en termes de ce que nous allons mesurer ici ?

Car si nous nous contentons de mesurer les anciens indicateurs de reprise après sinistre, nous n’avancerons
pas vraiment beaucoup.

Ce qui va se passer, c’est que nous serons attaqués, nous passerons à notre plan de reprise après sinistre, nous l’exécuterons,
et surprise, surprise, nous ne trouverons pas notre sauvegarde intacte, et il nous faudra 30, 40, 50, 60

jours pour nous remettre sur pied.

Nous devons donc changer de mentalité.

Et en ce qui concerne la conformité, c’était très rafraîchissant de voir que certaines des nouvelles politiques et certains des nouveaux calendriers de conformité

mentionnaient la résilience, la reprise et les tests, mais nous devons veiller à les aborder
de la bonne manière, avec les cadres et les contextes appropriés.

Oui, je suis tout à fait d’accord, Darren.

Réfléchis : si tu examines bon nombre des exigences de la directive DORA et ce que la Banque centrale européenne
a déclaré au sujet des tests de résistance, la plupart des organisations se sont mises en situation d’

échouer, car il est stipulé qu’il faut prouver que l’on est capable de se rétablir dans les limites de sa tolérance à l’impact
métier.

Et la plupart des organisations se basent sur cette tolérance aux impacts métier

sur des indicateurs de disponibilité ou sur l’ancien plan de reprise après sinistre qui stipule qu’on peut basculer du centre de données A vers
le centre de données B en quatre heures.

On ne peut pas remettre en état de fonctionnement toute une banque ou une institution financière entière en quatre heures, c’est
impossible.

Je pense donc – et cela met en évidence la nécessité de ce nouveau vocabulaire du MTCR –
qu’il faut réexaminer cette tolérance opérationnelle, cette tolérance à l’impact opérationnel, pour

la redéfinir en se demandant : « Si je perds mon système central, par exemple mon grand livre,

comment est-ce que je continue à fonctionner ?

Eh bien, je ne peux pas fonctionner.

Je dois donc mettre en place des plans d’urgence pour savoir comment je peux recourir à des sous-processus afin de pouvoir
ensuite revenir en arrière une fois que votre grand livre est de nouveau en ligne, pour reprendre l’exemple financier.

Mais, vous avez évoqué les tests : la plupart des organisations, lorsque je leur ai posé la question « À quand remonte votre dernier test de reprise après sinistre ?
», renvoient à leur plan de reprise après sinistre traditionnel.

Elles ne font pas référence à leur plan de cyber-récupération, car la plupart des organisations n’ont pas encore

entièrement conçu ni mis en œuvre de plan de reprise après cyberincident.

Et il va sans dire que ce MTCR doit être l’un des indicateurs clés de ce plan de Recovery
après cyberincident.

Vous avez défini les scénarios contre lesquels vous allez vous protéger et à partir desquels vous allez vous rétablir.

Et vous disposez ensuite d’une mesure MTCR pour ces différents types d’attaques.

Il est vraiment là pour essayer, comme je le disais, de combler ce fossé entre l’entreprise, l’informatique et le RSSI.

Tu sais, Darren, tu disais qu’il s’agissait de changer la culture d’entreprise, et Duncan, tu venais
justement de mentionner que tant de…

contrats entre, euh, les organisations exigent un délai de reprise, et cela n’a aucun sens.

Cela ne concerne donc pas seulement les équipes techniques, mais aussi les équipes de gestion
des risques d’entreprise et les juristes chargés de la rédaction des contrats, qui doivent comprendre que le RTO et le RPO ne suffisent pas, mais que

la nouvelle norme, c’est une reprise sans faille.

Et tout le monde doit comprendre quel doit être le résultat final, et non pas les étapes
intermédiaires qui

peuvent s’avérer insignifiantes, n’est-ce pas ?

Oui, je pense que c’est un très bon point.

Et je m’attends tout à fait, à mesure que nous avançons avec ce concept et que nous organisons des ateliers sur
la posture de risque souhaitée, dans toutes les entreprises viables et autour du MTCR, à ce que nous

découvrions que, vous savez, peut-être beaucoup plus de personnes que celles qui auraient traditionnellement été
associées à la Recovery devront s’y intéresser et faire entendre leur voix lors de ces

ateliers.

Précisément pour les raisons que tu as mentionnées, Danielle.

Je m’adresse donc aux dirigeants qui nous écoutent :

je vous encourage tous à consulter le rapport complet.

Il s’intitule « Redefining Cyber Recovery, Introducing Mean Time to Clean Recovery » (Redéfinir la cyber-Recovery : présentation du « Mean Time to Clean Recovery »).

Et j’ai une dernière question pour Duncan et Darren : vous avez abordé de
nombreux sujets aujourd’hui.

Vous avez ancré votre propos dans une application concrète pour une entreprise réelle, ce qui est tout à fait pertinent.

À l’intention des dirigeants qui nous écoutent : par où commencer ?

Par où commencer dès maintenant ?

Nous avons lu le rapport et souhaitons mettre en œuvre ce concept dans nos entreprises, dans nos
activités.

Comment s’y prendre ?

Eh bien, en ce qui me concerne, en tant que dirigeant non technique, j’encouragerais l’organisation d’une réunion
entre la personne chargée de la mise en place de l’infrastructure au sein de l’entreprise, généralement le directeur informatique (DSI),

et la personne en charge de la cybersécurité au sein de l’entreprise, généralement le RSSI (si ce n’est pas le cas),
d’organiser une réunion avec ces deux personnes, ces deux dirigeants, et de poser la question suivante : comment

rapidement, si nous devions subir une attaque catastrophique par ransomware – prenons l’exemple du ransomware

à titre d’exemple, car ce phénomène est très répandu et nous sommes tous touchés par les rançongiciels.

Donc, en cas de catastrophe liée à un rançongiciel, en combien de temps pourriez-vous rétablir ensemble l’activité
de l’entreprise et me garantir que les données que je m’apprête à utiliser pour gérer l’

entreprise sont intactes ?

Je vous garantis que cette réunion en entraînera cinq autres, car la
réponse n’est pas simple.

Cela nécessitera une collaboration entre toutes ces équipes.

Cela nécessitera également un changement de mentalité.

Et je pense que je dirais à peu près la même chose, à ceci près que j’élargirais probablement le public
pour inclure dans cette discussion des personnes telles que le directeur des risques et les responsables des achats.

Car la plupart des organisations, qu’il s’agisse d’un contrat SaaS ou
d’un contrat d’externalisation, n’abordent généralement pas cette question de la reprise après sinistre informatique.

Quand puis-je récupérer des données saines lors de Recovery ?

En effet, dans la plupart de ces types de contrats, c’est le client qui est responsable de
ses données.

Ces fournisseurs d’infrastructure et ces fournisseurs SaaS sont responsables de l’infrastructure
qui prend en charge ce service.

Ce sont donc eux qui doivent assumer la responsabilité de récupérer leurs données saines
.

Mais ils doivent ensuite les transmettre assez rapidement à leurs dirigeants pour essayer
de bien comprendre quelle est notre valeur commerciale (MVC), car les organisations, comme vous l’avez dit tout à l’heure,

Darren, ne peuvent tout simplement pas se permettre de restaurer l’intégralité de leurs systèmes d’entreprise
en très peu de temps, et n’en seront jamais capables.

La clé réside ici dans la hiérarchisation des priorités, et seule l’entreprise peut juger de ce qui est le plus important
pour elle en cas de cyber-catastrophe.

Darren, directeur technique chez Commvault, et Duncan, responsable de la pratique Sécurité et résilience chez Kyndryl.

Merci beaucoup.

Prochaines étapes : j’espère que vous allez diffuser ce concept de MTCR et aider les dirigeants
d’entreprise à l’approfondir lors d’ateliers.

Et je suis convaincu que nous commencerons à voir ce concept se généraliser à l’échelle mondiale à mesure que nous aiderons
nos entreprises à définir leur MVC spécifique.

Merci beaucoup de nous avoir accordé votre temps aujourd’hui.

Merci, Danielle.