DORA, NIS2 et status pages : transformer la communication d'incident en preuve de conformité EU

⚡TL;DR

• Le règlement DORA SaaS se concrétise via l'Article 19 : notification initiale 4 h après classification d'un incident majeur (24 h maximum après détection), rapport intermédiaire à 72 h et rapport final à 1 mois, chiffres officiels confirmés par les RTS/ITS JC 2024-33 publiés par les ESA le 17 juillet 2024.
• NIS2 Article 23 impose un early warning à 24 h, une notification à 72 h et un rapport final à 1 mois, applicable à 18 secteurs essentiels et importants en Europe.
• Une status page publique horodatée, archivée et exportable en JSON satisfait les trois propriétés d'une preuve opposable : horodatage RFC 3339 UTC, audit trail immuable, accessibilité publique vérifiable.
• L'ACPR signale dans son bilan 8 mois DORA (janvier 2026) que les délais 4 h sont « encore rarement respectés ». 2026 marque la fin de la tolérance et le début de l'enforcement actif.
• Le risque tiers ICT (DORA Article 28) impose une revue contractuelle du fournisseur de status page : juridiction, localisation des données, exit strategy, droit d'audit.

Le 15 janvier 2026, l'ACPR a publié son bilan des huit premiers mois d'application de DORA en concluant que les délais de notification de quatre heures sont « encore rarement respectés » par les entités financières françaises. À Francfort et Luxembourg, BaFin et CSSF observent un constat équivalent. Côté NIS2, 22 des 27 États membres ont transposé la directive au 1ᵉʳ avril 2026. L'Allemagne a fait entrer en vigueur le NIS2UmsuCG le 6 décembre 2025. L'Italie applique le décret législatif 138/2024 depuis le 16 octobre 2024. La France attend la promulgation de la Loi Résilience adoptée le 26 février 2025.

Dans ce paysage, une question opérationnelle revient à chaque audit : comment apporter la preuve qu'une notification d'incident a bien été émise dans les délais ? Les e-mails internes se perdent, les tickets ServiceNow se ferment, les captures d'écran se contestent. Reste un artefact public, horodaté, accessible à toute heure depuis l'extérieur : la status page. Or, pour la plupart des SaaS B2B européens, cette page reste un outil de communication marketing, pas un livrable d'audit. La bascule réglementaire qui s'est jouée entre 2024 et 2026 change radicalement ce statut.

Cet article s'adresse aux directeurs techniques, responsables sécurité de l'information, responsables SRE et délégués à la protection des données qui doivent piloter le règlement DORA SaaS et la directive NIS2 sur un service B2B européen. Il s'articule en trois temps : un volet pédagogique sur les régulations, un volet opérationnel sur l'anatomie d'une status page conforme, puis un volet checklist pour préparer un contrôle. Vous repartirez avec une cartographie unifiée des délais de notification incident DORA, un modèle d'export JSON aligné sur les templates RTS/ITS DORA, un framework en sept étapes couvrant les obligations DORA et la conformité NIS2, ainsi qu'une checklist de vingt-cinq points.

Le constat de départ est simple : la status page publique réunit, sans surcoût technique, les trois propriétés d'une pièce probante. Encore faut-il qu'elle soit conçue dans cet esprit. Les sections qui suivent montrent comment transformer un outil opérationnel en livrable d'audit. L'analyse s'appuie sur les textes officiels (EUR-Lex, RTS/ITS ESAs, ANSSI, ACPR, BaFin, CSSF, Banca d'Italia) et sur les retours d'expérience publics les plus récents.

Pourquoi la status page entre dans le périmètre d'audit EU en 2026

La status page publique a longtemps été perçue comme une vitrine. Elle servait à rassurer les clients pendant un incident, à éviter une saturation du support, à signaler une fenêtre de maintenance. En 2026, elle change de fonction. Les régulateurs européens, ACPR en tête, considèrent désormais qu'une communication publique d'incident horodatée fait partie intégrante du dossier de conformité ICT. Les textes ne la nomment pas formellement « preuve », mais elle est convoquée systématiquement lors des contrôles documentaires.

Le glissement réglementaire : de la page de courtoisie à l'artefact d'audit

Trois éléments expliquent ce basculement. D'abord, la fin de la période de transition du règlement DORA SaaS. Le règlement UE 2022/2554 est entré en application le 17 janvier 2025. Les huit premiers mois ont servi de période d'observation, durant laquelle les superviseurs n'ont pas appliqué de sanctions massives. À partir du premier trimestre 2026, l'ACPR, la BaFin, la Banque centrale de Luxembourg et la Banca d'Italia ont confirmé être passées en mode enforcement actif. Ensuite, la transposition de NIS2 se généralise. Au 1ᵉʳ avril 2026, 22 États membres sur 27 ont adopté un texte national, ce qui couvre la majorité des opérateurs économiques européens. Enfin, l'ENISA a publié en octobre 2025 son Threat Landscape qui documente une intensification des incidents ICT, ce qui pousse les régulateurs à durcir leur exigence de transparence.

Trois forces convergentes : régulation financière, sécurité réseau et supply-chain

Le règlement DORA SaaS s'applique aux entités financières et à leurs prestataires ICT critiques. La directive NIS2 couvre 18 secteurs (énergie, santé, transports, numérique, alimentation, infrastructures publiques, etc.). Pour un éditeur SaaS B2B européen, deux scénarios coexistent. Premier scénario : l'éditeur est lui-même opérateur essentiel ou important au sens de NIS2 (par exemple un hébergeur cloud, un fournisseur de service managé, un éditeur de signature électronique qualifiée). Il est alors directement soumis à la conformité NIS2. Second scénario : l'éditeur sert une banque, un assureur, une fintech soumise à DORA. Il devient alors un fournisseur ICT au sens de DORA Article 28, et son client doit contractualiser des obligations de résilience, d'auditabilité et de reporting. Dans les deux cas, la status page sort du champ marketing pour entrer dans le champ contractuel et réglementaire.

La chaîne d'approvisionnement entre également en jeu. NIS2 Article 21 paragraphe 2 impose une gestion explicite des risques liés aux fournisseurs et à la supply-chain. Une défaillance non communiquée d'un sous-traitant peut être imputée à l'opérateur principal. La status page sert alors de mécanisme contractuel de notification entre maillons de la chaîne.

Ce que disent les superviseurs en pratique

