Checklist: Navigating DORA compliance: addressing practical post-implementation steps (EU)

Introduction

This checklist sets out steps to assist legal and compliance teams, in-house counsel and private practitioners when assessing organisational alignment with the requirements of the Digital Operational Resilience Act, Regulation (EU) 2022/2054 (DORA), which applies from 17 January 2025. DORA establishes a regulatory framework for digital operational resilience across the financial sector, applying to both financial entities and certain information and communication technology (ICT) third-party service providers. The checklist provides an overview to help teams review existing measures, evaluate their effectiveness, and identify and implement improvements. It is not exhaustive, and there is no one-size-fits-all approach. Compliance should be assessed on a case-by-case basis, considering the specific context and risk profile of each organisation.

This checklist addresses the following steps:

1. ICT risk management and governance
2. ICT-related incident management, classification and reporting
3. Digital operational resilience testing
4. Managing ICT third-party risks (including contractual arrangements)
5. Information sharing and intelligence

This checklist can be used in conjunction with the following How-to guide: DORA requirements for financial entities and ICT third-party service providers and Quick views: Understanding the application and scope of DORA and DORA compliance – regulatory requirements, technical standards and guidelines.

Step 1 – ICT risk management and governance

Step 2 – ICT-related incident management, classification and reporting

Step 3 – Digital operational resilience testing

Step 4 – Managing ICT third-party risks (including contractual arrangements)

Step 5 – Information sharing and intelligence

Explanatory notes

Overview

The Digital Operational Resilience Act, Regulation (EU) 2022/2054 aims to harmonise digital operational resilience requirements and the management of ICT risks across the EU financial sector. As of 17 January 2025, in-scope financial entities should have carried out all necessary contractual updates and must ensure that internal governance frameworks, policies and procedures are aligned with DORA’s requirements. This includes areas such as ICT risk management, incident reporting, resilience testing, third-party risk and information sharing. Having mapped out firm-specific milestones, firms should be confident in their compliance. This is particularly important as implementation plans may be requested by regulators or form the basis of internal or external audits.

DORA applies to a wide range of EU-regulated financial entities, not just the ‘traditional’ market players such as banks, investment firms and insurance companies, but also ‘new’ players in the financial market such as crypto-asset service companies and critical ICT service providers (eg, cloud service providers) (see article 2(1), DORA). The terms financial entity and firm are used in this checklist to refer to these in-scope entities for the purposes of DORA compliance.

Sanctions for financial entities for non-compliance under DORA are substantial, with fines of up to €10 million (maximum); however, member states may set a lower figure or 2% of the total annual worldwide turnover. There can also be fines of up to 1% of their average daily turnover for each day of non-compliance for up to six months. The maximum fine for critical third parties is €5 million (see section 4.6 for more detail on what the term means below). In some cases, reputational damage and sanctions against senior management and members of the board of the financial entity may also arise.

Many larger regulated firms may already have established practices for outsourcing oversight and systems in place to manage ICT-related risks and regulatory compliance. These firms are likely to be familiar with existing sectoral requirements and the European Supervisory Authorities (ESAs) made up of the European Banking Authority (EBA), European Securities and Markets Authority (ESMA) and the European Insurance and Occupational Pensions Authority (EIOPA) acknowledge that the effort required to comply with DORA may be more challenging for some financial entities particularly those that have historically been subject to fewer or less detailed sectoral requirements regarding digital operational resilience.

Legal framework

This checklist should be read alongside the level 1 and level 2 requirements:

Level 1 requirements

• Regulation (EU) 2022/2544 on digital operational resilience for the financial sector (DORA) – directly applicable and sets out the regulatory framework; and
• related Directive (EU) 2022/2556 (DORA Directive) – not directly applicable and requires member state transposition.

Level 2 requirements

• Various regulatory technical standards (RTS), implementing technical standards (ITS), delegated acts, guidelines and Q&A support the application of DORA.

