Webinar recording: TLPT Masterclass (2026)
Learn how to get TLPT right. Access the recording of our practitioner-led session on ‘red team realism’ and how to build a pre-TLPT programme that really moves the needle.
Send me the link
Learn how to get TLPT right. Access the recording of our practitioner-led session on ‘red team realism’ and how to build a pre-TLPT programme that really moves the needle.
Send me the linkThreat‑Led Penetration Testing (TLPT) and TIBER exercises are a serious test of operational resilience under adversarial conditions in financial services. They are the closest thing an organisation can get to facing a determined and well-resourced adversary without the headlines and regulatory fallout.
At their best, these exercises are extremely valuable. They help organisations test detection and response under realistic conditions and assess how critical controls hold up under pressure.
Yet not every TLPT exercise delivers on that potential. In some cases, the red team compromises critical systems, the exercise exposes familiar gaps in detection, escalation and response, and a report is produced.
A TLPT should be intended as a resilience and capability-building exercise, but the ‘compliance machinery’ around it can create incentives that pull in another direction. The stated goals of capability and resilience improvement can easily be diluted by a compliance process where a risk-free execution or narrowed scope seem more rewarding.
Like any complex programme, the value TLPTs produce depends heavily on how they are designed and governed from beginning to end. One of the biggest influences on that is the control team.
An observed pattern is a control team that includes strong risk and regulatory input but limited technical and operational knowledge of the environment itself. That risk perspective is important, but a TLPT exercise is usually stronger when it is complemented by people who also understand the organisation’s systems and architecture in depth. A good balance makes it easier to interrogate a scenario and challenge the red team’s approach, which leads to valuable insights.
The effects of an imbalance in the control team composition show up in small but telling ways. A clarifying question about how a service is delivered could get treated as an attempt to ‘game the test’. A request for business context can get delayed in the name of preserving a ‘closed box’ approach. The result could be bias or discordance among stakeholders who are all trying to make the exercise work. Biases and restrictions can distort the scenarios while TLPT depends on realism. If the exercise is framed in a way that limits realistic modelling of adversarial behaviour, some of its value is lost.
Mandate is just as important. Once the red team report is delivered, the control team needs authority to help set priorities in a remediation plan and maintain momentum on addressing impactful red team observations. That may include challenging business decisions, if needed. As a result, important issues are not deferred or reframed as accepted risk.
Where the control team is well balanced and empowered, a strong red team can do more than achieve flags or confirm gaps that insiders may already know. The exercise becomes a way to surface deep organisational weaknesses and create pressure for meaningful change.
Another factor that shapes the value of TLPT exercises is whether they are designed to reflect today’s threat landscape.
Regulatory red teaming emerged in financial services around the middle of the last decade as frameworks like CBEST and TIBER-EU emerged. Back then, many of the cyber threat stories were relatively linear and legible. High‑profile campaigns followed a recognisable pattern: gain entry, move laterally, access the payment infrastructure, profit. The paths to impact were relatively easy to map, and the control narrative was clear and compelling.
Today, that framing no longer holds. While attackers still pursue funds and theft remains a concern, they also target data at scale, cause disruption in support of extortion, abuse identities, supplier relationships, software trust mechanisms, certificate infrastructure. The attack surface has expanded beyond core infrastructure, across cloud platforms, SaaS ecosystems, CI/CD pipelines, third parties. Scenarios involving trusted platforms can be especially valuable because they also assess governance and architectural assumptions about what the organisation implicitly trusts.
All this has implications for early design decisions. Scope definition matters enormously, and one of the most common failures is conservatism dressed up as risk management. Realism dies in the fine print of scope documents; an ongoing IT migration nobody wants tested yet, the recent merger still being integrated, a third-party dependency that no one owns. Those are often the untidy places a real attacker could explore.
Furthermore, real attacks rarely unfold in a clean sequence. They hit dead ends, pause, reroute and leverage opportunities that were not visible in the original work plan. That is why good scenarios are built around adversary behaviour, objectives and realistic capabilities.
Threat‑led testing should reflect this shift and demand scenarios rooted in current adversary behaviours and a broader view of resilience. Going back to the point in the previous section, this also means having a control team that understands the environment well enough to tell when courses of action against the systems supporting the objectives are credible and the scenario itself is relevant.
Certainly, provider selection matters too. If threat intelligence is generic or interchangeable from one test to the next, the exercise is modelled on an obsolete version of the threat. It could remain formally compliant while losing much of its threat-led concept. And if the red team provider is chosen mainly because of the ability to run a compliant exercise, the organisation may never test whether it could withstand a capable and relevant adversary.
____________________________________________________________________________________
{{standout}}____________________________________________________________________________________
There is often a gap between how organisations imagine advanced attacks and how those attacks actually unfold. A common misconception is that advanced intrusion activity will involve exotic tooling, zero-days and distinct behaviour. In practice, the most effective attacks look almost boring.
Some of the techniques and tradecraft that most consistently evade detection rely on 'living off the land' using native tools, standard protocols, valid credentials and admin pathways that already exist in the environment.
A proficient red team treats Active Directory and certificate services as home turf, relentlessly querying, mapping and analysing relationships, trusts, permissions and entitlements until the terrain gives up its weak points. Operators abuse standard authentication mechanisms to move laterally and escalate privileges in ways that can closely resemble routine administrative or service activity, unless defenders have the context to distinguish them. At scale, these activities can look legitimate and may be hard for defenders to catch.
For threat-led testing to be credible, scenarios must reflect this reality. Tests that centre on simplistic heist narratives or hype exploits can miss the quiet abuse paths — like those that are identity based — which can pose systemic risk.
There is also a strategic decision to be made about what success looks like in a TLPT exercise. If the red team can achieve its objectives without being detected, the test is often treated as successful. That is only part of the picture.
The testing is also there to show how the organisation prevents, detects, understands and responds to a compromise, and to expose the points where process, technology and human decision‑making break down.
Getting there means making the right trade-offs upfront. Prioritising stealth reflects how sophisticated attackers operate. As the red team closes in on the flags undetected, there is also value in making more realistically detectable moves and leaving the blue teams with something to respond to. This is less about letting the defenders off the hook and more about generating the evidence the organisation needs. Does detection break down? Where does incident escalation fail? Are any wrong calls made?
Organisations that handle this well tend to have one thing in common: expectations are set clearly before the exercise starts, and the control team plays a central role in setting them.
If threat‑led testing in your organisation has started to feel like a ritual rather than a catalyst, hiring a different red team or purchasing another security tool will not be the answer. More often, the gains come from strengthening the governance around the programme and having the right mix of expertise and authority aboard.
That can be achieved in two ways. First, include the people who understand the organisation's technical and operational reality. Second, empower the control team to act, giving them the mandate to support realistic scenarios, to push back on comfortable narratives, as well as keep attention on systemic weaknesses instead of isolated ones.
Threat‑led penetration testing can be an extraordinarily powerful instrument to test the organisation’s ability to manage real crises, challenge weak assumptions and provide a disciplined basis for prioritising resilience investments. It is worth doing the work before a formal TLPT begins to use it well.
Organisations that have already built a baseline — running smaller threat-informed red and purple team exercises, mapping logging, examining detection coverage — usually do not bring the number of findings to zero. What changes is the quality of the findings, with more of them sitting closer to real business impact, and fewer being basic weaknesses that could have been addressed earlier.
When TLPT is primarily considered as a compliance requirement, scenarios can get narrowed and the exercise may end up confirming what was already known rather than driving real change. TLPT that creates lasting value starts from a different objective: raising the organisation's resilience. Once that is the goal, the rest tends to follow. The control team will be composed for the depth the test needs to challenge assumptions, scenarios reflect how real adversaries behave, and findings and remediations are acted upon in the context of the organisation’s environment, business resilience and priorities.
An effective TLPT is designed and governed around realism: scenarios rooted in current adversary behaviour, a balanced control team, capable intel specialists and red team testers, and scope that includes the untidy areas a real attacker would explore. An exercise driven by compliance aiming for risk-free scope and execution can easily lose much of its value as a result.
The Control Team (CT) is a small group (typically 3-5 members) that owns the test from start to finish. They frame and steer the exercise. Some of their responsibilities include setting expectations before testing, keeping scenarios realistic, and prioritising remediation afterwards.
____________________________________________________________________________________
SecAlliance advises boards, control teams and CISOs on designing tests that satisfy supervisors and drive genuine resilience improvements.