sota.io
2026-05-26·5 min read·sota.io Team

DORA Incident Reporting Requirements: Automation Tools for the 4h/72h/1-Month Cascade 2026

Post #1320 in the sota.io EU Financial Compliance Series

DORA incident reporting 3-phase notification cascade — EU compliance timeline

Your data centre loses connectivity at 02:17 on a Tuesday morning. Your on-call engineer pages in. By 06:17 — four hours after you classified the event as a major ICT incident — you were legally required to have filed the initial DORA notification with your national competent authority.

Most incident management teams discover this deadline in a post-mortem, not a pre-mortem.

DORA's incident reporting framework (Articles 17–23) is among the most operationally demanding regulatory requirements ever imposed on the European financial sector. The cascade is precise: initial notification within 4 hours, intermediate report within 72 hours, final report within one month. Each phase requires a growing set of mandatory data fields drawn from the ESA's Implementing Technical Standards — templates that most commercial incident management tools do not natively support.

The second problem: the leading incident management platforms — PagerDuty, OpsGenie, Splunk On-Call — all run on US infrastructure. Your incident data, which contains detailed information about your vulnerabilities, your customers' exposure, and your recovery measures, sits under CLOUD Act jurisdiction. The authority managing your breach notifications can itself be accessed by US law enforcement.

This post maps the DORA incident reporting requirements in full, scores the major tooling options (US and EU-native), and provides a practical migration path for financial services teams.

DORA Incident Reporting: Articles 17–23 at a Glance

DORA's incident reporting obligations apply to all entities covered by the regulation: banks, credit institutions, investment firms, insurance companies, crypto-asset service providers (CASPs), payment institutions, central securities depositories (CSDs), and central counterparties (CCPs). If you process financial transactions or hold financial assets in the EU, you are in scope.

Article 17 — Classification of major ICT-related incidents. Financial entities must classify ICT incidents according to criteria set by the Joint Committee of the European Supervisory Authorities (ESAs). An incident is "major" if it meets thresholds across multiple dimensions: number of clients affected, geographic spread, duration of service disruption, economic impact, reputational damage, and criticality of affected services.

Article 18 — Harmonised classification. The ESAs published joint guidelines specifying exact thresholds. A major incident triggers reporting obligations; a significant cyber threat (Article 23) triggers voluntary notification — but only one of these classifications activates the mandatory cascade.

Article 19 — Reporting obligation. Major incidents must be reported to the competent authority "without undue delay." The ESA Implementing Technical Standards (Commission Implementing Regulation (EU) 2024/2845) specify the three-phase structure.

Article 20 — Harmonisation of content and templates. The ESAs specify mandatory fields for each phase. These templates run to over 100 required data elements across the three reporting phases, covering everything from incident discovery timestamp to number of client accounts affected to the MITRE ATT&CK classification of attack techniques.

Article 21 — Single entry point. Member states may designate a single national authority to receive all DORA reports; that authority forwards to EBA, ESMA, or EIOPA depending on entity type. As of 2026, most jurisdictions still require direct NCA submission.

Article 22 — Supervisory feedback. The competent authority may provide feedback to the reporting entity, including guidance on remediation. This creates a bidirectional workflow requirement in your incident management system.

Article 23 — Voluntary notification of significant cyber threats. Even when an incident does not qualify as "major," financial entities may voluntarily notify the NCA of significant cyber threats. Some NCAs have indicated they expect voluntary notifications in borderline cases.

The 3-Phase Notification Cascade

Phase 1: Initial Notification (T+4 hours)

The 4-hour clock starts the moment you classify an incident as "major" — not when it begins, and not when you discover it. This distinction matters operationally: a slow-developing incident that crosses the "major" threshold at 15:45 requires the initial notification no later than 19:45.

Required in Phase 1 (ITS template):

The initial notification is intentionally brief — regulators understand you have limited information at T+4. But you must have a system capable of generating this submission with partially complete data while the incident is still in progress.

Phase 2: Intermediate Report (T+72 hours)

The intermediate report adds substantial analytical detail. Additional required fields include:

The 72-hour deadline runs from the initial notification, not from the incident itself. If you filed the initial notification at T+4, the intermediate report is due at T+72 from that filing.

Phase 3: Final Report (T+30 days)

The final report is the most comprehensive. Additional fields cover:

The final report effectively becomes a case study for the regulator. NCAs use final reports to identify systemic vulnerabilities across the financial sector — your incident data contributes to sector-wide risk assessments.

The Incident Data Paradox: CLOUD Act and Your Security Vulnerabilities

Here is the jurisdictional problem that most DORA compliance teams have not addressed.

