DORA has applied since January 2025, which means the interesting question is no longer “how do we get ready?” but “how do we run it in steady state?” A lot of firms built a DORA programme to hit the date and are now discovering that resilience is not a project you complete — it is an operating model you sustain. Supervisors have moved past checking that you have the documents to checking that the machinery actually runs, and the firms that treated go-live as the finish line are the ones now finding the steady-state demands harder than the launch.
What steady state actually looks like
Three of DORA’s pillars turn into continuous operations rather than one-time deliverables.
ICT risk management becomes a living framework, not a document. The register of risks, the controls, the ownership all have to stay current as systems and threats change — a framework that was accurate at go-live and untouched since is a red flag, not a control.
Free · 4 minutes
Do you know where AI is already being used in your business — and what it can see?
Fourteen questions on shadow AI, data exposure, oversight, and governance debt — the gap between how fast AI is arriving and how much control you have over it. Banded finding on screen, full sheet by email.
Incident reporting becomes a capability you exercise, hopefully rarely but reliably. The classification logic and the reporting workflow have to work under pressure, within DORA’s tight windows, which means they need to be tested and maintained, not just designed.
Resilience testing becomes a cycle. This is where steady state bites hardest, because it includes threat-led penetration testing (TLPT) for the firms in scope — a demanding, roughly triennial exercise that simulates a real attacker against live systems, with the findings feeding remediation that then has to be evidenced.
TLPT is the part firms underestimate
For firms in scope, threat-led penetration testing is the most demanding recurring obligation, and the one most likely to be under-planned. It is not a routine pen test; it is an intelligence-led simulation of a genuine adversary against production systems, run to a defined framework, with the results scrutinised and remediation expected. Standing this up requires the right providers, careful scoping, and an organisation prepared to have its live defences genuinely tested — and then to act on what the test exposes. Firms that scoped their DORA programme around documentation often did not budget for the operational reality of TLPT, and discover its weight only when the cycle comes due.
Running DORA as an operating model
- Keep the framework live. Assign ownership for keeping the ICT risk framework, register and controls current, because a static framework is the clearest sign to a supervisor that DORA became a filing exercise.
- Exercise incident reporting. Test the classification and reporting workflow so it works within the windows under real pressure, not just on paper.
- Plan the testing cycle, including TLPT. Budget and scope the resilience testing cycle as a recurring operational commitment, with remediation funded and evidenced.
- Report resilience to the board on a cycle. Steady-state DORA includes keeping the board genuinely informed, because governance is an ongoing obligation too.
The firms that handle DORA well past go-live are the ones that converted their launch programme into an operating model — a living framework, an exercised incident capability, and a planned testing cycle — rather than a set of documents that were accurate once. Steady state is where resilience is actually demonstrated, and where a supervisor now looks.
Who this is for
This reading is for:
- CTOs and resilience owners past the DORA go-live scramble
- Boards asking what “ongoing DORA compliance” actually requires
- Compliance leads whose programme was built for the deadline, not the decade
- Firms treating DORA as a project rather than an operating model
Sixteen Pillars helps firms convert a DORA launch programme into an operating model – a living framework, an exercised incident capability, and a planned testing cycle including TLPT. Pricing is published at /pricing/. If this is live for your organisation and you would like an independent reading, the place to start is a conversation.
Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.
Free interactive tool
Website compliance checklist
What your site has to do, based on what it actually does
Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.
Everything that applies
Ordered by what to do first: legal requirements you can close quickly, then larger pieces of work, then what is expected rather than required. Not exhaustive, and not a legal audit.
Dated PDF, yours to keep or circulate.
Free interactive tool
Interactive deadline calculator
Check which regulations apply to you and when
Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.
Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.
Full Governance by Sixteen Pillars
Govern your business. Prove your compliance.
A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.
See what's coming