Staying able to deliver the service when something fails. This domain treats a cyber incident as one cause of disruption among several, which is why it belongs to the business as a whole.
What we track
DORA
EU financial entities. ICT risk management, resilience testing, incident classification, and the oversight regime for critical providers.
DORA regulatory technical standards
EU. The detail that decides compliance, including the subcontracting standard the Commission sent back to the ESAs once already.
UK operational resilience regime
UK. Important business services, impact tolerances, mapping, and severe but plausible scenario testing.
MAS technology and operational risk
Singapore. Expectations for regulated institutions, and the consultations that keep widening them.
ESAs oversight of critical ICT providers
EU. Designations, oversight activities, and what changes for you when a provider you depend on is designated.
Board governance codes
UK and international. What a board is expected to evidence about resilience, including the UK Cyber Governance Code of Practice.
Who is in scope
DORA covers a wide list of financial entities: credit institutions, payment and e-money institutions, investment firms, insurers and intermediaries, crypto-asset service providers, trading venues, central counterparties, fund managers and more. It also reaches ICT third-party providers serving them, and reaches them directly once they are designated as critical.
The UK regime works differently. It applies to banks, building societies, insurers, investment firms and payment institutions. It turns on important business services identified by the firm itself, which makes the identification exercise part of the compliance work.
Where the deadlines fall
The application dates for the main regimes have passed. The live dates are now operational: register submission cycles, testing windows, and the point at which a threat-led penetration test becomes due. Designation decisions for critical ICT providers arrive on their own schedule and change your obligations when they land.
The recurring trap is that testing and register cycles are annual or multi-year, which means a missed window is expensive to correct and hard to hide.
Where organisations get caught
DORA is a resilience regulation with cyber inside it. The test is not whether you have controls. It is whether you have identified your critical or important functions and set a tolerance for disruption to each. Then whether testing shows you stay inside that tolerance when something plausible goes wrong.
Scope follows the service. A function you outsourced is still yours to evidence, and your provider’s assurance report will not answer the supervisor’s question for you. Firms that treat a certification as the answer usually discover the gap during an examination.
Mapping comes third. Impact tolerances require you to know which systems, people, facilities and third parties support each service, at a level of detail most configuration databases were never maintained to. That work takes longest, and it is the part you cannot buy in.
Questions worth asking now
- Which of our services are important business services, and who signed that list off?
- What is the impact tolerance for each, expressed as something measurable?
- Can we show a test that put a service outside tolerance and what we changed afterwards?
- Which providers support each service, and how far into their supply chain can we see?
- If a provider we depend on were designated as critical, what would change for us?
- What does the board see about resilience, and how often?
Related domains
Third-party and supply chain risk covers the provider obligations inside this regime. Incident reporting covers the classification and notification duties. Cybersecurity regulation covers the general regimes that sit alongside it.