What DORA Article 14 communication requires before a crisis hits
DORA Article 14 requires a financial entity in scope to have crisis communication plans ready before any incident happens, so that it can responsibly disclose major ICT-related incidents or vulnerabilities to clients and counterparts and, where appropriate, to the public. The obligation has three parts: the crisis communication plans themselves under Article 14(1), communication policies that separate the staff who run response and recovery from those who only need to be informed under Article 14(2), and at least one named person who carries out the communication strategy and the public and media function under Article 14(3). An assessor will look for all three in writing and will expect each to be traceable to the entity's wider crisis management arrangements.
The link to Article 11 is direct. Article 11 requires the crisis management function to set clear procedures for internal and external crisis communications, and it requires the crisis communication plans to be tested. An entity therefore needs to show who decides that an incident is communicable, who drafts the message, which clients and counterparts receive it first, and when a public statement is made. Confirm with your compliance and legal teams which thresholds in your own policies trigger each step, and check that the same names appear in the incident runbook, the business continuity plan and the contact lists used during an exercise.
Most of the effort here is about people and rehearsal rather than tooling. A plan that names a spokesperson who is unreachable at night, or that has never been walked through with the executives who would approve a statement, will not pass a test. Run tabletop exercises that include a vulnerability disclosure scenario as well as a major incident, record what was decided and how long it took, and feed the gaps back into the plans. Case tools such as DFIR-IRIS can hold the incident timeline that communication drafts rely on, but the decisions about what to say and to whom remain with named people in the organization.
Which entities, teams and channels fall under DORA communication duties
Article 14 applies to the financial entities listed in Article 2(1), but the work it creates depends on a few scoping decisions. Entity type, size, the people who run response and recovery, and the clients and providers who must hear about incidents each change what the crisis communication plan has to cover.
Financial entity types in Article 2
Article 2(1) lists 20 types of financial entity in points (a) to (t), from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Each type brings its own clients and counterparts, so the plan must name the audiences that apply to that entity, not a generic list. Check each point against the entity's license or registration before deciding which recipients the plan must reach.
Microenterprise crisis procedures
Article 11(7) requires the crisis management function of entities other than microenterprises to set clear procedures for internal and external crisis communications. A microenterprise is therefore not held to that explicit procedure, but it still needs a plan that enables responsible disclosure under Article 14(1). Confirm with the competent authority how it reads the exemption before deciding what a small firm documents.
Staff in response and recovery
Article 14(2) requires communication policies that separate staff involved in ICT risk management, particularly response and recovery, from staff who only need to be informed. The first group needs operational detail and decision authority during an incident. Map each role to one of the two groups in advance, and name the individuals who receive live updates.
Staff who only need informing
Staff outside the response team, such as customer service, sales, and business unit managers, need approved statements and escalation paths rather than technical detail. Article 14(2) requires the communication policy to cover them as a distinct audience. Test whether these teams can answer routine client questions from the approved message without speculating about root cause.
Clients and counterparts receiving notice
Article 14(1) requires plans that enable responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients and counterparts. Identify which clients, correspondent banks, payment schemes and other counterparts must be told, through which channel, and who approves the message. Keep contact details current, since an outdated distribution list is a common failure point in a live incident.
ICT provider communications
Where an ICT third-party provider notifies the entity of its own incident or vulnerability, that notice may need to appear in the entity's plans and decisions. Review contract notice clauses and escalation contacts for each critical or important provider, and confirm how their statements will be checked before the entity repeats them. Confirm the exact handling with your competent authority and counsel.
How an assessor tests the communication plan and its policies
An assessor starts by reading the crisis communication plan and asking whether it can be used in the first hours of a major ICT incident or vulnerability. Under Article 14(1), the plan must enable responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients and counterparts and, where appropriate, to the public. The assessor will walk through a realistic scenario with the plan in hand and check whether each step names a trigger, an owner, a channel and a recipient group. Expect questions about who decides that an event qualifies, how the decision is recorded and how the plan links to the incident management and crisis management processes.
- Trigger definitions: The plan should state which events start communication, tied to the entity's own incident classification.
- Recipient mapping: Clients, counterparts and public audiences should each have a defined message owner and approval path.
- Linkage to other plans: The plan should reference the incident response and business continuity arrangements it depends on.
- Common finding: Plans that describe principles but no concrete steps, or that were written for a generic outage and never adapted to ICT security events.
Confirm that the plan has a version history and an approval record from the management body, and that the scenario walkthrough can be repeated by someone who did not write the plan.
Article 14(2) asks for communication policies that treat internal staff and external stakeholders differently depending on their role. Staff who take part in ICT risk management, particularly response and recovery, need operational detail and access to working channels. Staff who only need to be informed need timely, approved messages and a clear statement of what they must not say. An assessor will check whether the policies make that split explicit and whether access rights and distribution lists reflect it. The test is usually a comparison between the written policy, the distribution lists in the tooling and a sample of messages sent during an exercise or a real event.
- Role groups: The policy should list response staff, informed staff and external stakeholder groups with the information each group receives.
- Channel control: Each group should be tied to named channels, and the assessor will look for unofficial channels that carry incident detail.
- Approval rules: External messages should show who approved them and what review they passed.
- Common finding: A single all-staff distribution list used for both operational detail and general updates, or policies that never mention external stakeholders.
Check that the role groups in the policy match the groups in your identity and collaboration systems, because mismatches are where assessors usually find gaps.
Article 14(3) requires at least one person to be tasked with implementing the communication strategy for ICT-related incidents and with fulfilling the public and media function for that purpose. An assessor will confirm that the appointment is documented, that the person understands the authority they hold and that someone can act if that person is unavailable. The test is less about the job title and more about whether a named individual can approve a holding statement at two in the morning, speak to a regulator's press contact and coordinate with the crisis management function.
- Written appointment: The role should appear in the plan and in an authority matrix approved by the management body.
- Delegated cover: Assessors look for a named deputy with the same authority and access to the same templates.
- Authority limits: The policy should state what the role may disclose on its own and what requires executive or legal sign-off.
- Common finding: A media role held by one person with no backup, or a role that exists only on an org chart and has never been briefed.
Ask to see when the current holder and deputy were last briefed and whether their contact details are in the crisis contact list.
Article 11(6)(b) requires crisis communication plans to be tested, and an assessor will expect evidence that the testing happened, what it found and what changed afterwards. A plan that has never been exercised is the most common weakness an assessor identifies, because it usually fails in the first real use. The test approach is to request the exercise calendar, the scenario scripts, the attendance records, the timing data and the post-exercise actions, then check that the actions were closed and that the plan was revised.
- Exercise scope: Records should show which parts of the plan were exercised, including external notification and the public function.
- Timing evidence: Logs or timestamps showing how long approvals and messages took should be retained.
- Action tracking: Each finding should have an owner, a due date and a closure record.
- Common finding: Tabletop exercises that discuss the plan without producing messages, or test records that show no revision after the exercise.
Confirm with the entity's own test program which exercises are planned, and keep the evidence in a system that records who changed what and when.
Steps to build a crisis communication plan that passes review
This sequence turns Article 14 into a tested set of plans, policies and named roles, each built on the incident classification the entity already uses, so that a reviewer can trace every communication back to a trigger, an owner and a test.
Map audiences and communication triggers
Start from the incident classification process the entity already runs under Chapter III. List the events that would require communication, such as major ICT-related incidents and vulnerabilities, and for each one name the clients, counterparts, regulators and, where appropriate, the public who need to hear about it. Involve the ICT risk function, legal, operations and the business owners of affected services. The output is a trigger matrix that links each classification outcome to its audiences, the channel for each audience and the person who decides to send the message. Confirm with the legal team which regulatory notifications run on separate timelines so the matrix does not blur them with stakeholder updates.
Draft the crisis communication plan
Write the plan that enables responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients and counterparts and, as appropriate, to the public. Cover the approval path for each message, the content elements each audience needs, the handling of unconfirmed facts, and how updates are sequenced after the first notice. The plan should reference the crisis management procedure rather than duplicating it. The output is an approved plan with version history, signed off by the management body or the delegate it designates, and filed where incident responders can open it during an event.
Write internal and external communication policies
Prepare two policies, one for internal communication and one for external stakeholders. Article 14(2) expects them to separate staff who take part in ICT risk management, particularly response and recovery, from staff who only need to be informed. Define the groups, the information each group receives, the channel and the restrictions on forwarding draft material. For external stakeholders, define who may speak for the entity and what must be cleared before release. The output is two policies with named owners, review dates set by the entity, and an access model that reflects the staff groups.
Appoint the public and media lead with a deputy
Article 14(3) requires at least one person to implement the communication strategy for ICT-related incidents and to fulfil the public and media function for that purpose. Name that person in writing, record their authority to speak and their escalation path to the management body, and appoint a deputy who can act when the primary contact is unavailable. Confirm that both hold current contact details and have been briefed on the plan. The output is a signed appointment, a role description and a contact sheet that is tested as part of the exercises in the next step.
Integrate the plan into the crisis management procedure
Article 11(7) requires the crisis management function to set clear procedures for internal and external crisis communications. Map the communication steps onto the crisis management procedure so that the incident commander, the communication lead and the reporting owner each know when they act and what they hand over. Check that the communication steps use the same incident identifiers, severity labels and case records as the incident tooling. The output is a cross-referenced procedure in which every communication step has a named owner and a point in the response timeline.
Schedule and run communication tests
Article 11(6)(b) requires crisis communication plans to be tested. Build the test schedule into the annual resilience testing programme and set at least one scenario that involves a major incident and one that involves a vulnerability disclosure. Run the scenario with the people named in the policies, including the deputy, and record timings, decisions, message drafts and gaps. Include a scenario where the primary spokesperson is unavailable. The output is a test report with findings, owners and due dates for corrections, presented to the management body as part of the governance reporting it already receives.
Close findings and keep the evidence current
Track each finding from the tests and from real incidents through to closure, updating the plan, the policies and the contact sheet as needed. Keep version history for every document so a reviewer can see what changed, when and who approved it. Use the same review cycle for communication documents as for the wider ICT risk framework. Ask the independent reviewer, whether an internal audit function or an outside assessor, to sample a recent test and an incident to check the trail from trigger to message. The output is a current evidence set that shows the plan was tested, changed where tests required, and approved by the right people.
How case records and document history support communication evidence
A case record and its audit trail can show what was communicated, when and to whom, which is the proof a supervisor will look for when reviewing how an entity handled a major ICT-related incident under Article 14. The practical step is to decide, before any incident occurs, that every external and internal message about an incident is logged against the same case. DFIR-IRIS, an open-source incident case management platform licensed under LGPL-3.0-or-later, keeps each case as one record of assets, indicators, tasks and evidence with a full audit trail, and builds a consolidated timeline from that record. Teams can use case tasks and notes to log each notification to clients, counterparts or the public, with the time, the recipient group and the approver. Whether the platform records outbound communications natively, or only through notes and tasks that staff must fill in, is something to confirm in your own deployment before relying on it.
Versioned policy documents answer a different question: which communication policy was in force on a given date. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. BookStack controls who can edit and approve pages through roles, with permissions that can be overridden at the shelf, book, chapter or page level. Together these features can show that the crisis communication plan, the staff communication policy and the spokesperson designation were approved and unchanged over the period an incident covers. Ask your implementation partner and your auditor to agree which version of each document governs which period, and confirm that approvals are recorded in the platform rather than only in email.
Neither tool proves the communication happened on its own. The evidence is strongest when case records, message copies from the channels used and the versioned plan point to the same identifiers, so an assessor can trace one notification from the plan that required it to the case that triggered it. Confirm the export formats, retention settings and access controls for each tool in your environment, and decide who may close or amend a case entry after an incident. Those decisions, along with how long records are kept, are the ones that determine whether the evidence holds up in review.
Evidence that satisfies Article 14 and how to keep it current
Article 14 is tested through documents, people and records, so an assessor will ask for the plan, the policies, the named role and proof that communication was rehearsed and used in real incidents. Each item below has an owner, a review trigger and a place in the evidence set, and the register should show when each was last approved.
Approved crisis communication plan
The plan sets out how the entity discloses major ICT-related incidents and vulnerabilities to clients, counterparts and, where appropriate, the public. Check that it names the triggers for activation, the decision makers who approve each outbound message and the channels used for each audience. Record the approval by the management body or the delegate it authorized, and the date of the last review. Expect an assessor to compare the plan against the crisis management function described under Article 11.
Internal and external communication policies
The policies distinguish staff who manage ICT risk, particularly during response and recovery, from staff who only need to be informed. The external policy covers stakeholders such as clients, counterparts, suppliers and regulators, and states who may speak for the entity. Confirm that both policies are approved, version controlled and reviewed alongside the broader ICT risk documentation so that changes in one are reflected in the other.
Role description and appointment for the public function
Article 14 requires at least one person to implement the communication strategy for ICT-related incidents and fulfil the public and media function. Keep a signed role description that states authority, escalation path, deputies and the limits of what the role may disclose without legal or management review. Keep the appointment record current when the post holder changes, and confirm that a named backup can act during an out-of-hours incident.
Distribution lists and contact registers
Maintain lists that show who receives each category of message, for example the response team, executive staff, affected clients and key counterparts. Each list needs an owner who confirms entries quarterly and removes leavers promptly. Store contact details with the plan so they can be reached when corporate email or identity systems are unavailable. Ask the entity to confirm how often the lists are checked and who records the check.
Message templates and approval records
Pre-approved templates for initial notices, status updates and closure statements save time during an incident and reduce the risk of inaccurate wording. Each template should carry a version number, the approver, the conditions for use and the placeholders that must be completed. Keep the approved wording with the change history, so an assessor can see which version was used for a given message and who authorized it.
Test reports, corrections and incident communication logs
Article 11 requires crisis communication plans to be tested, so keep the exercise scenarios, attendance, timings and findings for each test, along with the corrective actions and their closure dates. Real incident communication logs show every message sent, to whom and when, and whether the plan was followed. Store these in a case or knowledge system with an audit trail, and review the plan after each test or incident to reflect the lessons learned.
What meeting Article 14 costs in staff time, tooling and testing
This table breaks down the cost of meeting Article 14 by component, showing who is paid, whether the cost is one-time or recurring, and what drives it up or down. Use it to build an internal budget and to write the scope you send to any outside provider. The main takeaway is that open-source tooling removes license spend but not the staff time spent drafting, approving, rehearsing and maintaining the communication plans.
| Cost component | Who is paid or who spends time | One-time or recurring | Drivers and what to request in a quote |
|---|---|---|---|
| Drafting crisis communication plans and policies | Internal security, compliance and communications staff | One-time, then recurring on review | Number of client and counterparty groups, languages and media channels. Request the hours and roles assumed for drafting. |
| Management and approval cycles | Management body members and senior staff | Recurring | Frequency of approvals and the number of sign-off steps. Ask how approvals are scheduled and who can approve in an incident. |
| Legal and regulatory review | In-house legal counsel or external lawyers | One-time, then recurring on change | Complexity of disclosure obligations across jurisdictions and contracts. Ask whether counsel review is in or out of scope. |
| Communications and media review | Internal communications team or external PR advisers | Recurring | Public and media exposure of the entity and pre-approved holding statements. Confirm whether drafting public statements is included. |
| Tooling for plans, cases and records | Software vendors or the entity's own platform team | Recurring for hosting and upkeep | Self-hosted open-source wikis and case tools can remove license spend, but staff still set up, configure, patch and back them up. Request the setup and support hours. |
| Rehearsal and crisis exercises | Internal crisis team, facilitators and observers | Recurring, at least yearly under Article 11 | Number of scenarios, participants and whether exercises involve clients or counterparts. Ask for the facilitation scope and debrief outputs. |
| External facilitation of tests | Independent facilitator or implementation partner | Recurring per test cycle | Scenario complexity, scope of external participants and reporting depth. Request a fixed scope, deliverables and timeline in writing before work starts. |
| Auditor or supervisor sampling | Internal evidence owners, plus the independent auditor's fees | Recurring per assessment cycle | Number of tests and records sampled and how well evidence is kept. Ask providers to prepare evidence in a form the auditor can sample directly. |
Which open-source tools can hold communication evidence
DFIR-IRIS is an open-source incident response platform licensed under LGPL-3.0-or-later. For Article 14, its value is that a major incident's communication trail can sit in the same record as the technical investigation. Each case becomes one record of assets, indicators of compromise, tasks and evidence, so the notifications and decisions made during the incident can be linked to the facts that prompted them.
- Case-level audit trail: Actions taken on a case are logged, which helps reconstruct who was told what and when.
- Consolidated timeline: The investigation timeline can be used as the reference for the sequence of client, counterpart and public communications.
- Evidence handling: Evidence is logged with SHA-256 verification and chain of custody, supporting statements made to clients or regulators about facts.
- Report generation: Reports are generated from case data, which can feed the basis for external messages without retyping.
- Alert triage: Alerts from SIEM, EDR and REST sources are triaged into cases, so the start of the communication clock can be traced to a recorded event.
Confirm with your own team whether the case fields can hold your communication decisions, approvers and recipients, and whether your alert sources connect to the platform in your environment.
XWiki is a wiki platform licensed under LGPL-2.1-or-later. It suits the crisis communication plan itself, because the plan is a living document that must show what changed and when. Every change to a page is kept under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one, which gives an assessor a documented history of how the plan evolved.
- Change history: Each edit records the change, the date and the author, so revisions to contact lists or escalation thresholds are traceable.
- Version comparison: Reviewers can compare the version in force during an incident with the current version.
- Rollback: An earlier approved version can be restored if a later edit was wrong, with the rollback itself recorded.
- Structured pages: Plan sections, such as spokesperson roles and disclosure templates, can be kept on separate pages with their own history.
- Review trail: Annual reviews and testing results can be stored alongside the plan version they tested.
Confirm whether your approval workflow, such as sign-off by the management body, is recorded in the platform or kept elsewhere, and how exports will be preserved for an examination.
BookStack is a documentation platform licensed under MIT. Article 14 requires communication policies that separate staff who manage the response from staff who only need to be informed. BookStack helps show that separation through role-based access, where user abilities come from the roles assigned to them. Permissions can be overridden per role at the shelf, book, chapter or page level, so sensitive communication material can be restricted more tightly than general policy content.
- Role-based abilities: Users receive permissions through assigned roles, which keeps access tied to a documented function.
- Granular overrides: Permissions can be set at shelf, book, chapter or page level, for example limiting a media-response playbook to named roles.
- Separation of audiences: Internal informational notices and response-team procedures can sit in different books with different access.
- Policy publication: Current communication policies are published in one place for staff, with access evidence showing who could read them.
- Access review support: Role assignments can be reviewed periodically, producing a record that the staff differentiation is maintained.
Confirm that your identity arrangements, such as single sign-on and deprovisioning, are in place, because role assignments in the platform are only as current as the accounts behind them.
Common Article 14 gaps and how to close them
Most Article 14 weaknesses are not missing documents. They are plans nobody has exercised, roles with no named holder, and contact details that no longer work. The cards below cover six gaps that assessors and supervisors commonly find, each with a practical fix you can check against your own organization.
Plans that were never tested
A crisis communication plan that has only been written is hard to defend. Article 11 requires these plans to be tested, so a tabletop exercise should walk through a major incident from detection to the first client notice and the first public statement. Check whether the exercise produced dated minutes, the gaps it exposed, and the owner of each fix. A plan without a test record is the first thing a reviewer will ask about.
No named public and media lead
Article 14(3) requires at least one person to implement the communication strategy and carry the public and media function. Many organizations name a department instead of a person, or name one person with no deputy who is on leave during an incident. Name a primary and at least one deputy in the plan, confirm both can be reached outside office hours, and record who may speak to the press and who must route queries to them.
Policies that blur response and informed staff
Article 14(2) asks communication policies to separate staff who run ICT risk management, especially response and recovery, from staff who only need to be informed. In practice, a single all-staff channel often carries technical detail to people who should only hear the business impact. Write two distinct distribution lists and message templates, and check that the policy states which group receives operational detail and which receives approved summaries.
Vulnerability disclosure missing from the plan
Article 14(1) covers responsible disclosure of major incidents and vulnerabilities, but many plans only address incidents. Without a vulnerability path, a researcher or a counterparty who finds a flaw in your services has no defined route, and the decision to notify clients may be made ad hoc. Add an intake channel, a triage owner, criteria for when a vulnerability reaches clients or the public, and a coordinated timeline agreed before any public statement.
Plans disconnected from crisis management
Article 11(7) expects the crisis management function to set clear procedures for internal and external crisis communications. A communication plan kept by marketing or a press office, with no link to the incident commander or the crisis management function, will stall when decisions are needed. Confirm that the communication lead sits in the crisis management structure, that activation criteria are shared, and that both documents reference the same escalation path.
Outdated contact lists
Contact lists for clients, counterparts, regulators, service providers and staff decay quickly, especially after reorganizations and provider changes. A list that was accurate at go-live can misdirect a notice on the day it matters. Set a review cadence in the policy, assign an owner for each list, and test reachability in the same exercise that tests the plan. Keep the lists in a controlled location with version history so changes can be traced.
Questions buyers ask about DORA Article 14 communication
How much effort does a DORA Article 14 crisis communication plan take to write?
Effort depends mostly on how many stakeholder groups the plan must reach, how many systems and third-party services could cause a major incident, and how much of the content already exists in your incident response and business continuity documents. An entity that already runs a tested incident response plan usually adds the communication layer, which covers clients, counterparts, regulators and, where appropriate, the public. A plan for a large group with many business lines and cross-border clients takes far more drafting, review and approval than one for a single-licence firm. Ask any provider to break its quote into drafting, stakeholder mapping, template creation, review by legal and communications teams, and approval by the management body.
What drives the time it takes to prepare crisis communications under DORA?
Preparation time is driven by four things: the number of audiences you must notify, the approvals each message needs, the state of your existing documentation, and the number of tests you plan to run. Pre-approved templates for common incident types shorten the path from detection to a usable message, but legal review of wording for clients and counterparts still takes time, so it is better done in advance. Organizations that hold their incident and communication records in a shared case system and a version-controlled wiki tend to prepare faster because the documents already exist in one place. Confirm your internal approval cycle before you agree any delivery date.
What does the work need from our staff?
The work needs named people from risk, security, operations, legal, compliance and communications, plus a senior sponsor who can approve the plan. Article 14 separates staff who respond to and recover from ICT incidents from staff who only need to be informed, so the plan must define both groups and what each receives. You will also need one person formally tasked with implementing the communication strategy and fulfilling the public and media function. That person should understand the technical incident and the regulatory reporting timeline, and should be able to take decisions during a live event. Plan time for workshops and for at least one exercise that involves the people who would act in a real incident.
Can a small financial entity write and test its crisis communication plan in-house?
Often yes, provided the entity has a clear owner, a manageable number of clients and counterparts, and someone who can draft and test the plan without a large team. Article 14 requires the plan and the communication policies, not a particular size of department, and the proportionality principle in Article 4 of DORA applies to how far the detail must go. Small firms still need to test the plan, so an in-house team should schedule a tabletop exercise, record what failed and update the plan. Legal review of external wording remains important regardless of size. If your team lacks time or experience with incident simulations, an outside partner can help with the exercise design while your own staff own the decisions.
Can a partner write our DORA communication plan for us?
A partner can draft the plan, build templates, map stakeholders and design tests, but the financial entity remains responsible for its controls and for the decisions the plan records. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and prepares systems and evidence for compliance assessments. Under a fixed-scope engagement, the deliverables, scope and timelines are agreed in writing before work starts, so you can see exactly what the partner will write and what you must approve. DeployOpen does not issue audit reports, attestations or certifications, and it does not replace the legal or communications advice your organization needs. Ask any partner which parts of the plan it drafts, which parts your staff must sign off, and who will run the tests.
Does DORA provide a certification for crisis communication?
No. DORA sets no certification scheme for crisis communication or for any other requirement. Competent authorities supervise compliance using their supervisory powers under Article 50, so your communication plan is assessed as part of your wider ICT risk management framework during supervisory review. The only attestation the Regulation provides for is the one that a threat-led penetration test met its requirements under Article 26(7). Be cautious with any vendor or consultant who offers a DORA communication certificate, because no such certificate exists under the Regulation. Ask instead for evidence that your plan was reviewed, tested and approved, and keep it ready for your supervisor.
Official DORA text to read alongside this page
The exact obligations for crisis communication sit in the text of Regulation (EU) 2022/2554 itself, and this page is a practical reading of them, not a substitute. Start with the Article 14 anchor in the EUR-Lex copy of Regulation (EU) 2022/2554, which covers the communication plans, the internal and external communication policies and the designated person for the public and media function. Read the article as published in the Official Journal, in the language version your legal or compliance team will rely on, and note the paragraph numbers you cite in your own documents so that an assessor can trace each claim back to the source.
Before you rely on any wording, confirm three things against the official text: which obligations apply to your type of financial entity, since Article 14 sits inside Chapter II and the proportionality principle in Article 4 shapes how it applies, how Article 14 links to the crisis management and testing duties in Article 11, and whether any amendments or pending changes affect the provision. The Commission's Digital Omnibus proposal touches reporting routes under Article 19, not Article 14, but the procedure is still moving, so check its current status on the European Parliament's Legislative Observatory rather than relying on an older summary. Record the date you checked each source.
Use the official text as the basis for a short clause-by-clause checklist for your crisis communication plan. Map each requirement to a named owner, a document in your management system and a test you can run, and ask your legal counsel or supervisory contact to confirm any interpretation that affects who you must notify and when. Where the text leaves room for judgment, such as what counts as a major incident warranting public statements, document the decision and the reasoning, because that record is what supervisors and auditors will ask to see.
How DeployOpen prepares Article 14 communication evidence
The sequence below shows how a fixed-scope engagement turns Article 14 communication requirements into a tested crisis communication plan, policies and a named responsibility, with evidence handed to the client's own auditor or competent authority reviewer.
Agree scope and deliverables in writing
Before any work starts, the client and DeployOpen agree in writing which entities, business functions, incident types and communication audiences are in scope, along with the deliverables and the acceptance check for each. The client keeps ownership of its controls and its decisions on what is disclosed to clients, counterparts and the public. A quote follows from this written scope, so the client should ask for the scope document to list each deliverable separately. The step closes when both parties sign the agreed scope.
Map current communication practice and gaps
DeployOpen reviews existing incident, escalation and disclosure documents, contact lists and any public statements procedures with the client's risk, legal, communications and ICT teams. The review checks whether responsible disclosure covers at least major ICT-related incidents and vulnerabilities, whether staff who respond are separated from staff who only need to be informed, and whether a named person holds the public and media function. The output is a gap register tied to the Article 14 requirements, which the client's management reviews.
Draft the crisis communication plan and policies
DeployOpen drafts the crisis communication plan, the internal and external communication policy and the audience matrix inside the client's own environment, using the client's terminology, approval chain and legal review steps. The plan defines who approves a disclosure, which clients and counterparts are notified and in what order, and when public statements are appropriate. Drafts are version controlled and reviewed by the client's named owners. The step closes when the client's management body or delegated owner approves the documents in their recorded form.
Assign the communication role and its deputies
DeployOpen helps the client document the person tasked with implementing the communication strategy for ICT-related incidents and fulfilling the public and media function, along with deputies and the handover rules between them. The role description, escalation path and contact records are written into the plan. The client makes the appointment, and the step is complete when the assignment, deputies and contact details are recorded and confirmed by each person named.
Configure case and document tools where chosen
Where the client selects open-source tools, DeployOpen configures them in the client's infrastructure. DFIR-IRIS can hold each incident as one case with its timeline, tasks and evidence, which gives communication records a traceable source. XWiki or BookStack can host the plan and templates with version history and role-based permissions, so approvals and access can be shown to an auditor. The client confirms that each tool's specific capabilities meet its needs before adoption. The step closes with a configuration record and a test of access rights.
Run rehearsal support for communication scenarios
DeployOpen designs tabletop rehearsals of major incident and vulnerability disclosure scenarios, prepares injects and observer notes, and facilitates or supports the sessions the client runs. Each rehearsal tests message approval, notification of clients and counterparts, handling of staff who only need information, and the public and media function. Gaps found are logged with owners and due actions. The step closes when the rehearsal record, participant list and corrective action list are filed.
Remediate findings and update the plan
DeployOpen helps the client correct the plan, templates, role assignments and tool settings identified in rehearsal, then records each change with its reason, date and approver. Updated versions replace the prior versions while keeping the history. The client confirms that the corrections address each logged finding. The step closes when the change log shows every finding closed or accepted by the named owner.
Hand over evidence for the client's auditor
DeployOpen compiles the evidence package: the approved plan and policies, the role appointments, tool configuration records, rehearsal records, corrective action logs and version histories, organized against the Article 14 requirements and the testing expectations in Article 11. The client reviews the package and hands it to its own auditor or competent authority contact. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and the supervisory authority make those determinations, so the client should confirm with them in advance which evidence they expect.
