Article 21: Centralisation of reporting of major ICT-related incidents

Article 21 is not a direct “you must file incidents to an EU hub” obligation on your firm today; it requires EU authorities to assess feasibility of a single EU Hub for major ICT incident reporting. Your job is to design incident reporting to be hub-ready: centralized intake, consistent data, clear accountability, and fast regulatory-response execution so you can adopt a future centralized channel without reworking controls. (Regulation (EU) 2022/2554, Article 21)

Key takeaways:

• Treat Article 21 as a change-readiness requirement: build a single internal reporting “front door” for major ICT incidents.
• Standardize the reportable-incident dataset and evidence trail so you can map to any future EU Hub schema quickly.
• Operationalize governance: named owners, regulatory-response workflow, drills, and remediation tracking to satisfy supervisory scrutiny.

The target keyword “article 21: centralisation of reporting of major ict-related incidents requirement” can mislead teams into searching for a new filing destination they must use immediately. Article 21 is narrower: it directs the European Supervisory Authorities (ESAs), via the Joint Committee and in consultation with the ECB and ENISA, to produce a report on whether further centralisation is feasible through a single EU Hub for major ICT-related incident reporting. The report’s purpose is to improve information flow, reduce reporting costs, and support thematic analysis and supervisory convergence. (Regulation (EU) 2022/2554, Article 21)

For a Compliance Officer, CCO, or GRC lead, the practical question becomes: “What do I implement now so we don’t get caught flat-footed if a hub goes live or our supervisor expects ‘centralised’ reporting capability?” The right answer is an operating model that centralizes incident reporting internally, produces consistent regulatory-ready outputs, and can adapt to new submission channels with minimal process change. This page translates Article 21 into requirement-level execution steps, evidence you should retain, audit questions you should expect, and a pragmatic plan you can run without waiting for future EU Hub details. (Regulation (EU) 2022/2554, Article 21)

Regulatory text

What the law says (excerpted): Article 21 states that the ESAs, through the Joint Committee and in consultation with the ECB and ENISA, shall prepare a joint report assessing the feasibility of further centralisation of incident reporting via a single EU Hub for major ICT-related incident reporting by financial entities, exploring ways to facilitate reporting flows, reduce costs, and underpin thematic analyses to enhance supervisory convergence. (Regulation (EU) 2022/2554, Article 21)

What an operator must do with that: Article 21 does not add a new incident notification deadline or a new submission destination by itself. Operationally, it creates a clear supervisory direction of travel: incident reporting will be pushed toward standardization and centralization at EU level. You should therefore:

• Centralize incident reporting inside your organization (one intake, one governance path, one evidence spine).
• Standardize the data model and decisioning behind “major ICT-related incidents” so you can map to a future hub without rebuilding the process.
• Prove that the process runs under stress: escalation, approvals, quality control, and remediation closure artifacts.

Reference for full context: (Regulation (EU) 2022/2554)

Plain-English interpretation (requirement-level)

Article 21 is a readiness and alignment requirement: regulators are actively evaluating a single EU-level reporting hub for major ICT incidents. Your supervisory reviewers will be comfortable when you can show you already report incidents through a centralized, repeatable workflow that produces consistent outputs, with clear ownership and audit-ready evidence.

Think of it as “design once, report many ways.” If the submission channel changes (for example, your national competent authority changes its portal, or an EU Hub emerges), you should only need to swap the “transmit” step, not redo classification criteria, stakeholder approvals, or supporting evidence collection.

Who it applies to (entity and operational context)

Entities in scope: Financial entities in scope of DORA incident reporting expectations are the population contemplated by Article 21’s EU Hub concept. Article 21 itself is written as an obligation on the ESAs to prepare a feasibility report, but it explicitly targets major ICT-related incident reporting by financial entities. (Regulation (EU) 2022/2554, Article 21)

Operational contexts that should be in-scope for your internal centralization design:

• ICT/security incident response and crisis management.
• Operational resilience / business continuity and service continuity.
• Regulatory reporting and supervisory communications runbooks.
• Third-party incident intake (outsourcers, cloud, SaaS, payment processors), because third-party outages are a common trigger for “major” incidents in practice.

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