Les positions publiques convergent. L'ACPR, via son portail OneGate et sa FAQ DORA, insiste sur la traçabilité des notifications. La BaFin allemande, dans son article officiel sur le reporting DORA, demande la cohérence entre la communication publique et le rapport réglementaire. La CSSF luxembourgeoise a publié les circulaires 25/892 et 25/893 en mai 2025, qui détaillent la classification et le reporting. L'ANSSI, en France, opère le portail MonEspaceNIS2 qui centralise les notifications NIS2 pour les opérateurs essentiels et importants. Le message est uniforme : il faut une trace publique horodatée, et cette trace n'est pas optionnelle. C'est un complément structurel au rapport réglementaire confidentiel.

Pour les équipes opérationnelles, cela impose de repenser la conception de la status page comme un livrable d'audit dès la phase d'architecture, et non comme un canal de communication réactif. C'est exactement ce que permet l'outil status page CaptainDNS, conçu pour produire un artefact opposable nativement.

À retenir : en 2026, votre status page peut être convoquée comme pièce probante par votre régulateur. La concevoir comme telle dès le départ évite une refonte coûteuse au moment de l'audit.

Règlement DORA SaaS : l'Article 19 décortiqué (4 h, 72 h, 1 mois)

Le règlement UE 2022/2554, dit DORA, s'applique aux entités financières européennes et à leurs prestataires ICT critiques. Son chapitre III, et plus spécifiquement l'Article 19, encadre la notification des incidents ICT majeurs. Pour un éditeur SaaS B2B servant une banque ou un assureur, comprendre cet article ne relève pas du juridique : c'est ce qui dicte l'orchestration opérationnelle d'un incident.

Champ d'application : entités financières et fournisseurs ICT critiques

L'Article 2 de DORA liste 20 catégories d'entités financières. On y trouve les établissements de crédit et de paiement, les prestataires de services d'information sur les comptes et de financement participatif, les entreprises d'investissement, plateformes de négociation, dépositaires centraux et contreparties centrales. S'y ajoutent les gestionnaires d'organismes de placement collectif, les entreprises d'assurance et de réassurance, les intermédiaires d'assurance, les institutions de retraite professionnelle, les agences de notation, les administrateurs d'indices de référence, les prestataires de services en crypto-actifs et les registres de titrisation. Toutes ces entités sont soumises directement aux obligations DORA.

Le chapitre V (Articles 28 à 44) étend par contrat les obligations DORA aux fournisseurs ICT. Si un fournisseur sous-tend une fonction critique ou importante (CIFA, Critical or Important Function Arrangement), les clauses contractuelles sont obligatoires. Si un fournisseur dépasse les seuils définis par les ESA (European Supervisory Authorities : EBA, EIOPA, ESMA), il peut être désigné « prestataire tiers critique » (CTPP, Critical Third-Party Provider) et tomber sous supervision directe.

Le triptyque temporel : 4 h, 72 h, 1 mois

L'Article 19 impose trois échéances pour notifier un incident ICT classé majeur :

• Notification initiale : 4 heures après la classification de l'incident comme majeur, avec une borne maximale de 24 heures après la détection.
• Rapport intermédiaire : 72 heures après la détection.
• Rapport final : 1 mois après la détection.

Le détail des délais et des champs obligatoires figure dans le document final des standards techniques JC 2024-33 publié le 17 juillet 2024 par les trois autorités européennes EBA, EIOPA et ESMA. Il s'agit de Regulatory Technical Standards (RTS) et Implementing Technical Standards (ITS) qui précisent le contenu attendu de chaque rapport. La notification initiale doit contenir neuf champs obligatoires. On y retrouve l'identité de l'entité, l'horodatage de la détection, l'horodatage de la classification, la description préliminaire et les critères de classification activés (Articles 17 et 18 DORA). Suivent l'impact estimé, les mesures immédiates prises, les prochaines étapes prévues et le contact dédié.

La classification s'appuie sur les critères de l'Article 18 DORA : matérialité de l'impact (nombre de clients affectés, durée, géographie, perte de données, criticité du service interrompu, gravité économique). Le délai de 4 heures démarre au moment où l'entité conclut formellement que l'incident est « majeur », pas à la détection. Cette nuance change tout en pratique : il faut documenter la chaîne de décision (qui a classifié, sur quels critères, à quelle heure UTC), faute de quoi le régulateur peut requalifier le délai et conclure à un dépassement.

À qui notifier en pratique selon votre juridiction

Les entités notifient leur autorité nationale compétente :

• France : ACPR via le portail OneGate (format JSON, sans signature électronique requise). En cas d'indisponibilité de OneGate (minuit-4 h, dimanches), envoi par courriel à 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr.
• Allemagne : BaFin via le portail MVP (Meldungs- und Veröffentlichungsplattform), avec format XBRL.
• Luxembourg : CSSF via le portail eDesk (Circulaire 25/893), accompagné d'une matrice de classification standardisée.
• Italie : Banca d'Italia via son portail dédié aux incidents DORA, au format CSV ou XML.

Pour les CTPP désignés, la supervision est conjointe entre ESA et régulateur national, avec un Joint Examination Team (JET) qui peut auditer sur site. Un éditeur SaaS B2B qui sert plusieurs banques européennes peut être amené à notifier plusieurs autorités en parallèle pour un même incident. Le délai notification incident DORA de 4 heures impose alors un format pivot type JSON exploité depuis sa status page, ce qui rejoint la logique du monitoring DNS résilient documenté précédemment.

Sanctions Articles 50 à 58

DORA prévoit des sanctions administratives lourdes. Pour les entités financières : jusqu'à 2 % du chiffre d'affaires annuel mondial ou 10 millions d'euros (le plus élevé), avec amende individuelle pouvant atteindre 1 million d'euros pour les responsables. Pour les CTPP : jusqu'à 1 % du chiffre d'affaires quotidien moyen mondial, pendant six mois maximum. Au-delà des amendes, les sanctions sont publiées (Article 54), ce qui ajoute un coût réputationnel significatif. Le bilan ACPR de janvier 2026 précise que la phase d'enforcement actif a démarré au premier trimestre 2026, mais sans encore citer de cas public sanctionné, signal que les régulateurs préparent leurs dossiers en silence.

À retenir : 4 heures après classification, vous devez disposer de 9 champs obligatoires prêts à transmettre. Si votre status page exporte déjà ces champs, vous avez gagné l'essentiel de la course.

Directive NIS2 : l'Article 23 et la cascade 24 h, 72 h, 1 mois

La directive UE 2022/2555, dite NIS2, complète DORA en couvrant tous les secteurs essentiels et importants hors finance pure. Son article 23 fixe une cascade de notification distincte, plus large dans son périmètre, et avec un point de départ différent. Pour un SaaS B2B européen, NIS2 s'applique souvent en parallèle de DORA, et orchestrer les deux est l'enjeu opérationnel principal de 2026.

