Contents

DORA Measures Catalogue: From Regulation to Auditable Implementation

DORA Measures Catalogue: From Regulation to Auditable Implementation

Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, commonly known as DORA, requires financial entities to do far more than maintain general IT security policies. DORA establishes uniform requirements for ICT risk management, major ICT-related incident reporting, operational or security payment-related incident reporting, digital operational resilience testing, information and intelligence sharing, ICT third-party risk management, contractual arrangements with ICT third-party service providers, and the oversight of critical ICT third-party service providers.

A DORA Measures Catalogue provides the structured bridge between the legal text, IT operations, ICT risk control, and internal audit. It answers three central questions:

Which measures does DORA expressly require?
What do these requirements mean for IT as the 1st Line of Defence?
What must ICT risk control and internal audit examine as the 2nd and 3rd Lines of Defence?

This turns DORA from an abstract regulatory framework into a practical, controllable, and auditable implementation model.

Why a DORA Measures Catalogue Is Necessary

DORA uses the term “measures” in several different regulatory contexts. These include measures for the sound management of ICT third-party risk, response measures, recovery measures, corrective measures, containment measures, preventive measures, protection measures, backup and restoration measures, contingency measures, monitoring measures, and remedial actions.

These terms are not interchangeable. A response measure in the context of an ICT-related incident is different from a corrective measure after a failed resilience test. A backup and restoration measure under the ICT risk management framework is different from an exit-related contingency measure for an ICT third-party service provider. A remediation measure after an ICT audit finding is different from a supervisory measure imposed in relation to a critical ICT third-party service provider.

A robust DORA Measures Catalogue must therefore translate each regulatory measure into a clear operational requirement, an IT implementation expectation, and an auditable control or testing activity. Only then can a financial entity demonstrate that DORA has not merely been documented, but implemented and embedded into daily ICT operations.

The Most Important Types of Measures Under DORA

1. Measures for the Sound Management of ICT Third-Party Risk

DORA expressly requires measures for the sound management of ICT third-party risk. This is one of the core pillars of the regulation.

In practice, financial entities must manage ICT third-party risk as an integral component of their ICT risk management framework. They must maintain and update a register of information covering contractual arrangements with ICT third-party service providers. They must also assess relevant risks before entering into ICT service contracts, including concentration risk, criticality of the supported function, provider suitability, information security standards, subcontracting risk, termination rights, and exit capability.

For IT, this means operating a complete ICT provider inventory, service dependency mapping, criticality classification, technical risk assessment, SLA monitoring, provider security reporting, exit planning, and evidence management.

ICT risk control and internal audit must verify whether the register of information is complete and current, whether critical or important functions are correctly identified, whether provider risk assessments are documented, whether exit strategies are realistic and tested, and whether ICT third-party dependencies are adequately monitored.

2. Response, Recovery, and Corrective Measures

DORA requires the management body to be informed about major ICT-related incidents, their impact, and the response, recovery, and corrective measures taken.

For IT, this means that major ICT-related incidents must be documented in a management-ready format. Incident documentation must show affected systems, affected critical or important functions, business impact, root cause, response actions, recovery steps, containment activities, communication measures, and corrective follow-up.

The audit focus is not limited to whether an incident report exists. ICT risk control and internal audit must verify whether major ICT-related incidents were escalated promptly, whether the management body received sufficient information, whether recovery actions were aligned with recovery time objectives and recovery point objectives, and whether corrective measures were assigned to owners, deadlines, statuses, and effectiveness checks.

3. Preventive Measures and the Digital Operational Resilience Strategy

DORA requires financial entities to maintain a digital operational resilience strategy as part of the ICT risk management framework. This strategy must explain how ICT risk is addressed, how ICT objectives are achieved, and how the current digital operational resilience situation is evidenced, including through the effectiveness of preventive measures.

In IT practice, preventive measures include patch management, vulnerability management, endpoint detection and response, identity and access controls, multi-factor authentication, secure configuration, network segmentation, backup reliability, logging, SIEM coverage, and security monitoring.

ICT risk control and internal audit must assess whether preventive measures are defined, measured, reported, and periodically reviewed. They must also verify whether the effectiveness of preventive measures is evidenced through KPIs, KRIs, security testing, incident trends, audit results, and management reporting.

4. Protection Measures and Cryptographic Keys

DORA requires financial entities to implement ICT security policies, procedures, protocols, and tools to protect data, information assets, and ICT assets. It also expressly refers to protection measures for cryptographic keys.

Operationally, IT must implement controlled cryptographic key management. This includes secure key generation, storage, rotation, revocation, backup, segregation of duties, access restriction, privileged access monitoring, and logging. Depending on the risk profile, this may involve HSM or KMS solutions, formal key lifecycle procedures, and evidence of key access control.

The audit must verify whether cryptographic keys are managed under documented procedures, whether access is restricted and monitored, whether encryption is based on approved classification and ICT risk assessment processes, and whether key rotation and revocation are demonstrably effective.