Below is a practical build sequence that turns Article 21 into an implementable control outcome: centralized, hub-ready major incident reporting.

1) Appoint a single accountable owner for “major incident reporting”

• Name an accountable executive owner (often CISO, Head of Operational Resilience, or COO depending on your model).
• Name a compliance owner for regulatory submissions and recordkeeping.
• Define decision rights for: incident “major” determination, submission approval, and post-incident corrections.

Deliverable: RACI for major ICT incident reporting, approved by Compliance and ICT leadership.

2) Create a single internal reporting “front door”

Centralization starts before reporting to a regulator. Build one intake path that all major incidents must flow through:

• Incident intake channels: SOC tooling, service desk, third-party notifications, business escalations.
• A single case record in your system of record (IRM/GRC platform or ticketing system with controls).

Control test: Show that incidents raised in different tools still end up with one authoritative “major incident” record and timeline.

3) Standardize the “major incident” decision workflow

Even though Article 21 does not define thresholds, you still need a consistent internal workflow:

• Triage → “potentially major” flag → structured assessment → decision → approval → reporting package.
• Include third-party-driven incidents with the same criteria and evidence requirements.

Practical tip: Require a written decision note for both outcomes (“major” and “not major”). Examiners often ask for rationale on borderline cases.

4) Define a regulatory reporting dataset and evidence spine

Build a stable internal dataset that will map to any future EU Hub schema:

• Incident identifiers, impacted services, start/end times, customer/market impact narrative, containment steps, root cause hypothesis, third-party involvement, and recovery status.
• Evidence links: monitoring alerts, change records, comms approvals, status pages, third-party notices, internal exec updates.

Deliverable: “Major ICT Incident Reporting Data Dictionary” plus an evidence checklist.

5) Implement a regulatory-response workflow (requests, follow-ups, corrections)

Article 21’s theme is smoother reporting flow and cost reduction through centralization. To be ready:

• Establish a workflow for regulator questions, supplemental submissions, and corrections.
• Require Legal/Compliance sign-off for external statements where appropriate.
• Track obligations and due dates in a central queue.

Where Daydream fits naturally: Daydream can act as the control register and evidence hub that links your incident workflow to specific DORA obligations, owners, and supervisory-ready artifacts, so follow-up requests don’t turn into ad hoc document hunts.

6) Run readiness drills and close gaps with tracked remediation

Centralization is judged by repeatability under pressure:

• Tabletop exercises for a “major incident” scenario that forces: classification decision, approval, drafting, evidence assembly, and simulated submission.
• Capture issues as corrective actions with owners and validation evidence after closure.

Deliverable: Exercise report, action log, and closure evidence.

Required evidence and artifacts to retain

Maintain an examiner-ready package that demonstrates centralized operation and traceability:

Artifact	What it proves	Owner
Major ICT incident reporting policy/standard	Defined governance and centralized reporting path	Compliance / ICT Risk
RACI and escalation matrix	Accountability and decision rights	GRC
Major incident workflow (diagram + SOP)	Repeatable process, not person-dependent	IR / Ops Resilience
Data dictionary + reporting template	Standardized dataset suitable for future hub mapping	Compliance
Incident register with “major” decision notes	Consistent classification, including non-major rationale	IR Manager
Evidence checklist with links per incident	Audit trail completeness	Incident Commander
Regulatory-response log (requests, follow-ups)	Controlled comms and responsiveness	Compliance
Exercise reports + remediation CAPA	Ongoing readiness and learning loop	Ops Resilience

Common exam/audit questions and hangups

Expect reviewers to probe “centralization” in concrete terms:

1. “Where is the single source of truth for major incidents?”
   They want one system of record, not scattered email threads.

2. “Show me how third-party incidents get captured and assessed.”
   A common hangup is treating third-party outages as “vendor management’s problem” rather than major incident reporting input.

3. “How do you ensure report quality and consistency?”
   Look for templates, data dictionary, required fields, approvals, and QA checks.

4. “What happens after the initial report?”
   Regulators often ask for updates and final reports; they will check that you can manage iterations without losing version control.