Périmètre étendu : dix-huit secteurs et chaîne d'approvisionnement

Les annexes I et II de la directive NIS2 listent 18 secteurs. L'annexe I distingue les secteurs hautement critiques : énergie, transports, banque, infrastructure du marché financier, santé, eau potable, eaux usées, infrastructure numérique, gestion des services informatiques B2B, administration publique et espace. L'annexe II couvre les autres secteurs critiques : services postaux et courriers, gestion des déchets, fabrication, production et distribution de produits chimiques, production et transformation de denrées alimentaires, fournisseurs de services numériques et recherche. La taille de l'entité (≥ 50 salariés et chiffre d'affaires ≥ 10 millions d'euros pour le statut « important », seuils plus élevés pour « essentiel ») détermine si elle relève de la conformité NIS2.

NIS2 Article 21 paragraphe 2 lettre d impose la gestion de la sécurité de la chaîne d'approvisionnement, y compris les aspects de sécurité concernant les relations directes entre fournisseurs et prestataires. Une status page mal exploitée par un fournisseur peut entraîner la responsabilité de l'opérateur essentiel ou important client.

Early warning 24 h, notification 72 h, rapport final 1 mois

L'Article 23 organise la notification en trois temps :

• Early warning dans les 24 heures suivant la connaissance d'un incident significatif.
• Notification d'incident dans les 72 heures suivant la connaissance, incluant une évaluation initiale, des indicateurs de compromission et une description de la sévérité.
• Rapport final dans le mois suivant la notification, avec analyse causale détaillée.

Le point de départ critique : « connaissance » (awareness), pas « détection » technique ni « classification » formelle. Dès qu'une équipe interne a conscience d'un incident significatif, le compteur démarre. Un incident est « significatif » s'il a entraîné ou est susceptible d'entraîner une perturbation grave des services ou des pertes financières importantes. Il peut aussi l'être s'il a affecté ou est susceptible d'affecter des tiers en causant des dommages matériels ou immatériels considérables.

Transpositions nationales au printemps 2026

L'état des lieux au 1ᵉʳ avril 2026 :

• France : Loi Résilience adoptée par l'Assemblée nationale le 26 février 2025, promulgation attendue au premier semestre 2026. L'ANSSI opère le portail MonEspaceNIS2 et coordonne le CERT-FR comme CSIRT national. Période de mise en conformité : 3 ans après promulgation. Pour suivre l'évolution de l'historisation des observations, voir la traçabilité DNS publiée par CaptainDNS en novembre 2025.
• Allemagne : NIS2UmsuCG promulgué le 5 décembre 2025, en vigueur le 6 décembre 2025. Le BSI a publié les détails opérationnels : environ 30 000 entités concernées, registration obligatoire dans les 3 mois, sanctions de niveau « board accountability ».
• Italie : décret législatif 138/2024 publié le 4 septembre 2024, en vigueur le 16 octobre 2024. L'ACN (Agenzia per la Cybersicurezza Nazionale) opère le portail de notification, complété par le DPCM 221 du 9 décembre 2024.
• Luxembourg, Pays-Bas, Belgique, Espagne, Portugal, Pologne, pays nordiques, pays baltes : transposition effective ou imminente (procédure parlementaire en cours).
• Cinq États en retard au 1ᵉʳ avril 2026 : risque de procédures d'infraction Article 258 TFUE.

Différence entre la directive et le règlement de protection des données

NIS2 et RGPD se chevauchent partiellement. Un incident peut être à la fois un « incident significatif » NIS2 et une « violation de données à caractère personnel » RGPD. Les notifications sont alors parallèles : CSIRT national pour NIS2, autorité de protection des données (CNIL en France) pour RGPD. Le délai RGPD Article 33 est de 72 heures « après en avoir pris connaissance ». NIS2 ajoute un early warning à 24 heures, ce qui crée une obligation supplémentaire. Pour un éditeur opérant un service de stockage SaaS qui subit une intrusion impliquant des données personnelles, trois canaux de reporting peuvent se déclencher en parallèle : NIS2, RGPD et DORA si le client est financier. D'où l'importance d'une source unique horodatée, qui est précisément la status page publique.

À retenir : sous NIS2, le compteur 24 h démarre dès la connaissance interne, pas après classification formelle. Préparez vos équipes à publier un message public dans les 4 premières heures pour ne pas devoir tout faire à la 23ᵉ heure.

Cartographie unifiée des trois régulations européennes

La complexité opérationnelle naît du croisement entre les trois régulations. Pour un éditeur servant simultanément des entités financières soumises au règlement DORA SaaS et des opérateurs essentiels relevant de la directive NIS2, un même incident peut déclencher trois canaux de notification, avec des délais et des destinataires différents. La status page joue alors le rôle de dénominateur commun horodaté pour la conformité NIS2 comme pour le délai notification incident DORA.

Tableau croisé des délais

Régulation	Fait générateur	Délai initial	Intermédiaire	Final	Autorité destinataire	Sanction maximale
DORA Article 19	Incident ICT classé majeur (Art. 17-18)	4 h après classification (24 h max après détection)	72 h après détection	1 mois après détection	ACPR (FR) / BaFin (DE) / CSSF (LU) / Banca d'Italia (IT)	2 % CA mondial ou 10 M€ (entité) / 1 % CA quotidien moyen 6 mois (CTPP)
NIS2 Article 23	Incident significatif	24 h early warning	72 h notification	1 mois rapport final	CSIRT national (CERT-FR / BSI / ACN / etc.)	10 M€ ou 2 % CA mondial (essentiel) / 7 M€ ou 1,4 % CA mondial (important)
RGPD Article 33	Violation de données personnelles	72 h après connaissance	n/a	(selon enquête CNIL)	CNIL (FR) ou équivalent national	20 M€ ou 4 % CA mondial

Fait générateur : qui démarre quand

Trois points de départ distincts cohabitent. DORA part de la classification comme incident majeur (formelle, documentée, datée). NIS2 part de la connaissance interne d'un incident significatif. RGPD part de la prise de connaissance d'une violation. Le plus court délai opérationnel est de 4 heures (DORA), mais il démarre tard (après classification). Le plus précoce est l'early warning NIS2 à 24 h, qui peut démarrer plusieurs heures avant la classification DORA.

Pour les équipes ops, cela signifie qu'un seul incident peut être à la fois en avance NIS2 et en retard DORA, d'où la nécessité d'un journal commun et d'un mécanisme de classification rapide. Côté supervision, l'outil monitor d'uptime HTTP multi-régions fournit l'horodatage technique objectif sur lequel s'appuie la classification.

