Article 14: Communication

DORA’s article 14: communication requirement means you must maintain an actionable crisis communication plan that supports responsible disclosure of major ICT-related incidents or vulnerabilities to clients, counterparties, and, where appropriate, the public. Operationalize it by defining disclosure triggers, decision rights, message templates, approval workflows, and test evidence inside your ICT risk management framework. (Regulation (EU) 2022/2554, Article 14)

Key takeaways:

• You need a written, executable crisis communication plan aligned to your ICT risk management framework. (Regulation (EU) 2022/2554, Article 14)
• The plan must cover responsible disclosure to clients and counterparties at minimum, and to the public when appropriate. (Regulation (EU) 2022/2554, Article 14)
• Examiners will look for clear accountability, fast internal escalation, controlled messaging, and proof the plan is tested and updated.

Article 14 sits inside DORA’s broader ICT risk management expectations and focuses on one outcome: during an ICT crisis, you communicate quickly, consistently, and responsibly to the right external audiences. The regulatory language is short, but the operational surface area is large. Your incident response team, SOC, IT operations, legal, compliance, privacy, customer support, communications/PR, and third-party management all end up in the process, often under time pressure and incomplete facts.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat “crisis communication” as a controlled process with pre-approved pathways, not ad hoc drafting during an incident. That means you set explicit triggers for when communications are required, define who can approve external statements, and maintain templates that translate technical impact into customer-facing language. You also need to decide how you will handle vulnerability disclosure versus incident disclosure, because the audiences, timing, and content controls differ.

This page gives requirement-level guidance you can implement immediately: scope, roles, step-by-step build, artifacts to retain, audit questions, and a practical execution plan tied directly to the article 14: communication requirement. (Regulation (EU) 2022/2554, Article 14)

Regulatory text

Requirement (excerpt): “As part of the ICT risk management framework referred to in Article 6(1), financial entities shall have in place crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts as well as to the public, as appropriate.” (Regulation (EU) 2022/2554, Article 14)

What the operator must do:
You must maintain crisis communication plans as a formal component of your ICT risk management framework. Those plans must enable “responsible disclosure” and must, at minimum, cover external communications about (1) major ICT-related incidents and (2) vulnerabilities to clients and counterparties, plus public communications when appropriate. (Regulation (EU) 2022/2554, Article 14)

Plain-English interpretation (what “good” looks like)

You need a repeatable way to communicate externally during ICT events without creating new risk. “Responsible disclosure” in practice means:

• You provide timely, accurate, non-misleading information tailored to the audience.
• You avoid disclosing details that materially increase exploitation risk (especially for vulnerabilities that are unpatched).
• You control who speaks for the firm, how content is approved, and how updates are issued as facts change.
• You can show this is part of governance, not a one-off document.

A strong implementation reads like an operations manual: who decides, what triggers outbound comms, what’s said, where it’s sent, and how you prove it happened.

Who it applies to (entity + operational context)

Entity scope: “Financial entities” in scope of DORA must comply. (Regulation (EU) 2022/2554)
Operational scope: Any business line, channel, or product where ICT disruption or vulnerabilities could affect:

• Clients (retail, corporate, institutional)
• Counterparties (market counterparties, partners, intermediaries)
• Public audiences (media, general public, broader market) when appropriate (Regulation (EU) 2022/2554, Article 14)

Where this usually lives:

• Ownership often sits with CISO + Head of Comms/PR, with Legal/Compliance as approval authorities.
• GRC typically owns the control definition, evidence, testing cadence, and mapping into the ICT risk management framework.

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

Use the steps below as your build sheet for the article 14: communication requirement.

1) Define “major ICT-related incident” and “vulnerability” triggers for communications

Article 14 requires disclosure capability for “major” incidents and vulnerabilities. (Regulation (EU) 2022/2554, Article 14) Operationally, you need a trigger model that is consistent with how your firm classifies incident severity and vulnerability criticality.

Deliverables:

• A communications trigger matrix (incident severity levels mapped to “notify / update / no external comms” outcomes).
• A vulnerability disclosure decision tree (e.g., confirmed exploitation, exposure to clients, third-party product vulnerability affecting service, patch available vs not).

2) Set decision rights and approvals (RACI that works under pressure)

Create a RACI that answers:

• Who declares a “crisis” for communication purposes?
• Who approves messaging for clients/counterparties?
• Who approves public statements?
• Who can speak to media?
• Who coordinates regulator-facing comms vs customer comms (even if those are separate obligations elsewhere in DORA)?

Minimum roles to name:

• Incident Commander (or Major Incident Manager)
• CISO (or delegate)
• Legal
• Compliance
• Communications/PR
• Customer Support lead
• Third-party manager (when the issue originates at a third party)

3) Build message templates that are safe and usable

You want templates that work for both incidents and vulnerabilities. Keep them modular so teams can fill in known facts without improvising.

Template blocks to pre-write:

• What happened (plain language)
• When it started / detection time (as known)
• Who is impacted (who, where, which services)
• What the customer should do (password reset, monitoring, contact points)
• What you are doing (containment, restoration, investigation)
• Next update time and channel
• Known unknowns disclaimer (avoid speculation; commit to updates)

4) Define channels, audiences, and contact data governance

Decide where messages go and who owns the lists:

• Client emails, portals, in-app notifications
• Counterparty distribution lists
• Status page
• Call center script updates
• Public web statement or press holding statement

Control requirement: you must keep contact lists current and restrict access. If contact data is wrong, “plans” fail.

5) Integrate communications into incident and vulnerability workflows

Your plan must be executable from the same systems your teams already use (ticketing, incident tooling, GRC). Build “communication tasks” into:

• Major incident playbooks (create draft, route approvals, publish, log evidence)
• Vulnerability management workflow (triage, exploitability, disclosure decision, patch coordination, customer messaging)

This is where many programs fail: the plan exists, but the workflow does not.

6) Test and exercise the plan, then track corrective actions

Article 14 explicitly requires having plans in place as part of the framework; supervisors will still expect evidence that the plan works in practice. (Regulation (EU) 2022/2554, Article 14)

Run:

• Tabletop exercises that include Legal/Comms and customer support, not only IT.
• Post-incident reviews that validate whether communications matched the plan.
• Corrective actions with owners and closure evidence.

If you manage controls in Daydream, store the plan, RACI, templates, exercise results, and remediation tracking in a single requirement record so you can show end-to-end traceability during supervisory review.

Required evidence and artifacts to retain (exam-ready)

Keep artifacts in a single, indexed repository. Auditors will ask for “show me” evidence.

Core documents

• Crisis Communication Plan (approved, versioned) mapped into ICT risk management framework scope. (Regulation (EU) 2022/2554, Article 14)
• Communication trigger matrix for major incidents and vulnerabilities. (Regulation (EU) 2022/2554, Article 14)
• RACI and escalation paths (including out-of-hours coverage)
• Message templates (client, counterparty, public) with approval rules

Operational records

• Incident timelines showing when communication decisions were made
• Approval logs (Legal/Compliance sign-off) and final messages issued
• Distribution evidence (screenshots, mailing logs, portal notifications)
• Exercise materials: scenarios, attendance, results, lessons learned
• Corrective action plan tickets and closure proof

Third-party related

• Where relevant, coordination records with affected third parties (who drafted what, what was approved, what was published), especially for shared incidents.

Common exam/audit questions and hangups

Expect questions like:

1. “Show the crisis communication plan and where it sits in the ICT risk management framework.” (Regulation (EU) 2022/2554, Article 14)
2. “How do you decide whether an ICT incident is ‘major’ for customer communications?” (Regulation (EU) 2022/2554, Article 14)
3. “Who can approve public disclosure and what controls prevent inconsistent messaging?”
4. “Show evidence from a recent incident or exercise: drafts, approvals, final comms, and timing.”
5. “How do you handle vulnerability disclosures when details could increase exploitation risk?” (Regulation (EU) 2022/2554, Article 14)

