DORA: ICT risk, providers and evidence

Definition: DORA es­tab­lishes digital operational re­silience for the financial sector

DORA introduces common digital resilience principles for the financial sector. Its goal is for banks, payment institutions, investment companies, insurers and other financial entities to be able to maintain services despite an ICT failure, cyberattack, provider error or operational incident. It is not merely a documentation exercise; organisations must be able to show that critical services have accountable owners, effective controls, completed tests and evidence that those controls operate.

Organising DORA remediation

Determine scope using entity type, exclusions and proportionality. A remediation timetable does not suspend existing obligations: incident reporting, access protection, backups and oversight must operate. Address urgent gaps promptly; reviews after 30/60/90 days assess progress.

• Critical or important functions: classify them using DORA criteria and disruption impact, not the everyday meaning of “critical”.
• ICT system: an application, infrastructure, cloud, network, backup or provider service supporting a critical function.
• Records of completed work: a test result, report, log, owner decision, review record or confirmed change.
• Remediation plan: owners, dates, dependencies and interim safeguards; approving a plan does not itself resolve non-compliance.
• 30-day review: assess the function map, register of information, evidence gaps and backup test results.
• 60-day review: verify incident classification and reporting, the test plan, contracts and management reports.
• 90-day review: assess provider oversight, monitoring, recovery, permissions and evidence completeness.
• After 90 days: regular ICT operations, assigned control owners, updated risks and a task list for improving resilience.

Legal status: DORA already applies

The Digital Operational Resilience Act is Regulation (EU) 2022/2554. It has applied since 17 January 2025, so in 2026 DORA is not a preparatory initiative but the governing ICT resilience regime. It brings together compliance, cybersecurity, business continuity, ICT provider oversight and IT operations.

What DORA changes for an organisation

DORA is more than a compliance project. It tests whether financial services can continue through a failure, cyber incident, provider error or ICT infrastructure disruption. Documentation is useful only when it is tied to real systems, completed tests, management decisions and clear service ownership. The benefit, however, is a more resilient organisation: clear critical services, known ICT providers, tested failure scenarios, faster incident response times, and evidence ready before an auditor or competent authority asks.

Main DORA areas

An operational DORA programme must map the relationships among business services, ICT systems, providers, risks, controls and evidence. Without that map, an organisation can easily create policies that no one can operate or maintain. Key DORA requirements include an ICT risk management framework, incident classification and reporting, regular operational resilience testing, ICT third-party risk management and documentation that shows decisions, actions and test results.

• ICT risk management: assets, processes, owners, business impact, risk tolerance and management decisions.
• Incident handling: classification, escalation, communication, registers, reporting and post-incident findings.
• Resilience testing: backup, recovery, failure scenarios, vulnerabilities, business continuity and exercises.
• ICT third-party risk: contracts, subcontractors, criticality, exit plans, SLAs, reports and reviews.
• Voluntary threat-information sharing: agreed rules, confidentiality and data protection; Article 45 does not require participation in every such arrangement.

Who does DORA apply to?

DORA applies directly to the financial entities within its scope. Other ICT providers may receive contractual and operational requirements from their financial-sector customers, while DORA's direct oversight framework applies to ICT third-party service providers designated as critical. Scope should therefore be assessed separately for the regulated entity, its services and the providers supporting critical or important functions.

Management body and service-owner responsibilities

Service owners perform assigned tasks and escalate risks. The management body remains responsible for the ICT risk framework; outsourcing and risk acceptance do not remove regulatory obligations.

• Which functions are critical or important, and which ICT systems support them.
• What kind of downtime, data loss or service degradation is unacceptable from a business perspective.
• Which ICT provider creates concentration risk, depends on subcontractors or lacks an exit plan.
• How we classify incidents and who decides on escalation, communication and the final report.
• What evidence reaches management after a test, incident, provider review or exception approval.

How to translate DORA into systems and ownership

What is most often missing is not the policy itself, but the connection between the business service, system, provider, risk and evidence that a control works. Without these links, the organisation cannot tell who performs a test, who accepts the risk or what must be shown during an audit or supervisory review.

• For each critical service, identify ICT systems, data, integrations, operational impact, business owner and technical owner.
• For each provider, specify the criticality, SLA, processing location, subcontractors, exit plan and method of receiving reports.
• Assign evidence for each control: test result, log, review record, decision, monitoring report or exception acceptance.
• For incidents, establish classification, escalation thresholds, contacts, reporting deadlines and a post-incident review template.
• For the management board, prepare a short map of risks, costs, tolerances and decisions requiring approval.

