DORA compliance is an ongoing responsibility rather than a one-off implementation project. The precise measures required will depend on the entity’s size, risk profile, activities and applicable regulatory framework. Nevertheless, the following areas should form the foundation of a DORA compliance programme.

1. Establish governance and accountability

The management body has ultimate responsibility for the financial entity’s ICT risk. It should define, approve and oversee the ICT risk-management framework, establish clear responsibilities and receive timely information about major incidents, testing results, control weaknesses, third-party dependencies and remediation.

The management body should also approve and periodically review ICT business-continuity and response-and-recovery arrangements, oversee policies governing ICT third-party services and allocate appropriate budgets and resources.

Responsibility for managing and overseeing ICT risk should be assigned to an appropriate control function, with sufficient independence and segregation from internal audit. DORA permits the Three Lines Model or an equivalent internal risk-management and control framework.

Members of the management body must also maintain sufficient knowledge and skills to understand and assess ICT risk, including through regular training.

2. Maintain a comprehensive ICT risk-management framework

Financial entities should establish and maintain a sound, comprehensive and well-documented ICT risk-management framework as part of their overall risk-management arrangements.

This includes identifying and classifying ICT-supported business functions and maintaining accurate inventories of information and ICT assets. Entities should understand which systems, processes, people and third parties support their critical or important functions and how those dependencies could affect service continuity.

The framework should include proportionate protection, prevention and detection controls, secure and up-to-date ICT systems, continuous vulnerability and threat monitoring, and clear processes for assessing risk when systems, services or suppliers change.

Financial entities must also maintain ICT business-continuity and response-and-recovery arrangements. These should define recovery-time and recovery-point objectives, backup and restoration procedures, crisis-management responsibilities and communication plans.

For most entities, the ICT risk-management framework must be reviewed at least annually and after major incidents, material changes, testing results or audit findings. It should also be subject to regular independent internal audit. Certain microenterprises and qualifying entities are subject to different or simplified requirements.

 3. Classify, manage and report ICT-related incidents

Financial entities must have processes to detect, manage, record, classify and report ICT-related incidents.

Incident classification should consider factors such as affected clients and transactions, service downtime, geographical spread, data loss, the criticality of affected services, reputational consequences and economic impact. Potential major incidents should be escalated promptly, and reporting responsibilities should be understood before a disruption occurs.

Major ICT-related incidents must be reported to the relevant competent authority through initial, intermediate and final reports. Under the current EU framework, the initial notification is generally due within four hours of classification as a major incident and no later than 24 hours after the entity becomes aware of the incident. An intermediate report generally follows within 72 hours of the initial notification, while a final report is generally due within one month of the intermediate or latest updated intermediate report.

For CySEC-regulated entities, the applicable forms, submission process and deadlines are explained in CySEC Circular C700. CySEC has subsequently highlighted deficiencies in how some entities classify and report incidents and has reminded regulated entities to apply the relevant criteria and thresholds carefully in Circular C751.

Notification of a significant cyber threat is voluntary under DORA where the entity considers the threat relevant to the financial system, service users or clients.

Incident processes should also be coordinated with other potentially applicable requirements, including personal-data-breach reporting. Major incidents that disrupt core activities should lead to structured post-incident reviews, root-cause analysis and corrective action.

4. Test digital operational resilience

Policies and plans cannot, by themselves, demonstrate resilience. Financial entities other than microenterprises must maintain a proportionate digital operational resilience testing programme.

Testing may include vulnerability assessments, network-security assessments, gap analyses, scenario exercises, performance and end-to-end testing, penetration testing and crisis simulations involving management and relevant business functions.

Appropriate tests must be conducted at least annually on ICT systems and applications supporting critical or important functions. Weaknesses identified through testing should be prioritised, remediated and subject to follow-up validation.

Threat-led penetration testing is a separate advanced requirement. It does not apply automatically to every financial entity. Entities selected by the competent authority under DORA’s criteria must generally undertake TLPT at least every three years, although the competent authority may adjust the frequency according to the entity’s risk profile and operational circumstances.

Recovery arrangements should also be tested under realistic conditions. An organisation should be able to demonstrate not only that systems can be restored, but also that business services, decision-making and communication can continue effectively during disruption.

5. Manage ICT third-party risk

Using an external service provider does not transfer the financial entity’s regulatory responsibility. ICT third-party risk must be managed as an integral part of the entity’s ICT risk-management framework.

Before entering an arrangement, financial entities should assess the provider, the services involved and whether they support a critical or important function. They should consider concentration risk, substitutability, subcontracting and the consequences of provider failure.

Contracts must contain the provisions required by DORA. Depending on the service, these may include service descriptions, security and availability requirements, incident-assistance obligations, data-access and recovery provisions, audit and inspection rights, subcontracting conditions, termination rights and cooperation with competent authorities. Arrangements supporting critical or important functions are subject to additional requirements.

Entities should monitor provider performance and risk throughout the relationship and maintain credible exit strategies. The objective is not necessarily to use several providers for every service, but to demonstrate that concentration and continuity risks are understood and can be managed without unacceptable disruption.

DORA also requires financial entities to maintain a register of information covering contractual arrangements for ICT services at the relevant entity, sub-consolidated and consolidated levels.

CySEC-regulated entities must currently submit their register annually by 28 February, with a reference date of 31 December of the preceding year. CySEC requires the register to be submitted in XBRL-CSV format, as explained in Circular C751.

DORA also establishes EU-level oversight for ICT third-party providers formally designated as critical. Other technology providers may be affected through the contractual and oversight obligations imposed on their regulated financial-sector customers.

6. Maintain evidence and invest in people

Regulators need evidence that controls operate effectively, not simply confirmation that policies exist.

Financial entities should maintain appropriate governance records, asset and dependency inventories, risk assessments, incident reports, test results, remediation records, supplier assessments, contract reviews, training records and internal-audit reports. Management information should allow the board and senior management to understand the organisation’s risk exposure and progress in addressing weaknesses.

People are equally important. DORA requires ICT-security awareness and digital-operational-resilience training to form compulsory elements of staff training. These requirements apply to employees and senior management, with the depth of training reflecting each person’s responsibilities.

Training should help personnel understand how to recognise and escalate risks, what to do during an incident and how their decisions affect the continuity of critical or important functions. Cross-functional exercises can help directors, executives, operations teams, technology specialists, compliance professionals and risk managers practise working together during realistic disruptions.

One of the most significant implementation mistakes is treating DORA as an initiative owned solely by the ICT department. Technology teams have an essential role, but resilience failures can also arise from unclear accountability, poor communication, inadequate supplier oversight or delayed decision-making.

Operational resilience ultimately depends on informed leadership, capable professionals and a culture in which risk information is shared and acted upon.