DORA, NIS2 and status pages: turning incident communication into EU compliance evidence

⚡TL;DR

• DORA Article 19 requires an initial notification 4 hours after classification of a major incident (24 hours maximum after detection), an intermediate report at 72 hours and a final report at 1 month, official figures confirmed by the RTS/ITS JC 2024-33 published by the ESAs on 17 July 2024.
• NIS2 Article 23 imposes an early warning at 24 hours, a notification at 72 hours and a final report at 1 month, applicable to 18 essential and important sectors in Europe.
• A public timestamped status page, archived and exportable in JSON, satisfies the three properties of admissible evidence: RFC 3339 UTC timestamp, immutable audit trail, verifiable public accessibility.
• The ACPR notes in its 8-month DORA review (January 2026) that the 4-hour deadlines are "still rarely met". 2026 marks the end of tolerance and the beginning of active enforcement.
• ICT third-party risk (DORA Article 28) requires a contractual review of the status page provider: jurisdiction, data localisation, exit strategy, audit rights.

On 15 January 2026, the ACPR published its eight-month review of DORA enforcement, concluding that the four-hour notification deadlines are "still rarely met" by French financial entities. In Frankfurt and Luxembourg, BaFin and CSSF report an equivalent finding. On the NIS2 side, 22 of the 27 Member States transposed the NIS2 directive by 1 April 2026: Germany brought the NIS2UmsuCG into force on 6 December 2025, Italy has applied legislative decree 138/2024 since 16 October 2024, and France is awaiting the promulgation of the Resilience Act adopted on 26 February 2025. For European B2B SaaS providers, DORA compliance is no longer a paperwork exercise; it is an operational discipline measured in minutes.

In this landscape, an operational question comes up in every audit: how do you prove that an incident notification was actually issued within the deadlines? Internal emails get lost, ServiceNow tickets get closed, screenshots can be contested. What remains is a public, timestamped artifact, accessible at any time from the outside: the status page. Yet, for most European B2B SaaS providers, this page remains a marketing communication tool, not an audit deliverable. The regulatory shift that played out between 2024 and 2026 radically changes this status, and reshapes the DORA incident reporting timeline expected from every ICT provider.

This article addresses CTOs, CISOs, Heads of SRE and DPOs who must drive DORA compliance and NIS2 compliance for a European B2B SaaS. It is structured in three parts: an educational segment on the regulations, an operational segment on the anatomy of a compliant status page, and a checklist segment to prepare for an inspection. You will leave with a unified deadlines map, a JSON export template aligned with the DORA RTS/ITS templates, a seven-step framework and a 25-point checklist.