À qui notifier : le mapping complet par juridiction

Pour les SaaS B2B opérant dans plusieurs pays européens, voici la matrice de destinataires :

• France : ACPR (DORA), CERT-FR via MonEspaceNIS2 (NIS2), CNIL (RGPD).
• Allemagne : BaFin (DORA), BSI (NIS2), BfDI ou autorité Land (RGPD).
• Italie : Banca d'Italia (DORA, via portail dédié), ACN (NIS2), Garante (RGPD).
• Luxembourg : CSSF (DORA via eDesk), GovCERT-LU (NIS2), CNPD (RGPD).
• Espagne : Banco de España et CNMV (DORA), INCIBE-CERT (NIS2), AEPD (RGPD).
• Pays-Bas : DNB et AFM (DORA), NCSC-NL (NIS2), AP (RGPD).

L'idée d'un point d'entrée unique européen progresse : le paquet Digital Omnibus présenté par Bird & Bird prévoit une harmonisation à 18 mois post-adoption. En 2026, cette harmonisation n'est pas encore effective : il faut donc piloter manuellement les notifications multiples, et la status page reste le seul livrable cohérent à toutes les juridictions.

---

Créez une status page conforme DORA et NIS2 dès aujourd'hui

---

À retenir : quand 3 régulations s'appliquent, la plus courte fenêtre gagne, souvent 4 h DORA. La status page horodatée publique sert les trois en parallèle.

La status page comme pièce probante : pourquoi les auditeurs la demandent

Une pièce probante au sens juridique combine trois propriétés : horodatage fiable, immuabilité, accessibilité publique vérifiable. Aucun autre artefact technique d'un SaaS B2B ne coche les trois cases en même temps. Les logs internes ne sont pas accessibles publiquement. Les PDF post-mortem peuvent être édités après coup. Les e-mails clients ne sont pas horodatés cryptographiquement. La status page publique remplit les trois conditions, à condition d'avoir été conçue dans cet esprit.

Trois propriétés probantes : horodatage signé, archivage immutable, audience publique

L'horodatage doit suivre RFC 3339 au format UTC. C'est le standard reconnu par l'ensemble des juridictions européennes pour les opérations électroniques (eIDAS, eIDAS 2). L'horodatage en heure locale (CET, CEST, BST) est inacceptable car ambigu autour des changements d'heure. L'horodatage qualifié au sens RFC 3161, signé par un Trust Service Provider qualifié, est encore plus solide juridiquement, mais reste optionnel en pratique tant que l'horodatage UTC est cohérent et vérifiable.

L'immuabilité repose sur l'audit trail : chaque mise à jour d'incident doit être versionnée, jamais écrasée. Si vous corrigez un message à 14 h 17 UTC après une publication à 14 h 02 UTC, les deux versions doivent rester accessibles, avec la mention « édité à 14 h 17 ». Cette discipline éditoriale ressemble à la pratique des médias en ligne sur les corrections factuelles.

L'accessibilité publique est ce qui distingue la status page d'un log interne. La page doit être consultable sans authentification, depuis n'importe quel point d'Internet. Cela impose une infrastructure d'hébergement distincte de l'application principale : si votre application tombe, votre status page doit rester debout. C'est une exigence d'architecture qui se renforce avec DNSSEC actif sur le domaine status et HTTPS strict.

Cas Cloudflare R2 du 21 mars 2025 : modèle de référence

Cloudflare a documenté publiquement un incident sur son service R2 le 21 mars 2025. L'entreprise a publié un post-mortem détaillé trois jours après l'incident. Le déroulé est exemplaire. Annonce sur la status page à 14 h 04 UTC, peu après le début de la dégradation. Mises à jour toutes les 15 à 30 minutes. Identification de la cause racine (problème de configuration storage). Résolution annoncée à 15 h 11 UTC. Post-mortem complet le 24 mars avec timeline détaillée, root cause et prochaines étapes correctives. La status page sert ici de pivot temporel : elle horodate les engagements opérationnels, et le post-mortem ultérieur s'y réfère explicitement.

Pour un éditeur SaaS B2B européen, ce modèle est directement transposable. Il n'exige pas d'outillage exotique : il exige une discipline éditoriale et un format d'export structuré.

Quand le fournisseur de status page tombe lui-même en panne

OneUptime a documenté un cas révélateur : entre le 2 et le 23 février 2026, le module system metrics d'Atlassian Statuspage est resté indisponible pendant 21 jours consécutifs. L'analyse publiée par OneUptime le 25 février 2026 souligne le paradoxe : un fournisseur de status page qui n'arrive pas à maintenir le SLA de ses propres composants ne peut pas servir d'artefact d'audit pour ses clients. Le risque concentré sur un fournisseur unique devient une vulnérabilité contractuelle directe.

Bilan ACPR à huit mois : la tension réglementaire face à la réalité opérationnelle

Le bilan ACPR du 15 janvier 2026 signale que les délais 4 heures sont « encore rarement respectés ». Ce constat n'est pas un blanc-seing : il accompagne l'annonce du passage en mode enforcement actif. Le message implicite : l'année 2026 marque la transition entre la tolérance et la sanction. Pour les entités qui n'ont pas encore une status page conforme, le risque de sanction est concret. Sur le plan des principes de sécurité TLS et chaîne de confiance, la rigueur de l'horodatage et de la signature s'aligne sur les mêmes exigences cryptographiques.

À retenir : seule une status page publique horodatée combine les trois propriétés d'une preuve opposable. La concevoir comme telle est aujourd'hui un investissement à très haut retour réglementaire.

Anatomie d'une status page conforme au règlement DORA SaaS : dix attributs obligatoires

Une status page conçue comme livrable d'audit doit cocher dix cases techniques. La liste ci-dessous synthétise les attentes croisées des superviseurs européens (ACPR, BaFin, CSSF, Banca d'Italia, ACN) et les bonnes pratiques opérationnelles des éditeurs les plus matures.

Attribut 1, identification claire des composants et services. La granularité doit descendre au niveau produit/région. Un libellé « API » est insuffisant ; il faut « API REST v3, région EU-West », « API REST v3, région US-East », « SFTP B2B », « Webhooks ». Cela permet de déclarer un incident partiel sans déclencher une panique injustifiée sur l'ensemble du service.

Attribut 2, horodatage RFC 3339 UTC partout. Aucune date en heure locale. Aucune date sans fuseau. La conversion en heure locale se fait côté navigateur. La cohérence UTC garantit l'opposabilité juridique.