5. “How do you evidence lessons learned and closure?”
   They will want remediation tracking and validation proof, not just a post-incident memo.

Frequent implementation mistakes and how to avoid them

Mistake: Building for a hypothetical EU Hub while ignoring current internal fragmentation.
Avoid it by focusing on internal centralization first: one workflow, one record, one dataset. The transmit channel can change later. (Regulation (EU) 2022/2554, Article 21)

Mistake: No explicit ownership across IR, ICT risk, and Compliance.
Fix it with a named accountable owner and an approval path that is usable during an incident, not just on paper.

Mistake: Weak evidence discipline (no timestamps, no decision rationale, missing third-party communications).
Solve it with an evidence checklist embedded into the incident record and enforced at incident closure.

Mistake: Treating “major incident reporting” as a one-time form.
Operational reality includes updates, corrections, and supervisory questions. Build a regulatory-response queue with sign-offs.

Mistake: Drills that stop at technical recovery.
Your exercise must force the reporting workflow: classification, drafting, approvals, and evidence packaging.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 21, so you should manage this primarily as a supervisory expectation and change-readiness risk rather than a “case law” driven requirement. (Regulation (EU) 2022/2554, Article 21)

Risk implications if you ignore the direction of travel:

• Operational risk: inconsistent internal reporting increases cycle time and errors during major incidents.
• Supervisory risk: inability to produce consistent, centralized records invites remediation actions after examinations.
• Third-party risk: fragmented intake of provider incidents leads to incomplete narratives and weak root-cause support.

Practical 30/60/90-day execution plan

You asked for speed. This plan is oriented around control outcomes and deliverables rather than calendar promises.

First 30 days (stabilize governance and intake)

• Confirm accountable owner and cross-functional RACI for major incident reporting.
• Document the “single front door” intake design (even if tooling changes later).
• Create the reporting template + minimum required dataset (data dictionary v1).
• Stand up a regulatory-response queue and sign-off rules (Compliance + Legal where needed).

By 60 days (standardize execution and evidence)

• Implement the workflow in your system of record (GRC/IRM/ticketing).
• Add an evidence checklist to the incident record and enforce it at closure.
• Backfill decision notes for recent “near-major” incidents to prove consistent classification.
• Train incident commanders and on-call leaders on the reporting workflow.

By 90 days (prove it runs under stress)

• Run a major incident reporting drill that produces a complete “submission-ready” package.
• Capture gaps and drive corrective actions to closure with validation evidence.
• Perform a lightweight mapping assessment: confirm your dataset can map to a new submission endpoint without redesign (the “hub-ready” test).

Frequently Asked Questions

Does Article 21 require my firm to report major ICT incidents to a single EU Hub today?

Article 21 describes a feasibility assessment by the ESAs for a single EU Hub; it does not itself establish a mandatory hub reporting channel. Your practical move is to centralize internal reporting so you can adopt a future channel with minimal change. (Regulation (EU) 2022/2554, Article 21)

What should I show an examiner to demonstrate “centralisation” right now?

Show a single system of record for major incident reporting, a defined workflow with approvals, and consistent evidence packaging per incident. Keep decision notes for “major” and “not major” determinations.

How do third-party incidents fit into centralised reporting?

Treat third-party notifications as an input to the same triage and classification workflow, with required evidence captured in your incident record. Require third parties to provide timely incident details through contractual and operational channels aligned to your dataset.

We have separate SOC, ITSM, and GRC tools. Do we need to replace them?

No. Centralisation can be achieved through one authoritative case record and controlled integrations or handoffs from feeder systems. Auditors care about traceability, timestamps, and consistency more than tool count.

What’s the minimum artifact set to be “hub-ready”?

A standardized reporting template, a data dictionary, a central incident register with evidence links, and a regulatory-response log for follow-ups. Add a drill report that demonstrates the process works end-to-end.

How can Daydream help without forcing a process rewrite?

Use Daydream to maintain a single register that ties Article 21-aligned controls to owners and evidence artifacts, and to run a regulatory-response workflow for escalations and remedial actions with Compliance sign-off. That reduces time spent assembling proof during supervisory requests.