Since 17 January 2025, the Digital Operational Resilience Act (DORA) has been in force for financial institutions across the EU. Where much compliance legislation mainly revolves around paperwork, DORA is unusually concrete about one thing: how, and how often, you must test whether your organisation can withstand a real attack. For CISOs and risk managers in the financial sector, that’s no longer an abstract requirement, but a recurring obligation with a fixed frequency.
Two test levels, not one
DORA distinguishes between two types of testing, and that distinction is exactly where many organisations stumble.
All institutions falling under DORA must carry out basic tests on critical ICT systems at least annually: vulnerability scans, network security reviews, gap analyses, source code reviews where possible, scenario-based testing and performance testing. This is the foundation, and it’s exactly where a regular penetration test fits in.
On top of that, institutions designated as significant by their regulator face a heavier obligation: Threat-Led Penetration Testing (TLPT), at least once every three years, based on Articles 26 and 27 of the regulation. TLPT is not an ordinary pentest, but a realistic red-team test based on current threat intelligence, carried out on live production systems, including outsourced ICT services.
Where TLPT comes from, and why that matters for Dutch institutions
TLPT isn’t a new European invention. It builds on TIBER-NL, the framework that De Nederlandsche Bank (DNB) developed as one of the first in Europe, which was later developed further into TIBER-EU by the ECB. Dutch institutions that already have experience with TIBER-NL therefore already have a head start: the methodology and the division of roles between commissioning party, regulator and testing party are largely familiar territory.
Not every institution that falls under DORA automatically gets a TLPT obligation. The national regulator (in the Netherlands, DNB or the AFM, depending on the type of institution) determines which organisations qualify based on systemic relevance and risk profile. Institutions that don’t qualify remain bound to the annual basic tests, which in practice comes down to a combination of vulnerability scans and regular penetration tests.
What this means practically for test planning
Because the TLPT obligation follows a three-year cycle, many compliance experts expect the first genuine TLPT engagements to really get going around 2027. That doesn’t mean there’s time to lose: a TLPT engagement requires preparation, an intelligence phase, and coordination with the regulator, and that takes months, not weeks.
For the annual basic tests, a more practical lesson applies: don’t plan them as a one-off exercise around the audit deadline, but as a fixed part of your annual calendar — just like the vulnerability scan and the regular pentest many institutions already run.
A real-world example
Imagine: a mid-sized payment institution has spent the past few years investing mainly in compliance documentation, and relatively little in repeated technical testing. During the first annual basic test under DORA, it turns out an internal admin panel, built years ago for a project long since completed, is still reachable from the internet with an outdated password policy. Nobody had this panel on their radar anymore, simply because it was built outside the regular change processes. This is exactly the kind of forgotten, never-retested component the annual basic test under DORA is meant to catch: not to confirm everything is fine, but to discover what has since fallen out of view.
How MonkeysICT can help with this
For the annual basic tests under DORA, our regular penetration tests and vulnerability scans align directly with what the regulation requires. For institutions preparing for a future TLPT obligation, we’re happy to think ahead with you about scoping and planning, even before the regulator’s process itself has started.