Beyond DORA: Preparing for the Next Wave of Financial Sector Cyber Regulation

Cloud breaches rarely start with a zero-day. They start with a storage bucket left open, an identity role with far more permissions For two years, the question in financial services was whether firms would be ready for DORA. That question has been answered. Registers of information have been filed, contracts have been renegotiated, and the European Supervisory Authorities have named the technology providers they intend to oversee directly.

The firms that treated DORA as a project with an end date are now discovering the problem with that framing. Oversight has moved from preparation to operation, and the regulatory pipeline behind DORA did not stop. Instead of replacing DORA, product security rules, reformed network security requirements, and a new UK reporting regime all land inside the next eighteen months, and overlap with DORA instead of.

This article covers where DORA enforcement actually stands, what the regulation solved and what it left open, which requirements arrive next in the EU and UK, and how to build a compliance program that absorbs the next framework without starting over.

Where DORA Enforcement Stands Today

DORA has applied since January 2025. The supervisory machinery around it took longer to switch on, and 2025 was the year it did.

The sequence matters because it explains what supervisors now hold. Financial entities compiled registers of information detailing every contractual arrangement for ICT services. The ESAs collected that data, assessed providers against DORA’s criticality criteria in cooperation with national competent authorities, notified the providers concerned, and heard their representations. In November 2025, they published the first list of designated critical ICT third-party providers.

That designation carries real consequences for the providers named:

  • Direct oversight by the ESAs: A Lead Overseer is assigned to each provider, coordinated across the three authorities, replacing supervision that previously reached them only indirectly through their financial sector customers.
  • Investigatory powers: The Lead Overseer can demand information, conduct general investigations and on-site inspections, and issue binding recommendations covering ICT security, subcontracting arrangements, and data location.
  • Financial consequences for non-compliance: DORA provides for periodic penalty payments of up to 1% of average daily worldwide turnover, charged for each day of continued breach for up to six months, and disclosed publicly.
  • An EU coordination point and oversight fees: Each designated provider must nominate a legal entity to act as the contact for its Lead Overseer and pay annual fees for the oversight it receives.
  • A last-resort power over the relationship: Where a designated provider leaves risks unaddressed, competent authorities can require financial entities to suspend or terminate use of its services.

The list is not static. The ESAs will review and republish it annually, providers can be added or removed as their market position changes, and a provider may request designation voluntarily.

For background on DORA’s original requirements and the five pillars underpinning them, our earlier guide to the Digital Operational Resilience Act, its challenges and solutions, covers the framework in detail. What follows builds on it rather than repeating it.

One misunderstanding is worth correcting immediately, because it is common and it is expensive. ESA oversight of a critical provider does not discharge your own obligations toward that provider. Some providers have begun arguing that direct supervision makes customer audit rights and due diligence redundant, which  it doesn’t. Your duties under DORA sit on you, independently of whatever oversight the provider receives, and a supervisor asking why your third-party risk assessment is thin will not accept the provider’s regulatory status as the answer.

What DORA Got Right (and Where Gaps Remain)

DORA deserves credit on several fronts, and understanding what it achieved helps predict where regulators go next.

What DORA got right:

It replaced guidance with binding law: Before DORA, ICT risk expectations arrived as supervisory guidelines that varied by authority and sector. DORA is a regulation, so it applies directly across the EU without national transposition. The contrast with NIS2, where obligations still depend on twenty-seven separate national laws, is instructive.

  • DORA made third-party risk a first-class obligation: Contractual minimums, register requirements, and exit planning turned outsourcing oversight from a procurement formality into a supervised discipline.
  • DORA reached the providers themselves: Bringing critical technology suppliers under direct oversight closed a structural gap. Regulators previously had no route to a firm that underpinned hundreds of financial entities without being regulated by any of their supervisors.
  • DORA fixed accountability at the top: Management bodies own ICT risk under DORA, which moved resilience onto board agendas.
  • DORA created visibility into concentration: The registers gave supervisors their first coherent picture of where the sector’s dependencies actually concentrate.