Attribut 3, severity codée et stable. Quatre niveaux minimum : operational, degraded performance, partial outage, major outage. Les libellés doivent être stables dans le temps (pas de renommage par marketing). Le code numérique sous-jacent (par exemple 0/1/2/3) doit transiter dans le flux JSON pour permettre l'automatisation.

Attribut 4, lien explicite vers l'incident en cours et identifiant stable. Chaque incident doit avoir un identifiant unique, persistant après résolution, accessible par URL canonique. Les régulateurs demandent souvent : « Donnez-nous l'URL exacte de la communication publique de l'incident XYZ. »

Attribut 5, audit trail visible. Chaque mise à jour doit être versionnée, datée, et identifier l'auteur (au moins par rôle ou identifiant). Les éditions postérieures doivent rester visibles avec mention « édité le … ».

Attribut 6, export structuré JSON, RSS, Atom, ICS. Le JSON sert l'extraction automatisée vers les rapports régulateurs. RSS et Atom servent l'abonnement client (et le sourcing par des outils comme StatusGator ou IsDown). ICS sert la maintenance planifiée pour les équipes clientes.

Attribut 7, indépendance d'infrastructure. La status page doit être hébergée hors du périmètre applicatif surveillé. Si votre application est sur AWS Frankfurt, votre status page ne doit pas l'être. Cette indépendance est non négociable : c'est ce qui distingue un livrable utile en cas de panne majeure d'un placebo.

Attribut 8, versionnage des mises à jour. Conséquence directe de l'attribut 5 : un système de stockage immuable type Write-Once-Read-Many (WORM) ou registre signé garantit qu'aucune réécriture rétroactive n'est techniquement possible.

Attribut 9, notifications cross-canal. E-mail, webhook, RSS et SMS optionnel. Les régulateurs demandent souvent à être abonnés pendant les contrôles : refuser un canal d'abonnement n'est pas envisageable.

Attribut 10, conservation longue durée. L'archivage des snapshots (JSON et HTML) doit couvrir au minimum 6 ans pour aligner DORA Articles 5 à 14 (ICT risk framework, registre incidents) et NIS2 transpositions nationales. La France impose 6 ans dans la Loi Résilience adoptée. Les transpositions italienne et allemande retiennent un minimum de 5 ans.

---

Aside : risque tiers ICT et clauses contractuelles DORA Articles 28 et 30

Le chapitre V de DORA encadre les relations entre entités financières et fournisseurs ICT. L'Article 28 impose la tenue d'un registre des accords contractuels ICT, la classification des fonctions critiques ou importantes (CIFA), et la concentration du risque tiers. L'Article 30 énumère les clauses contractuelles minimales : description claire du service, niveaux de service mesurables, localisation des données, sécurité de l'information, accessibilité et restitution des données, droit d'audit, exit strategy.

Pour un éditeur ou un client SaaS B2B européen, ces deux articles dictent un questionnement objectif au moment de choisir un fournisseur de status page :

• Localisation des données. L'hébergement des données de la status page (incidents, commentaires, métadonnées) est-il garanti contractuellement en Europe ? Les sous-traitants (CDN, backups, monitoring interne) sont-ils tous localisés en Europe ?
• Juridiction du fournisseur. Un fournisseur dont la maison mère est aux États-Unis active le risque CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), qui permet aux autorités américaines d'exiger des données stockées par une entreprise sous juridiction américaine, indépendamment du pays de stockage physique. Cela ne disqualifie pas automatiquement les fournisseurs concernés (Atlassian Statuspage, par exemple), mais impose des SCC (Standard Contractual Clauses) RGPD renforcées et un DPA explicite.
• Certifications. SOC 2 Type II et ISO 27001 sont utiles mais non suffisants pour DORA, qui exige une auditabilité spécifique au secteur financier. Demandez explicitement un Statement of Applicability incluant la clause DORA Article 28.
• Registre des sous-traitants. Un fournisseur conforme DORA doit pouvoir fournir la liste à jour de ses sous-processeurs avec leur localisation et leur rôle. Refus = signal d'alerte.
• Exit strategy testée. La capacité de récupérer la totalité de votre historique status page en format ouvert (JSON, CSV) en moins de 72 heures doit être contractualisée et testée annuellement. Un export bricolé en cas d'urgence ne tient pas devant un auditeur.

Les fournisseurs US (Atlassian Statuspage, StatusGator, certains BetterStack selon la juridiction du contrat) cohabitent avec des alternatives européennes (Instatus EU, CaptainDNS, OpenStatus en mode self-hosted). Le choix ne se fait pas sur les features ou le pricing, il se fait sur l'alignement DORA Articles 28 et 30. Pour le détail des clauses contractuelles, consultez la synthèse Bird & Bird sur les clauses contractuelles DORA. Sur la même logique d'hébergement européen contractualisé, voir aussi le guide MTA-STS complet.

---

À retenir : 10 attributs techniques plus 1 question juridique de juridiction forment la checklist anatomie. Toute défaillance sur un attribut est un risque d'audit, pas un détail de produit.

Modèle d'incident report : du JSON status page au rapport DORA

L'objectif d'une status page DORA-ready n'est pas seulement de communiquer publiquement. C'est aussi de nourrir directement le rapport réglementaire confidentiel, sans saisie manuelle répétée. Le pivot entre les deux est un fichier JSON structuré, dérivé de la status page et transposé sur les templates RTS/ITS JC 2024-33.

Correspondance champ à champ entre l'export status page et le template régulateur

Le rapport initial DORA exige neuf champs minimum. Le tableau ci-dessous montre la correspondance avec un export JSON status page :

• entity_id (status page) → champ « LEI » ou identifiant national du rapport DORA.
• incident.uuid (status page) → champ « Reference number » du rapport.
• incident.detected_at (timestamp RFC 3339 UTC) → champ « Date and time of detection ».
• incident.classified_at → champ « Date and time of classification ».
• incident.preliminary_description → champ « Description of the incident ».
• incident.classification_criteria (liste codée Art. 18) → champ « Classification criteria activated ».
• incident.impact_estimate (clients, durée, géographie, données) → bloc « Estimated impact ».
• incident.immediate_actions (tableau de mesures) → champ « Immediate measures taken ».
• incident.contact (e-mail + téléphone du contact DORA) → champ « Reporting contact ».

Exemple JSON pour un incident DDoS classé majeur

