Threat-led penetration testing (TLPT)

Threat-led penetration testing, often shortened to TLPT, is a controlled test of a live production environment that follows real threat intelligence. Instead of checking a list of known weaknesses in isolation, the test recreates the tactics of plausible attackers and follows them through the systems that support a critical function. The firm, the testers and the relevant authorities each have a part to play, and the framework that governs the exercise sets out how those parts fit together. That shared structure is what separates TLPT from an ordinary penetration test that happens to use a threat report as background reading.

The findings from TLPT are not a simple pass or fail grade. They describe how far an attack path progressed, which controls detected or slowed it, where response broke down, and what should change as a result. A firm that treats a clean result as proof of safety, or a long finding list as proof of failure, has missed the point. The value lies in the evidence about detection, response and recovery in production, and in a remediation plan that can be tracked to completion.

A test in a laboratory copy can show whether a single control works, but it cannot show how people, processes and technology behave together when a real service is at stake. Live production is where customer transactions flow, where third party connections are active, and where an incident would actually cause harm. Testing there, under strict controls, reveals timing problems, alert fatigue, unclear escalation routes and dependencies that a paper review or an isolated scan would miss. The risk of testing in production is real, which is why preparation, safeguards and agreed stop conditions matter as much as the attack scenarios themselves.

The starting point is threat intelligence that is relevant to the firm, its sector and its technology. Intelligence providers and testers study the groups and methods most likely to target comparable firms, then shape scenarios around those methods. A scenario might begin with phishing aimed at staff who handle privileged access, move through credential misuse, and end with an attempt to disrupt settlement or alter payment data. Each step is chosen because it mirrors observed attacker behaviour, not because it is convenient to test or because a tool happens to support it.

That discipline also protects the exercise from drifting into a generic security check. If a scenario does not reflect a plausible threat to the firm's critical functions, it does not belong in TLPT, however interesting the technique may be. The intelligence therefore needs regular review, and the test team needs to explain why each scenario was selected. A reader of the final report should be able to trace every major attack path back to an intelligence judgement, and to see which paths were considered and deliberately left out.

Three groups shape a TLPT exercise. The firm owns the critical functions, provides the target systems and staff, and remains responsible for safety, remediation and ongoing resilience. The testers bring independence and specialist skill, and they must be able to challenge the firm's assumptions without becoming part of its day to day security operation. The authorities provide oversight through the applicable framework, including expectations on scope, reporting and the handling of findings. When any of these roles blurs, the exercise loses credibility: a firm that directs the testers too closely, or testers who lack independence, produce reassurance rather than evidence.

Findings should be read as a map of an attack path, not as a scorecard. A finding that an attacker reached a particular system is less important on its own than the chain that made it possible: which initial access worked, why detection was slow, which privilege escalation succeeded, and where the response team regained control. Weaknesses in monitoring, in identity controls, in supplier access or in incident playbooks often matter more than a single software flaw, because they determine how long an attacker can remain present and how much damage can follow.

The recurring pitfall is scoping the test to the systems that are easiest to test, so that the critical functions the test exists to protect are never touched. Easy targets produce tidy reports and comfortable meetings, but they leave the most consequential systems unexamined. A payments hub, a trading platform or a claims system may be harder to include because of change controls, supplier constraints or fear of disruption, yet those are precisely the systems whose failure would hurt customers and markets most.