DORA, NIS2 and technical cybersecurity

DORA focuses on financial-sector digital resilience, while NIS2 governs cybersecurity more broadly across essential and important entities. For financial entities covered by DORA, however, the lex-specialis rule in NIS2 Article 4 must be considered: where a sector-specific Union act imposes equivalent ICT risk-management and incident-reporting requirements, the corresponding NIS2 provisions do not apply. Scope still needs an entity-specific assessment, and documents do not replace working controls and evidence.

What the supporting evidence should contain

Evidence quality is what separates a paper-only programme from an operational one. The supporting evidence should be maintained routinely, not assembled only before an audit or after an incident. This requires current documents, reports and confirmations that show controls operate in reality rather than only on paper.

• A register of information on ICT contractual arrangements, linked to services, providers, functions and owners; coverage is not limited to providers supporting critical functions.
• Incident log with classification, decisions, communication, response times and corrective actions.
• Results of backup, recovery, vulnerability, business continuity and emergency-scenario tests.
• Reviews of providers, contracts, SLAs, subcontractors, exit plans and concentration risks.
• Monitoring reports, access reviews, exception approvals and risk owner decisions.

A partner’s ISO 27001 certificate and DORA compliance

Virtline’s own ISMS certificate describes the certified management-system scope. It helps assess the partner’s working practices but does not certify a customer’s DORA compliance. Review conclusions need actual controls and current evidence.

Common mistakes in DORA implementation

Problems usually arise when compliance is disconnected from IT. An organisation may have a policy but no recovery test, a provider register but no clear link between systems and critical functions, or an incident procedure without a practiced escalation path.

Risks that need to be named directly

A robust DORA evidence set does not hide difficult dependencies. It shows where the organisation has a concentration risk, where a provider is critical, where backup testing does not confirm service recovery and where a management decision is required.

• One financial service depends on several systems, but only some of them have a technical owner.
• The ICT provider supports a critical process and the contract does not provide for an exit scenario or resilience reports.
• Incidents are closed in the helpdesk without regulatory classification and without a reporting decision.
• The backup test confirms that the file has been restored, but it does not confirm that the entire business function has been restored.
• Monitoring generates alerts but has no escalation path, priorities, or measurable response time.

How Virtline supports DORA

We combine auditing, implementation and ongoing operation of the ICT environment. We translate recommendations into configurations, procedures, tests, monitoring, documented evidence and operational tasks instead of leaving them in a table.

What the organisation receives after the project

The goal is a maintainable set of deliverables, not a one-off workshop document. The output therefore defines specific responsibilities, review intervals and required evidence rather than stopping at recommendations.

• Map of ICT services, critical functions, providers and decision owners.
• Gap register with priorities, dependencies, owners and time-bound deadlines.
• Incident-response, testing and provider-management procedures tied to real systems.
• Templates of management and operational reports that show the status of risks and activities.
• Supporting evidence for a DORA audit: registers, test results, reviews, decisions and acceptance records.

DORA priorities for 2026

Keep the results of tests, reviews and incident handling together so you can show an auditor, client or competent authority how your procedures work in practice. Identify the critical services and supporting ICT systems, who approves risk decisions, how recovery is tested and how providers are overseen.

• Maintain an up-to-date map of critical functions, ICT systems, providers, owners and technical dependencies.
• Link incident records to classifications, response times, escalation decisions and post-incident findings.
• Test operational resilience: backup, recovery, failure scenarios, communication and actions on the provider side.
• Regularly evaluate ICT contracts, SLAs, subcontractors, exit plan, processing location and concentration risk.
• Prepare a short report for the board: risk status, missing evidence, budget, decision owners and time-bound deadlines.

Quick selection of the scope: audit, implementation or maintenance

Not every organisation needs the same starting point. A company with established documentation may need evidence and configuration testing. An organisation without an ICT service registry should start with a dependency map. After an incident, the entity should first organise classification, communication and corrective actions. DORA is worth treating as a digital resilience programme that combines compliance, cybersecurity and IT maintenance.

Contact

Preferably before an auditor, client or competent authority asks for evidence. A short workshop helps separate critical activities from documentation work and establish a realistic regulatory gap-closure plan.

• There is no current map of ICT services, providers and critical processes.
• Backup exists, but there are no regular tests to restore services.
• Incidents are handled ad hoc, without classification or a record of decisions.
• ICT provider contracts do not reflect service criticality.
• The management board needs brief information about risk, budget and priorities.

Sources for the requirements and dates discussed