The starting observation is simple: the public status page combines, at no additional technical cost, the three properties of admissible evidence. It just needs to be designed with that intent. The following sections show how to turn an operational tool into an audit deliverable, drawing on official texts (EUR-Lex, ESA RTS/ITS, ANSSI, ACPR, BaFin, CSSF, Banca d'Italia) and the most recent public feedback.

Why the status page enters the DORA compliance audit scope in 2026

The public status page was long perceived as a showcase. It reassured customers during an incident, prevented support saturation, and signalled a maintenance window. In 2026, its function changes. European regulators, with the ACPR in the lead, now consider that a public timestamped incident communication is an integral part of the ICT compliance file, without formally naming it "evidence" in the texts, but consistently calling for it during documentary inspections.

The regulatory shift from courtesy page to audit artifact

Three factors explain this shift. First, the end of the DORA transition period. EU Regulation 2022/2554 entered into application on 17 January 2025. The first eight months served as an observation period, during which supervisors did not apply massive sanctions. From the first quarter of 2026, the ACPR, BaFin, the Central Bank of Luxembourg and Banca d'Italia confirmed they had moved into active enforcement mode. Second, the NIS2 transposition is becoming widespread. By 1 April 2026, 22 of 27 Member States had adopted a national text, covering the majority of European economic operators. Finally, ENISA published its Threat Landscape in October 2025, documenting an intensification of ICT incidents, which pushes regulators to tighten their transparency requirements.

Three converging forces of regulation, security and supply chain

DORA applies to financial entities and their critical ICT providers. NIS2 covers 18 sectors (energy, health, transport, digital, food, public infrastructure, etc.). For a European B2B SaaS vendor, two scenarios coexist. First scenario: the vendor is itself an essential or important operator within the meaning of NIS2 (for example a cloud hosting provider, a managed service provider, a qualified e-signature publisher). It is then directly subject to NIS2. Second scenario: the vendor serves a bank, an insurer, a fintech subject to DORA. It then becomes an ICT provider within the meaning of DORA Article 28, and its client must contractually impose resilience, auditability and reporting obligations. In both cases, the status page moves out of the marketing scope and into the contractual and regulatory scope.

The supply chain also comes into play. NIS2 Article 21 paragraph 2 imposes explicit management of supplier and supply-chain risks. An unreported failure by a subcontractor can be attributed to the main operator. The status page then serves as a contractual notification mechanism between links in the chain.

What supervisors say in practice

Public positions converge. The ACPR, through its OneGate portal and its DORA FAQ, insists on the traceability of notifications. German BaFin, in its official article on DORA reporting, requires consistency between public communication and the regulatory report. Luxembourg's CSSF published circulars 25/892 and 25/893 in May 2025, which detail classification and reporting. ANSSI, in France, operates the MonEspaceNIS2 portal which centralises NIS2 notifications for essential and important operators. The message is uniform: a public timestamped trace is required, and it is not optional. It is a structural complement to the confidential regulatory report.

For operational teams, this means rethinking the design of the status page as an audit deliverable from the architecture phase, and not as a reactive communication channel. This is exactly what the CaptainDNS status page tool enables, designed to natively produce an admissible artifact.

Key takeaway: in 2026, your status page can be cited as admissible evidence by your regulator. Designing it as such from the start avoids a costly rework at audit time.

DORA Article 19 unpacked: 4h, 72h, 1 month

EU Regulation 2022/2554, known as the DORA regulation, applies to European financial entities and their critical ICT providers. Its Chapter III, and more specifically Article 19, governs the notification of major ICT incidents. For a B2B SaaS vendor serving a bank or insurer, understanding this article is not a legal matter: it dictates the operational orchestration of an incident and anchors the DORA incident reporting timeline that every supervisor verifies first.

Scope of financial entities and critical ICT providers

DORA Article 2 lists 20 categories of financial entities: credit institutions, payment institutions, account information service providers, crowdfunding service providers, investment firms, trading venues, central securities depositories, central counterparties, collective investment undertaking managers, insurance and reinsurance undertakings, insurance intermediaries, occupational retirement institutions, rating agencies, benchmark administrators, crypto-asset service providers, securitisation repositories, funds, etc. All these entities are directly subject to DORA.

Chapter V (Articles 28 to 44) contractually extends DORA obligations to ICT providers. If a provider underpins a critical or important function (CIFA, Critical or Important Function Arrangement), the contractual clauses are mandatory. If a provider exceeds the thresholds defined by the ESAs (European Supervisory Authorities: EBA, EIOPA, ESMA), it can be designated a "critical third-party provider" (CTPP) and fall under direct supervision.

The temporal triptych of 4h, 72h and 1 month

Article 19 imposes three deadlines to notify an ICT incident classified as major:

• Initial notification: 4 hours after the classification of the incident as major, with a maximum bound of 24 hours after detection.
• Intermediate report: 72 hours after detection.
• Final report: 1 month after detection.

The detail of the deadlines and mandatory fields is set out in the final technical standards document JC 2024-33 published on 17 July 2024 by the three European authorities EBA, EIOPA and ESMA. These are Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) which specify the expected content of each report. The initial notification must contain nine fields: entity identity, detection timestamp, classification timestamp, preliminary description, classification criteria activated (DORA Articles 17 and 18), estimated impact, immediate measures taken, next planned steps, dedicated contact.

Classification relies on the criteria of DORA Article 18: materiality of impact (number of clients affected, duration, geography, data loss, criticality of the interrupted service, economic severity). The 4-hour deadline starts when the entity formally concludes that the incident is "major", not at detection. This nuance changes everything in practice: the decision chain must be documented (who classified, on what criteria, at what time UTC), failing which the regulator can requalify the deadline and conclude there was a breach.

Who to notify in practice according to your jurisdiction

Entities notify their national competent authority:

• France: ACPR via the OneGate portal (JSON format, no electronic signature required). When OneGate is unavailable (midnight to 4 am, Sundays), submission is by email to 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr.
• Germany: BaFin via the MVP portal (Meldungs- und Veröffentlichungsplattform), in XBRL format.
• Luxembourg: CSSF via the eDesk portal (Circular 25/893), accompanied by a standardised classification matrix.
• Italy: Banca d'Italia via its dedicated DORA incidents portal, in CSV or XML format.

For designated CTPPs, supervision is jointly performed by ESAs and the national regulator, with a Joint Examination Team (JET) that can audit on site. A B2B SaaS vendor serving several European banks may need to notify multiple authorities in parallel for a single incident, hence the critical interest of a pivot format such as JSON exploited from its status page, which echoes the logic of resilient DNS monitoring documented previously.

Sanctions under articles 50 to 58

DORA provides for heavy administrative sanctions. For financial entities: up to 2% of annual worldwide turnover or 10 million euros (whichever is higher), with individual fines up to 1 million euros for the persons responsible. For CTPPs: up to 1% of average daily worldwide turnover, for a maximum of six months. Beyond fines, sanctions are published (Article 54), which adds significant reputational cost. The ACPR review of January 2026 specifies that the active enforcement phase started in the first quarter of 2026, but without yet citing a public sanctioned case, a signal that regulators are preparing their files quietly.

Key takeaway: 4 hours after classification, you must have 9 mandatory fields ready to transmit. If your status page already exports these fields, you have won most of the race.

NIS2 Article 23 and the 24h, 72h, 1 month cascade