Your incident management platform holds the most sensitive operational security data your organisation produces. Incident timelines document your vulnerabilities. Root cause analyses explain exactly how attackers or failures penetrated your defences. Recovery logs reveal your detection gaps. Client impact data identifies which customer segments are most exposed.

When this data sits on PagerDuty's AWS infrastructure, on Atlassian's OpsGenie cloud, or on Splunk On-Call's US servers, it falls under the Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 18 U.S.C. §2713). US law enforcement can compel US-headquartered companies to produce customer data stored anywhere in the world, including European data centres, without notifying the data subject or the data controller's home regulator.

This creates a precise paradox: the tool you use to document your vulnerabilities for GDPR-compliant DORA reporting is itself a CLOUD Act-exposed US service. The detailed security incident data you generate to satisfy Article 19 can be accessed by US authorities without your knowledge.

In the context of financial services, this exposure is particularly acute. DORA incident reports document:

A US intelligence agency obtaining this data via CLOUD Act gains a detailed map of your financial infrastructure's weaknesses — all compiled by your own compliance team.

US Tool Scorecard

Each tool is scored out of 25 across five dimensions: Data Residency (0–5), Legal Jurisdiction (0–5), DORA Template Support (0–5), Operational Capability (0–5), and Certification/Compliance (0–5).

PagerDuty — Score: 6/25

PagerDuty Inc. is incorporated in Delaware and headquartered in Portland, Oregon. Its infrastructure runs primarily on AWS, including AWS regions in the EU. An AWS EU region provides physical data residency but does not remove CLOUD Act exposure — PagerDuty remains a US company legally obligated to comply with US government data demands.

The CLOUD Act problem specific to PagerDuty: PagerDuty's incident timelines, postmortem records, and escalation logs are all stored as customer data. A US government subpoena or National Security Letter targeting PagerDuty can access every incident report you've filed — including the ones documenting your DORA-reportable breaches — without notification to you or your NCA.

OpsGenie (Atlassian) — Score: 7/25

Atlassian acquired OpsGenie in 2018. Atlassian plc is incorporated in the UK but its operational headquarters are in Sydney, Australia, with US entities controlling cloud infrastructure. OpsGenie data residency options include EU regions, but Atlassian's US entities remain subject to US legal demands.

Splunk On-Call (formerly VictorOps) — Score: 5/25

Cisco acquired Splunk in March 2024. Cisco Systems is a US company headquartered in San Jose, California. Splunk On-Call (the former VictorOps product) runs on Splunk's cloud infrastructure, which is transitioning to Cisco's infrastructure post-acquisition.

Acquisition risk: Post-Cisco acquisition, Splunk's product roadmap is uncertain. DORA compliance teams building long-term processes on Splunk On-Call face integration continuity risk.

ServiceNow ITOM + ITSM — Score: 9/25

ServiceNow is the closest US tool to DORA compliance readiness. Its Government Cloud (US) is FedRAMP High authorised; its commercial EU cloud regions store data in EU data centres. ServiceNow has invested in financial services compliance features, including workflow templates for regulatory reporting.

Third-Party Risk Inception (ServiceNow): DORA Article 28 requires rigorous third-party ICT risk management. ServiceNow is itself potentially a "critical ICT third-party provider" under Article 31 designation criteria. Using ServiceNow to manage your DORA third-party risk assessments — while ServiceNow itself may be designated as critical ICT TPP — is a circular dependency that regulators are beginning to examine.

EU-Native Alternatives

Zabbix — Score: 24/25

Zabbix LLC is a Latvian company founded in 2001, headquartered in Rīga. Zabbix is the gold standard for EU-sovereign monitoring and alerting. The open-source core is maintained by a European company with no US parent, no US venture capital, and no CLOUD Act exposure.

Why Zabbix scores 24 instead of 25: The remaining point reflects the additional build effort required for DORA-specific notification templates versus commercial platforms with pre-built compliance workflows. For financial entities with internal engineering capacity, this gap closes quickly; for smaller institutions, it may argue for a commercial EU-native ITSM alongside Zabbix for monitoring.

EU stack: Zabbix + OTRS (for ticket management) + Keycloak (for identity federation) is a fully EU-sovereign incident management stack with no US dependencies.

Xurrent (formerly 4me) — Score: 23/25

4me BV rebranded to Xurrent in 2023. Xurrent is a Dutch company incorporated in Amsterdam, providing enterprise ITSM/ESM with a strong financial-sector compliance focus. Xurrent's data centres are in the Netherlands, and the company has invested specifically in DORA compliance readiness.

