DORA readiness for financial entities and their ICT suppliers

DORA has applied since 17 January 2025. For financial entities, readiness now means maintaining an operating model for digital operational resilience, not preparing for a future deadline. For technology suppliers, it means understanding customer-facing responsibilities and whether a separate direct oversight regime applies.

The leadership question is practical: can the organization explain which financial services depend on which ICT systems, how disruption will be handled, and what evidence supports its recovery assumptions? Policies matter, but they cannot answer that question alone. Management needs a connected view of responsibilities, dependencies, contracts, tests, incidents, and unresolved risks.

Determine your role before building the checklist

Start with a documented applicability decision for each relevant legal entity. DORA, Article 2 identifies covered categories and exclusions. A business describing itself as a FinTech, startup, or SME is not automatically in scope or exempt.

Examples of covered financial entities include credit institutions, payment institutions, investment firms, and insurance undertakings, subject to the regulation’s detailed scope rules. Record the applicable category, any exclusion or exemption, the relevant competent authority, and the reasoning behind your conclusion.

For suppliers, distinguish three positions:

A supplier supporting a critical or important financial function is not, for that reason alone, a designated critical ICT third-party provider. Financial entities assess the importance of their functions and dependencies; designation of critical providers takes place through the supervisory framework under Article 31.

Location does not settle the supplier question. A US-based cloud or software provider can face DORA-related customer requirements when serving EU financial entities. That commercial relationship does not automatically make it subject to every obligation imposed on a financial entity.

Proportionality also needs a reasoned assessment. Article 4 considers factors including size, overall risk profile, and the nature, scale, and complexity of services. Article 16 provides a simplified ICT risk-management framework for specified categories. These are not interchangeable concepts, and ordinary SME status is not a universal shortcut. Keep the eligibility analysis with the scope decision.

Make management accountability visible

Under DORA, Article 5, the management body has ultimate responsibility for managing the financial entity’s ICT risk. Delegating implementation to a CISO, technology team, or external provider does not transfer that accountability.

Leadership should establish who proposes decisions, who approves them, and who checks whether implementation works. The operating model should cover business continuity, incident response and recovery, third-party arrangements, budget, and the knowledge needed for meaningful oversight.

A practical recommendation is to give management a decision-focused reporting pack rather than a percentage-complete dashboard. Include:

• Critical or important functions with untested recovery assumptions.
• Material incidents, customer effects, and outstanding corrective actions.
• Supplier dependencies with incomplete contracts or weak exit options.
• Significant control gaps, accountable owners, and remediation dates.
• Decisions requiring funding, a change of supplier, or an explicit risk response.

Each gap should distinguish the regulatory requirement, the current operational weakness, and the proposed remedy. A missing approval record is different from a backup that cannot be restored. Both may need action, but they require different owners and priorities.

Management approval of a remediation plan is not permission to postpone applicable obligations indefinitely. Where a gap is material, consider immediate safeguards, escalation, and any supervisory implications alongside the longer-term fix.

Build the program around financial functions

An asset inventory is necessary, but resilience planning should begin with the service that must continue. Identify the financial function, its business owner, disruption consequences, and the systems and providers supporting it.

For a payment service, map identity, cloud infrastructure, transaction processing, monitoring, and supplier escalation. Include less visible dependencies such as DNS, connectivity, privileged access, encryption keys, and support tooling. An alternative production environment may be unusable if it depends on the same failed identity service.

The resulting map should connect each function to:

• Supporting applications, infrastructure, information assets, and external services.
• Relevant contracts and service owners.
• Recovery objectives and the business impact analysis supporting them.
• Detection, response, recovery, and communication arrangements.
• Tests, findings, and unresolved dependency risks.

Validate the map with both operational and business teams. Procurement records show what was purchased; they do not necessarily show how a service operates today.

Use this model to organize ICT risk management, incident management and reporting, resilience testing, and ICT third-party risk. DORA also contains provisions for voluntary cyber-threat information sharing. If participating, define membership, confidentiality, permitted use, and handling rules rather than treating sharing as an unrestricted exchange of incident data.

