En avril 2004, la banque centrale européenne tient une table ronde « à portes fermées » selon ses propres termes, à propos de la continuité. Elle en tire une petit document intitulé « Issues paper. Payment Systems Business Continuity. », publié le 10 mai 2005.

L’année suivante, en juin 2006, sort « Business continuity oversight expectations for Systemically Important Payment Systems (SIPS) » qui reprend et étend le document précédemment cité.

Tout en se basant largement sur le travail de la BRI, la BCE critique le fait que le « Core Principle VII » contient des directives de mise en œuvre des dispositions qui couvrent la continuité des activités d’une manière plutôt générique. L’objectif de son document est de fournir des conseils aux opérateurs SIPS (Systemically Important Payment Systems) pour les aider à atteindre des niveaux de résilience suffisamment robustes et cohérents.

La BCE développe quatre éléments clé :

Nous allons passer brièvement en revue ces quatre éléments.

Les systèmes doivent avoir une stratégie bien définie de continuité d’activité et un mécanisme de surveillance approuvés par le conseil d’administration.

Les fonctions critiques, même externalisées, doivent être identifiées et les processus au sein de ces fonctions classés et priorisés en fonction de leur criticité.

Les SIPS devraient chercher à pouvoir récupérer et à reprendre les fonctions ou services essentiels (y compris les services essentiels sous-traités à des fournisseurs tiers) au plus tard deux heures après la survenue d’une perturbation. Dans les cas extrêmes, les objectifs de continuité doivent tendre à la récupération et la reprise des fonctions essentielles au sein du même jour de règlement afin de s’assurer que toutes les transactions en attente soient terminées à la date de règlement prévue dans tous les scénarios envisagés.

Les plans de continuité des activités devraient envisager une variété de scénarios plausibles, y compris les grandes catastrophes naturelles, les pannes et les actes terroristes touchant une large zone. Ces scénarios devraient être documentés régulièrement sous la forme d’un Business Impact Analysis (BIA), qui consiste à évaluer les menaces possibles, leur probabilité d’occurrence et l’impact financier ou opérationnel sur le système. Il est déconseillé de se baser sur le fait qu’une panne puisse n’être que temporaire. Simplicité et praticabilité doivent être les principales considérations lors de la conception des systèmes d’urgence et de la documentation des procédures.

Le Business Impact Analysis (BIA), ou l’évaluation des risques, doit également répondre à deux éléments clés du plan de reprise après désastre (DRP) IT, à savoir le site secondaire, et l’impact de la défaillance de chacun des composants du système de base, des composants des systèmes externes et des services d’infrastructure utilisés.

Il est bon d’éviter que les membres du personnel, critiques pour l’organisation, soient simultanément présents sur le même site. En conséquence, il serait de bonne pratique que les sites primaire et secondaire soient situés dans des zones géographiques avec différents profils de risque et soient gérés par un personnel différent.

Une considération importante lors de la conception du système devrait être d’éviter une situation où la défaillance d’un composant ou d’un service particulier puisse causer la défaillance de l’ensemble du système (c’est à dire les SPOF). Sur la base de cette considération, une « bonne pratique » serait d’inventorier les dépendances externes et de mettre en évidence les SPOF restants. Lorsqu’un SPOF ne peut être évité, les dispositions d’urgence devraient être mises en place pour résoudre le problème.

Par définition, la défaillance technique des participants essentiels au système peut induire un risque systémique. Au minimum, les participants concernés doivent être en mesure de fermer un jour ouvrable et rouvrir le lendemain sur le site secondaire.

Les opérateurs devraient établir des équipes de gestion de crise et bien structurer les procédures formelles pour gérer une crise et sa communication interne ou externe.

Le BCP devrait être testé au moins une foi par an. Le but de ces tests est de valider l’efficacité de la stratégie de continuité d’activité, de vérifier que les dispositions sont viables dans la pratique, d’identifier les problèmes non apparents lors de la phase de planification, d’assurer la poursuite et de familiariser le personnel avec BCP, y compris leurs rôles et responsabilités.

Il est fondamental que les changement d’infrastructure soient correctement pris en compte par le BCP.

La communication du BCP doit relever d’un fragile équilibre entre la nécessaire confidentialité et l’efficacité.