Financial resilience

Meeting DORA requirements

The European DORA regulation places on the financial sector a requirement that is simple to state and heavy to implement: stay operational despite a digital incident, and prove it. It also reaches, indirectly, the IT providers who serve those entities.

The challenge

A requirement of resilience, not merely of compliance

DORA (Digital Operational Resilience Act) structures the digital resilience of the financial sector around five pillars: governance of technology-related risk, incident management and reporting, resilience testing, control of third-party provider risk, and threat information sharing.

The spirit of the text differs from classic documentary compliance: it asks you to demonstrate that in the event of an outage, an attack or a supplier failure, the critical functions keep running. The burden of proof falls on tests, not on intentions.

Two areas carry most of the effort: the register of ICT providers — with the associated contractual clauses and exit strategies — and the testing programme, which ranges from conventional tests to threat-led penetration testing (TLPT) for the most significant entities.

Many organisations established in Switzerland are affected indirectly: a subsidiary in the Union, European clients, or the status of provider to an entity subject to the regulation.

What is at stake

Critical functions not identified, therefore not protected
Register of ICT providers incomplete or not maintained
Incident reporting deadlines that cannot be met
Testing programme absent or purely documentary
No exit strategy in case a provider fails

Diagram

Five pillars, one requirement of proof

Steering sets the frame; the tests, the third-party register and information sharing provide the demonstration the regulator expects.

Our approach

How we proceed

We start from the critical functions and your real dependencies, rather than from an article-by-article reading of the regulation.

Applicability and critical functions

Determining your exposure to the regulation — directly or as a provider — and identifying the critical or important functions along with the systems that support them.

Gap analysis across the five pillars

Assessment of what exists: ICT risk governance, incident capability, testing programme, third-party management and threat intelligence. Gaps are prioritised by regulatory requirement and by risk.

Third-party register and contracts

Building the register of ICT providers, reviewing the contractual clauses expected and formalising the exit strategies — the workstream most often underestimated.

Incident capability

Classification, escalation procedures and reporting templates that make the regulatory deadlines achievable, tested through a crisis simulation exercise.

Testing programme

Setting up a regular programme — penetration tests, configuration reviews and, for the entities concerned, threat-led testing — producing evidence the regulator can use.

Services involved

Several disciplines, a single point of contact

DORA brings governance, offensive testing and response capability together: we cover all three through a single point of contact.

Audit & Advisory GRC Penetration testing Forensics & incident response SOC

Deliverables

Applicability note and map of critical functions
Gap analysis across the five pillars
Register of ICT providers and clause review
Incident procedures and reporting templates
Resilience testing programme and associated reports

Frequently asked questions

Often yes, indirectly. A Swiss entity with a subsidiary in the Union, serving European clients or acting as an ICT provider to a financial entity subject to the regulation will have the requirements passed on contractually. We always start by clarifying that point.

A threat-led penetration test: an offensive exercise run on production systems, following the scenarios of attackers realistically likely to target you. It applies only to the most significant entities, but its logic — testing what actually matters — benefits everyone.

With the register of ICT providers and the identification of critical functions. Those are the two foundations: without them, neither the risk analysis, nor the testing programme, nor the exit strategies can be calibrated properly.

The frameworks overlap considerably. If you already run an ISMS, a large part of the governance work is reusable; what DORA mainly adds is the requirement for regular testing and formalised control of provider risk. We build on what exists rather than starting over.

DORA: are you in scope, and how far?

An applicability note and a gap analysis are enough to clarify your situation and frame the effort.