Turn ICT risk management into funded work

DORA’s ICT risk-management provisions cover identification, protection and prevention, detection, response and recovery, learning, and communication. The framework must connect these activities rather than leave them as separate policy collections.

Start the gap assessment with the mapped functions. Ask whether access controls protect their systems, vulnerabilities are addressed, changes are controlled, suspicious activity is detected, and recovery arrangements reflect realistic failures. Consider technical faults and operational mistakes as well as malicious attacks.

For each material weakness, create a remediation record containing an owner, business impact, required action, completion criteria, and evidence of closure. Dependencies matter: improving restoration procedures may require changes to backup access, supplier commitments, and staff training before a successful test is possible.

Recovery objectives should come from business needs and impact analysis, not from whatever a vendor’s standard service level happens to offer. Where the technical capability cannot meet the objective, management must decide whether to improve the architecture, change the service arrangement, or reconsider the operating model. A target written in a continuity plan is not evidence of recoverability.

Prepare incident decisions before the disruption

DORA requires financial entities to manage ICT-related incidents and report major incidents to the relevant competent authority. Articles 17–23 establish the framework; the applicable regulatory technical and implementing standards supply detailed classification criteria, thresholds, reporting content, and procedures.

Do not rely on a generic incident checklist for the detailed reporting schedule. Maintain a current reporting matrix identifying the applicable standards, authority instructions, submission channel, reporting stages, and deadline calculations. Assign responsibility for keeping it current.

The response process should make several decisions executable under pressure:

• Who records detection, assessment, and classification timestamps?
• Who obtains impact information from operations and suppliers?
• Who decides whether the major-incident criteria are met?
• Who approves and submits reports, including outside normal working hours?
• Who handles customer communication and other applicable notifications?

Record the classification reasoning even when an incident is not reported as major. An incomplete initial picture should trigger reassessment as information develops, not a permanent assumption that the event is minor.

Supplier notification commitments should leave the financial entity enough time to assess and meet its own obligations. Reporting tasks can be outsourced where permitted, but responsibility remains with the financial entity.

Where a major ICT-related incident affects clients’ financial interests, DORA requires financial entities to inform those clients without undue delay about the incident and the measures taken to mitigate its adverse effects. Separately assess personal-data breach obligations and other applicable rules. One disruption can create several notification decisions, with different recipients and legal tests.

Test the assumptions that management relies on

A digital operational resilience testing program should be proportionate and risk-based. Vulnerability assessments, scenario exercises, security testing, and recovery tests answer different questions; none should be treated as a universal substitute for the others.

A tabletop can establish whether decision-makers understand escalation. It cannot prove that transaction data can be restored accurately. A penetration test can expose exploitable weaknesses without proving that an alternative supplier can take over a service.

For each test, define the function, scenario, scope, success criteria, independence arrangements where required, and expected evidence. Preserve the results, findings, remediation decisions, and retest outcomes. Check applicable coverage and frequency requirements against DORA and the relevant standards, including any exemptions or simplified-framework provisions.

Threat-led penetration testing is a separate supervisory requirement for selected financial entities under Article 26. It is not a blanket obligation for every financial business or ICT supplier.

Management should review failed assumptions, not merely whether tests occurred. If an exercise reveals that restoration depends on one unavailable administrator, the outcome is an operational risk requiring action, not a completed testing milestone.

Treat third-party risk as a service-continuity issue

Under DORA, a financial entity remains responsible for its obligations when using ICT suppliers. Articles 28–30 connect third-party risk assessment, contractual arrangements, monitoring, and exit planning.

Maintain the register and the operational picture

Financial entities must maintain a register of information concerning ICT contractual arrangements at the required individual, sub-consolidated, and consolidated levels. Use the applicable implementing standards for its structure. A purchasing spreadsheet or list of approved vendors is not automatically sufficient.

Reconcile the register with contracts, service ownership, and dependency maps. Maintain required distinctions for services supporting critical or important functions. A new subcontractor, service location, or expanded scope can change the risk picture even when the supplier’s name stays the same.

