When must a financial entity tell its clients about a DORA major incident?
A client contract, a customer or a regulator now expects your DORA-aligned incident handling to include clear notice to the people affected. Article 19(3) requires a financial entity to inform clients without undue delay when a major ICT-related incident affects their financial interests, and to describe the measures taken to mitigate its effects. Where a significant cyber threat exists, the same provision requires the entity to tell potentially affected clients about the protective measures they can take. Your organization owns that decision and the wording of the message. The trigger is therefore a judgment made against your own classification of the incident, not a fixed clock that starts at detection.
The trigger, the content and the audience depend on three things: the type of financial entity you are, the client base you serve, and what the incident touched. A payment service that loses access to a payment channel affects different clients, and different financial interests, than an ICT outage in an internal reporting tool. Document the criteria that link a technical incident to a client impact before an event happens, including which clients are in the affected group and how you will identify them from your own records. Confirm with your competent authority and your legal counsel how sectoral rules applicable to your entity type interact with these duties. Under the Regulation, the ICT incident classification and reporting technical standards supply the incident criteria you should align with, so check the current text of Delegated Regulation (EU) 2025/301 in your planning.
Roles need to be fixed in advance. The organization decides whether a client is affected, approves the notice and carries legal responsibility for it. An implementation partner such as DeployOpen can prepare the workflow, the templates, the contact lists and the evidence trail, and can test that the notification path works from detection through to client message. Only an independent auditor or the supervisor assesses whether the arrangement meets the Regulation, and no partner can issue an attestation on it. Ask any partner for a written scope that names the artifacts they will deliver and who signs off each one.
How the client notification runs from detection to final update
The sequence turns a suspected ICT incident into a client message that is approved, released through an agreed channel and kept current as the incident develops. Each phase hands a named output to the next, so the entity can show who decided what and when.
Detect and classify the incident as major
The incident response team logs the event in the incident register, records what systems, services and clients it touches, and runs the classification criteria set in the entity's incident management process. The output is a classification record that states whether the incident is major and why, signed off by the person who owns incident management. Confirm the criteria against the current technical standards for incident classification before relying on them.
Decide whether client financial interests are affected
Once the incident is major, the crisis or incident lead assesses which clients or client groups lose service, data access, transaction capability or money, and whether that loss touches their financial interests. Legal and client-facing teams review the affected population against contracts and service descriptions. The output is a written decision listing affected clients, the impact type and the reasoning, so the notification duty can be evidenced later.
Identify protective measures for clients
Where the incident is a significant cyber threat rather than a realized impact, the team identifies the steps clients should take to protect themselves, such as credential resets, transaction checks or access restrictions. Where a major incident has occurred, the team records the mitigation measures the entity has taken to limit its effects. The output is a list of recommended client actions and mitigation measures, each checked with the system owner for accuracy.
Draft the client message
The communication owner drafts the notice using the crisis communication plan, stating what happened in plain terms, which clients are affected, what has been done and what clients should do. The draft avoids speculation about root cause and keeps technical detail for later reports. The output is a versioned draft with a fact check trail linking each statement to the incident record.
Approve the message with responsible managers
Designated managers, typically covering the ICT risk, legal, compliance and business lines, review the draft against the decision record and the classification. They approve or return it with comments, and the person tasked with the communication strategy confirms that the wording matches what the entity has told supervisors. The output is a recorded approval with names, dates and the final version, kept with the incident file.
Release through the agreed channel
The approved notice is sent to affected clients through the channel set in the crisis communication plan, such as direct email, a secure client portal or account manager contact, and the send is logged with recipients and timestamps. Media or public statements, where needed, go through the same approval record. The output is a distribution log showing who was told, how and when, which proves the notification was made without undue delay.
Issue follow-up updates as the incident develops
The communication owner keeps the affected clients informed as facts change, including when service is restored, when mitigation steps change or when new clients are affected. Each update goes through the same drafting and approval steps and is logged. The output is a dated update trail that runs to a closing notice confirming recovery and any remaining client actions, which then feeds the post-incident review.
What the crisis communication plan must enable under Article 14
Article 14(1) of DORA requires a financial entity's crisis communication plans to enable responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients and counterparts and, as appropriate, to the public. The plan is therefore not a press template. It is an operational document that must answer who tells which client, through which channel, with what content, and on whose authority, before the first notification goes out. Client notification under Article 19(3) is one output of that plan, so the plan has to be ready before an incident begins, not drafted during one.
Article 17(3)(d) sets the scope of what the communication plans must cover. They must address staff, external stakeholders and the media under Article 14, the notification of clients, internal escalation procedures including ICT-related customer complaints, and information for financial entities acting as counterparts. Complaint handling is easy to overlook: a surge of customer complaints can be the first sign of a major incident, so the escalation path from the complaints function to the incident team should be written down and tested. Ask the team owning complaints whether their queue has a route to the incident manager.
Two further obligations shape how the plan is built. Article 11(6)(b) requires crisis communication plans to be tested, so a desk exercise that walks through a client notification from classification to dispatch is part of compliance, not an optional drill. Article 11(7) requires the crisis management function of entities other than microenterprises to set clear procedures for internal and external crisis communications. Confirm with your competent authority and your own legal counsel how these procedures interact with the notification timing and content rules that apply to your entity type, since the regulatory technical standards and the EBA operational instructions can add detail.
What must be in place before a client notification is needed
Client notification under DORA is only as fast as the preparation behind it. The items below are the records, templates, paths and owners that must exist before an incident occurs, so that the entity can tell affected clients without undue delay. Each card names how to check that the item is genuinely working.
Current client contact register
Keep a register of every client whose financial interests could be affected by your ICT services, with named contacts, escalation contacts, preferred channels and out-of-hours numbers. Review it on a fixed cadence and after every contract change or staff move. To check it, pick three clients at random and confirm that the listed contact still exists, answers on the stated channel, and is authorized to receive incident information.
Pre-approved message templates
Prepare notification templates in advance, with placeholders for the incident description, the estimated financial impact, the measures taken to mitigate its effects and the protective steps clients should apply to a significant cyber threat. Legal and communications teams should approve the wording before any incident, so that only facts need to be filled in. To check them, ask whether each placeholder maps to a field the incident team actually records during triage.
Escalation path including customer complaints
Article 17(3)(d) expects internal escalation procedures that cover ICT-related customer complaints, so complaints about service disruption must route into the incident process rather than a separate queue. Define who classifies a complaint as a possible incident and who decides whether a client notification is required. To check the path, trace a simulated complaint from the service desk to the notification decision and time each handover.
Named owner for the communication strategy
Article 14(3) requires at least one person to be tasked with implementing the communication strategy for ICT-related incidents and fulfilling the public and media function for that purpose. Record this owner, a deputy, and their authority to speak externally. To check it, confirm that the named person appears in the crisis management documentation, has signed the role description, and can be reached when the primary contact is unavailable.
Testing schedule for the communication plan
Article 11(6)(b) requires crisis communication plans to be tested. Set a schedule that includes at least one exercise covering client notification, not only internal crisis response. Record each exercise's date, participants, the notifications sent, and the gaps found. To check the schedule, review the last exercise report and confirm that every gap has an owner and a closure date.
Record of client systems exposure
Maintain a mapping from each ICT system or service to the clients and client functions that depend on it. Without this map, the entity cannot judge quickly whether a major incident affects a client's financial interests. Keep the map linked to the asset inventory and update it when services are added, changed or outsourced. To check it, select one production system during a test and confirm the mapping lists every affected client within the time set by the crisis plan.
Who owns the notification, who prepares it, and who checks it
The financial entity owns client notification under DORA. Article 19(3) places the duty to inform clients without undue delay on the entity itself, and Article 14(3) requires at least one person in the entity to be tasked with implementing the communication strategy for ICT-related incidents and fulfilling the public and media function. The management body approves the crisis communication approach, and the people named in the plan decide when a major incident affects clients' financial interests and what the notice says about mitigation. These decisions cannot be delegated to an outside firm.
- Decision on triggers: the entity decides whether an incident meets the client-impact threshold and when the notice goes out.
- Named communications owner: one identified person carries the Article 14(3) role and holds authority to speak for the entity.
- Approval of messages: legal, compliance and the business owner review each notice before release.
- Protective measure guidance: the entity decides which steps it asks clients to take in a significant cyber threat.
- Record keeping: the entity keeps the timestamps, drafts and approvals that show what was sent and why.
Confirm that these named roles appear in the crisis communication plan and that deputies are named for absences.
DeployOpen works as an implementation partner. Under a fixed-scope engagement, DeployOpen can help prepare the systems, plans and evidence that support client notification, including the parts of Article 14 and Article 11 that concern communication procedures. This work is preparation only. DeployOpen does not decide when a client must be told, does not sign or send client notices, does not act as the public spokesperson, and does not issue reports, attestations or certifications.
- Plan and template drafting support: preparing notification templates, escalation paths and crisis communication plan structure for the entity to adopt.
- Tabletop exercise support: designing and facilitating scenario tests that exercise the notification process, since Article 11(6)(b) requires crisis communication plans to be tested.
- Evidence preparation: organizing test records, approval trails and plan versions so the entity can produce them on request.
- Tooling integration: configuring the self-hosted platforms that store contact lists, incident records and message logs inside the client's own infrastructure.
- Documentation handover: delivering written procedures the entity's own staff can run without the partner.
Ask any provider to state in writing which of these items it performs and which remain with the entity.
Supervision sits with the national competent authority for each type of financial entity under Article 46, and the authority may use its Article 50 powers to review how entities handle communication. An independent assessor, where the entity commissions one, reviews the same evidence to form its own view. Neither body is a service provider in this process: they test what the entity did and produced, and they issue no certificate for client notification. The only authority-issued attestation DORA provides for relates to threat-led penetration testing under Article 26(7), not to communications.
- Document review: the reviewer checks the crisis communication plan against Article 14 and Article 17(3)(d).
- Test evidence review: the reviewer examines tabletop records, lessons learned and plan updates.
- Sample of notices: the reviewer may ask for past client notices and the approvals behind them.
- Consistency checks: the reviewer compares what the plan says with what staff describe in interviews.
- Findings and follow-up: the reviewer reports gaps to the entity, which owns the remediation.
Confirm with your competent authority which evidence it expects and in what format.
Where client notification plans usually fail under DORA
Most client notification gaps under DORA are not missing policies. They are plans that were never exercised, rules nobody agreed on, and contact data that no longer matches the client base. The cards below cover the failures that surface most often and the check that catches each one before an incident does.
Crisis communication plan never tested
Article 11 requires crisis communication plans to be tested, and a plan that has only been read is not one. Teams often discover during a live incident that the approval chain is unclear, the templates are missing, or nobody knows which channel reaches clients. Run a tabletop exercise that ends with a client message actually drafted and approved within the timeline the plan sets. Record what slowed the team down and fix it before the next test.
No agreed test for financial interests
Article 19(3) requires clients to be informed without undue delay when a major incident affects their financial interests, but the Regulation does not give a checklist for deciding that. Without an internal rule, the decision depends on who is on call and becomes hard to defend later. Write down the criteria that trigger client notice, such as impaired transactions, delayed payments or exposed client assets, and record who made each call and when.
Client contact lists out of date
A notification sent to a former contact or a shared mailbox nobody monitors counts as no notification in practice. Client lists drift as accounts close, counterparties change and service contacts leave the firm. Tie the client register to the service catalogue so every client affected by a given service can be identified quickly, and verify contact routes on a fixed schedule. Confirm that the list can be filtered by affected service, not only exported in full.
Conflicting media and client messages
When the public statement and the client notice describe the incident differently, clients question both and the authority may ask why. Typical conflicts involve the cause, the number of clients affected or the expected recovery time. Draft one fact sheet from the incident team's current findings and derive every outbound message from it, with a version number and a timestamp. Require the fact sheet to be reissued whenever the facts change.
No named owner for public communication
Article 14(3) requires at least one person to be tasked with implementing the communication strategy for ICT-related incidents and fulfilling the public and media function. Where that role is assigned only as a shared responsibility, nobody approves wording at 2 a.m. Name a primary and a deputy in the plan, state their authority to publish, and confirm both have contact details that work outside office hours. Check that the named people appear in the current staff list.
Complaints not linked to escalation
Article 17(3)(d) expects internal escalation procedures to cover ICT-related customer complaints. In many firms, complaints go to a customer service queue and never reach the incident team, so a service outage shows up as dozens of separate tickets rather than one major incident. Set a rule that a defined number of complaints about the same service within a short window triggers escalation to incident management. Review complaint categories regularly so that technical faults are not filed under billing or general inquiries.
What the Digital Omnibus proposal could change
The Commission's Digital Omnibus proposal, COM(2025) 837 of 19 November 2025, would change how major ICT incident reports reach supervisors. It would amend Article 19 of DORA so that major incident reports and voluntary threat notifications pass through a single entry point under NIS2 instead of going to each financial entity's competent authority directly. The proposal is tracked as procedure 2025/0360(COD), and as of October 2026 the European Parliament's Legislative Observatory lists it as awaiting committee decision. Nothing in the proposal is law until it is adopted, so entities should treat the current Article 19 as the operative text. The proposal on EUR-Lex is the place to read what is being changed.
The likely effect is on the channel, not on the substance of the client duty. Article 19(3) requires an entity to inform clients without undue delay when a major incident affects their financial interests, including the measures taken to mitigate its effects, and to warn potentially affected clients about protective measures when a significant cyber threat is present. A new reporting route to a single point would not remove that obligation to clients. Compliance leads should ask their competent authority, in writing, how it expects to receive reports during the transition, and confirm whether any interim instructions or templates will change the notification timing or content they have planned for.
The practical step is to keep client notification as a standalone workstream in the incident response plan, with named owners for drafting, approval and release, and with the public communication role under Article 14(3) assigned to a specific person. Build the notification templates so that the reporting channel can be swapped without rewriting the client messages. Test the crisis communication plan on the current requirements and record the results, so that any change to the reporting route becomes a configuration update to the plan rather than a redesign. Review the plan again once the procedure's outcome is known and once the competent authority publishes its guidance.
Questions buyers ask about DORA client notification
When does DORA require us to notify clients about an incident?
DORA requires you to inform clients without undue delay when a major ICT-related incident affects their financial interests. The notice must also describe the measures taken to mitigate the effects. The trigger is the effect on clients' financial interests, not the incident label alone, so the first step is an internal assessment of who is affected and how. For significant cyber threats, the duty is different: you must tell potentially affected clients about protective measures they can take. Confirm the exact wording and scope with your competent authority and your legal team, and record the time of your assessment so you can show why the notice was sent when it was.
Must every ICT incident be communicated to all clients?
No. The notification duty in Article 19(3) applies to major incidents that affect clients' financial interests, and the notice goes to the clients who are affected. Minor incidents that do not reach clients' financial interests do not trigger a client notice under this provision, although they still count toward your incident records and classification. Your crisis communication plan should define the criteria that move an incident from internal handling to client notice, and who applies them. Keep the classification reasoning in the incident file so an assessor can trace each decision.
Who decides on and signs off a client notice?
The organization decides and owns the notice, and the decision should sit with named roles in the crisis management function. Article 14(3) requires at least one person in the entity to be tasked with implementing the communication strategy for ICT-related incidents and fulfilling the public and media function. Your communication plans must also cover internal escalation, including ICT-related customer complaints, under Article 17(3)(d). In practice, define who drafts, who approves on behalf of management, and who sends. Test these steps as part of your crisis communication exercises, because Article 11(6)(b) requires the plans to be tested.
Can an ICT provider send client notices on our behalf?
A provider can prepare drafts, monitor systems and supply the technical facts, but the financial entity remains responsible for the notice to its clients. DORA places the duty on the entity, so the message should come from the entity, in its name, after its own review. Put this split in the contract with the provider: who supplies timestamps and impact data, how quickly, and who approves wording. Be cautious about any arrangement that removes your control over what clients receive. Confirm the legal position for your jurisdiction and entity type with counsel and your competent authority before relying on a provider for distribution.
How much effort does a client notification readiness project take, and what drives it?
The effort depends mainly on the number of client groups, the number of systems that can affect them, how mature your incident classification already is, and how many approval steps the notice needs. No researched duration or fee applies here, so ask any implementation partner for a written scope that lists each deliverable: the notification criteria, the templates, the escalation paths, the role assignments and the test exercises. Costs are one-time for design and testing and recurring for retesting, staff changes and template updates. Ask for the scope in writing before work starts, and check that the quote covers testing rather than only documents.
Can we build client notification capability in-house?
Yes, many organizations do this in-house, provided they have people who understand DORA, incident classification and crisis communication, and who can run tests. The requirements are about the plan, the roles and the tested procedures, so an internal team can own them. Outside help is most useful for specialist gaps, such as reviewing the criteria against your entity type, running a realistic exercise, or preparing evidence for an assessor. DeployOpen prepares systems, controls and evidence for compliance assessments and runs security testing and training, but it does not issue reports or certificates, and an independent auditor or authority makes that judgment.
How DeployOpen prepares client notification readiness
DeployOpen helps regulated financial entities prepare the systems, communication plans and evidence needed to tell clients about major ICT incidents. We plan, implement and document the notification workflow inside your own infrastructure, and we do not issue reports or attestations, which remain the role of your competent authority and independent assessors.
How we scope
- We agree a written scope listing which client groups, channels and incident types the notification workflow covers.
- We confirm which roles own the Article 14(3) communication function and who approves client messages.
- We record the systems and data sources the workflow depends on, so scope and deliverables are fixed before work starts.
How we build
- We configure the open-source platforms in your environment to hold notification templates, contact lists and escalation paths.
- We draft crisis communication plans covering clients, counterparts and public statements, mapped to your incident process.
- We set up logging so the time and content of each client notice can be shown later to supervisors and auditors.
How we hand over
- We deliver the communication plan, runbooks and test records in a form your compliance and legal teams can review and sign off.
- We run a walkthrough of a simulated client notification so the designated person can operate the workflow without us.
- We document open items and the points your legal counsel must confirm before the plan takes effect.
How we support
- Testing of the crisis communication plan can be repeated on a schedule you agree, to support the testing expected under Article 11.
- Changes to clients, contracts or platforms can be updated in the plan through an agreed change process.
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
