Les activités d’abord, les systèmes ensuite
Un BIA qui part de l’inventaire applicatif produit une criticité par serveur qu’aucun dirigeant ne peut arbitrer. Un BIA qui part de la chaîne de valeur, les activités qui fabriquent et livrent le produit, puis relie chacune à ses systèmes, données et fournisseurs supports, produit une criticité que le métier reconnaît comme la sienne. Les dépendances sont l’essentiel : un outil de ticketing discret devient critique le jour où le BIA montre que la prise de commande s’arrête sans lui.
Les objectifs qu’il produit
Pour chaque activité, la durée maximale d’interruption admissible, le délai de reprise que le plan de continuité doit tenir, le point de reprise que les sauvegardes doivent respecter, et le niveau de service minimal en mode dégradé. Ces nombres fixent les exigences de continuité et de reprise, mais ils calibrent aussi l’impact dans l’analyse de risque : un scénario de disponibilité sur une activité tolérant quatre heures se note autrement qu’un scénario sur une activité tolérant une semaine.
Dans NIS2 et DORA
La continuité d’activité, la gestion des sauvegardes et la gestion de crise figurent parmi les mesures de gestion des risques de NIS2 ; DORA exige des entités financières qu’elles identifient et classent leurs fonctions métier supportées par les TIC et qu’elles conduisent une analyse d’impact de leur exposition à des perturbations graves, alimentant les plans de réponse et de reprise. Un BIA tenu à jour, par activité et par entité, est ce que les deux cadres supposent existant, et ce que la plupart des groupes ne reconstruisent qu’en audit.