Review contracts against the actual service

Assess the applicable contractual requirements, including service descriptions, locations, data protection, access and recovery of data, incident assistance, cooperation, termination rights, and service levels. Arrangements supporting critical or important functions require additional provisions, including relevant reporting, continuity, access, inspection, audit, and exit arrangements.

Legal, procurement, technology, and business owners should review these together. A contractual audit right may be difficult to exercise in practice; a promised recovery arrangement may not cover the customer’s full service chain. Identify those limitations before accepting the arrangement.

Examine concentration and exit capability

Concentration risk is not limited to purchasing several services from one company. Different suppliers may rely on the same cloud platform, region, network, or subcontractor. Assess substitutability, migration complexity, and the consequences of a common failure.

An exit plan should address data formats, extraction, access, migration dependencies, transition support, deletion, and continuity during the move. For critical or important functions, treat exit testing and review as substantive work, not a document-writing exercise.

Suppliers can prepare a consistent assurance package containing service scope, responsibility boundaries, incident contacts, continuity evidence, subcontracting information, and contract positions. Customer-specific requirements still need review; a certificate does not replace them.

Understand where DORA and NIS2 meet

DORA is an EU regulation with direct applicability. NIS2 is a directive implemented through national law, with applicability depending on sector, size, service, and inclusion rules. Its national transposition deadline was 17 October 2024; organizations need to examine the applicable national implementation rather than assume a single identical operating regime.

DORA Article 1(2), together with NIS2 Article 4, establishes the sector-specific relationship for covered financial entities in the relevant areas. Do not interpret this as an instruction to duplicate equivalent risk-management and incident-reporting controls. Equally, do not assume it removes obligations from every company in a financial group or its supply chain.

A managed service provider serving a bank may need its own NIS2 assessment while meeting DORA-related contractual commitments. An entity-by-entity obligations matrix should record the legal basis, scope, authority, reporting route, and evidence required.

Shared controls can support DORA, ISO 27001, privacy obligations, and customer assurance where scope and evidence match. Reuse an access review or recovery test when it genuinely supports several requirements, while preserving financial-sector details. An ISO 27001 certificate does not establish DORA compliance.

Enforcement also differs. DORA’s financial-entity supervisory powers and penalties depend on its provisions and applicable national measures; designated critical providers have a separate oversight regime. Do not budget risk around a supposed universal DORA fine. Assess the relevant legal exposure and the operational consequences of inadequate resilience.

Worked example: a payment-service dependency review

Consider an illustrative payment institution that uses a cloud platform, an identity provider, and an outsourced monitoring service. Assume the institution is in DORA scope and payment execution is classified as a critical or important function.

The first review finds three weaknesses: production and recovery environments share the same identity dependency; the monitoring supplier’s incident escalation process is unclear; and the cloud exit plan lists an alternative provider without demonstrating data extraction and migration.

Management commissions three linked work packages:

The business owner checks whether payment recovery objectives remain achievable. Compliance verifies that reporting procedures and register entries reflect the arrangements. Management approves necessary funding and reviews remaining limitations.

This example does not establish compliance by itself. It shows how one function can expose decisions that would remain hidden in separate policy, supplier, and testing checklists.

Establish an evidence-based review rhythm

DORA has no universal certification process that replaces ongoing obligations. Independent assurance can inform management, but readiness must be demonstrated through operating controls, records, and supervisory engagement where required.

A practical next step is to select one critical or important function and assemble its scope decision, dependency map, risk assessment, contracts, incident procedures, test results, and open actions. Review whether those records tell a consistent story.

Secani supports this workflow by modeling systems and services, connecting dependencies, and keeping requirements, evidence, owners, tasks, and review decisions in context. Upload existing material against the relevant objects, turn gaps into assigned work, and retain explicit human approval for AI-assisted suggestions and conclusions.

Expand from that first function once ownership and evidence paths are clear. Leadership should be able to see what has been demonstrated, what remains uncertain, and which decision is needed next.