How to Draft a DORA Incident Policy That Works

A payment outage at 02:00, a compromised cloud account or a ransomware alert can become a regulatory event before the technical team has identified the root cause. For regulated firms, knowing how to draft DORA incident policy documentation is not a paper exercise. It is how management ensures that legal, compliance, operations, cyber security and critical suppliers act on the same facts, within the required timeframe.

The Digital Operational Resilience Act applies to a broad range of EU financial entities, including payment institutions, e-money institutions, investment firms, credit institutions and authorised crypto-asset service providers. It is not automatically applicable to every technology business or online gaming operator, so scope should be confirmed first. Where DORA applies, however, an incident policy must do more than describe a generic cyber response. It must support the detection, classification, escalation, reporting and closure of ICT-related incidents in a way that can stand up to supervisory scrutiny.

Start with the regulatory outcome, not a template

A copied policy often fails at the moment it is needed because it uses generic language such as “report material incidents promptly” without defining who decides materiality, what information is required or how the decision is recorded. DORA requires financial entities to establish and implement an ICT-related incident management process, classify incidents and report major ICT-related incidents to the relevant competent authority.

Your policy should therefore be a management-level control document. It sets the firm’s rules, ownership, decision rights and reporting principles. Supporting procedures, playbooks and technical runbooks should explain the operational detail: how a security alert is triaged, how a ticket is opened, how evidence is retained and how a regulatory submission is prepared.

This distinction matters. A policy that includes every technical response step quickly becomes outdated. A policy that is too high-level gives staff no workable path during an outage. The right balance depends on the firm’s size, business model, ICT architecture and reliance on outsourced providers, but the policy must always point clearly to the procedures that make it operational.

Define the incidents your DORA policy covers

Use a definition that captures more than cyber attacks. An ICT-related incident can arise from a system failure, data integrity issue, unavailable service, failed deployment, third-party outage, unauthorised access or operational error affecting network and information systems.

The policy should cover incidents affecting customer-facing services, internal systems, payment flows, trading or custody arrangements, client data, regulatory reporting and critical or important functions. For a crypto-asset service provider, that may include wallet infrastructure, private-key management environments, blockchain node providers, transaction-monitoring systems and custody partners. For a payment firm, it may include authentication services, core banking interfaces, cloud infrastructure and card-processing dependencies.

Avoid treating every alert as a regulatory incident. That creates alert fatigue and weakens escalation discipline. Instead, establish a clear staged approach: an event is identified, assessed as a potential incident, classified according to documented criteria, and escalated where it reaches the relevant threshold. The policy should require the rationale for material decisions to be recorded, including decisions not to submit a major-incident report.

Build an escalation model with named accountability

During a serious outage, the most expensive failure is often uncertainty over who is in charge. The policy must identify the incident owner and the functions that must be engaged at each stage. Titles are more durable than individual names, but role holders should be listed in an operational contact register maintained separately.

At a minimum, allocate responsibility across the ICT or security lead, business continuity owner, compliance function, legal counsel, risk management, communications lead and senior management. The compliance and legal functions should not be informed only after technical remediation has begun. They need early access to confirmed facts so the firm can assess classification, reporting obligations, client communications and contractual notification duties.

The management body retains ultimate accountability for the ICT risk management framework. Your policy should state when senior management must be notified, who may approve a major-incident classification, and who is authorised to make regulatory submissions. Include a contingency route where the primary decision-maker is unavailable. An escalation model that works only during office hours is not a credible control.

Set decision points, not vague expectations

A usable policy identifies trigger points. For example, immediate escalation may be required when a critical service is unavailable, sensitive data may have been compromised, a key third-party provider has failed, financial loss is accumulating, or a cross-border customer impact is likely.

The policy should then require the incident team to assess the criteria set out in the applicable DORA technical standards and supervisory reporting requirements. These may concern affected clients or counterparties, duration, geographical spread, transaction impact, data losses, economic impact, reputational effects and criticality of the affected service. Do not hard-code thresholds that may change unless there is a controlled process for legal review and policy updates.

Make regulatory reporting a controlled process

DORA reporting is not a single message sent at the end of an incident. Major ICT-related incidents may require an initial notification, subsequent reporting as the situation develops, and a final report after resolution and analysis. The precise format, channels and deadlines should be maintained in a controlled reporting procedure that reflects the firm’s competent authority and current technical standards.

Your policy should require the team to start a reporting clock as soon as a potentially major incident is identified. It should also establish a fact-validation process. Early reports may be based on incomplete information, but they must be accurate, appropriately qualified and internally approved.

Include a clear rule against waiting for a full root-cause analysis before escalating. Root cause can take days or weeks to establish, particularly where a cloud provider, software vendor or telecommunications supplier is involved. The firm should report what it knows, state what remains under investigation and update the authority through the prescribed process.

Where the incident affects customers, the policy should also address external communications. Regulatory notification, contractual notice and customer messaging are separate obligations with different audiences. They must be coordinated, but a public statement should never compromise an investigation, disclose security-sensitive details or contradict information given to the regulator.

Treat third-party dependency as part of incident management

A large proportion of operational disruption originates outside the firm’s direct infrastructure. DORA expects financial entities to manage ICT third-party risk, and an incident policy that ignores supplier involvement will leave a critical gap.

The policy should require suppliers supporting critical or important functions to notify the firm promptly of relevant events, preserve evidence, provide regular updates and cooperate with investigations. Those duties belong in contracts, service-level arrangements and exit plans, but the policy should make clear that the firm remains responsible for its regulatory assessment and reporting.

Maintain an escalation register for critical providers, including 24-hour contacts, contractual notification terms, service dependencies and alternative arrangements. For fast-growing fintech and crypto firms, this should include cloud providers, KYC vendors, hosting providers, custody technology suppliers, transaction-monitoring tools and managed security service providers. A supplier’s assurance that an issue is “contained” is not a substitute for your own classification analysis.

Connect the policy to testing, evidence and remediation

A policy proves its value in testing, not in board approval. Test realistic scenarios that cross functional boundaries: a cloud-region outage during a high-volume payment period, a ransomware event affecting customer data, or a compromised administrator account at a critical vendor. The purpose is to expose practical gaps in contacts, authority, evidence collection and reporting readiness.

Each exercise and live incident should produce a documented review. Record the timeline, decisions, evidence, communications, customer impact, regulatory assessment, lessons learned and remedial actions. Assign an owner and deadline to each action, then report overdue items through the appropriate risk governance forum.

The policy should also require periodic review following material changes to systems, outsourcing arrangements, business lines or regulatory guidance. A newly acquired regulated entity, a migration to a new cloud architecture or entry into a new EU market can change the firm’s incident profile overnight.

Approve a policy your team can execute

Before approval, test the draft against a simple question: can the on-call team identify the incident owner, reach the right decision-maker, assess potential major-incident status and begin controlled reporting without searching through multiple documents? If the answer is no, the policy needs further work.

A well-drafted DORA incident policy does not promise that disruption will never occur. It gives your business a defensible way to contain harm, protect customers and demonstrate control when disruption does occur. For firms operating under close regulatory scrutiny, that preparedness can protect both regulatory standing and the commercial confidence needed to keep growing.