EU Directive 2022/2555, known as NIS2, complements DORA by covering all essential and important sectors outside pure finance. Its Article 23 sets a distinct notification cascade, broader in scope, and with a different starting point. For a European B2B SaaS, NIS2 often applies in parallel to DORA, and orchestrating both is the main operational challenge of 2026.

Extended scope across eighteen sectors and the supply chain

Annexes I and II of NIS2 list 18 sectors. Annex I distinguishes highly critical sectors (energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, B2B IT services management, public administration, space), Annex II the other critical sectors (postal and courier services, waste management, manufacturing, production and distribution of chemicals, production and processing of food, digital service providers, research). The size of the entity (≥ 50 employees and turnover ≥ 10 million euros for "important" status, higher thresholds for "essential") determines whether it falls under NIS2.

NIS2 Article 21 paragraph 2 letter d requires management of supply chain security, including security aspects concerning direct relationships between suppliers and providers. A status page poorly handled by a supplier can entail the liability of the client essential or important operator.

Early warning at 24h, notification at 72h, final report at 1 month

Article 23 organises notification in three stages:

• Early warning within 24 hours of awareness of a significant incident.
• Incident notification within 72 hours of awareness, including an initial assessment, indicators of compromise and a severity description.
• Final report within one month of notification, with detailed root cause analysis.

The critical starting point: "awareness", not technical "detection" or formal "classification". As soon as an internal team is aware of a significant incident, the clock starts. An incident is "significant" if it has caused or is likely to cause a serious disruption to services, significant financial losses, or has affected or is likely to affect third parties by causing considerable material or immaterial damage.

National transpositions in spring 2026

The state of play as of 1 April 2026:

• France: Resilience Act adopted by the National Assembly on 26 February 2025, promulgation expected in the first half of 2026. ANSSI operates the MonEspaceNIS2 portal and coordinates CERT-FR as the national CSIRT. Compliance period: 3 years after promulgation. To follow the evolution of long-term observation retention, see the DNS traceability published by CaptainDNS in November 2025.
• Germany: NIS2UmsuCG promulgated on 5 December 2025, in force on 6 December 2025. The BSI published the operational details: approximately 30,000 entities concerned, mandatory registration within 3 months, "board accountability" level sanctions.
• Italy: legislative decree 138/2024 published on 4 September 2024, in force on 16 October 2024. The ACN (Agenzia per la Cybersicurezza Nazionale) operates the notification portal, supplemented by DPCM 221 of 9 December 2024.
• Luxembourg, Netherlands, Belgium, Spain, Portugal, Poland, Nordic countries, Baltic states: effective or imminent transposition (parliamentary procedure ongoing).
• Five States lagging behind as of 1 April 2026: risk of infringement procedures under Article 258 TFEU.

Difference between the directive and the data protection regulation

NIS2 and GDPR partially overlap. An incident can be both a NIS2 "significant incident" and a GDPR "personal data breach". Notifications are then parallel: national CSIRT for NIS2, data protection authority (CNIL in France) for GDPR. The GDPR Article 33 deadline is 72 hours "after becoming aware". NIS2 adds a 24-hour early warning, which creates an additional obligation. For a vendor operating a SaaS storage service that suffers an intrusion involving personal data, three reporting channels may be triggered (NIS2 + GDPR + DORA if the client is financial), hence the importance of a single timestamped source, which is precisely the public status page.

Key takeaway: under NIS2, the 24h clock starts as soon as internal awareness exists, not after formal classification. Prepare your teams to publish a public message in the first 4 hours so you don't have to do everything in the 23rd hour.

Unified map of the three European regulations

Operational complexity arises from the intersection of the three regulations. For a vendor serving both financial entities and NIS2 essential operators, the same incident can trigger three notification channels, with different deadlines and recipients. The status page then plays the role of timestamped common denominator.

Cross-table of deadlines

Regulation	Trigger	Initial deadline	Intermediate	Final	Recipient authority	Maximum sanction
DORA Article 19	ICT incident classified as major (Art. 17-18)	4h after classification (24h max after detection)	72h after detection	1 month after detection	ACPR (FR) / BaFin (DE) / CSSF (LU) / Banca d'Italia (IT)	2% worldwide turnover or 10M€ (entity) / 1% average daily turnover for 6 months (CTPP)
NIS2 Article 23	Significant incident	24h early warning	72h notification	1 month final report	National CSIRT (CERT-FR / BSI / ACN / etc.)	10M€ or 2% worldwide turnover (essential) / 7M€ or 1.4% worldwide turnover (important)
GDPR Article 33	Personal data breach	72h after awareness	n/a	(subject to CNIL investigation)	CNIL (FR) or national equivalent	20M€ or 4% worldwide turnover

Trigger event and who starts when

Three distinct starting points coexist. DORA starts from classification as a major incident (formal, documented, dated). NIS2 starts from internal awareness of a significant incident. GDPR starts from becoming aware of a breach. The shortest operational deadline is 4 hours (DORA), but it starts late (after classification). The earliest is the NIS2 24h early warning, which may start several hours before the DORA classification.

