Article 19: Reporting of major ICT-related incidents and voluntary notification of significant cyber threats

Article 19 requires you to detect, classify, and report “major ICT-related incidents” to your competent authority through a repeatable workflow with clear accountability, fast escalation, and durable evidence. Operationalize it by defining what “major” means for your entity, wiring incident response into regulatory reporting, and running drills to prove the process works. (Regulation (EU) 2022/2554, Article 19)

Key takeaways:

• Define a “major incident” decision rule and escalation path that triggers regulatory reporting, not just internal response. (Regulation (EU) 2022/2554, Article 19)
• Assign owners across Security/IT, ICT Risk, Legal/Compliance, and third-party management, then test the workflow end-to-end. (Regulation (EU) 2022/2554, Article 19)
• Retain evidence that shows timeliness, governance approvals, report content, and post-incident remediation closure. (Regulation (EU) 2022/2554, Article 19)

The fastest way to fail Article 19 is to treat it as “SOC sends an email to the regulator.” Article 19 is an operating requirement: you need a standing mechanism to (1) recognize when an ICT incident crosses the “major” threshold, (2) report it to the competent authority responsible for your entity, and (3) optionally notify significant cyber threats in a controlled, defensible way. (Regulation (EU) 2022/2554, Article 19)

For a CCO, GRC lead, or ICT risk owner, the work is mostly governance and process engineering. Your incident responders already manage outages and attacks; the gap is usually classification, escalation, and evidence. Regulators will ask who decides “major,” how quickly you decide, what you reported, and whether you can prove the process operated consistently across business lines and third parties. (Regulation (EU) 2022/2554, Article 19)

This page is requirement-level implementation guidance for the target keyword “article 19: reporting of major ict-related incidents and voluntary notification of significant cyber threats requirement.” It focuses on building a practical reporting workflow, integrating third-party incidents, and creating audit-ready artifacts without inventing obligations beyond the DORA text you can cite here. (Regulation (EU) 2022/2554, Article 19)

Regulatory text

What the rule says (excerpt): “Financial entities shall report major ICT-related incidents to the relevant competent authority as referred to in Article 46 in accordance with paragraph 4 of this Article.” (Regulation (EU) 2022/2554, Article 19)

What that means for operators: you must have a reliable method to identify a “major ICT-related incident” and send a report to your competent authority for supervision. This is not optional for major incidents; the voluntary element applies to notifying significant cyber threats, not to major incident reporting. Keep your procedure aligned to DORA’s incident reporting obligations as a whole (Article 19 points to details elsewhere in the Regulation). (Regulation (EU) 2022/2554, Article 19) (Regulation (EU) 2022/2554)

Plain-English interpretation (requirement intent)

The requirement in one line

Build a repeatable incident-to-regulator reporting pipeline: detect → classify “major” → escalate → draft → approve → submit → follow up → remediate, with evidence at each step. (Regulation (EU) 2022/2554, Article 19)

Why this exists (operationally)

Competent authorities need consistent, comparable reporting of serious ICT disruptions and cyber events so they can supervise operational resilience across the financial sector. Your job is to make reporting a normal part of incident operations, not an ad hoc scramble. (Regulation (EU) 2022/2554, Article 19)

Who it applies to

Entity scope

• Financial entities within DORA’s scope must report major ICT-related incidents to their relevant competent authority. (Regulation (EU) 2022/2554, Article 19)

Operational scope (what parts of the business)

Expect this to touch:

• Security operations / incident response: detection, triage, technical facts.
• IT operations / SRE / infrastructure: availability impact, recovery actions.
• ICT risk / GRC: classification, control mapping, evidence, remediation tracking.
• Legal & Compliance: regulatory interpretation, sign-off, communications controls.
• Third-party management: incidents at critical providers that affect your services; contractual notification triggers and timelines.

If your services rely on third parties (cloud, core banking, market data, payments processors), include third-party-originated incidents in your “major incident” classification and escalation workflow so reporting is not delayed while you negotiate facts with the provider. (Regulation (EU) 2022/2554, Article 19)

What you actually need to do (step-by-step)

Step 1: Name accountable owners (RACI that works under pressure)

Create a simple RACI for “major incident reporting”:

• Accountable: CISO or Head of ICT Risk (pick one, document it).
• Responsible (content): Incident Commander / SOC Manager.
• Responsible (submission mechanics): Compliance (or a Regulatory Affairs function).
• Consulted: Legal, Data Protection (as needed), Third-party owner.
• Informed: Executive management; board reporting channel as defined internally.

A common operating model is “Security writes the facts, Compliance owns the regulatory output and filing, Legal approves external statements.” Document the handoffs. (Regulation (EU) 2022/2554, Article 19)

Step 2: Define “major ICT-related incident” classification criteria you can execute