DORA requires mechanisms to promptly detect anomalous activities, ICT network performance issues, ICT-related incidents, and potential material single points of failure. These detection mechanisms must define alert thresholds and criteria for triggering ICT-related incident response processes.

For IT, this means maintaining SIEM rules, SOC use cases, monitoring thresholds, anomaly detection, automated alerts, ticket creation, escalation workflows, on-call processes, and incident response runbooks.

ICT risk control and internal audit must verify whether detection mechanisms are regularly tested, whether alerts are correctly classified, whether response processes are triggered, whether escalation timelines are met, and whether incidents can be traced from technical detection through to closure.

6. ICT Business Continuity, Response, and Recovery Measures

DORA requires financial entities to implement an ICT business continuity policy and associated ICT response and recovery plans. These arrangements must ensure the continuity of critical or important functions and enable financial entities to respond to and resolve ICT-related incidents quickly, appropriately, and effectively.

In practice, IT must maintain business continuity plans, response and recovery plans, restart sequences, RTO and RPO definitions, failover procedures, restore runbooks, backup procedures, redundant capacities, crisis activation criteria, and recovery testing evidence.

ICT risk control and internal audit must assess whether critical or important functions are mapped, whether response and recovery plans are aligned with the business impact analysis, whether recovery plans are tested at least annually where required, and whether test results lead to documented remediation.

7. Backup, Restoration, and Recovery Measures

DORA contains specific requirements for backup policies and procedures, restoration and recovery procedures and methods, backup systems, segregated recovery environments, and checks to ensure data integrity after restoration.

For IT, this means defining the scope and frequency of backups based on data criticality and confidentiality. It also means implementing secure backup systems, physically and logically segregated recovery environments, periodic restore tests, reconciliation procedures, and data integrity checks.

The audit must verify whether backup policies are documented, whether backup frequencies correspond to business criticality, whether restoration tests are successful, whether backup environments are protected from corruption and unauthorised access, and whether recovery procedures achieve the defined RTO and RPO.

8. Containment Measures

DORA requires dedicated plans that enable containment measures, processes, and technologies suited to each type of ICT-related incident and designed to prevent further damage.

In IT practice, containment measures include isolating compromised systems, disabling compromised accounts, blocking malicious indicators of compromise, segmenting or severing network connections, quarantining endpoints, disabling affected interfaces, preserving forensic evidence, and preventing lateral movement.

ICT risk control and internal audit must verify whether containment runbooks exist, whether roles and responsibilities are clear, whether containment measures were activated in past incidents, and whether incident records show that further damage was effectively limited.

9. Communication and Crisis Management Measures

DORA requires crisis communication plans that enable responsible disclosure of major ICT-related incidents or vulnerabilities to clients, counterparts, and the public where appropriate. It also requires communication policies for internal staff and external stakeholders.

For IT, this means providing reliable technical facts for crisis management. IT must produce incident timelines, affected service lists, business impact assessments, technical root-cause information, workaround descriptions, service restoration status, and technical input for supervisory or client communication.

ICT risk control and internal audit must assess whether crisis communication plans are tested, whether crisis roles are assigned, whether internal and external communication channels are documented, whether technical situation reports are reliable, and whether communication decisions are supported by traceable evidence.

10. Digital Operational Resilience Testing and Corrective Measures

DORA requires financial entities, other than microenterprises, to establish, maintain, and review a sound and comprehensive digital operational resilience testing programme as part of the ICT risk management framework. The testing programme must identify weaknesses, deficiencies, and gaps and lead to the prompt implementation of corrective measures.

Testing may include vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, penetration testing, and, for selected entities, threat-led penetration testing.

For IT, this means maintaining a structured test calendar, test scope, test methodology, issue classification, remediation tracking, retesting evidence, and closure documentation.

ICT risk control and internal audit must verify whether tests are risk-based, whether critical or important functions are included, whether findings are prioritised, whether remediation is completed, and whether corrective actions are validated before closure.

11. Learning, Evolving, and Post-Incident Improvement Measures

DORA requires financial entities to learn from ICT-related incidents, cyber-attacks, digital operational resilience testing, business continuity activations, supervisory reviews, and information shared by counterparts.

Operationally, IT must conduct post-incident reviews after major ICT-related incidents, analyse root causes, assess whether procedures were followed, evaluate the effectiveness of response and communication, and incorporate lessons learned into the ICT risk assessment process.

ICT risk control and internal audit must verify whether post-incident reviews are performed, whether lessons learned are documented, whether recurring weaknesses are identified, and whether the ICT risk management framework is continuously improved based on incident and testing experience.

DORA encourages financial entities to exchange cyber threat information and intelligence within trusted information-sharing arrangements, provided that the relevant legal conditions are met.

For IT and security teams, this means establishing processes to receive, assess, and operationalise threat intelligence. Threat intelligence should feed into vulnerability management, detection logic, incident response procedures, security monitoring, and risk assessment.

ICT risk control and internal audit must assess whether shared threat intelligence is relevant, whether it is used in operational controls, whether the legal and confidentiality requirements are observed, and whether the organisation can demonstrate how threat intelligence improves detection, prevention, and response.