Where gaps remain:

  • Visibility is not substitutability: Regulators can now see that much of the sector depends on a handful of providers. Nothing about oversight makes those providers easier to replace. Exit plans for a hyperscaler remain documents rather than executable strategies for most firms.
  • Subcontracting chains stay opaque: Firms map their direct providers reasonably well. Visibility past the first tier, into the dependencies their providers rely on, is still thin, and that is where concentration hides.
  • Compliance became a data exercise: Register submissions consumed effort that went into populating fields rather than reducing risk. A complete register and a resilient firm are not the same thing.
  • Testing is periodic, exposure is continuous: Threat-led penetration testing on a multi-year cycle produces a point-in-time verdict on an environment that changes weekly.
  • Proportionality lands unevenly: Smaller entities carry obligations designed with systemic institutions in mind, and the relative cost falls hardest on firms with the least capacity.
  • Overlap creates duplicated work: Firms subject to DORA, NIS2 in some capacity, national rules, and sector guidance frequently answer the same question in four formats for four audiences.

Those gaps predict the direction of travel. Expect more attention to subcontracting transparency, more continuous forms of assurance, and more pressure to demonstrate that resilience testing reflects current conditions.

What’s Coming Next in Financial Cyber Regulation

Three developments will shape compliance workload through 2027, and none of them replaces DORA.

NIS2 and Overlapping EU Requirements

For financial entities, DORA generally takes precedence over NIS2 on ICT risk management and incident reporting, which is the point of having sector-specific legislation. That precedence is narrower than firms assume.

  • Group entities outside financial scope: A banking group commonly contains subsidiaries that fall under NIS2 in their own right rather than under DORA. Group-wide policy has to satisfy both.
  • Your suppliers are inside NIS2: Technology and service providers you depend on face their own NIS2 obligations, with their own reporting duties and timelines, which affects what they tell you and when.
  • National divergence persists: NIS2 binds through national law, and several member states transposed late enough that the Commission referred them to the Court of Justice of the European Union in July 2026. Cross-border groups are managing a patchwork rather than one rulebook.

The larger addition is the Cyber Resilience Act, which governs the security of products with digital elements. It entered into force in December 2024, its reporting obligations apply from 11 September 2026, and its main obligations follow in December 2027. Manufacturers must report actively exploited vulnerabilities and severe incidents through a single reporting platform, submitting an early warning within 24 hours and a fuller notification within 72 hours, and must document product components including a software bill of materials.

Financial institutions are rarely manufacturers, so the CRA reaches most of them indirectly, and that indirect route is the useful part. Vendors will be obliged to produce vulnerability information and component inventories that firms have spent years requesting without success. Firms that prepare to consume that data, rather than treating the CRA as somebody else’s regulation, gain genuine supply chain visibility. Firms that ignore it will receive software bills of materials they have no process to use.

Emerging US and UK Regulatory Signals

The UK moved decisively in 2026. On 18 March, the FCA, the PRA, and the Bank of England published policy statements establishing a single framework for operational incident and third-party reporting. The rules take effect on 18 March 2027, giving firms a twelve-month implementation window.

  • Unified incident reporting: Firms report serious operational and cyber incidents through one portal against defined thresholds, replacing inconsistent routes into separate regulators.
  • An annual third-party register: In-scope firms must maintain and submit a register of material third-party arrangements, echoing DORA’s register in purpose while differing in detail.
  • Broad application: The third-party obligations extend well beyond the largest institutions, reaching banks, designated investment firms, building societies, Solvency II firms, payment and e-money institutions, and others.
  • A separate designation regime: The UK Critical Third Parties regime sits alongside this, allowing regulators to designate and oversee certain technology providers directly.

One design difference deserves attention from anyone operating in both jurisdictions. DORA embeds third-party control in the regulation itself through mandated contractual terms and direct oversight of critical providers. 

The UK framework, outside the designated Critical Third Parties population, does not regulate material third parties directly and instead holds the firm fully accountable for incidents originating with a supplier. The obligations converge on outcomes and diverge on mechanism, so a control set built purely to satisfy DORA will not automatically satisfy the UK regime.

Alongside this, the Cyber Security and Resilience Bill continues through Parliament with Royal Assent expected during 2026 and substantive obligations arriving through secondary legislation, extending UK network security requirements to managed service providers, data centres, and designated critical suppliers.

