EU DORA Compliance

Start the compliance record with the covered financial-entity type, any Article 2 exclusion considered, and whether Article 16 assigns the entity to the simplified ICT risk management framework. Then identify the critical or important functions and the ICT services, assets, data locations, providers, and subcontractors that support them. The financial entity's management body remains accountable for the applicable ICT risk framework. ICT third-party service providers are relevant through the entity's dependency and contract controls, while providers designated as critical are also subject to the separate Union oversight framework.

The governance file should make the management body's role visible: approved ICT risk framework, strategy, budget and investment decisions, risk tolerance, third-party risk strategy, escalation routes, and training evidence for management and staff. Compliance evidence is weak if it only names a policy owner and does not show how the management body reviews risks and receives incident, testing, and third-party reports.

DORA compliance should map ICT risk controls to the functions and services they protect. The core evidence set should include asset and information-asset inventories, risk assessments, risk treatment decisions, detection controls, business continuity and response plans, backup and restoration measures, change and vulnerability processes, logging, access controls, cryptography controls, and post-incident lessons learned.

The ICT risk management RTS adds operational detail that makes the evidence testable. For example, asset records should include ownership, business functions supported, continuity requirements, interdependencies, exposure to external networks, and support end dates where relevant. Vulnerability and patch management evidence should show sources monitored, scans or assessments performed, provider vulnerability handling, remediation tracking, and prioritisation.

DORA compliance requires an incident management process that can detect, manage, classify, escalate, and report ICT-related incidents. A usable compliance record should show all ICT-related incidents and significant cyber threats, the classification analysis, impacted services, senior-management escalation, client communications where required, and the report or notification submitted to the relevant competent authority.

Incident evidence should separate three questions: whether an event is an ICT-related incident, whether it is major, and what reporting package is required. The classification RTS covers criteria such as affected clients or counterparts, transactions, duration, geographical spread, data losses, criticality of services, reputational impact, and economic impact. The reporting ITS then standardises the initial notification, intermediate report, final report, reclassification, outsourced reporting notice, aggregated provider report, and voluntary significant cyber-threat notification templates.

For financial entities other than microenterprises, DORA compliance includes the Article 24 digital operational resilience testing programme. Microenterprises still need proportionate testing under Article 25, but they should not be recorded as subject to the Article 24(1) programme requirement. Evidence should show the testing universe, test type, frequency or trigger, owner, result, remediation decision, retest status, and management reporting.

Threat-led penetration testing is a narrower and more intensive obligation for financial entities identified by the relevant authority. TLPT evidence should not be a generic penetration-test certificate. It should include the validated scope, critical or important functions selected or excluded with rationale, threat intelligence report, red team test plan, blue team and red team reports, findings summary, remediation plan, attestation, authority involvement, and any joint or pooled testing arrangements.

DORA compliance must make ICT third-party dependencies visible before, during, and after a contract. The third-party file should show whether an ICT service supports a critical or important function, the pre-contract risk assessment and due diligence, concentration risk assessment, contractual clauses, audit and access rights, service-level and security monitoring, incident cooperation, exit plan, termination triggers, subcontracting permissions, and periodic reassessments.

The register of information is a central evidence artifact, not a procurement spreadsheet. The register templates are designed to capture contractual arrangements for ICT services, intra-group supply chains, entities using and signing arrangements, ICT providers, subcontractors that underpin critical or important functions or material parts, data storage and processing locations, sensitivity of data, and the level of reliance on the ICT service. Register evidence should reconcile to contracts, service inventories, outsourcing records, incident records, and concentration-risk analysis.

A DORA compliance file should be built so that a supervisor, internal audit team, external assurance reviewer, or management body can trace each obligation from source to owner to operating evidence. The pack should not rely on narrative assurance alone; it should contain dated records, control outputs, exceptions, approvals, test results, incident reports, supplier records, register extracts, and remediation status.

Oversight evidence is especially important where ICT third-party providers are designated as critical. DORA creates an oversight framework involving the European Supervisory Authorities, Lead Overseers, the Oversight Forum, recommendations to critical ICT third-party providers, competent-authority follow-up, and information exchange. Financial entities still need their own contract, monitoring, exit, and risk records even where a provider is subject to DORA oversight.