For ops teams, this means a single incident can be simultaneously ahead of NIS2 and behind on DORA, hence the need for a common log and a fast classification mechanism. On the supervision side, the multi-region HTTP uptime monitor tool provides the objective technical timestamp on which classification relies.

Whom to notify with the complete mapping by jurisdiction

For B2B SaaS vendors operating in several European countries, here is the recipients matrix:

• France: ACPR (DORA), CERT-FR via MonEspaceNIS2 (NIS2), CNIL (GDPR).
• Germany: BaFin (DORA), BSI (NIS2), BfDI or Land authority (GDPR).
• Italy: Banca d'Italia (DORA, via dedicated portal), ACN (NIS2), Garante (GDPR).
• Luxembourg: CSSF (DORA via eDesk), GovCERT-LU (NIS2), CNPD (GDPR).
• Spain: Banco de España and CNMV (DORA), INCIBE-CERT (NIS2), AEPD (GDPR).
• Netherlands: DNB and AFM (DORA), NCSC-NL (NIS2), AP (GDPR).

The idea of a single European entry point is gaining ground: the Digital Omnibus package presented by Bird & Bird anticipates harmonisation 18 months post-adoption. In 2026, this harmonisation is not yet effective: multiple notifications must therefore be steered manually, and the status page remains the only consistent deliverable across all jurisdictions.

---

Build a DORA and NIS2 compliant status page starting today

---

Key takeaway: when 3 regulations apply, the shortest window wins, often DORA's 4 hours. The public timestamped status page serves all three in parallel.

The status page as admissible evidence for DORA compliance audits

Admissible evidence in legal terms combines three properties: reliable timestamping, immutability, verifiable public accessibility. No other technical artifact of a B2B SaaS ticks all three boxes at once. Internal logs are not publicly accessible. Post-mortem PDFs can be edited after the fact. Customer emails are not cryptographically timestamped. The public status page meets all three conditions, provided it has been designed with that intent.

Three evidentiary properties of signed timestamp, immutable archive and public audience

The timestamp must follow RFC 3339 in UTC format. This is the standard recognised by all European jurisdictions for electronic operations (eIDAS, eIDAS 2). Local time timestamping (CET, CEST, BST) is unacceptable because it is ambiguous around daylight saving transitions. Qualified timestamping within the meaning of RFC 3161, signed by a qualified Trust Service Provider, is legally even more solid, but remains optional in practice as long as the UTC timestamp is consistent and verifiable.

Immutability rests on the audit trail: each incident update must be versioned, never overwritten. If you correct a message at 14:17 UTC after a publication at 14:02 UTC, both versions must remain accessible, with the mention "edited at 14:17". This editorial discipline resembles the practice of online media regarding factual corrections.

Public accessibility is what distinguishes the status page from an internal log. The page must be consultable without authentication, from anywhere on the Internet. This requires hosting infrastructure separate from the main application: if your application goes down, your status page must remain up. This is an architectural requirement reinforced by active DNSSEC on the status domain and strict HTTPS.

The Cloudflare R2 reference case of 21/03/2025

Cloudflare publicly documented an incident on its R2 service on 21 March 2025. The company published a detailed post-mortem three days after the incident. The sequence is exemplary: status page announcement at 14:04 UTC (shortly after the start of the degradation), updates every 15 to 30 minutes, identification of the root cause (storage configuration issue), resolution announced at 15:11 UTC, full post-mortem on 24 March with detailed timeline, root cause, next corrective steps. The status page serves here as a temporal pivot: it timestamps the operational commitments, and the later post-mortem refers to it explicitly.

For a European B2B SaaS vendor, this model is directly transposable. It does not require exotic tooling: it requires editorial discipline and a structured export format.

When the status page provider itself goes down

OneUptime documented a revealing case: between 2 and 23 February 2026, the system metrics module of Atlassian Statuspage remained unavailable for 21 consecutive days. The analysis published by OneUptime on 25 February 2026 highlights the paradox: a status page provider that cannot maintain the SLA of its own components cannot serve as an audit artifact for its customers. Risk concentrated on a single provider becomes a direct contractual vulnerability.

ACPR eight-month review and regulatory tension versus operational reality

The ACPR review of 15 January 2026 reports that the 4-hour deadlines are "still rarely met". This observation is not a free pass: it accompanies the announcement of the move into active enforcement mode. The implicit message: 2026 marks the transition between tolerance and sanction. For entities that do not yet have a compliant status page, the sanction risk is concrete. On the principles of TLS security and chain of trust, the rigour of timestamping and signature aligns with the same cryptographic requirements.

Key takeaway: only a public timestamped status page combines the three properties of admissible evidence. Designing it as such today is a very high-return regulatory investment.

Anatomy of a DORA-ready status page across ten mandatory attributes