{
  "entity": {
    "lei": "5493000F4ZO33MV32P92",
    "name": "captaindns.com",
    "ncas": ["ACPR-FR", "BaFin-DE"]
  },
  "incident": {
    "uuid": "INC-2026-05-15-001",
    "url_public": "https://status.captaindns.com/incidents/INC-2026-05-15-001",
    "detected_at": "2026-05-15T14:02:11Z",
    "classified_at": "2026-05-15T14:48:32Z",
    "classification_criteria": [
      "geographical_spread:multi_region",
      "data_loss:none",
      "duration_estimate:over_2h",
      "clients_affected:over_10000"
    ],
    "severity": "major_outage",
    "preliminary_description": "Volumetric DDoS attack (1.2 Tbps) on EU-West API ingress, mitigation engaged at T+8min, traffic partially restored T+15min, full mitigation T+47min.",
    "impact_estimate": {
      "clients_affected_estimate": 12400,
      "geography": ["EU-West", "EU-North"],
      "data_loss": false,
      "downstream_dependencies": ["bank-X", "insurer-Y"]
    },
    "immediate_actions": [
      "Activation BGP blackhole upstream",
      "Failover to APAC fallback (read-only mode)",
      "Public status page update T+11min"
    ],
    "next_steps": [
      "Continuous monitoring 24h",
      "Forensic capture preserved",
      "Intermediate report scheduled T+72h"
    ],
    "contact": {
      "name": "DORA Incident Notifier (role dedicated)",
      "email": "dora-incidents@captaindns.com",
      "phone": "+33 1 00 00 00 00"
    },
    "timestamps_audit_trail": [
      {"at": "2026-05-15T14:08:00Z", "action": "public_announce", "version": 1},
      {"at": "2026-05-15T14:23:00Z", "action": "update_severity", "version": 2},
      {"at": "2026-05-15T14:55:00Z", "action": "resolution_announced", "version": 3}
    ]
  }
}

Workflow d'extraction et de transmission

L'industrialisation du flux repose sur trois briques. Une tâche cron lit la status page toutes les 5 minutes, sérialise les incidents au format JSON, signe le fichier avec une signature détachée (PGP ou cosign). Une seconde tâche, déclenchée par un webhook lors de la classification, prépare la version régulateur en mappant les champs sur les XSD officiels (XBRL pour BaFin, XML pour Banca d'Italia, JSON pour ACPR OneGate). Une troisième brique gère la transmission via les API ou portails dédiés (OneGate API, eDesk CSSF, MVP BaFin), avec retry en cas d'indisponibilité du portail.

Sur la sécurisation du transport e-mail des notifications complémentaires, la rigueur des politiques MTA-STS hébergées s'inscrit dans la même logique de preuve cryptographique exploitable en audit.

À retenir : si votre status page exporte ce JSON, vous remplissez le rapport DORA en 4 heures sans ressaisie. C'est la différence entre tenir le délai et le rater.

Framework pratique en sept étapes (HowTo)

Pour passer du concept à l'opérationnel, voici un framework en sept étapes, applicable sur 90 jours pour un SaaS B2B européen disposant d'une équipe SRE de base.

Framework de mise en conformité status page DORA et NIS2

Sept étapes pour rendre votre status page opposable face à un audit ACPR, BaFin, ACN ou CSSF en 90 jours.

1. Étape 1 : inventaire des services et classification de criticité

   Dresser la liste exhaustive des services exposés et associer à chacun une criticité au sens DORA (CIFA / non-CIFA) ou NIS2 (essentiel / important / hors-scope). Documenter le critère retenu et la méthode de classification. Cet inventaire est le socle de tous les engagements ultérieurs. Sans inventaire propre, impossible de justifier au régulateur pourquoi un sous-service n'apparaît pas sur la status page.

2. Étape 2 : choix du fournisseur de status page selon DORA Articles 28 et 30

   Évaluer chaque candidat sur cinq critères objectifs : juridiction du fournisseur, localisation des données, sous-traitants documentés, exit strategy contractualisée, audit trail technique. Un fournisseur sans réponse écrite sur ces cinq points doit être écarté, indépendamment de ses fonctionnalités. La revue contractuelle doit être validée par la direction juridique avant signature.

3. Étape 3 : architecture multi-régions et indépendance DNS

   Héberger la status page sur une infrastructure strictement distincte du périmètre applicatif. DNS séparé (sous-domaine status. dédié, autorité distincte), hébergement géographiquement séparé. Activer DNSSEC, HSTS et CAA sur le domaine status. L'indépendance s'éprouve : couper artificiellement l'application principale en test et vérifier que la status page reste consultable. Sans test, l'indépendance n'est qu'une déclaration.

4. Étape 4 : templates d'incident pour quatre niveaux de gravité

   Préparer quatre modèles d'annonce publique : operational maintenance, degraded performance, partial outage, major outage. Chaque modèle inclut les champs obligatoires (timestamps UTC, severity, composants affectés, mesures immédiates, ETA estimée). Les modèles doivent être validés par le DPO, la direction juridique et la direction communication. Sans pré-validation, chaque incident exige une revue urgente qui coûte du temps précieux.

5. Étape 5 : pipeline d'archivage horodaté et scellé

   Mettre en place un snapshot horodaté toutes les 5 minutes (JSON + HTML) déposé dans un stockage immuable (S3 Object Lock en mode compliance, ou registre signé local type sigstore). Conservation minimum 6 ans. La signature détachée du snapshot doit être déposée séparément pour permettre la vérification d'intégrité par un tiers.

6. Étape 6 : test trimestriel sous forme de tabletop exercise

   Organiser tous les trois mois un exercice tabletop simulant un incident majeur. L'objectif : valider que le délai entre détection et publication publique reste inférieur à 15 minutes, et que la classification DORA est documentée en moins de 4 heures. Le test doit impliquer SRE, comms, juridique, DPO et un membre du COMEX. Un compte-rendu écrit du tabletop fait partie des preuves auditables.

7. Étape 7 : revue annuelle alignée audit ACPR, BaFin, ACN, CSSF

   Organiser annuellement une revue formelle (board level) qui passe en revue les incidents majeurs de l'année, vérifie la conformité des notifications, valide les évolutions de la status page et arbitre les investissements de l'année suivante. Cette revue est exigée par DORA Article 17 (gouvernance et organisation ICT risk management). Sans trace écrite de cette revue, l'auditeur peut conclure à un défaut de gouvernance, ce qui aggrave toute sanction.

L'enchaînement des étapes 1 à 4 prépare l'infrastructure ; les étapes 5 et 6 verrouillent la preuve et la résilience ; l'étape 7 institutionnalise la démarche. Pour les équipes qui n'ont jamais piloté de simulation, l'investissement initial paraît élevé. Il est en réalité dérisoire face au risque de sanction. Sur la rigueur des contrôles HTTPS et HSTS associés au domaine status, voir le guide HSTS preload.