Hangups you can prevent:

• The plan references teams or tools that changed, but the document was not updated.
• Approvals require a single executive who is unreachable after hours.
• Support scripts conflict with PR statements.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating the plan as a PR document.
Fix: make it an operational runbook with triggers, RACI, and workflow steps tied to incident tooling.

Mistake 2: No vulnerability disclosure workflow.
Article 14 explicitly includes vulnerabilities, not only incidents. (Regulation (EU) 2022/2554, Article 14)
Fix: create a vulnerability disclosure decision tree and pre-approved language for “we are investigating” and “patch available” scenarios.

Mistake 3: Over-sharing technical detail early.
Fix: separate “customer impact statement” from “technical root cause analysis,” and control sensitive details until risk is reduced.

Mistake 4: Missing counterparty communications.
Fix: inventory counterparties by service dependency and define notification channels and owners.

Mistake 5: No evidence.
Fix: require communications artifacts to be attached to the incident record before closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t rely on enforcement anecdotes to justify design choices. Your risk case should be operational: poor crisis communication increases legal exposure, customer harm, counterparty disputes, and supervisory findings due to weak ICT risk management governance. (Regulation (EU) 2022/2554, Article 14)

Practical execution plan (30/60/90-day)

Numeric timelines are often helpful, but you asked for a plan you can execute without unsupported timing claims. Use phased delivery instead.

Immediate (stabilize)

• Assign accountable owner (single-threaded) and confirm Legal/Compliance approval authority.
• Publish a minimum viable crisis communication plan: triggers, RACI, draft templates.
• Create a single intake point for comms requests during incidents (ticket type or incident task).

Near-term (make it executable)

• Integrate communication steps into major incident and vulnerability workflows.
• Stand up channel governance: contact lists, status page ownership, call center script process.
• Run a tabletop exercise that includes Comms, Legal, and customer support; open corrective actions.

Ongoing (prove operation)

• Track each major incident for communications compliance: decision time, approvals, messages sent, and post-incident review.
• Refresh templates and contact lists based on lessons learned.
• Maintain a control-to-evidence register (Daydream works well for keeping the plan, tests, and artifacts tied to the article 14: communication requirement in one place).

Frequently Asked Questions

Does article 14 require public disclosure for every major ICT incident?

No. The text requires plans enabling disclosure to clients and counterparties at minimum, and to the public “as appropriate.” (Regulation (EU) 2022/2554, Article 14) Your plan should define what “as appropriate” means for your firm with clear decision rights.

Does article 14 cover vulnerabilities even if there is no confirmed incident?

Yes. The requirement explicitly includes “major ICT-related incidents or vulnerabilities.” (Regulation (EU) 2022/2554, Article 14) Treat vulnerability disclosure as its own workflow with controls to avoid increasing exploitation risk.

What counts as “responsible disclosure” in practice?

Provide accurate impact and action guidance without publishing sensitive details that could help attackers. Document your decision-making, approvals, and update cadence so you can show governance under audit. (Regulation (EU) 2022/2554, Article 14)

Who should own the crisis communication plan: Security or Communications?

Security should own technical classification and incident facts; Communications should own external messaging mechanics; Legal/Compliance should own approval gates. Put one accountable executive over the whole plan and document the RACI to prevent conflicts during an event.

How do we handle third-party incidents where the provider controls the narrative?

Pre-negotiate coordination in third-party contracts and playbooks: who drafts customer messaging, who approves, and how conflicts are resolved. Keep your own client/counterparty obligations front and center, and retain evidence of coordination decisions.

What evidence will an auditor ask for first?

The approved plan, triggers, RACI, templates, and proof of testing or real incident execution (drafts, approvals, final comms, and distribution records). Tie these artifacts to the incident record and retain them in a controlled repository.