Firms will therefore need to develop an approach that looks at both level 1 and 2 requirements holistically across digital operational resilience and the broader risk management strategy. Useful links to relevant legislation and RTS/ITS have been included under each of the step headings of the checklist.

See Quick view: DORA compliance – regulatory requirements, technical standards and guidelines.

Step 1 – ICT risk management and governance

Establishing, implementing and maintaining the effective and prudent management of ICT risk is a core requirement under DORA, including where ICT functions are outsourced to ICT third-party service providers. ICT risk refers to any threat that could compromise the security, availability or integrity of network and information systems causing disruption to operations or functions. Common examples include malware, phishing and cyber-attacks; however, incidents may also arise internally from human error (eg, data breaches, software certificate expiration) or from systems failures like outages. Financial entities must maintain an inventory and update it periodically or in good time when there is a major change – see article 8(3), DORA.

1.1 Is the ICT risk management framework integrated into the overall risk management strategy?

Firms should have a well-documented ICT risk management framework integrated into their overall risk management strategy. This framework should cover strategies, policies, protocols, systems and tools to protect ICT and information assets ranging from software to physical infrastructure. The framework should also outline how to identify, respond to, recover from and learn from ICT-related incidents, cyber threats and ICT vulnerabilities. Put simply, does the firm know how issues arise and have a plan in place to prevent escalation? To assess this, financial entities should ask the following questions:

• Are ICT-supported business functions, information assets and ICT assets supporting these functions clearly mapped out and regularly reviewed?
• Are ICT security, business continuity, crisis management and backup policies including disaster and recovery mechanisms up to date?
• Review the IT taxonomy and ICT concentration risk assessment to consider criticality and/or importance of systems and services. Consider whether any organisational or technical adjustments are needed.
• Establish cross-functional check-ins for key personnel (including legal, compliance, IT, procurement) to share information on current practice and evolving ICT risks and threats. These risks do not operate in isolation and may not be visible across all teams.

1.2 Has the firm established a governance and control framework for the management of ICT risks?

Financial entities should review their internal governance and control frameworks for managing ICT risks, including those related to services provided by ICT third-party service providers. Revisit DORA implementation plans, including mapping and classification of the ICT-supported business functions, personnel and designate clear roles and responsibilities for ICT risk oversight. Ensure everyone knows and understands their role, the nature of risks and address post-implementation compliance gaps.

1.2.1 Review existing team structures and ensure separate team structures exist for running IT systems, monitoring IT risks and auditing IT controls

For financial entities (other than micro-enterprises), responsibility for managing and overseeing ICT risk must be assigned to a dedicated control function. This function must have a governance structure that reflects the three lines of defence (or another internal) model with clear segregation of duties between risk management, control and internal audit functions (article 6(3), DORA).

Assess whether current arrangements support effective ICT risk oversight and resilience:

• Are roles and responsibilities clearly assigned to senior management teams with ICT risk expertise? Staff need to know what is expected of them and the authority they have for decision-making.
• Is budget and resourcing (both human and technical) allocation sufficient?
• Are internal reporting lines clear (this should include internal reporting, channels for ICT third-party service providers (where applicable)) and to the board?
• Have any team or provider changes affected existing arrangements?
• Are escalation plans and process documents clear and practical when viewed through a risk and resilience lens?
• Are training and awareness programmes tailored to staff roles with individual ‘risk objectives’ built into job descriptions and performance reviews?

1.2.2 Board reporting and oversight

The management body (the board) of the financial entity holds ultimate responsibility for defining, approving, implementing and overseeing the ICT-risk management and operational resilience strategy (under article 5(2), DORA). This includes personal liability implications for non-compliance with potential for regulatory inquiries and formal investigation if standards fall short.

Best practice for boards includes:

• appointing and documenting an individual senior manager or board member as responsible for the ongoing management and oversight of the ICT risk management framework;
• ensuring regular reporting on ICT risk management within the broader ICT risk management framework;
• involving legal, compliance and IT teams in board meetings to brief on ICT risks, incidents, audits and resilience testing;
• maintaining clear escalation procedures, which are reviewed periodically;
• formally approving key policies such as business continuity plans, confidentiality policies, crisis communication plans, ICT response and recovery plans, and internal audit;
• receiving regular training (at least annually) on ICT risk and resilience delivered internally or provided by external consultants; and
• promoting a ‘tone from the top’ by embedding ‘operational resilience compliance’ into the firm culture working closely with senior management to do so.

1.3 Has the firm got dedicated and comprehensive business continuity policies and disaster and recovery plans in place?

These should be regularly reviewed to ensure they align fully with the operational resilience requirements. It is prudent to check that the firm has not over-relied on pre-existing business continuity policies to fulfil their operational resilience obligations.

1.4 Has the firm built in procedures to learn and evolve both from external events as well as the entity’s own ICT incidents?

Establish processes for annual reviews of the ICT risk management framework and regular internal audits conducted by qualified ICT-competent auditors. Develop a formal remediation process for critical audit findings and consider who has ownership of remediation actions, define timelines for compliance and set these out in writing. Establish responsibility for scanning the regulatory horizon to identify external events and feed those into the firm’s own risk assessment and stress testing.

Step 2 – ICT-related incident management, classification and reporting

Firms must establish ICT-related incident management processes that enable timely detection, handling and reporting of ICT-related incidents. These processes should be embedded within the broader ICT risk management framework and closely aligned with disaster recovery and business continuity plans. Effective incident response must be carried out within prescribed time frames and supported by strong governance and oversight at board level.

See also Quick view: DORA compliance – regulatory requirements, technical standards and guidelines.

2.1 Has the firm defined, established and implemented a management process to monitor and log ICT-related incidents?

To comply with DORA’s ICT-related incident reporting requirements (articles 17–19, DORA), firms must maintain and regularly review protocols for incident detection, response, investigation, remediation and recovery.

Key considerations:

• Ensure the firm has a documented incident management procedure in place to record all ICT-related incidents, ‘near-miss’ incidents and significant cyber threats.
• Implement early warning indicators to detect potential threats and deploy anomaly detection tools to identify potential ICT disruptions promptly.
• Use agreed formats such as dashboards or scorecards to record and aggregate incidents and ensure these tools work.
• Assign responsibility for reviewing incidents in the first line, and then provide assurance by second or third lines through monitoring the robustness of the first-line reviews to ensure appropriate identification of root causes (even minor ones) and areas for improvement.
• Consider how these processes integrate into the broader incident detection and response framework.

2.1.1 Reporting and governance considerations

Establish and document the reporting procedures and ensure the reporting framework is tested appropriately following system changes or on a risk-weighted basis to ensure ongoing effectiveness and compliance with DORA’s time frames and standards.

Provide targeted training to staff responsible for managing incident response to identify potential incidents, apply classification criteria accurately, and follow the agreed reporting steps. Roles and responsibilities for incident detection and classification should be clearly defined, assigned and kept under review, particularly where there have been internal staff changes or staff departures.

2.2 Has the firm established and implemented a classification programme for ICT-related incidents in accordance with the criteria set out in DORA and the RTS, ITS and guidance developed by the ESAs?

Consider whether the firm has established, implemented and embedded a classification framework for determining the impact of ICT-related incidents and cyber threats incorporating the criteria set out in article 18, DORA (and further specified by the ESAs) including (among other things) the criticality of the services, the number and relevance of affected clients, the duration of the disruption and reputational impact (as further specified in Commission Delegated Regulation (EU) 2024/1772).

2.2.1 Consider the method of classification

