EU DORA Compliance

Start the compliance record with the covered entity type, the critical or important functions in scope, and the ICT services, assets, data locations, providers, and subcontractors that support those functions. DORA applies to defined financial entities and ICT third-party service providers, while the management body remains responsible for approving, overseeing, and being accountable for the ICT risk management 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.

DORA compliance should include a testing programme that covers ICT systems, controls, and processes according to risk. Evidence should show the testing universe, test type, frequency or trigger, owner, result, remediation decision, retest status, and management reporting. Tests can include vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, source-code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.

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.