Quelle est la différence entre RTO, RPO et DMTA ?

Les trois valeurs répondent à des questions différentes sur une même interruption :

• La DMTA fixe la limite extérieure. C’est au métier de la définir : combien de temps ce processus peut-il rester à l’arrêt avant que le préjudice pour les clients, les finances, les obligations légales ou la réputation ne devienne inacceptable ?
• Le RTO est l’objectif de remise en service. Il doit se situer à l’intérieur de la DMTA, avec une marge suffisante pour absorber une reprise qui se passe moins bien que prévu.
• Le RPO regarde en arrière, depuis le moment de la panne. Il indique la quantité de données, mesurée en temps, que l’on peut se permettre de perdre et de reconstituer. Un RPO de quatre heures signifie que les sauvegardes ou la réplication ne doivent jamais laisser plus de quatre heures de données exposées.

Le RTO et la DMTA portent sur le délai de reprise, le RPO sur les données. Un processus peut avoir un RTO long et un RPO très court : un grand livre comptable peut attendre une journée avant de revenir, mais ne peut perdre aucune transaction.

Ils découlent d’une analyse d’impact sur l’activité. Pour chaque processus, on décrit ce qui se passe à mesure que l’interruption se prolonge, on repère le moment où l’impact devient inacceptable (la DMTA), puis on fixe le RTO et le RPO à l’intérieur de cette limite. ISO 22301, la norme internationale des systèmes de management de la continuité d’activité, situe ce travail dans son analyse d’impact sur l’activité et son appréciation des risques (article 8.2).

La réglementation demande désormais le même raisonnement :

• DORA (règlement (UE) 2022/2554) impose aux entités financières d’élaborer et de documenter des procédures de sauvegarde, de restauration et de rétablissement (article 12). Pour fixer les objectifs de délai et de point de rétablissement de chaque fonction, elles tiennent compte du fait qu’il s’agit ou non d’une fonction critique ou importante et de l’incidence globale potentielle sur l’efficience du marché (article 12, paragraphe 6).
• NIS2 (directive (UE) 2022/2555) range la continuité des activités, par exemple la gestion des sauvegardes et la reprise des activités, ainsi que la gestion des crises, parmi les mesures de gestion des risques de cybersécurité de l’article 21, paragraphe 2, point c).

Voir à qui s’applique DORA et le champ d’application de NIS2.

• Fixer un RTO plus long que la DMTA, ou égal à celle-ci, de sorte que le moindre retard de reprise dépasse la limite.
• Retenir les valeurs que l’informatique sait tenir plutôt que celles dont le métier a besoin, sans jamais comparer les deux.
• Laisser chaque équipe saisir ses valeurs en texte libre (« au plus vite », « une demi-journée », « 4h »), impossibles à comparer ou à consolider.
• Fixer des objectifs pour les processus mais pas pour les actifs et les fournisseurs dont ils dépendent : un système ou un prestataire plus lent à redémarrer fixe alors, sans le dire, le RTO réel.
• Ne jamais les tester. L’article 11, paragraphe 6, de DORA impose de tester au moins une fois par an les plans de continuité des activités de TIC et les plans de réponse et de rétablissement.

Une liste commune de seuils de temps, identique pour chaque processus et chaque actif, règle le troisième problème et rend les autres visibles.

Dans Acuna GRC, le RTO, le RPO et la DMTA sont des champs de chaque processus et de chaque actif, choisis dans la liste de seuils de temps tenue par votre administrateur. La vue d’ensemble de l’AIA, dans l’espace de travail Operate, liste chaque processus du périmètre de l’AIA avec son évaluation d’impact, son RTO et son premier impact : un processus dont le RTO arrive après son premier impact sérieux saute aux yeux. Les scénarios d’impact décrivent ce qui se passe à mesure que l’interruption se prolonge, chacun avec une gravité et un seuil de temps, et l’analyse des points de défaillance uniques liste les actifs qui soutiennent plusieurs processus critiques.