Classification assessments may be performed manually (using pre-defined criteria such as decision trees or matrices) or can be automated through systems that assess incidents against regulatory thresholds in real time. Regardless of the method used, firms must ensure that classification decisions are accurate, take ownership of the assessment process and build in monitoring for updates from the ESAs including maintaining version controls and audit mechanisms to track changes to ensure that teams have access to the most up-to-date versions. The classification of events and the obligation to notify major incidents without unnecessary delay must be clearly understood and firms must deploy real-time management systems that align with DORA timelines.

2.2.2 Has the firm updated reporting and classification of major incident criteria?

DORA characterises a major ICT incident as an unexpected event that compromises the security network and information systems and negatively affects the availability, authenticity, integrity or confidentiality of data, or the services the financial entity provides. Commission Delegated Regulation (EU) 2024/1772 sets out materiality thresholds to determine whether an incident qualifies as major and should be reported (see section 2.3 below for reporting time frames). Each competent authority publishes national guidelines for reporting (eg, the Central Bank of Ireland has produced guidance on reporting under materiality thresholds). It is essential to be familiar with the reporting submission methods and systems used in each jurisdiction to ensure the time frames are met. Consider documenting these processes in a formal policy. Raising awareness through internal communications and training will help ensure that the relevant teams (across IT, legal, risk, operations and compliance) understand and follow the correct procedure.

2.3 Has the firm developed processes for reporting ICT-related incidents to regulators using standardised templates within the required time frames?

Ensure firms are aware of the duty to report major ICT-related incidents to their national competent authority using standardised templates. This includes an initial notification (as soon as possible but within four hours after classifying the IT incident as major and not later than 24 hours from the moment the entity has become aware), intermediate report (within 72 hours from the submission of the initial notification) and final report (no later than one month after the submission of the intermediate report). See article 19, DORA and Commission Delegated Regulation (EU) 2025/301.

Ensure compliance teams oversee the content of the reports and adherence to timelines and consider the quality of ‘raw data’ (ie, internally-generated data used to assess the criticality of any incident) obtained from the business. Familiarity with the standard forms and national regulator guidance is essential, and responsibilities for data gathering, incident recording and formatting must be clearly defined.

To support effective reporting, firms could consider implementing a stress-incident response playbook covering escalation procedures, notification triggers, key business stakeholders and an inventory of critical or important functions and systems. Check that incident data is stored securely and retained in accordance with all regulatory requirements. Provide targeted training to ensure staff understand their role in the incident reporting process.

2.4 Has the firm reviewed and tested the wider communication strategy for internal and external stakeholders?

Firms should regularly test their communication policies and protocols, review the crisis communication plans, and report outcomes and lessons learned to the board and senior management. This can be done either by reviewing actual results from a relevant incident, or through a testing scenario designed to mimic that same type of relevant incident. This includes communication with internal and external stakeholders (such as regulators, consumers and the media). To support this consider the following questions:

• Do internal communication plans include clear escalation paths for managing communications during an incident and do they identify key decision-makers?
• Do external communication plans anticipate how the firm would quickly provide critical warnings and advice to consumers, the regulators, the media and other stakeholders especially where no direct communication channels exist?
• When were the plans last tested and what improvements were implemented? What is being done differently in the next round of testing?

Step 3 – Digital operational resilience testing

All financial entities are required to test ICT systems and applications supporting critical or important functions (ie, functions whose disruption would have material consequences) to detect potential ICT vulnerabilities and to build readiness, skills and resilience to deal with ICT-related incidents.

3.1 Has the firm developed and formally documented a risk-based ICT testing programme?

Financial entities should have an established robust, comprehensive, risk-based and proportionate testing programme that should be integrated into the wider ICT risk management framework and considers how testing supports ICT objectives and risk mitigation. Micro-enterprises (as defined under article 3, DORA) are a financial entity that employs fewer than 10 with an annual turnover/balance sheet not exceeding €2 million. Entities noted in article 16(1), DORA are exempt. It remains good practice to include specific reference to ICT within any risk management framework.