You need a decision rule that produces consistent outcomes during messy incidents. Build:

• A classification rubric (severity/impact categories).
• A decision log requirement (who decided, based on what evidence).
• A fallback rule: if key facts are unknown but impact indicators suggest “major,” escalate and prepare to report.

Keep the rubric practical: business service impact, customer impact, data integrity, duration/recurrence, and systemic relevance are typical dimensions (describe them in your internal standard, even if the exact thresholds are defined in your wider DORA implementation). The goal is a defensible “why this was major” narrative. (Regulation (EU) 2022/2554, Article 19)

Step 3: Embed a regulatory reporting trigger inside incident response

Add explicit tasks to your IR playbooks:

1. “Regulatory triage” checkpoint during early incident management.
2. Clock start: record the time you first detected the event and the time you declared it potentially major.
3. Evidence capture: preserve logs, timelines, and key communications in an incident folder with controlled access.
4. Draft report: standard template populated from your incident ticket.

This is where teams usually break: the incident gets handled, but nobody owns the regulatory workstream. Treat “regulatory reporting” as a parallel track with its own owner and checklist. (Regulation (EU) 2022/2554, Article 19)

Step 4: Build the report package and approval workflow

Create a “major incident report” package with:

• Executive summary (what happened, when, current status).
• Impact description (services affected, customers/processes impacted).
• Root cause hypothesis (clearly labeled as preliminary if not confirmed).
• Containment and recovery actions taken.
• Current risks (ongoing compromise risk, stability risk).
• Next steps and remediation plan.

Add an approval chain that functions during weekends/holidays. Pre-authorize alternates. Track approvals in a system of record (ticketing/GRC tool) so you can show who signed off and when. (Regulation (EU) 2022/2554, Article 19)

Step 5: Include third-party incident intake and correlation

Operationalize these controls:

• Contractual requirement for third parties to notify you quickly of incidents affecting your services.
• A dedicated intake channel (email alias + ticket queue) that routes to the Incident Commander and ICT risk.
• Mapping between third-party services and your critical business services so you can assess materiality fast.

If you use Daydream, create a single register entry for Article 19 with linked controls, owners, and evidence artifacts, then connect it to your third-party inventory so incidents can be traced to affected services and contracts without manual chasing. (Regulation (EU) 2022/2554, Article 19)

Step 6: Run readiness drills and close gaps with tracked remediation

Do tabletop exercises that force the decision:

• “Is it major?”
• “Do we report now with incomplete facts?”
• “Who approves the submission?”
• “What do we say about third-party responsibility?”

Record actions, gaps, and remediation tasks, then validate closure with evidence (updated playbooks, training completion, revised templates). This is a strong supervisory story because it proves the process is real. (Regulation (EU) 2022/2554, Article 19)

Required evidence and artifacts to retain

Maintain an Article 19 evidence pack. Minimum set:

• Policy/standard: incident classification standard that defines “major” and escalation. (Regulation (EU) 2022/2554, Article 19)
• Procedure/playbooks: IR playbooks with regulatory reporting steps embedded. (Regulation (EU) 2022/2554, Article 19)
• RACI and on-call rota: named roles, alternates, contact paths.
• Reporting templates: major incident report template; voluntary significant threat notification template (if you implement voluntary notifications). (Regulation (EU) 2022/2554, Article 19)
• System evidence: incident tickets, decision logs, timestamps, approvals, submission confirmations, regulator correspondence. (Regulation (EU) 2022/2554, Article 19)
• Post-incident records: RCA, corrective action plan, validation/closure evidence, lessons learned.
• Third-party artifacts: notification clauses, SLAs for incident notice, third-party incident reports, your internal impact assessment.

Auditors care less about beautiful documents and more about traceability: “show me one major incident and the end-to-end proof.” (Regulation (EU) 2022/2554, Article 19)

Common exam/audit questions and hangups

Expect questions like:

• “How do you define a ‘major ICT-related incident,’ and who makes that call?” (Regulation (EU) 2022/2554, Article 19)
• “Show evidence of a major incident report submitted to the competent authority, including approvals and timestamps.” (Regulation (EU) 2022/2554, Article 19)
• “How do third-party incidents get assessed for ‘major’ impact on your services?” (Regulation (EU) 2022/2554, Article 19)
• “How do you ensure the process works outside business hours?”
• “How do you prevent under-reporting due to uncertainty early in an incident?”

Hangup pattern: teams can explain the process verbally but cannot produce a consistent evidence trail across incidents. Fix this with mandatory fields in the incident ticket and a standard “regulatory reporting” sub-task list. (Regulation (EU) 2022/2554, Article 19)

Frequent implementation mistakes and how to avoid them