A status page designed as an audit deliverable must tick ten technical boxes. The list below synthesises the combined expectations of European supervisors (ACPR, BaFin, CSSF, Banca d'Italia, ACN) and the operational best practices of the most mature vendors.

Attribute 1, clear identification of components and services. Granularity must descend to the product/region level. A label "API" is insufficient; you need "API REST v3, EU-West region", "API REST v3, US-East region", "B2B SFTP", "Webhooks". This allows declaring a partial incident without triggering unjustified panic across the entire service.

Attribute 2, RFC 3339 UTC timestamps everywhere. No local-time dates. No dates without time zone. Conversion to local time happens client-side in the browser. UTC consistency guarantees legal admissibility.

Attribute 3, coded and stable severity. Four levels minimum: operational, degraded performance, partial outage, major outage. The labels must be stable over time (no marketing renaming). The underlying numeric code (e.g. 0/1/2/3) must flow through the JSON feed to enable automation.

Attribute 4, explicit link to the current incident and stable identifier. Each incident must have a unique identifier, persistent after resolution, accessible via a canonical URL. Regulators often ask: "Give us the exact URL of the public communication for incident XYZ."

Attribute 5, visible audit trail. Each update must be versioned, dated, and identify the author (at least by role or identifier). Subsequent edits must remain visible with mention "edited on…".

Attribute 6, structured export in JSON, RSS, Atom, ICS. JSON serves automated extraction to regulator reports. RSS and Atom serve customer subscriptions (and sourcing by tools like StatusGator or IsDown). ICS serves planned maintenance for customer teams.

Attribute 7, infrastructure independence. The status page must be hosted outside the monitored application perimeter. If your application is on AWS Frankfurt, your status page must not be. This independence is non-negotiable: it is what distinguishes a useful deliverable during a major outage from a placebo.

Attribute 8, versioning of updates. Direct consequence of attribute 5: an immutable storage system such as Write-Once-Read-Many (WORM) or a signed registry guarantees that no retroactive rewrite is technically possible.

Attribute 9, cross-channel notifications. Email, webhook, RSS and optional SMS. Regulators often request to be subscribed during inspections: refusing a subscription channel is not an option.

Attribute 10, long-term retention. Snapshot archiving (JSON and HTML) must cover at least 6 years to align DORA Articles 5 to 14 (ICT risk framework, incident register) and NIS2 national transpositions. France mandates 6 years in the adopted Resilience Act. Italian and German transpositions retain a minimum of 5 years.

---

Aside on ICT third-party risk and DORA Articles 28 and 30 contractual clauses

DORA Chapter V governs the relationships between financial entities and ICT providers. Article 28 requires maintaining a register of ICT contractual arrangements, classification of critical or important functions (CIFA), and concentration of third-party risk. Article 30 enumerates the minimum contractual clauses: clear service description, measurable service levels, data localisation, information security, data accessibility and return, audit rights, exit strategy.

For a European B2B SaaS vendor or client, these two articles dictate an objective line of questioning when choosing a status page provider:

• Data localisation. Is the hosting of status page data (incidents, comments, metadata) contractually guaranteed in Europe? Are subcontractors (CDN, backups, internal monitoring) all located in Europe?
• Provider jurisdiction. A provider whose parent company is in the United States activates the CLOUD Act risk (Clarifying Lawful Overseas Use of Data Act, 2018), which allows US authorities to require data stored by a company under US jurisdiction, regardless of the country of physical storage. This does not automatically disqualify the affected providers (Atlassian Statuspage, for example), but requires strengthened GDPR Standard Contractual Clauses (SCC) and an explicit DPA.
• Certifications. SOC 2 Type II and ISO 27001 are useful but not sufficient for DORA, which requires sector-specific auditability for finance. Explicitly request a Statement of Applicability including the DORA Article 28 clause.
• Subcontractor register. A DORA-compliant provider must be able to provide the up-to-date list of its sub-processors with their location and role. Refusal = warning signal.
• Tested exit strategy. The ability to recover your entire status page history in an open format (JSON, CSV) in less than 72 hours must be contractualised and tested annually. A makeshift export in an emergency does not hold up before an auditor.

US providers (Atlassian Statuspage, StatusGator, certain BetterStack offerings depending on the contract jurisdiction) coexist with European alternatives (Instatus EU, CaptainDNS, OpenStatus in self-hosted mode). The choice is not about features or pricing, it is about alignment with DORA Articles 28 and 30. For the detail of contractual clauses, consult the Bird & Bird summary on DORA contractual clauses. On the same logic of contractualised European hosting, see also the complete MTA-STS guide.

---

Key takeaway: 10 technical attributes plus 1 legal question about jurisdiction form the anatomy checklist. Any failure on one attribute is an audit risk, not a product detail.

Incident report template from status page JSON to DORA report

The goal of a DORA-ready status page is not only to communicate publicly. It is also to directly feed the confidential regulatory report, without repeated manual entry. The pivot between the two is a structured JSON file, derived from the status page and transposed onto the RTS/ITS JC 2024-33 templates.

Field-by-field correspondence between the status page export and the regulator template

The initial DORA report requires nine minimum fields. The table below shows the correspondence with a status page JSON export:

• entity_id (status page) → "LEI" or national identifier field of the DORA report.
• incident.uuid (status page) → "Reference number" field of the report.
• incident.detected_at (RFC 3339 UTC timestamp) → "Date and time of detection" field.
• incident.classified_at → "Date and time of classification" field.
• incident.preliminary_description → "Description of the incident" field.
• incident.classification_criteria (coded list Art. 18) → "Classification criteria activated" field.
• incident.impact_estimate (clients, duration, geography, data) → "Estimated impact" block.
• incident.immediate_actions (array of measures) → "Immediate measures taken" field.
• incident.contact (email + phone of the DORA contact) → "Reporting contact" field.

JSON example for a DDoS incident classified as major

{
  "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 for extraction and transmission

Industrialising the flow relies on three building blocks. A cron task reads the status page every 5 minutes, serialises incidents in JSON format, signs the file with a detached signature (PGP or cosign). A second task, triggered by a webhook upon classification, prepares the regulator version by mapping fields to the official XSDs (XBRL for BaFin, XML for Banca d'Italia, JSON for ACPR OneGate). A third building block handles transmission via the dedicated APIs or portals (OneGate API, eDesk CSSF, MVP BaFin), with retry in case of portal unavailability.

On securing the email transport of complementary notifications, the rigour of hosted MTA-STS policies follows the same logic of cryptographic proof usable in audit.

Key takeaway: if your status page exports this JSON, you complete the DORA report in 4 hours without re-keying. That is the difference between meeting the deadline and missing it.

Practical seven-step framework (HowTo)

To move from concept to operations, here is a seven-step framework, applicable over 90 days for a European B2B SaaS with a baseline SRE team.

DORA and NIS2 status page compliance framework

Seven steps to make your status page admissible facing an ACPR, BaFin, ACN or CSSF audit within 90 days.

1. Step 1: service inventory and criticality classification

   Draw up the exhaustive list of exposed services and associate each with a criticality under DORA (CIFA / non-CIFA) or NIS2 (essential / important / out-of-scope). Document the criterion retained and the classification method. This inventory is the foundation of all subsequent commitments. Without a clean inventory, it is impossible to justify to the regulator why a sub-service does not appear on the status page.

2. Step 2: provider selection under DORA Articles 28 and 30

   Evaluate each candidate against five objective criteria: provider jurisdiction, data localisation, documented subcontractors, contractualised exit strategy, technical audit trail. A provider without a written answer on these five points must be discarded, regardless of its features. The contractual review must be validated by the legal department before signature.

3. Step 3: multi-region architecture and DNS independence

   Host the status page on infrastructure strictly distinct from the application perimeter. Separate DNS (dedicated status. subdomain, distinct authority), geographically separate hosting. Activate DNSSEC, HSTS and CAA on the status domain. Independence must be tested: artificially cut the main application in test and verify that the status page remains consultable. Without a test, independence is just a declaration.

4. Step 4: incident templates for four severity levels

   Prepare four public announcement templates: operational maintenance, degraded performance, partial outage, major outage. Each template includes the mandatory fields (UTC timestamps, severity, components affected, immediate measures, estimated ETA). The templates must be validated by the DPO, the legal department and the communications department. Without pre-validation, each incident requires an urgent review that costs precious time.

5. Step 5: timestamped and sealed archive pipeline

   Implement a timestamped snapshot every 5 minutes (JSON + HTML) deposited in immutable storage (S3 Object Lock in compliance mode, or local signed registry such as sigstore). Minimum retention 6 years. The detached signature of the snapshot must be deposited separately to enable integrity verification by a third party.

6. Step 6: quarterly tabletop exercise test

   Organise every three months a tabletop exercise simulating a major incident. The objective: validate that the delay between detection and public publication remains below 15 minutes, and that the DORA classification is documented in less than 4 hours. The test must involve SRE, comms, legal, DPO and a member of the executive committee. A written report of the tabletop is part of the auditable evidence.

7. Step 7: annual review aligned with ACPR, BaFin, ACN, CSSF audits

   Organise annually a formal (board level) review that examines the major incidents of the year, verifies notification compliance, validates status page evolutions and arbitrates investments for the following year. This review is required by DORA Article 17 (ICT risk management governance and organisation). Without written evidence of this review, the auditor can conclude there is a governance failure, which aggravates any sanction.

The sequence of steps 1 to 4 prepares the infrastructure; steps 5 and 6 lock in the evidence and resilience; step 7 institutionalises the approach. For teams that have never run a simulation, the initial investment seems high. It is actually negligible against the sanction risk. On the rigour of HTTPS and HSTS controls associated with the status domain, see the HSTS preload guide.

Key takeaway: without a quarterly 4-hour drill, you will discover in production that your notification process does not hold. The drill costs half a day. A failed notification costs 10 million euros.

Frequently asked questions

FAQ

Is our SaaS affected by DORA if we provide a service to a bank?

Yes, indirectly. DORA Articles 28 and 30 require financial entities to contractually pass on the obligations to their ICT providers, particularly those underpinning a CIFA (Critical or Important Function Arrangement). You will therefore be subject to mandatory contractual clauses: data localisation, audit rights, exit strategy, measurable service levels. If you are designated a CTPP (Critical Third-Party Provider) by the ESAs, you fall under direct supervision. The status page then becomes a quantified and admissible contractual deliverable.

What is the exact deadline for an initial DORA notification?

Four hours after the classification of the incident as major, with a maximum bound of 24 hours after detection. Classification relies on DORA Article 18 and the materiality criteria (customer impact, duration, geography, data loss, service criticality). The deadline starts at the moment of the "major incident" verdict, not at detection. The JC 2024-33 document published in July 2024 by the ESAs lists the nine mandatory fields of the initial report: entity identity, detection timestamp, classification timestamp, preliminary description, classification criteria, estimated impact, immediate measures, next steps, dedicated contact.

What is the operational difference between DORA and NIS2 for our status page?

DORA applies primarily to the financial sector (banks, insurers, funds, payment service providers) and starts its clock 4 hours after classification. NIS2 covers 18 essential and important sectors (energy, health, digital, transport, food, etc.) and starts 24 hours after internal awareness of the incident. The two converge on 72 hours of intermediate notification and 1 month for the final report. If you are in both perimeters (rare but possible), DORA prevails due to the shorter deadline. The status page serves both regulations with the same timestamped artifact, provided that the JSON export format covers the fields of both templates.

Can the status page really serve as admissible evidence in audit?

A public page that is timestamped, archived and exportable in JSON, RSS or Atom meets the three properties of admissible evidence: RFC 3339 UTC timestamp, immutability via visible audit trail, verifiable public accessibility. No post-mortem PDF or internal log combines these three criteria. Several European regulators (ACPR, BaFin) now consider public incident communication as an integral part of the ICT audit file, without formally naming it "evidence", but it is regularly cited during documentary inspections. By comparison, a qualified RFC 3161 timestamp by a Trust Service Provider provides an additional legal level.

Is our US Atlassian Statuspage status page compatible with DORA Article 28?

The question is not absolute incompatibility, but management of ICT third-party risk and jurisdiction. A status page provider under US jurisdiction activates the CLOUD Act and requires strengthened SCC (Standard Contractual Clauses) and a GDPR DPA. To remain compliant with DORA Articles 28 to 30, require the provider: European localisation of data and logs, audit clauses, annually tested exit strategy, ISO 27001 and SOC 2 Type II certifications, up-to-date subcontractor register. If your service underpins a CIFA, these clauses are mandatory, not optional. Failing this, your financial client will have to arbitrate between maintaining the contract and regulatory risk.

What are the 5 pillars of DORA?

DORA rests on five structuring pillars. First pillar: ICT risk management (Articles 5 to 15), which imposes an ICT risk governance and management framework. Second pillar: ICT-related incident management, classification and reporting (Articles 17 to 23), which includes Article 19 on reporting. Third pillar: digital operational resilience testing (Articles 24 to 27), including TLPT (Threat-Led Penetration Testing) for significant entities. Fourth pillar: management of ICT third-party risk (Articles 28 to 44), which dictates contracts with ICT providers, including the status page provider. Fifth pillar: information sharing arrangements (Article 45). Pillar 2 imposes the status page as artifact, pillar 4 dictates its contractual conditions.

Whom to notify in France for a DORA incident?

The ACPR via the OneGate portal, in JSON format, no electronic signature required. For OneGate unavailability periods (midnight to 4 am, Sundays and public holidays), submission is by email to 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr. For a NIS2 incident, the designated national CSIRT (CERT-FR via MonEspaceNIS2 once the Resilience Act is promulgated). For a GDPR incident involving personal data, the CNIL. The same incident may trigger two or three parallel routes, hence the critical operational interest of a pivot format such as status page JSON exploited once and transposed to each regulator template.

How long must we archive our status pages?

No deadline is explicitly set by DORA Article 19, but consistency with Articles 5 to 14 (ICT risk framework, incident register, audit trail) suggests a minimum of 5 to 6 years. GDPR requires being able to demonstrate compliance under Article 5 paragraph 2, with no set deadline. National regulators (ACPR, BaFin) typically request 5 years of auditable archives. The French Resilience Act adopted in February 2025 provides for 6 years for NIS2. Prudent recommendation: archive all status page snapshots (JSON and HTML) in immutable storage such as WORM or signed registry, for at least 6 years, with a documented restoration procedure within 72 hours.

Do we need a different status page per EU market (FR, DE, IT)?

No, a single multilingual status page is sufficient, provided that the content is identical in substance from one language to another. National regulators accept a unified deliverable as long as it is accessible in the language of the relevant jurisdiction. Beware of time zones: use UTC as the single source of truth and display local conversion client-side in the browser. If your service operates under several authorities (ACPR + BaFin + CSSF), maintain a stable and global incident identifier, translated by linguistic mapping, never by separate history. Duplicating history leads to temporal inconsistencies that are highly exposed in audit.

What happens if we miss a 4-hour DORA deadline?

Administrative sanctions up to 2% of annual worldwide turnover or 10 million euros (whichever is higher) for the entity, and up to 1 million euros individual fines for identified responsible persons. For CTPPs: up to 1% of average daily worldwide turnover, for six months. Beyond fines, reputational consequences via the publication of sanctions (Article 54). The ACPR, in its eight-month review of January 2026, notes that these 4-hour deadlines are "still rarely met". 2026 marks the end of tolerance and the beginning of active enforcement. Maintaining an exhaustive public trace (timestamped status page) is today the best insurance against an unfavourable requalification.

Final checklist of twenty-five points to validate before the audit

This checklist synthesises DORA, NIS2 and GDPR requirements applicable to the status page of a European B2B SaaS. It is structured in three blocks: documentary (7 points), technical (10 points), organisational (8 points). Ticking 25 out of 25 does not guarantee the absence of sanction, but places the entity in a solid defensive situation against an ACPR, BaFin, ACN, CSSF or Banca d'Italia inspection.

Documentary block (seven points)

1. Written incident classification policy signed by management (severity matrix mapped to DORA and NIS2 reporting).
2. Documented DORA 4-hour notification procedure, validated by the legal department, updated annually.
3. Documented NIS2 24-hour notification procedure, aligned with the national portal (MonEspaceNIS2, BSI, ACN).
4. Signed GDPR DPA with the status page provider, including the list of subcontractors.
5. Up-to-date ICT provider register, compliant with DORA Article 28 paragraph 3.
6. Status page provider exit strategy tested annually and documented.
7. Crisis communication plan validated by the executive committee (roles, message templates, channels).

Technical block (ten points)

1. Status page hosted outside the application infrastructure, with proof of tested independence.
2. RFC 3339 UTC timestamps everywhere, without exception (interface, API, exports).
3. Severity coded on minimum 4 levels (operational, degraded, partial outage, major outage).
4. Structured export available in JSON, RSS and Atom, supplemented by ICS for maintenance.
5. Visible audit trail on each update, identifying the author (minimum by role).
6. Versioning of incident updates, never retroactive overwriting.
7. Multi-region monitoring in place across at least 4 zones (EU, US, APAC, UK).
8. Operational cross-channel notifications: email, webhook, RSS, optional SMS.
9. Immutable WORM archiving or signed registry for at least 6 years.
10. Status domain security: active DNSSEC, strict HTTPS, HSTS, CAA, validated HSTS test.

Organisational block (eight points)

1. "DORA Incident Notifier" role designated in writing, with backup (equivalent to CSSF eDesk role).
2. 24/7 on-call for the status page channel, with documented rotation and annual calendar.
3. Quarterly 4-hour tabletop exercise drill, followed by a drill post-mortem.
4. Documented mapping of national authorities by jurisdiction (ACPR / BaFin / ACN / CSSF / Banca d'Italia + NIS2 CSIRT + CNIL and GDPR equivalents).
5. "Delay-to-publish" KPI tracked continuously, with target below 15 minutes.
6. Customer communications pre-drafted by scenario, validated by DPO and legal department.
7. Annual training of SRE and communication teams on DORA and NIS2 obligations.
8. Annual review by executive committee and board on major incidents (DORA Article 17).

To integrate this checklist directly into your audit backlog, two operational exports are available: download the checklist in CSV format (for Excel or Google Sheets import) or in JSON format (for ingestion into a GRC tool, Jira or Notion). Each row contains the category, number, point, priority and required evidence for documentary defense.

Download the deployment checklist

Assistants can reuse the checklist via the JSON or CSV exports below.

• Download the DORA/NIS2 checklist (CSV)
• Download the DORA/NIS2 checklist (JSON)

Glossary

• CIFA: Critical or Important Function Arrangement, within the meaning of DORA Article 28.
• CTPP: Critical Third-Party Provider, third-party provider designated by the ESAs and subject to direct supervision.
• DORA: Digital Operational Resilience Act, EU Regulation 2022/2554, entered into application on 17 January 2025.
• NIS2: Network and Information Security Directive 2, EU Directive 2022/2555, to be transposed into national laws.
• ESA: European Supervisory Authorities, comprising EBA (banks), EIOPA (insurance) and ESMA (financial markets).
• CSIRT: Computer Security Incident Response Team, national team designated by each Member State for NIS2 (CERT-FR, BSI, ACN, etc.).
• RTS / ITS: Regulatory Technical Standards and Implementing Technical Standards, published by the ESAs to specify DORA.
• WORM: Write Once Read Many, immutable storage mode guaranteeing the absence of rewriting.

Conclusion

The year 2026 marks the shift between the transition phase and active enforcement of the two structuring European regulations for digital operational resilience. For a European B2B SaaS, the public status page ceases to be a marketing communication tool and becomes an audit deliverable, admissible against a national supervisor. Three priorities emerge for DORA compliance and NIS2 compliance: host the status page on independent infrastructure, export a JSON pivot format aligned with JC 2024-33, organise a quarterly 4-hour drill to validate the complete chain. Vendors that anticipate this transformation between 2026 and 2027 will turn a regulatory obligation into a commercial advantage: a financial client or essential operator will always prefer a vendor whose status page can directly feed its own regulator report, rather than a vendor where each incident requires manual reconstruction of the evidence. To start industrialising this approach, hosting a compliant status page is the fastest entry point.