In the United States, the pattern is fragmented but consistent in direction:

  • Securities and Exchange Commission disclosure rules: Public companies must disclose material cybersecurity incidents on a short timeline and describe risk management and governance annually, which pulls cyber into financial reporting discipline.
  • Federal banking agency notification: Banking organizations must notify their primary federal regulator within 36 hours of determining that a notification incident has occurred, one of the tightest clocks in force anywhere.
  • New York Department of Financial Services Part 500: Amended requirements have phased in through 2025, including multi-factor authentication across the board, asset inventory obligations, and governance expectations that read as a preview of where other state and federal regulators are heading.
  • Federal incident reporting still consolidating: Critical infrastructure reporting rules continue to develop, and firms should expect an additional federal reporting channel rather than a replacement for existing ones.

The common thread across all three jurisdictions is worth naming plainly. Regulators are converging on short incident reporting clocks, demonstrable third-party oversight, board-level accountability, and evidence that controls have been tested. The forms differ. The substance does not.

How to Future-Proof Your Compliance Program

If every incoming framework asks for the same four things in different formats, the efficient response is to build those capabilities once and map them outward, rather than running a fresh programme per regulation.

Building Beyond a DORA Checklist

A DORA checklist answers one regulator in one format. A control framework answers any regulator in any format. Moving from the first to the second involves a handful of deliberate steps:

  • Maintain one control library, mapped to many frameworks: Define each control once, then map it to DORA, NIS2, the UK regime, ISO 27001, and SOC 2. When a new framework arrives, you map rather than rebuild, and you stop maintaining four descriptions of the same access control.
  • Hold evidence continuously, not at audit time: Most of the cost of compliance is assembling proof after the fact. Systems that generate evidence as a byproduct of operation turn an audit into an extraction exercise.
  • Design incident response to the tightest clock you face: A firm subject to DORA, the UK regime, and US banking rules should build to the shortest applicable deadline and file the rest from the same assessment. Meeting a deadline measured in hours requires continuous detection and triage, since an incident that starts on a Saturday still has to be classified and reported on time.
  • Treat resilience testing as a programme: DORA requires threat-led penetration testing for significant entities on a multi-year cycle. Meeting the letter of that requirement leaves long gaps, so pair the mandated exercise with more frequent, narrower testing. SecurityHQ supports both through penetration testing and adversary simulation aligned to the threats your sector actually faces.
  • Keep a live regulatory horizon: Assign ownership for tracking what is coming, with dates and an assessed impact, and review it quarterly at management level. The firms caught out by DORA were not unaware of it. They were late.

Third-Party and ICT Risk Management as an Ongoing Practice

Third-party risk is where every one of these frameworks concentrates, and where annual questionnaire cycles fail most visibly. A supplier assessed as low risk in January can be breached in March, and nothing in a yearly process surfaces that.

What ongoing practice looks like:

  • A register you actually use: Treat the register as an operational inventory that drives monitoring and continuity planning, not a filing obligation. If it is only opened for submissions, it will be wrong by the time it matters.
  • Continuous monitoring of supplier exposure: Track breaches, credential exposure, and attack surface changes affecting your providers as they happen. SecurityHQ delivers this through Threat and Risk Intelligence, which monitors third-party and supply chain exposures alongside your own.
  • Contracts that let you meet your deadlines: A supplier notification window longer than your own reporting deadline guarantees you miss it. Push notification terms, audit rights, and subcontracting transparency into every material contract at renewal.
  • Concentration analysis past the first tier: Identify where different suppliers depend on the same underlying provider. Diversification that shares a single cloud region is not diversification.
  • Exit plans you have rehearsed: Test at least one material exit or failover scenario rather than documenting all of them. An untested plan tells a supervisor you wrote a document.
  • One assessment, many reports: When an incident involves a supplier, run a single investigation and generate each regulator’s filing from it. Parallel workstreams produce inconsistent submissions, and inconsistency is what draws follow-up questions.

Build Resilience That Outlasts the Current Rulebook

The frameworks will keep arriving. The capabilities they ask for have been stable for years: know your dependencies, detect quickly, respond on a clock, and prove it afterward. 

SecurityHQ works with financial institutions and their providers to deliver those capabilities as an operating practice, combining 24/7 detection and response, third-party and supply chain monitoring, offensive testing, and board-level security governance. Talk with a security expert to review your position against DORA today and find out what to do  next.

The Digital Operational Resilience Act is an EU regulation that has applied since January 2025, setting requirements for ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing. It covers a broad range of financial entities including banks, payment and e-money institutions, investment firms, insurers and intermediaries, crypto-asset service providers, trading venues, central securities depositories, fund managers, and pension institutions, together with the ICT providers serving them. As a regulation, it applies directly across the EU without national transposition.