13. Exit and Contingency Measures for ICT Third-Party Service Providers

DORA requires financial entities to maintain exit strategies for ICT services supporting critical or important functions. These strategies must enable the financial entity to exit contractual arrangements without disruption to business activities, without limiting regulatory compliance, and without detriment to the continuity and quality of services provided to clients.

For IT, this means developing transition plans, identifying alternative providers, ensuring data portability, defining migration procedures, securing backup access, maintaining technical documentation, and testing whether services and data can be transferred or reintegrated in-house.

ICT risk control and internal audit must verify whether exit plans are documented, whether they are technically feasible, whether alternative solutions are identified, whether data transfer is realistic, and whether contingency measures support business continuity during provider failure or contract termination.

14. Contractual Control Measures for ICT Services

DORA specifies key contractual provisions for ICT services. Contracts must clearly allocate rights and obligations and must include service descriptions, locations of service provision and data processing, availability, authenticity, integrity and confidentiality requirements, access, recovery and return of data, assistance in case of ICT incidents, cooperation with authorities, termination rights, and training-related conditions.

For ICT services supporting critical or important functions, additional contractual requirements apply. These include full service level descriptions, performance targets, reporting obligations, business contingency plans, ICT security measures, TLPT participation where relevant, access and audit rights, and exit strategies.

IT, procurement, legal, and vendor management must therefore ensure that ICT contracts are not merely commercial agreements, but operational control instruments.

ICT risk control and internal audit must verify whether contracts contain the required DORA clauses, whether service levels are measurable, whether audit rights are enforceable, whether subcontracting is controlled, and whether contractual provisions support effective ICT risk management.

DORA establishes a Union Oversight Framework for critical ICT third-party service providers. This framework does not replace the financial entity’s own responsibility for managing ICT third-party risk. Financial entities remain fully responsible for compliance with DORA even where ICT services are provided by external or intra-group providers.

For IT and vendor management, this means maintaining provider documentation in a form that can support supervisory oversight. Architecture documentation, service dependencies, risk assessments, control evidence, incident records, audit reports, subcontracting information, exit plans, and provider remediation status must be available and reliable.

ICT risk control and internal audit must verify whether critical ICT third-party service providers are identifiable, whether documentation is complete, whether provider evidence is timely and reliable, and whether the financial entity can respond to supervisory information requests.

Role of IT as the 1st Line of Defence

Under DORA, IT is responsible for the operational implementation of ICT controls, ICT processes, ICT systems, and technical evidence. IT must ensure that the ICT risk management framework works in practice.

This includes:

technical protection controls,
ICT asset and information asset inventories,
ICT risk identification and assessment,
incident detection and response,
backup, restoration, and recovery,
business continuity and crisis support,
ICT third-party dependency management,
digital operational resilience testing,
remediation tracking,
technical documentation and evidence management.

The key point is that DORA does not require a purely conceptual ICT compliance framework. It requires operational resilience that can be demonstrated through functioning systems, tested procedures, reliable documentation, and traceable evidence.

Role of ICT Risk Control as the 2nd Line of Defence

ICT risk control must monitor whether IT implements DORA requirements appropriately and whether ICT risks are managed within the financial entity’s risk tolerance.

Typical 2nd Line of Defence activities include:

reviewing the ICT risk management framework,
challenging ICT risk assessments,
monitoring ICT KRIs and KPIs,
reviewing ICT incident trends,
monitoring remediation actions,
challenging ICT third-party risk assessments,
reviewing major ICT changes,
checking regulatory reporting readiness,
escalating control weaknesses,
reporting ICT risk exposure to governance bodies.

The 2nd Line of Defence therefore focuses on risk transparency, challenge, oversight, escalation, and management reporting.

Role of Internal Audit as the 3rd Line of Defence

Internal audit provides independent assurance on the appropriateness and effectiveness of DORA implementation. It must not limit itself to reviewing policies. It must test the operational reality.

Typical internal audit procedures include:

sample testing of ICT-related incidents,
reviewing major incident escalation,
testing backup and recovery evidence,
reviewing business continuity tests,
checking digital operational resilience test results,
tracing remediation findings,
testing ICT access and key management controls,
reviewing ICT third-party contracts,
checking provider evidence,
testing exit plans,
reviewing crisis management and communication procedures,
assessing the quality of evidence provided to management and supervisors.

The 3rd Line of Defence must determine whether DORA controls are not only designed, but also implemented, operated, tested, and evidenced.

The DORA Measures Catalogue Makes Implementation Auditable

A DORA Measures Catalogue is a central tool for implementing digital operational resilience in a controlled and auditable manner. It translates the legal terminology of DORA into concrete operational requirements for IT and into specific testing procedures for ICT risk control and internal audit.

Its value lies in the structured connection between regulation, IT operations, risk control, and audit:

The legal source defines the regulatory requirement.
The target requirement explains the intended control objective.
The IT practice describes what must be implemented operationally.
The audit procedure defines what must be tested by the 2nd and 3rd Lines of Defence.

This turns DORA from a legal obligation into a practical, auditable, and manageable ICT control framework for financial entities.