The Last Piece of DORA Falls Into Place: 10 Lessons From the First Six Months

Skadden Publication / Cybersecurity and Data Privacy Update

Nicola Kerr-Shaw Aleksander J. Aleksiev William E. Ridgway David A. Simon Susanne Werry

Executive Summary

  • What is new: The EU’s Delegated Regulation on Subcontracting has come into force, completing the legal framework of the Digital Operational Resilience Act (DORA). Attention will now turn to enforcement.
  • Why it matters: DORA’s requirements impact both financial entities and IT service providers, and introduce new obligations around cybersecurity, incident response and IT contract terms.
  • What to do next: As these obligations start to be implemented in practice and enforcement gathers pace, companies should assess their DORA compliance position and stress-test key documentation such as “critical or important functions” lists and incident response plans.

__________

On 22 July 2025, the EU’s Delegated Regulation on Subcontracting came into force, meaning the legal framework of the EU’s landmark financial sector cybersecurity law “DORA” is now essentially complete. With the legal foundations set, attention will now turn to enforcement, and regulators (including the European Central Bank, German BaFin and Banque de France) have identified DORA’s operational resilience requirements as a strategic priority for the coming year.

In the six months since DORA took effect, Skadden has been strategically guiding a range of companies — including both financial entities and IT service providers —in navigating DORA compliance and, increasingly, through cyber incidents that potentially trigger DORA notifications. In this alert, we set out 10 key lessons we have learned from our extensive experience advising companies through the first six months of DORA implementation.

For more background on DORA, see our previous client alerts: “Countdown to DORA – Four Takeaway Points From Regulators’ December Statements” and “DORA – Key Considerations for Alternative Investment Funds.”

1. Compliance maturity varies widely and remains a work in progress. Many of DORA’s obligations reflect existing financial sector rules, such as the European Banking Authority’s outsourcing guidelines, so entities in highly regulated subsectors (e.g., banks) and large IT service providers (e.g., hyperscalers) already had robust cybersecurity compliance frameworks in place that they could tweak and expand to achieve the DORA standard. Others, such as smaller fund managers, have started from a less robust position and have therefore required more wide-ranging changes to develop their cybersecurity frameworks to meet the DORA standard. For many of these smaller entities, DORA compliance remains a work in progress.

2. A targeted approach can optimize compliance spending. DORA requires implementation of an intimidating number of new policies and procedures. Taking a targeted and risk-based approach to compliance is key so that companies with limited compliance budgets can focus resources to address the areas of DORA (such as vendor management for critical vendors) that present the greatest enforcement risk.

3. Carefully scope your critical functions. DORA sets out two tiers of obligations: a baseline set of obligations that applies to all IT services, and a more stringent set of obligations — including obligations relating to incident reporting — that applies only to services supporting “critical or important functions.”

We have found that companies are often tempted to define their critical functions in overly broad and generic terms, with the result that minor IT systems would be subject to DORA’s “critical or important function” obligations — and only realise this overly broad application after an incident has occurred. Companies should therefore consider testing that functions identified as critical are genuinely critical.

4. Stress-test incident response playbooks. DORA’s timelines for notification are short (24 hours from when a company becomes aware of the incident), and the incident notification triggers are complex and novel (e.g., reputational and economic impacts). Companies should therefore consider stress-testing incident response playbooks through incident simulations to ensure that those tactics:

a. set out an escalation procedure that identifies key decision-makers and empowers them to make key decisions (e.g., whether to notify regulators) within 24 hours; and

b. include easy-to-use information to guide DORA decisions, such as (i) summaries of notification triggers, (ii) identification of the business stakeholders that hold the information necessary to assess those triggers and (iii) lists of “critical or important functions” and the systems supporting them.

Companies should also consider if these stress tests can be conducted under legal privilege to determine whether the candid discussions during (and findings from) these simulations are protected from subsequent disclosure.

5. Commit to (and document) a proportionate compliance approach. Many terms in DORA (including the definition of “critical or important function”) are unclear, and it will be some time before guidance, enforcement activity, market practice and case law begin to sharpen their meaning. Given this uncertainty, it is often not possible for companies to identify one “right” DORA compliance answer. Instead, companies have needed to:

a. identify a proportionate and defensible compliance position;

b. document the rationale behind that compliance position; and

c. continue monitoring enforcement activity, so that the compliance position can be updated if necessary.

6. Provide support to board members. DORA imposes personal liability on board members. Board members are often, understandably, concerned about taking on personal responsibility for IT systems, and require significant support from legal and IT staff (e.g., training) to ensure board members can confidently navigate their company’s IT and DORA risks. Companies should think about how they will evidence robust training of board members to a regulator, and consider engaging external counsel to provide thorough training in line with market standards.

7. Ensure IT is in the room. DORA requires extensive new IT policies and procedures. While compliance teams need to bring policies up to DORA standards, ensuring that those policies are integrated into existing IT standards and can be implemented in practice is equally important. IT teams should be consulted from the outset to (i) ensure that DORA standards are implemented in a proportionate manner and (ii) determine how to best execute DORA standards through tweaks to existing policies rather than building from scratch.

8. Consider intragroup context. DORA-regulated entities located in the EU are often reliant on their non-EU parent companies’ IT infrastructure. Consideration is therefore important of not just how DORA affects EU entities’ obligations, but also how those obligations flow through non-EU entities: This often requires nuanced discussions between EU and non-EU teams to identify how a non-EU entity can provide the support the EU entities require for DORA compliance without introducing undue burdens on the non-EU entities.

9. Rolling out contracts takes time, but playbooks help. DORA requires new IT contract terms to be in place across regulated entities’ services contracts. Renegotiating contracts to include these terms will inevitably take time, but having on-market contract templates and negotiation playbooks that distinguish between “must-haves” and “nice to haves” can minimise delays. Organizations should also consider taking a targeted approach, prioritizing their highest-risk suppliers before moving on to the long tail of minor service providers.

10. DORA compliance is more than “set and forget.” The DORA regulatory environment remains in flux — for example, the Delegated Regulation on Subcontracting was only just published; the Luxembourg regulator and European Banking Authority are both in the process of revising their IT outsourcing guidelines to reflect DORA; and, earlier in July, the European Supervisory Authorities finally released their guidance on DORA oversight of critical IT providers. In addition, regulated entities’ IT environment, as well as market practices and regulators’ expectations, continue to evolve. Companies therefore need to maintain ongoing review of their DORA policies. In many cases, DORA explicitly requires annual review. We have found that annual “checklists” are a good way for organizations to track required reviews.

This memorandum is provided by Skadden, Arps, Slate, Meagher & Flom LLP and its affiliates for educational and informational purposes only and is not intended and should not be construed as legal advice. This memorandum is considered advertising under applicable state laws.

BACK TO TOP