Why Xurrent scores 23: The DORA template support is structured but not fully automated; the final assembly of ESA ITS submissions still requires manual data extraction. The pricing (enterprise-tier SaaS) creates a barrier for smaller financial entities. These gaps are architectural and addressable with professional services.

Notable clients: Xurrent is deployed by several Dutch and European financial institutions, giving it practical DORA implementation experience that most US tools lack entirely.

ilert — Score: 22/25

ilert GmbH is a German company founded in 2019, headquartered in Cologne (Köln). ilert is a modern, API-first alerting and incident management platform explicitly designed as an EU-native alternative to PagerDuty.

Competitive positioning: ilert is explicitly marketing itself as the EU-sovereign PagerDuty alternative. Its GDPR DPA, German legal entity, and Frankfurt infrastructure make it the simplest like-for-like replacement for teams currently using PagerDuty who need to migrate before a regulatory review.

Gap: ilert is newer than PagerDuty and lacks some enterprise features (advanced reporting, CMDB integration, complex escalation hierarchies). For most financial services teams, the gap closes with configuration; for the most complex enterprise environments, Xurrent is the stronger choice.

Signl4 — Score: 21/25

Signl4 is operated by Derdack GmbH, a German company founded in 1999, headquartered in Potsdam. Signl4 is a mobile-first alerting and incident response platform with EU data centres.