3.1.1 Consider the methods of testing

Ensure the different methods of testing are understood. DORA prescribes the tests that should be conducted including (among others) vulnerability assessments and scans, gap analyses, open-source analyses, source code reviews, scenario-based testing and end-to-end testing (see article 25(1), DORA). The approach should be scaled appropriately based on the size, overall risk profile and complexity of the services and activities and be risk-based considering evolving ICT threats, asset criticality and specific risks.

3.1.2 Consider who is responsible for testing, findings and follow up

Ensure that ICT tools and systems are tested by qualified, independent (internal or external) testers. Establish procedures to:

• safeguard against conflicts of interest when using internal testers;
• record findings systematically;
• follow up on identified weaknesses, gaps or deficiencies;
• define and implement corrective actions;
• track counteractive measures to closure;
• clarify who oversees follow-up actions and reports to senior management and the board;
• consider who has authority to sign off on corrective actions; and
• consider whether the time spent on testing is proportionate to the level of risk involved.

3.1.3 Ensure lessons learned are monitored and recorded

Record all testing outcomes to inform updates to risk assessments, controls and the overall digital operational resilience strategy. Designated teams (eg, legal, compliance, IT and risk) should ensure findings are shared and reviewed. Issues should be classified on a risk basis – review this categorisation against internal risk tolerances and DORA’s classification criteria (see section 2.2).

3.2 Are resilience tests being undertaken at least annually for systems supporting critical or important functions?

DORA requires testing of ICT systems and applications supporting critical or important functions at least annually (see section 4.1 below and article 24(6), DORA). Consider whether the annual review of testing is as rigorous, and subject to as the same level of robust oversight, as the initial implementation planning. Are there any areas identified that can be strengthened? Evaluate where there have been significant changes to ICT risk since the last review and whether ad-hoc digital resilience testing been completed when appropriate.

3.3 Is the firm in scope and have processes been put in place to carry out threat-led penetration testing?

Firms should assess whether they meet the criteria in relevant member states for the application of threat-led penetration testing (TLPT) obligations. This is based on systemic importance and ICT risk profile.

Consider too whether the firm has processes in place to deal with notifications from the TLPT authority that testing is required. Each member state will designate an authority who will be charged with all tasks and responsibilities related to TLPT being conducted in that state. The TLPT authority will lead and coordinate the TLPT process for financial entities, including identifying participants, confirming scope and reporting requirements, and signing off on completed work. Entities will be given at least three months’ notice before the preparation phase begins. Given the extent of the undertaking, it is fair to expect the TLPT authority to provide ample notice to relevant organisations where this will apply.

Testing should be undertaken on live systems to simulate ‘real-world’ attacks at least every three years (article 26, DORA). It is essential to understand the procedural and technical requirements of TLPT including alignment with the Threat Intelligence-based Ethical Red Teaming (TIBER)–EU framework and the inclusion of all relevant teams across structured testing protocols involving red teams (to simulate attacks), blue teams (to report within 10 weeks on response and lessons learned), purple teams (post-attack analysis) and some models also show white team involvement (control and oversight). If there are insufficient resources in-house, employ external threat intelligence providers (if internal teams do not have the requisite experience). Ensure that testers are professionally accredited and insured and any ICT third-party service providers involved should be contractually bound to participate.

At the end of the testing, after reports and remediation plans have been agreed, understand the process for provision of the TLPT outcomes to the respective competent authority along with corrective action plans and documentation evidencing that TLPT has been undertaken in accordance with the requirements (article 26(6), DORA).

Step 4 – Managing ICT third-party risk (including contractual arrangements)

Financial entities are required to manage and assess third-party ICT risk as part of their overall ICT risk management framework. Ensure the identification of third-party arrangements is thoroughly vetted, documented and monitored.

