📋 For the boardroom DORA gives you three years between TLPT cycles. The test itself takes nine months. That leaves roughly two years of runway, and most organizations use this time without a clear focus on what the TLPT will actually require of them. Organizations that use this period to build a structured security testing strategy arrive at their TLPT with fewer basic vulnerabilities, a more capable Blue Team, and significantly more useful findings. This blog explains what that strategy looks like in practice.
Introduction
Most organizations we speak to treat the pre-TLPT period as a waiting room.
They know a TLPT is coming. They know roughly when. And they assume that when the time comes, they will bring in the right party, run the test, and handle whatever comes out of it. That is not the best plan.
Here is what actually happens to organizations that approach it that way: the Red Team walks in and finds the basics. Unpatched systems. Misconfigured services. Phishing susceptibility at scale. The TLPT burns nine months and a significant budget uncovering vulnerabilities that a standard pentest would have found in a week. The findings are real, but they are not strategic. And the board is left with a remediation backlog instead of genuine insight into their resilience.
We have seen this pattern enough times to be direct about it: a TLPT is only as valuable as the security foundation underneath it. If that foundation is weak, the test tells you the foundation is weak. You did not need nine months and €150,000 to learn that.
The good news is that the two years before your TLPT are not dead time. They are your most important asset in making the test worthwhile. This blog explains how to use them.
The three-year window, used correctly
DORA requires a TLPT every three years. Subtract nine months for the test itself, and you have roughly 27 months of pre-TLPT runway. That is not nothing: that is enough time to fundamentally change what the TLPT will find.
The goal of the pre-TLPT period is not to hide vulnerabilities from the Red Team. It is the opposite. You want to eliminate the straightforward findings so that the Red Team has to work harder, go deeper, and ultimately tell you something more meaningful about your actual resilience.
Three things happen when you prepare this way:
1. The low-hanging fruit is gone
Basic vulnerabilities, the ones any competent attacker would exploit first, are found and fixed before the TLPT starts. The Red Team has to work harder to achieve their objectives. That is a good outcome for your security and a more rigorous test for your team.
2. Your Blue Team gets real experience
A security team that has never been tested performs differently from one that has dealt with real attack simulations. The pre-TLPT period is your opportunity to build that experience incrementally. A professional Red Team will always bring techniques and approaches your defenders have not seen before. But a team that knows their own environment deeply, and has learned to recognize anomalies through repeated testing, is far better equipped to detect and respond to the unexpected than one that has never been tested at all.
3. The TLPT findings become tangible and actionable
When basic issues are already resolved, the TLPT uncovers the sophisticated gaps: the detection blindspots, the escalation paths that are not obvious, the organizational and process failures that no tool can catch. Those are the findings that produce tangible, actionable security improvement.
Building your security testing strategy
The most practical framework for building a pre-TLPT security testing strategy is one you already know from Blog 1: the Unified Kill Chain. The same three phases that structure a TLPT scenario, IN, THROUGH, OUT, give you a logical way to structure your testing across two years.
The principle is simple: test each phase of the kill chain before you run a test that covers all three simultaneously.
There is a fourth dimension to pre-TLPT preparation that is rarely discussed but consistently underestimated: leg-ups. A leg-up is a pre-arranged condition that gives the Red Team a starting position, for example:
- a non-traceable laptop,
- a standard user account,
- or pre-established network access. These are legitimate and common elements of a TLPT scenario, but arranging them during the test phase is time-consuming and disruptive. Organizations that understand their own environment well enough to anticipate which leg-ups will be needed, and have the internal processes to arrange them quickly, run significantly smoother tests.
The periodic assessments in your pre-TLPT strategy serve a dual purpose here: they reduce vulnerabilities, and they build the organizational knowledge and relationships needed to arrange leg-ups without friction when the time comes. Depending on the maturity of your organization, it is worth considering whether some leg-ups, such as dedicated test accounts or isolated devices, can be prepared well in advance of the test phase. Failing to arrange leg-ups on time is one of the most common pitfalls we see in TLPT trajectories. More on that and other common pitfalls in blog 3.
IN: testing your external exposure and people
The IN phase is where attackers gain their initial foothold. For most financial institutions, the realistic attack vectors are external-facing systems, phishing, and physical access. Your pre-TLPT testing in this phase should cover all three.
Relevant tests at this stage:
- External Attack Surface pentest: a structured assessment of everything your organization exposes to the internet, including web applications, APIs, and third-party and cloud-hosted systems.
- Phishing simulation: this is not a standard phishing test that measures how many employees clicked a link. A realistic phishing simulation uses current techniques, including 2FA fatigue attacks where an attacker exploits push notification overload to bypass multi-factor authentication, and does not stop at credential capture. Once a user session is compromised, we continue operating from that foothold, exactly as a real attacker would. That continuation is where the most valuable findings emerge.
- Physical security assessment: physical intrusion is not a universally applicable attack vector. Whether it is relevant depends entirely on your threat intelligence. In the context of hybrid warfare, however, physical sabotage has featured in enough documented incidents to take seriously, particularly for organizations with critical on-premise infrastructure or geopolitical exposure. Where the threat intelligence supports it, testing physical security before the TLPT is not just a worthwhile consideration: it is a logical extension of a realistic threat scenario.
THROUGH and OUT: testing your internal resilience
Once an attacker is in, the question becomes what they can do. This is where detection and response capabilities are most exposed, and where most organizations are least prepared.
Relevant tests at this stage:
- Internal network pentest: how far can an attacker move from an initial foothold? What can they reach? How long does it take your team to notice?
- Workstation and laptop assessment: endpoints are a primary propagation vector. Understanding how a compromised device can be used as a launchpad matters.
- Cloud and Active Directory assessment: for organizations with significant cloud infrastructure or hybrid environments, these are often where the most consequential vulnerabilities live.
- Application pentests: applications are not just an IN-phase concern. Internal and customer-facing applications that handle sensitive data or critical processes are relevant throughout the kill chain and should be tested regularly, not just once.
- Purple Team and Gold Team sessions: Purple Teaming trains your Blue Team by running through realistic attack scenarios together with the Red Team, building detection and response capability in real time. Gold Teaming extends this to senior leadership, making the business impact of security gaps tangible at board level. Both are effective dry runs for the dynamics you will encounter in the TLPT closure phase.
The scenario-based pentest: a full rehearsal
If you want to go further than individual phase tests, a Scenario Based Pentest sits between a standard pentest and a full Red Team exercise. It tests a specific part of the attack chain end-to-end, against a realistic scenario derived from actual threats in your sector.
Think of it as a dress rehearsal. You choose the starting point, an assumed initial foothold, for example, and we simulate what an attacker would realistically do from there. The findings are immediately actionable, and the experience of running through a real attack scenario builds organizational readiness in a way that individual component tests do not.
It is also, in our experience, the test that produces the most productive conversations between a CISO and their board. Nothing makes the case for security investment more clearly than watching a simulated attacker reach your critical data in three steps.
If you want to go even further, there are two additional options worth considering. A Purple Team or Gold Team exercise gives your defenders and leadership direct experience with realistic attack scenarios before the TLPT starts. Advanced Red Teaming (ART), the modular framework developed by DNB, goes one step further: it combines threat intelligence, realistic attack scenarios and structured learning moments into a complete dry run that mirrors the TLPT process closely, without the full regulatory overhead of TIBER-EU. For organizations that want maximum preparation before their first TLPT, ART is the most complete option available.
What this looks like in practice
Many types of organizations fall under DORA's TLPT requirements, and they need meaningfully different pre-TLPT strategies. We highlight two of them.
Large, traditional financial institution
A large bank or insurer typically has a broad attack surface: public-facing applications, extensive internal infrastructure, a large workforce, and multiple office locations. The threat profile includes financially motivated attackers and, in some cases, state-sponsored groups.
Option A: a phased build-up
Year 1:
- External Attack Surface pentest, including internet-facing web applications and APIs, to establish a baseline
- Phishing simulation targeting high-privilege employee groups, using current techniques including 2FA fatigue
- Internal network pentest from an assumed foothold
- Application pentests on critical internal or customer-facing applications
Year 2:
- Workstation assessment and Active Directory review
- Continued application pentesting, integrated into development and release cycles where the environment changes frequently
- Scenario Based Pentest combining IN and THROUGH phases
- Purple Team session to evaluate and improve Blue Team detection and response
Option B: continuous purple teaming
For organizations that want to build Blue Team maturity faster, an alternative is to run quarterly Purple Team scenarios throughout the two-year period alongside regular internal network and application pentests. Rather than building toward a single rehearsal, you run a new scenario every quarter, each one targeting a different part of the kill chain or a different threat actor profile. Over two years, that is eight scenarios. By the time the TLPT starts, your Blue Team has not prepared for a Red Team. They have worked alongside one, repeatedly.
This approach requires more investment and internal capacity, but it produces a measurably more capable defending team and, in our experience, the most strategically valuable TLPT findings.
Fintech or cloud-first financial service provider
A fintech operating a SaaS platform has a fundamentally different attack surface. The critical asset is the platform itself. Internal infrastructure may be minimal. The workforce is often smaller but more technical, and the environment changes rapidly.
Year 1:
- Whitebox pentest on the core platform as a baseline, covering application logic, authentication, and API security in depth
- Immediately follow with continuous pentesting: integrating security testing directly into the development cycle so that new features and infrastructure changes are tested as they are released, not months later
Year 2:
- Continue continuous pentesting throughout the year
- Cloud and infrastructure assessment to review the full cloud environment as it stands two years into growth and change
- Purple Team session in the final months before the TLPT: a structured exercise where Red Team and Blue Team work together to test detection and response across your most critical scenarios, giving your team the experience they need before the TLPT removes the safety net
The underlying logic is the same regardless of organization type: map your critical assets, understand your realistic threat profile, and test systematically across the attack chain before the TLPT does it for you.
What this looks like in practice: De Vereende
De Vereende is a specialist insurer operating in a sector where data integrity and operational continuity are business-critical. Although not subject to DORA's most stringent requirements based on their size, they chose to follow the guidelines and build a testing program that reflects genuine resilience, not minimum compliance.
Working with Securify, they developed a structured security testing strategy that combined penetration testing and Purple Teaming sessions, building both technical remediation and internal security awareness systematically over time.
The result was not just a cleaner vulnerability profile ahead of their compliance obligations. It was a measurably more resilient organization. Their CISO put it directly: "We already knew where our strengths and weaknesses lay, but the collaboration with Securify has elevated our security to a higher level."
That shift, from knowing your weaknesses in theory to having tested them in practice, is exactly what the pre-TLPT period is for. The TLPT will test your resilience regardless of whether you are ready. The only question is what it will find.
Read the full De Vereende case study
A note on continuous pentesting
For organizations with rapidly evolving environments, particularly fintechs and platform-driven financial services providers, a point-in-time testing strategy has inherent limits. A vulnerability introduced in a sprint two months before the TLPT starts will not be caught by a test conducted six months earlier.
Continuous pentesting solves this problem. Rather than testing once and hoping nothing changes, you maintain a live view of your security posture as the environment evolves. New features get tested as they ship. Infrastructure changes are reviewed as they happen. The security picture stays current.
This is not a prerequisite for a successful TLPT, but for organizations where the environment changes frequently, it is increasingly the approach that produces the most mature security programs ahead of a TLPT.
Further reading: Why annual pentesting no longer provides certainty
In short
The two years before your TLPT are not a waiting room. They are the foundation that determines what your TLPT will actually find, and therefore what value you will extract from it.
A structured security testing strategy, built around your specific threat profile and mapped to the kill chain, does three things simultaneously: it reduces your actual risk, it builds your team's capacity to respond to real attacks, and it ensures that your TLPT produces tangible, actionable insight rather than a basic remediation list.
The organizations that approach TLPT this way get more from the test. They also, in our experience, tend to be the ones that are ready for what comes after it.
In blog 3, we cover the most common pitfalls in a TLPT trajectory: from preparation to closure, and how to avoid them.