Signl4 vs ilert: Signl4 is more mature (25 years of history vs ilert's 6 years) but focuses more on operational technology and industrial alerting. For financial services specifically, ilert's financial-services marketing and ISO 27001 certification give it an edge for DORA compliance conversations with auditors.

OTRS / ((OTRS)) Group — Score: 20/25

OTRS Group is a German company headquartered in Oberaichen (Baden-Württemberg). OTRS provides both the open-source OTRS ticketing system and the commercial ((OTRS)) enterprise product. OTRS Group acquired STORM IT Management (Managed Operations) in 2020, expanding its compliance-focused enterprise offering.

The 100+ Data Field Problem: Template Automation

The most underestimated DORA operational challenge is not the 4-hour deadline — it is assembling the correct data for the ESA ITS templates while an incident is actively in progress.

Commission Implementing Regulation (EU) 2024/2845 specifies the templates for DORA major incident reporting. Across the three reporting phases, these templates require over 100 distinct data elements. The initial notification alone requires approximately 27 mandatory fields. The intermediate and final reports add cumulative fields covering root cause analysis, impact quantification, third-party involvement, and remediation measures.

The operational problem: most of these fields require data from multiple systems. The incident ticket (your ITSM), the monitoring platform (your SIEM/APM), the client database, the third-party contract register (your vendor risk management system), and the financial impact model. Under time pressure, assembling this data manually is error-prone.

What automation looks like in practice:

A mature DORA-compliant incident management system does the following automatically:

  1. Incident classification engine. When an incident ticket is created, the system evaluates classification criteria (affected client count, duration estimate, service criticality) against DORA Article 18 thresholds. If classification as "major" is triggered, the system starts the 4-hour reporting clock and creates the ITS template.

  2. Pre-populated template. The ITS template is pre-filled from available data: entity identifier (LEI), ICT service registry (affected systems mapped to business services), client segmentation data (approximate affected count from your CRM), incident discovery timestamp from your monitoring system.

  3. Escalation and approval workflow. The compliance officer and CISO are automatically pulled into the incident workflow. They review the pre-populated template, add information not available from automated sources (preliminary root cause, reputational impact assessment), and approve submission.

  4. Submission integration. The approved template is submitted via the NCA's API or portal interface. The submission reference number is recorded in the incident ticket.

  5. Intermediate and final report reminders. The system tracks the 72-hour and 30-day deadlines from initial submission and creates templated follow-up tasks.

None of the US tools provide this out of the box. Among EU-native tools, Xurrent is closest to this model with its DORA workflow guidance and structured incident management processes.

Building the DORA-Sovereign Incident Management Stack

A fully EU-native DORA incident management stack can be assembled from available open-source and commercial EU components:

Tier 1: Monitoring and Detection (Zabbix BE/Checkmk DE)

Tier 2: Alert Routing and On-Call (ilert DE or Signl4 DE)

Tier 3: Incident Ticket and ITSM (Xurrent NL or OTRS DE)

Tier 4: SIEM and Security Analytics (Wazuh ES or OpenSearch ES)

Tier 5: Compliance Reporting (Custom or Xurrent)

This stack has zero CLOUD Act exposure: all components are either self-hosted or operated by EU companies with EU data centres and no US parent entities.

Scoring Summary

ToolHQCLOUD Act RiskDORA TemplatesScore
ZabbixLatvia (EU)None (self-hosted)Build required24/25
XurrentNetherlands (EU)NoneStructured support23/25
ilertGermany (EU)NoneBuild required22/25
Signl4Germany (EU)NoneBuild required21/25
OTRS / ((OTRS))Germany (EU)None (self-hosted)Configurable20/25
ServiceNowUSAFull exposureMarketplace apps9/25
OpsGenie / AtlassianUSA/AUFull exposureNone7/25
PagerDutyUSAFull exposureNone6/25
Splunk On-CallUSA (Cisco)Full exposureNone5/25

Implementation Roadmap

Months 0–6: Triage and Baseline

Immediate priority: Verify current incident reporting capability against DORA Article 19 timelines.

  1. Map your current incident management workflow to the 4h/72h/30d cascade. Where does it break?
  2. Audit current tooling: is any component US-headquartered without EU legal entity controlling data?
  3. Build a manual ITS template in the short term — a structured spreadsheet or SharePoint form that your compliance officer can populate in under 2 hours.
  4. Establish the classification criteria for "major" incidents per Article 18 — what thresholds trigger reporting for your entity type (bank, insurer, CASP, payment institution)?
  5. Identify your NCA (national competent authority) and understand their submission channel (email, web portal, API).

Quick win: ilert or Signl4 deployment can replace PagerDuty/OpsGenie in 2–4 weeks with limited migration effort. This removes CLOUD Act exposure from your incident alerting data immediately.

Months 6–18: Automation

  1. Deploy Xurrent or ((OTRS)) for ITSM with DORA-structured incident ticket templates.
  2. Integrate monitoring (Zabbix/Checkmk) → alerting (ilert/Signl4) → ITSM (Xurrent/OTRS) with automated ticket creation.
  3. Build the ITS template pre-population workflow: incident ticket fields → DORA template fields.
  4. Test the 4-hour cascade with tabletop exercises: create a simulated major incident at a known time, run the full notification workflow, measure time-to-submission.
  5. Connect the ITS template submission to your NCA's preferred channel.

Months 18–36: Maturation

  1. Connect client impact assessment: integrate CRM/customer database to provide client count estimates automatically.
  2. Automate the 72-hour and 30-day follow-up reminders with pre-populated intermediate and final report templates.
  3. Implement supervisory feedback workflow (Article 22): NCA responses are tracked in the incident ticket.
  4. Build voluntary notification workflow for significant cyber threats (Article 23): lower classification threshold triggers Tier 2 review queue.
  5. Annual tabletop exercise with compliance officer, CISO, and NCA liaison.

The 2025-01-17 Baseline and Where Teams Stand Now

DORA's incident reporting obligations applied from 17 January 2025. Seventeen months after the obligation date, most financial services teams fall into one of three categories:

Category A (Prepared): Major institutions with dedicated DORA compliance programmes. Typically using manual ITS templates submitted via NCA portal, with automation planned for 2026.

Category B (Working on it): Mid-size firms that have classified their incident management tool as "compliant" based on EU data residency claims, without accounting for CLOUD Act exposure of US parent companies.

Category C (Exposed): Smaller financial entities and FinTechs that have not yet reviewed their incident management tooling against DORA obligations. These entities are operating US-jurisdiction incident management tools and may not have the 4-hour submission capability built.

NCAs are beginning their DORA supervisory examinations in 2026. The first enforcement actions related to incident reporting process failures are expected in late 2026.

What This Means for EU-Hosted Infrastructure

If your financial services workloads run on EU-native infrastructure — Hetzner, Scaleway, OVHcloud, IONOS — your compute and storage are already outside CLOUD Act reach. But infrastructure sovereignty is incomplete without application sovereignty.

A financial institution running its core banking on Hetzner Germany, its incident management on PagerDuty, and its SIEM on Splunk Cloud has a mixed sovereignty profile. The DORA incident data — the breach reports, the root cause analyses, the vulnerability timelines — flow through US-headquartered systems regardless of where the core infrastructure runs.

A fully sovereign DORA incident management stack requires both: EU-hosted infrastructure and EU-legal-entity application providers.

The tooling exists. Zabbix, ilert, Xurrent, Signl4, and OTRS collectively cover the full DORA incident reporting workflow. The migration timeline is measured in months, not years. For FinTechs and challenger banks building greenfield, the default stack should start with EU-native components — the migration cost from US tools grows with every month of incident history stored in CLOUD Act-jurisdiction systems.

Next in the EU-DORA-COMPLIANCE-TOOLS series: DORA Third-Party Risk Management — EU-Compliant Vendor Assessment Tools 2026 (Articles 28–44).

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing