Automating DORA Incident Reporting: Building the 4-Hour NCA Notification Pipeline

The Clock Starts Before You Are Ready

When a major ICT incident hits a European financial institution, the regulatory clock does not wait for internal politics, manual triage, or email chains. DORA Article 19(4) mandates that the initial notification to the competent authority must be submitted "without undue delay and in any case within the time limits to be set" by the regulatory technical standards. The EBA, ESMA, and EIOPA joint RTS on incident reporting establish a 4-hour window from the moment an incident is classified as major.

Four hours. That is the window between classification and the first submission to your National Competent Authority. Not four hours from detection. Not four hours from impact. Four hours from the point at which you determine the incident meets the classification thresholds under Art. 18.

This distinction matters because it creates a perverse incentive to delay classification — a strategy that supervisors are well aware of, and one that will not survive the enforcement posture described in Art. 50-56. The solution is not ambiguity in classification, but automation that makes the entire pipeline fast enough that the 4-hour window becomes comfortable rather than impossible.

Why Manual Reporting Fails

Most institutions today manage incident reporting through a combination of spreadsheets, email templates, and manually populated regulatory forms. The process typically involves:

1. Incident detected by SOC or operations team
2. Triage call with stakeholders (30-90 minutes to convene)
3. Manual severity classification against DORA criteria
4. Draft report written by the CISO or incident manager
5. Legal review (30-60 minutes, if available)
6. Compliance review (30-60 minutes)
7. Final approval from senior management
8. Submission through the NCA's portal or email

The arithmetic is unforgiving. On a good day, with every stakeholder immediately available and every data source at hand, the manual process barely fits within 4 hours. On a bad day — a Friday evening, a public holiday, a concurrent operational crisis — it does not fit at all.

The EBA's supervisory expectations for incident reporting quality add another dimension. The initial notification is not a placeholder. It must contain structured data about the incident type, affected services, number of impacted clients, estimated financial impact, and the entity's initial assessment of root cause and containment status. Submitting a vague one-paragraph notification risks a supervisory finding for inadequate reporting.

The Three-Phase Reporting Architecture

DORA's incident reporting regime follows a three-phase structure, each with distinct content requirements and deadlines:

Phase 1: Initial Notification (T+4 hours)

The initial notification is a structured alert to the NCA that a major incident has occurred. It must include:

• Incident classification and type (cyberattack, system failure, third-party failure, etc.)
• Date and time of detection and classification
• Affected critical or important functions
• Estimated number of impacted clients
• Geographic scope of impact
• Initial containment measures taken
• Point of contact for supervisory follow-up

Phase 2: Interim Report (T+72 hours)

The interim report provides substantive detail on the incident's progression:

• Updated impact assessment (financial, operational, client)
• Root cause analysis (preliminary)
• Recovery actions taken and timeline
• Communication actions (internal and external)
• Whether the incident has been contained

Phase 3: Final Report (T+1 month)

The final report is the comprehensive regulatory record:

• Confirmed root cause
• Total financial impact
• Total clients and transactions affected
• Duration of disruption per affected service
• Lessons learned and remediation plan
• Testing plan for remediation validation
• Evidence of recovery and return to normal operations

Designing the Automated Pipeline

The automation architecture must address four problems simultaneously: speed (hitting the 4-hour window), accuracy (structured data, not free text), auditability (every action logged), and flexibility (NCAs across 27 member states have different portal formats and submission channels).

Component 1: Classification Engine

The classification engine evaluates incoming incidents against Art. 18 thresholds in real time. The DORA classification criteria include:

The engine must be deterministic. Given the same inputs, it must produce the same classification output. This is essential for audit defense — a supervisor must be able to reconstruct why an incident was or was not classified as major, and the reasoning must be consistent and documented.

Component 2: Report Assembly Engine

Once classified, the report assembly engine pulls structured data from authoritative sources:

• Asset register: Affected systems, their criticality classification, dependencies, and business service mapping
• Client impact database: Number and segments of affected clients, transaction volumes
• Service dependency map: Upstream and downstream systems, third-party providers involved
• Incident history: Similar past incidents, recurring patterns, previous remediation actions

The engine populates report templates using this structured data, producing a draft that is 70-80% complete before a human reviewer touches it. The remaining 20-30% — narrative context, management judgment, forward-looking assessment — requires human input but on a pre-populated foundation.

Component 3: Review and Approval Workflow

Automation does not eliminate human judgment; it compresses the time humans spend on non-judgment tasks. The review workflow must enforce:

• Separation of duties: The person who classifies the incident cannot be the sole approver of the NCA notification
• Escalation timeouts: If the designated reviewer does not act within a configurable window (e.g., 60 minutes), the notification auto-escalates to the next authority level
• Mobile-ready approval: Reviewers must be able to approve from any device — incident reporting deadlines do not respect office hours

Component 4: NCA Submission Adapter

Different NCAs accept reports through different channels. Some provide API endpoints. Others require web portal submissions. A few still accept structured emails. The submission adapter must abstract this variation:

For cross-border incidents affecting operations in multiple member states, Art. 19(7) requires notification to the competent authority of the home member state. The institution must determine whether additional notifications to host member state authorities are required based on the significance of the impact.

Implementation Priorities

Building the full pipeline is a multi-quarter effort. The pragmatic approach is to implement in phases, starting with the components that reduce the most risk:

Quarter 1: Classification and alerting. Implement the classification engine with Art. 18 thresholds. Connect it to your existing SIEM and monitoring stack. The output is not automated submission but automated alerting to the right people with pre-classified severity.

Quarter 2: Report pre-population. Connect the assembly engine to your asset register, client database, and service map. Produce draft reports that are 70% populated. The review and approval process remains manual but starts from a structured draft instead of a blank page.

Quarter 3: Workflow and submission. Implement the review workflow with escalation timeouts and mobile approval. Connect the NCA submission adapter to your primary NCA's channel. Test end-to-end with tabletop exercises.

Quarter 4: Evidence and audit. Implement the evidence archive with chain-of-custody tracking. Every report version, every approval action, every submission confirmation is stored immutably. This is what demonstrates to supervisors that your incident reporting process is systematic, not ad hoc.

The Evidence Chain

Automation without evidence is not compliance. For every incident that triggers the NCA notification pipeline, the following evidence must be preserved:

This evidence chain is what distinguishes a mature incident reporting capability from a checkbox process. When a supervisor audits your incident handling, they will ask not only whether the report was submitted on time, but whether the classification was correct, whether the impact assessment was reasonable, and whether the root cause analysis was thorough. The evidence chain answers all of these questions before they are asked.

The DORA evidence management framework applies here with particular force: each artifact must be integrity-verified (SHA-256 checksums), access-controlled (RBAC), and retention-managed (minimum 10 years per the entity's audit retention policy).

Testing the Pipeline

A notification pipeline that has never been tested under pressure will fail when it matters. DORA Art. 26 requires that resilience testing programmes cover the institution's ability to respond to ICT incidents. This includes testing the incident reporting pipeline itself.

Recommended testing cadence:

• Monthly: Tabletop exercise with the incident management team walking through a simulated major incident, using the automated pipeline to produce a draft notification
• Quarterly: Full pipeline test with classification, report assembly, review workflow, and simulated NCA submission (using a test environment or sandbox portal)
• Annually: As part of the institution's TLPT programme, include a scenario that triggers the NCA notification pipeline with realistic time pressure

Each test must produce evidence: the tabletop minutes, the draft reports generated, the workflow logs, and the lessons learned. This evidence feeds directly into your Art. 14 board reporting on incident management readiness.

Cross-Border Complexity

For institutions operating across multiple EU member states, the reporting obligation is not a single NCA submission but potentially multiple parallel submissions. Art. 19(6) addresses cross-border notification, and the joint ESA RTS further specifies the coordination mechanism.

The practical challenge is that different NCAs may have different portal formats, different field requirements, and different expectations for the level of detail in the initial notification. An automated pipeline must handle this variation through the submission adapter architecture described above, with NCA-specific templates that produce compliant outputs for each jurisdiction.

The register of information maintained under Art. 28 is a critical input here. It maps which third-party providers support which services in which jurisdictions. When an incident involves a third-party provider, the asset register and third-party register together determine which NCAs need to be notified and what the estimated cross-border impact is.

Common Pitfalls

Over-classifying to be safe. Filing every incident as major to avoid missing one creates noise that degrades your relationship with the NCA and diverts resources from genuine major incidents. The classification engine must be calibrated against historical data and validated against supervisory expectations.

Under-investing in data quality. The automated pipeline is only as good as the data it draws from. If your asset register is incomplete, your client impact database is stale, or your service dependency map is inaccurate, the automated reports will be inaccurate — and automated inaccuracy at scale is worse than manual inaccuracy.

Treating the initial notification as the end. The initial notification is the beginning. The 72-hour interim report and the 1-month final report are where supervisory scrutiny concentrates. Automating the initial notification but leaving the interim and final reports as manual processes defeats the purpose.

Forgetting about the assessment tool. Use structured self-assessment to identify gaps in your incident reporting readiness before a real incident reveals them.

Measuring Pipeline Effectiveness

Once operational, track these metrics to demonstrate pipeline maturity to supervisors:

These metrics belong in your quarterly board reporting as evidence that the institution's incident reporting capability is not just documented but operationally tested and continuously improved.

Conclusion

The 4-hour NCA notification window is not a challenge that can be solved with faster typists or more responsive compliance officers. It requires a systematic, automated pipeline that reduces the time humans spend on data gathering, formatting, and coordination — and maximizes the time available for the judgment calls that only humans can make: Is this incident correctly classified? Is the impact assessment reasonable? Are we being transparent with the supervisor?

Automation is the tool. Audit-readiness is the outcome. The institutions that build this pipeline now will report incidents confidently, with complete evidence chains and demonstrable process maturity. The institutions that do not will discover their gaps at the worst possible moment: during a real incident, under regulatory scrutiny, with the clock already running.

---

Resume en francais

Les articles 17 a 23 de DORA imposent un regime de signalement des incidents en trois phases : notification initiale a l'autorite nationale competente (ANC) dans un delai de 4 heures apres la classification, rapport intermediaire dans les 72 heures et rapport final dans le mois. Cet article presente une architecture technique pour automatiser l'ensemble du pipeline — du moteur de classification (criteres de l'article 18) a l'assemblage automatique des rapports, en passant par le workflow d'approbation avec separation des taches et la soumission adaptee a chaque ANC. Les composants cles comprennent un moteur de classification deterministe, un assemblage de rapports alimente par le registre des actifs TIC et la base clients, un workflow de revue avec escalade automatique et un adaptateur de soumission multi-juridictionnel. L'article detaille egalement la chaine de preuves requise, le programme de tests recommande et les metriques de performance du pipeline. L'automatisation ne remplace pas le jugement humain : elle comprime le temps consacre aux taches sans valeur ajoutee pour maximiser la fenetre disponible pour les decisions critiques.