A DORA policy can be complete on paper.The real test is production.

The signal from the regulator

In August 2026, the Dutch Authority for the Financial Markets (AFM) reported significant progress in DORA implementation. EBA approval of information registers rose from 40% in 2025 to 94% in 2026.

But supervisory reviews still found gaps between documented controls and day-to-day practice, including missing policies, entity-level coverage gaps and fewer incident notifications than expected.

That is the gap worth testing: not whether the policy exists, but whether the organisation can actually execute it when a critical service fails.

1. Start with the service

• ✦Pick one business-critical service — the one that would cause real damage if it stopped for a day.
• ✦Define the owner and operating team.
• ✦Know who declares an incident and who can authorise emergency changes.
• ✦Identify the supplier that must respond and how fast.

2. Map the dependencies

• ✦Trace the service through applications, integrations and infrastructure.
• ✦Record which suppliers and APIs it relies on.
• ✦Identify identity, monitoring and backup paths.
• ✦Map how recovery actually works, not how it is documented.

3. Introduce a failure

Choose a realistic scenario — server loss, network partition, supplier outage — and answer these questions against the real environment, not the diagram.

• ✦What failed?
• ✦What else is affected?
• ✦Can monitoring show why?
• ✦Can we restore or fail over?
• ✦What needs to be reported, and to whom?

4. Find where resilience breaks

This is usually where the documentation and production reality begin to diverge.

• ✦Monitoring does not detect the failure.
• ✦Architecture contains unmapped dependencies.
• ✦Recovery depends on something never tested.
• ✦Ownership breaks down across several systems.

5. Fix and retest

• ✦Improve detection where monitoring is blind.
• ✦Map missing system and supplier dependencies.
• ✦Test backups, restore procedures and failover.
• ✦Fix integrations or systems that block recovery.
• ✦Clarify technical decision ownership.

From policy to production test

We start with one critical service and follow it all the way down.

We trace the applications, integrations, infrastructure, identity, monitoring, suppliers and recovery processes it depends on.

Then we introduce realistic failure scenarios and follow the response end to end: what gets detected, who acts, what access is available, which dependencies fail and whether the service can actually be recovered.

The result is a concrete view of where documented controls and production reality diverge.

Find the weak point before production does

Controlled failure is cheaper than an uncontrolled incident. Testing exposes weak dependencies, unclear ownership and recovery gaps while there is still time to fix them.

Built against a production standard

The systems we operate have run for 6+ years without a major outage. We bring the same production mindset to resilience testing: understand the dependencies, remove avoidable failure points and make recovery something that has been tested rather than assumed.

Frequently asked questions