4.1 Have third-party ICT service providers been accurately identified and their compliance with operational resilience requirements been reviewed and documented?

Third-party ICT service providers include a broad range of vendors such as cloud service providers and data analytics firms. Even when outsourcing ICT services, firms retain full accountability and liability for regulatory compliance and digital operational resilience and risk management (article 28(1)(a), DORA). This reflects the underlying legal principle that outsourced ICT services can pose risks not only to individual firms but also to the wider financial system, potentially threatening systemic stability.

Third-party ICT service providers are categorised by criticality, particularly for the use of services supporting critical or important functions (where disruption would materially impair the firm’s financial performance, continuity of services or regulatory compliance).

Firms must also map their supply chain to include fourth-party subcontractors used by the third-party ICT services providers (particularly if they impact critical or important functions).

This requirement will likely be met by agreed disclosure by the ICT service provider of all relevant sub-contracting arrangements. They may have a scheduled or annual re-publish of this data. In any case, it is for the financial entity to satisfy themselves that appropriate controls are in place to understand fourth-party risk and to enable them to exit from any arrangements that present a risk level outside their agreed risk tolerance. This is best achieved by paying detailed attention to this assessment during initial and ongoing due diligence checks.

4.2 Have procurement and third-party strategies been updated to consider concentration risk and resilience as part of the upfront and on-going third-party engagement?

Even where third-party risk management (TPRM) processes are embedded within existing third-party vendor management programmes (TPVM), firms must ensure that:

• teams can identify when third-party issues escalate into material risks based on the firm’s defined risk tolerance levels;
• they assess resilience and cybersecurity during vendor selection;
• there is a policy on the use of services, exit plans, supporting critical or important functions and considers oversight of high-risk providers (see section 4.1 above);
• they consider personnel responsible for monitoring of vendor performance and risk exposure; and
• there are clear escalation procedures and governance structures to manage such risks effectively.

4.3 Do third parties’ operational resilience programmes mirror the firm’s own and have they provided some level of assurance?

Firms must evaluate their due diligence processes to ensure the service provider meets risk and resilience standards (see article 28(4), DORA). This assessment becomes more extensive when the subcontracted services support a critical or important function (see section 4.1 above). Consider too the risk of any potential conflicts of interest that may arise from such arrangements and whether you are able to understand the concentration risk facing your firm if too many services are all with the same provider. Regulators will monitor concentration risk across sectors and markets.

4.4 Is there evidence of consistent engagement with third parties to ensure records are regularly updated with the necessary information?

Firms must maintain a register of information (article 28(3), DORA) detailing all contractual arrangements with third-party ICT service providers. This must be updated regularly and aligned with standard templates set out in Commission Implementing Regulation (EU) 2024/2956.

The register of information must be reported to the designated regulator at least annually (first submission deadlines were around 30 April 2025 but varied across different member states). Compliance teams should establish formal reporting lines to relevant internal committees and define escalation protocols to senior decision-making bodies. Ensure the register of information is kept up-to-date and follows national regulatory guidance on submission formats and procedures.

4.5 Have contracts with third-party ICT service providers been reviewed and updated to meet DORA requirements?

Firms should have identified, located and updated existing contract arrangements to find any remaining gaps with DORA contractual requirements. Contracts must now include mandatory clauses under article 30(2), DORA such as service descriptions, subcontracting conditions and termination rights.

Consider how more stringent requirements have been applied where third-party ICT services contracts involve critical or important functions (article 30(3), DORA). These include enhanced service-level descriptions, notification obligations, business continuity and security measures, and participation in TLPT. Contracts must also grant unrestricted access, inspection and audit rights, obligations to participate fully in TLPT, performance monitoring and exit strategies.

Conduct progress checks on the review and updating of templates and contracting standards to meet new requirements. Consider how to make the process more efficient using contract templates, databases to aggregate subsidiary entity arrangements into a parent-entity hierarchy and overarching position, playbooks reaching out to all ICT third parties and negotiating DORA amendments.