À retenir : sans drill trimestriel de 4 heures, vous découvrirez en production que votre processus de notification ne tient pas. Le drill coûte une demi-journée. Une notification ratée coûte 10 millions d'euros.

Questions fréquentes

FAQ

Notre SaaS est-il concerné par DORA si nous fournissons un service à une banque ?

Oui, indirectement. Le règlement DORA SaaS s'applique alors via les Articles 28 et 30 : les entités financières doivent répercuter contractuellement les obligations DORA sur leurs fournisseurs ICT, particulièrement ceux qui sous-tendent une CIFA (Critical or Important Function Arrangement). Vous serez donc soumis à des clauses contractuelles obligatoires : localisation des données, droits d'audit, exit strategy, niveaux de service mesurables. Si vous êtes désigné CTPP (Critical Third-Party Provider) par les ESA, vous tombez sous supervision directe. La status page devient alors un livrable contractuel quantifié et opposable.

Quel est le délai exact d'une notification DORA initiale ?

Quatre heures après la classification de l'incident comme majeur, avec une borne maximale de 24 heures après la détection. La classification s'appuie sur DORA Article 18 et les critères de matérialité (impact clients, durée, géographie, perte de données, criticité du service). Le délai démarre au moment du verdict « incident majeur », pas à la détection. Le document JC 2024-33 publié en juillet 2024 par les ESA liste les neuf champs obligatoires du rapport initial : identité de l'entité, horodatage détection, horodatage classification, description préliminaire, critères de classification, impact estimé, mesures immédiates, prochaines étapes, contact dédié.

Quelle est la différence opérationnelle entre DORA et NIS2 pour notre status page ?

Le règlement DORA SaaS prime sur le secteur financier (banques, assureurs, fonds, prestataires de services de paiement) et démarre son chronomètre 4 heures après classification. La conformité NIS2 couvre 18 secteurs essentiels et importants (énergie, santé, numérique, transport, alimentation, etc.) et démarre 24 heures après connaissance interne de l'incident. Les deux convergent sur 72 heures de notification intermédiaire et 1 mois pour le rapport final. Si vous êtes dans les deux périmètres (rare mais possible), DORA prime en raison du délai plus court. La status page sert les deux régulations avec le même artefact horodaté, à condition que le format JSON exporté couvre les champs des deux templates.

La status page peut-elle vraiment servir de pièce probante en audit ?

Une page publique horodatée, archivée et exportable en JSON, RSS ou Atom remplit les trois propriétés d'une preuve opposable : horodatage RFC 3339 UTC, immuabilité via audit trail visible, accessibilité publique vérifiable. Aucun PDF post-mortem ni log interne ne combine ces trois critères. Plusieurs régulateurs européens (ACPR, BaFin) considèrent désormais la communication publique d'incident comme partie intégrante du dossier d'audit ICT, sans la nommer formellement « preuve », mais elle est régulièrement convoquée lors des contrôles documentaires. À titre comparatif, un horodatage qualifié RFC 3161 par un Trust Service Provider apporte un niveau juridique supplémentaire.

Notre status page Atlassian Statuspage US est-elle compatible DORA Article 28 ?

La question n'est pas d'incompatibilité absolue, mais de gestion du risque tiers ICT et de juridiction. Un fournisseur de status page sous juridiction américaine active le CLOUD Act et nécessite des SCC (Standard Contractual Clauses) et un DPA RGPD renforcés. Pour rester conforme DORA Articles 28 à 30, exigez du fournisseur : localisation européenne des données et des logs, clauses d'audit, exit strategy testée annuellement, certifications ISO 27001 et SOC 2 Type II, registre à jour des sous-traitants. Si votre service sous-tend une CIFA, ces clauses sont obligatoires, pas optionnelles. À défaut, votre client financier devra arbitrer entre maintien du contrat et risque réglementaire.

Quels sont les 5 piliers de DORA ?

DORA repose sur cinq piliers structurants. Premier pilier : ICT risk management (Articles 5 à 15), qui impose un cadre de gouvernance et de gestion des risques ICT. Deuxième pilier : ICT-related incident management, classification and reporting (Articles 17 à 23), qui inclut l'Article 19 sur le reporting. Troisième pilier : digital operational resilience testing (Articles 24 à 27), dont les TLPT (Threat-Led Penetration Testing) pour les entités significatives. Quatrième pilier : management of ICT third-party risk (Articles 28 à 44), qui dicte les contrats avec les fournisseurs ICT, y compris le fournisseur de status page. Cinquième pilier : information sharing arrangements (Article 45). Le pilier 2 impose la status page comme artefact, le pilier 4 en dicte les conditions contractuelles.

Qui notifier en France pour un incident DORA ?

L'ACPR via le portail OneGate, au format JSON, sans signature électronique requise. Pour les périodes d'indisponibilité de OneGate (minuit-4 h, dimanches et jours fériés), l'envoi se fait par courriel à 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr. Pour un incident NIS2, le CSIRT national désigné (CERT-FR via MonEspaceNIS2 une fois la Loi Résilience promulguée). Pour un incident RGPD impliquant des données personnelles, la CNIL. Un même incident peut déclencher deux ou trois voies parallèles, d'où l'intérêt opérationnel critique d'un format pivot type JSON status page exploité une seule fois et transposé vers chaque template régulateur.

Combien de temps devons-nous archiver nos status pages ?

Aucun délai n'est fixé explicitement par DORA Article 19, mais la cohérence avec les Articles 5 à 14 (ICT risk framework, registre incidents, audit trail) suggère un minimum de 5 à 6 ans. Le RGPD impose de pouvoir démontrer sa conformité au sens de l'Article 5 paragraphe 2, sans délai fixé. Les régulateurs nationaux (ACPR, BaFin) demandent typiquement 5 ans d'archives auditables. La Loi Résilience française adoptée en février 2025 prévoit 6 ans pour NIS2. Recommandation prudente : archiver tous les snapshots status page (JSON et HTML) en stockage immuable type WORM ou registre signé, pour 6 ans minimum, avec procédure documentée de restitution sous 72 heures.

Faut-il une status page différente par marché EU (FR, DE, IT) ?

Non, une seule status page multilingue suffit, à condition que le contenu soit identique en substance d'une langue à l'autre. Les régulateurs nationaux acceptent un livrable unifié dès lors qu'il est accessible dans la langue de la juridiction concernée. Attention en revanche aux fuseaux horaires : utilisez UTC comme source unique de vérité et affichez la conversion locale côté navigateur (client-side). Si votre service opère sous plusieurs autorités (ACPR + BaFin + CSSF), maintenez un identifiant incident stable et global, traduit par mapping linguistique, jamais par historique séparé. Une duplication d'historique entraîne des incohérences temporelles très exposées en audit.

Que se passe-t-il si nous ratons un délai 4 h DORA ?

Sanctions administratives jusqu'à 2 % du chiffre d'affaires annuel mondial ou 10 millions d'euros (le plus élevé) pour l'entité, et jusqu'à 1 million d'euros d'amende individuelle pour les responsables identifiés. Pour les CTPP : jusqu'à 1 % du chiffre d'affaires quotidien moyen mondial, pendant six mois. Au-delà des amendes, conséquences réputationnelles via la publication des sanctions (Article 54). L'ACPR, dans son bilan 8 mois de janvier 2026, note que ces délais 4 heures sont « encore rarement respectés ». 2026 marque la fin de la tolérance et le début de l'enforcement actif. Conserver une trace publique exhaustive (status page horodatée) est aujourd'hui la meilleure assurance contre une requalification défavorable.

Checklist finale : vingt-cinq points à valider avant l'audit

Cette checklist synthétise les exigences DORA, NIS2 et RGPD applicables à la status page d'un SaaS B2B européen. Elle est structurée en trois blocs : documentaire (7 points), technique (10 points), organisationnel (8 points). Cocher 25 points sur 25 ne garantit pas l'absence de sanction, mais place l'entité dans une situation défensive solide face à un contrôle ACPR, BaFin, ACN, CSSF ou Banca d'Italia.

Volet documentaire (sept points)

1. Politique de classification des incidents écrite et signée par la direction (matrice severity vers reporting DORA et NIS2).
2. Procédure de notification DORA 4 heures documentée, validée par la direction juridique, mise à jour annuellement.
3. Procédure de notification NIS2 24 heures documentée, alignée sur le portail national (MonEspaceNIS2, BSI, ACN).
4. DPA RGPD signé avec le fournisseur de status page, incluant la liste des sous-traitants.
5. Registre des fournisseurs ICT à jour, conforme DORA Article 28 paragraphe 3.
6. Exit strategy du fournisseur de status page testée annuellement et documentée.
7. Plan de communication de crise validé par le COMEX (rôles, messages-types, canaux).

Volet technique (dix points)

1. Status page hébergée hors infrastructure applicative, avec preuve d'indépendance testée.
2. Horodatage RFC 3339 UTC partout, sans exception (interface, API, exports).
3. Severity codée sur 4 niveaux minimum (operational, degraded, partial outage, major outage).
4. Export structuré disponible en JSON, RSS et Atom, complété par ICS pour la maintenance.
5. Audit trail visible sur chaque mise à jour, identifiant l'auteur (rôle minimum).
6. Versionnage des mises à jour incidents, jamais d'écrasement rétroactif.
7. Monitoring multi-régions en place sur au moins 4 zones (EU, US, APAC, UK).
8. Notifications cross-canal opérationnelles : e-mail, webhook, RSS, SMS optionnel.
9. Archivage immuable WORM ou registre signé sur au minimum 6 ans.
10. Sécurité du domaine status : DNSSEC actif, HTTPS strict, HSTS, CAA, test HSTS validé.

Volet organisationnel (huit points)

1. Rôle « DORA Incident Notifier » désigné par écrit, avec backup (équivalent CSSF eDesk role).
2. Astreinte 24/7 sur le canal status page, avec rotation documentée et calendrier annuel.
3. Drill 4 heures trimestriel sous forme de tabletop exercise, suivi d'un post-mortem du drill.
4. Mapping documenté des autorités nationales par juridiction (ACPR / BaFin / ACN / CSSF / Banca d'Italia + CSIRT NIS2 + CNIL et équivalents RGPD).
5. KPI « delay-to-publish » suivi en continu, avec objectif inférieur à 15 minutes.
6. Communications clients pré-rédigées par scenario, validées par DPO et direction juridique.
7. Formation annuelle des équipes SRE et communication sur les obligations DORA et NIS2.
8. Revue annuelle COMEX et conseil d'administration sur les incidents majeurs (DORA Article 17).

Pour intégrer cette checklist directement dans votre backlog d'audit, deux exports opérationnels sont disponibles : télécharger la checklist au format CSV (pour import Excel ou Google Sheets) ou au format JSON (pour ingestion dans un GRC, Jira ou Notion). Chaque ligne contient la catégorie, le numéro, le point, la priorité et l'évidence requise pour la défense documentaire.

Télécharger la checklist de déploiement

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser la checklist.

• Télécharger la checklist DORA/NIS2 (CSV)
• Télécharger la checklist DORA/NIS2 (JSON)

Glossaire

• CIFA : Critical or Important Function Arrangement, fonction critique ou importante au sens de DORA Article 28.
• CTPP : Critical Third-Party Provider, fournisseur tiers critique désigné par les ESA et soumis à supervision directe.
• DORA : Digital Operational Resilience Act, règlement UE 2022/2554, entré en application le 17 janvier 2025.
• NIS2 : Network and Information Security Directive 2, directive UE 2022/2555, à transposer dans les droits nationaux.
• ESA : European Supervisory Authorities, regroupant l'EBA (banques), l'EIOPA (assurances) et l'ESMA (marchés financiers).
• CSIRT : Computer Security Incident Response Team, équipe nationale désignée par chaque État membre pour NIS2 (CERT-FR, BSI, ACN, etc.).
• RTS / ITS : Regulatory Technical Standards et Implementing Technical Standards, publiés par les ESA pour préciser DORA.
• WORM : Write Once Read Many, mode de stockage immuable garantissant l'absence de réécriture.

Conclusion

L'année 2026 acte la bascule entre la phase de transition et l'enforcement actif des deux régulations européennes structurantes pour la résilience opérationnelle numérique. Pour un SaaS B2B européen, la status page publique cesse d'être un outil de communication marketing et devient un livrable d'audit, opposable à un superviseur national. Trois priorités émergent au titre du règlement DORA SaaS comme de la conformité NIS2 : héberger la status page sur une infrastructure indépendante, exporter un format JSON pivot aligné JC 2024-33, organiser un drill trimestriel de 4 heures pour valider la chaîne complète. Les éditeurs qui anticipent cette transformation entre 2026 et 2027 transformeront une obligation réglementaire en avantage commercial. Un client financier ou un opérateur essentiel préférera toujours un fournisseur dont la status page peut servir directement à son propre rapport régulateur, plutôt qu'un fournisseur où chaque incident exige une reconstruction manuelle de la preuve. Pour commencer à industrialiser cette démarche, l'hébergement d'une status page conforme constitue le point d'entrée le plus rapide.