DORA vs CPS 230: Two Operational Resilience Regimes, One Underlying Problem

The EU's Digital Operational Resilience Act has applied to in-scope financial entities since 17 January 2025. Australia's APRA CPS 230 came into force on 1 July 2025. Neither regulator coordinated with the other, and the two regimes use different structures, different reporting authorities, and different timelines — but they were built to solve the same underlying problem that surfaced repeatedly through the 2008 financial crisis, COVID-era operational shocks, and a string of high-profile third-party ICT outages: financial institutions had become critically dependent on technology and service providers whose own resilience nobody was formally regulating.

DORA is structured around five pillars: ICT risk management (a documented framework covering identification, protection, detection, response, and recovery), incident reporting (major ICT-related incidents must be reported to the relevant national competent authority on a defined timeline), digital operational resilience testing (including, for larger entities, threat-led penetration testing), ICT third-party risk management (with a register of all ICT third-party arrangements and stricter obligations for 'critical' providers), and information sharing (voluntary arrangements for sharing cyber threat intelligence between financial entities).

The third-party risk pillar is where DORA goes further than most equivalent regimes: it gives EU authorities the power to designate certain ICT providers as 'critical' and subject them to direct oversight — reaching outside the EU financial entity itself and into the provider's own operations, wherever that provider is based.

Both regimes require regulated entities to define tolerance levels for disruption to critical operations, and both place explicit obligations around reliance on external service providers rather than treating outsourcing as a purely commercial decision. In that respect, an organisation that has built genuine CPS 230 capability — critical operations mapping, tolerance levels, service provider oversight — has already built much of the conceptual scaffolding DORA also requires.

The mechanics diverge in specifics that matter operationally: DORA's incident reporting timelines and its direct oversight power over 'critical' ICT providers go further than CPS 230's current framework. And DORA's extraterritorial pull works differently — it reaches through EU financial entities to their third-party providers, rather than applying directly to the provider's own home-market obligations the way GDPR's Article 3 does to any organisation processing EU personal data.

A single operational disruption at an internationally active financial group can trigger DORA incident reporting to an EU competent authority, NIS2 early-warning obligations to a national CSIRT, and GDPR breach notification to a data protection authority — on three different clocks, to three different regulators, for what may be a single underlying event. A GRC platform serving a genuinely multinational risk function needs to be able to map one incident to multiple, differently timed regulatory obligations without forcing the risk team to manually reconcile three separate spreadsheets under time pressure.

For an Australian-headquartered group without EU operations, DORA is not directly relevant today. For a group with EU subsidiaries, EU customers processed through EU infrastructure, or a critical technology provider that itself falls under DORA's third-party oversight, it is worth treating as a live requirement — and worth asking, specifically, whether a shortlisted GRC platform can structurally support DORA's reporting and third-party oversight mechanics, not just APRA's.