Consider too whether there are plans in place for remediation of legacy ICT contracts. This plan will also need ‘owners’ for oversight and resourcing to ensure that matters are remediated in good time and without undue delay.

It is good practice to have better oversight of critical or important contracts than non-critical ones and senior management teams should be aware of who their critical and important third parties are.

4.6 Has the firm considered the implications of their oversight framework for critical third-party ICT service providers with clear parameters for service-level agreements and obligations to notify where issues are identified?

Third-party ICT service providers designated as ‘critical’ due to their systemic relevance are subject to direct oversight by a Lead Overseer. This authority has extensive powers to assess, investigate and issue recommendations on the provider’s ICT risk management practice and management. Firms must ensure they take reasonable steps to monitor their relationships and the service received.

The DORA oversight framework assigns the role of Lead Overseer to the ESAs to ensure that critical ICT third-party service providers (CTPPs) are adequately monitored on a pan-European scale, for the risks that they may pose to EU financial sector. This mitigates cross-border challenges for financial entities.

Financial entities may only use critical providers from outside the EU if they establish a subsidiary within 12 months of being designated as critical. Ensure that teams are aware of the regulatory expectations should a vendor be designated as critical and implement processes to track and record designations and prepare to liaise with regulatory authorities to support investigations or information requests. The ESAs will have started their oversight engagement by the end of 2025. See Quick view: DORA compliance – regulatory requirements, technical standards and guidelines.

Step 5 – Information sharing and intelligence

DORA actively promotes collaboration among financial entities and relevant authorities to strengthen digital operational resilience to share knowledge regarding cyber threats and vulnerabilities.

5.1 Has the firm established or joined trusted information sharing arrangements for cyber threats and vulnerabilities?

Consider whether the firm has formally joined or established any information sharing arrangements, such as sector-specific forums, intelligence sharing networks or public–private partnerships. If so, review the procedures in place regarding:

• Types of information shared – consider cyber-threat intelligence such as indicators of compromise, tactics, techniques and procedures, and cyber security alerts.
• Secure and trusted arrangements – ensure the arrangements are conducted within trusted communities with appropriate access controls and encryption.
• Conduct and participation – set out rules of conduct in writing, including safeguards for legal and regulatory compliance (eg, business confidentiality, data protection and competition laws.
• Staff training and awareness – consider whether staff understand what types of information can be shared, how information can be shared, to whom and the importance of protecting sensitive data and preserving confidentiality. See How-to guide: How to comply with data processing principles under the GDPR and Checklist: Processor due diligence (data protection and cybersecurity).

5.2 Consider the procedures for notifying competent authorities of the participation in information-sharing arrangements

Financial entities are required to notify competent authorities of their participation in information-sharing arrangements. Ensure the firm has procedures in place for how they will do this both when joining and leaving. Staff involved in regulatory reporting should have these requirements built into refresher training sessions.

Additional resources

Related Lexology Pro content

How-to guide:

DORA requirements for financial entities and ICT-third party service providers

Quick views:

Understanding the application and scope of DORA 
DORA compliance – regulatory requirements, technical standards and guidelines 

This practical resource is derived from an MBL Seminars seminar, delivered by Stephen Fairclough of Elf Education Limited.

MBL, now part of Law Business Research and a sister brand to Lexology, is a leading learning and development provider for professional service firms.

Reliance on information posted:

While we use reasonable endeavours to provide up to date and relevant materials, the materials posted on our site are not intended to amount to advice on which reliance should be placed. They may not reflect recent changes in the law and are not intended to constitute a definitive or complete statement of the law. You may use them to stay up to date with legal developments but you should not use them for transactions or legal advice and you should carry out your own research. We therefore disclaim all liability and responsibility arising from any reliance placed on such materials by any visitor to our site, or by anyone who may be informed of any of its contents.