1. Mistake: “Major” is undefined or defined only in prose.
   Avoid: use a rubric with explicit decision factors and a required decision log entry. (Regulation (EU) 2022/2554, Article 19)

2. Mistake: Compliance finds out late.
   Avoid: add a hard escalation trigger to the IR workflow, plus an on-call compliance contact. (Regulation (EU) 2022/2554, Article 19)

3. Mistake: Third-party incidents are treated as “their problem.”
   Avoid: contract for notification, map providers to services, and treat third-party outages as first-class incidents in your system. (Regulation (EU) 2022/2554, Article 19)

4. Mistake: Reporting is email-based with no system of record.
   Avoid: store drafts, approvals, and submissions in a controlled repository linked to the incident ticket; Daydream-style control-to-evidence mapping helps keep it consistent. (Regulation (EU) 2022/2554, Article 19)

5. Mistake: No proof that improvements were implemented.
   Avoid: track corrective actions to closure with validation evidence after each major incident or drill. (Regulation (EU) 2022/2554, Article 19)

Enforcement context and risk implications

No public enforcement cases were provided in the sources you supplied, so this page does not list case examples.

Risk to manage anyway:

• Supervisory findings risk: inability to demonstrate timely, consistent reporting and governance under DORA obligations. (Regulation (EU) 2022/2554, Article 19)
• Operational risk: delayed escalation or misclassification can cause late reporting, inconsistent narratives, and avoidable friction with your competent authority. (Regulation (EU) 2022/2554, Article 19)

Practical execution plan (30/60/90)

Use this as an execution sequence, not a promise of elapsed time.

First 30 days (foundation)

• Appoint an Article 19 owner and backups; publish the RACI and escalation contacts. (Regulation (EU) 2022/2554, Article 19)
• Draft the “major incident” classification rubric and decision log requirements; socialize with SOC/IT/Legal. (Regulation (EU) 2022/2554, Article 19)
• Create reporting templates and a standard incident ticket sub-task list for regulatory reporting. (Regulation (EU) 2022/2554, Article 19)
• Build an evidence folder structure (or GRC workspace) and define what gets saved where.

Next 60 days (integration)

• Update IR playbooks to include regulatory triage and escalation triggers. (Regulation (EU) 2022/2554, Article 19)
• Integrate third-party incident intake: notification mailbox, ticket routing, provider-to-service mapping, contractual review queue. (Regulation (EU) 2022/2554, Article 19)
• Train incident commanders and compliance approvers using one realistic scenario.

Next 90 days (prove it works)

• Run a tabletop exercise that forces a borderline “major” decision and a draft submission package. (Regulation (EU) 2022/2554, Article 19)
• Close gaps through a tracked corrective action plan; attach validation evidence. (Regulation (EU) 2022/2554, Article 19)
• Build a standing “regulatory reporting readiness” dashboard: open incidents under review, classification decisions pending, reports drafted/submitted, corrective actions aging.

If you want this to stay operational, manage Article 19 the way you manage uptime: clear ownership, standard workflows, and routine testing. (Regulation (EU) 2022/2554, Article 19)

Frequently Asked Questions

What counts as a “major ICT-related incident” for Article 19?

Article 19 requires reporting of “major ICT-related incidents” but your operation still needs an internal decision rule to classify incidents as major and trigger reporting. Implement a rubric and a documented decision log so you can defend each call. (Regulation (EU) 2022/2554, Article 19)

Who should submit the report: Security or Compliance?

Either can submit, but you need a single accountable owner and a defined approval chain so reporting is consistent and auditable. Many firms have Security provide technical content while Compliance owns filing and recordkeeping. (Regulation (EU) 2022/2554, Article 19)

Do we have to report incidents caused by third parties?

If the incident impacts your services and meets your “major” criteria, treat it as your reportable event even if the root cause is at a third party. Build contractual notification and internal intake so you can assess impact quickly. (Regulation (EU) 2022/2554, Article 19)

What evidence will an auditor ask for first?

Expect requests for one end-to-end example: incident ticket, “major” determination record, report draft, approvals, submission confirmation, and post-incident remediation closure. Store those artifacts together so retrieval is fast. (Regulation (EU) 2022/2554, Article 19)

How do we handle reporting when facts are incomplete early on?

Use a “provisional major” path: escalate, start the reporting workstream, and clearly label unknowns and hypotheses in your internal drafts and external narrative. Your decision log should explain why you treated it as potentially major. (Regulation (EU) 2022/2554, Article 19)

Where does voluntary notification of significant cyber threats fit operationally?

Treat it as a separate playbook with its own approval gate, since the decision is discretionary and communications-sensitive. Reuse the same evidence discipline: who decided, what was observed, and what was shared externally. (Regulation (EU) 2022/2554, Article 19)