Threat-Led Penetration Testing: What TLPT Actually Means

TLPT is used two ways, and the gap between them is large enough that anyone reading a proposal with the phrase in it should ask which one is meant. Both can be good work. Only one of them produces a result a supervisor will read as a supervisor.

The regulated meaning

In several jurisdictions, threat-led penetration testing is a defined, supervised programme, not a service a firm sells. The characteristics that mark it out:

• Prescribed threat intelligence. A separate provider produces a targeted intelligence report on adversaries realistically relevant to the institution, and the test is built from it.
• Regulator involvement. The supervisor is aware, and in some frameworks approves the scope and observes.
• Prescribed scope. Criteria in the framework identify the critical functions; the institution does not choose them.
• Separation of duties. The intelligence provider and the testing provider are usually required to be different organisations, and both may need accreditation.
• Formal closure. The programme closes on a remediation plan submitted and tracked, not on a report filed.

All that machinery exists for comparability. Because the method was prescribed, a supervisor can read one institution's results against another's.

The load on the institution is heavier than the testing window suggests. Someone inside has to run a control group that knows the exercise is live, is trusted to say nothing for weeks, and holds the authority to stop it. Legal signs the authorisation before a tester touches anything. The intelligence phase runs before testing begins, and the closure phase runs long after testing ends. Budget the elapsed time and the named people, not just the days of testing.

The marketing meaning

Elsewhere the phrase is used to mean "a red team informed by threat intelligence", which is what a competent red team already is. Used this way it describes good practice and carries no supervisory weight.

Confusing them is expensive, because one costs several times the other. The supervised version buys two providers instead of one, an intelligence phase that produces a deliverable of its own, accreditation overhead on both firms, and a closure process somebody external tracks. The other buys testing.

The two side by side

Reading a claim

Three questions settle it:

• Under which framework? A supervised programme is always named. The framework has a name, a version and published requirements. "We follow TLPT principles" is the marketing meaning.
• Who produces the threat intelligence? If the answer is "we do", it is not the regulated variety, which generally requires separation.
• Is your regulator involved? If nobody has told them, it is a red team.

A fourth question is useful on the procurement side: what is the deliverable comparable to? A supervised programme produces a result you can hold against peers because everyone ran the prescribed method. A red team report is comparable to your own last one, and that is enough to buy on its own terms, provided the report says what was attempted and failed as well as what worked. See what a red team report contains.

What the intelligence phase should contain

Whichever meaning applies, the intelligence phase decides whether the exercise is realistic, and it is the easiest part of a proposal to fake. A targeted intelligence product is specific to you:

• Your external estate as an outsider assembles it: domains, exposed services, cloud tenancy, suppliers with standing access, and the staff footprint social engineering would use.
• Actor sets named with a stated reason they would come for you, drawn from your sector, the data you hold and the payment rails you touch.
• Scenarios traced to tradecraft that has been observed somewhere, mapped to MITRE ATT&CK techniques so your defenders can check coverage technique by technique.
• A statement of what the intelligence did not find, so the scenarios that were dropped stay visible.

An industry trends report with your logo on the cover is not intelligence. If each scenario cannot be traced back to a line in the intelligence document, the exercise has quietly reverted to what the testers find interesting.

Where India stands

No supervised threat-led testing regime of the TIBER or CBEST kind exists in any of the six RBI cyber Directions issued on 31 July 2026. The RBI's 2026 Directions treat red teaming permissively: at ¶162 the word is "may". That is covered in red teaming under the RBI's 2026 Directions.

That makes a red team here a risk decision, not a compliance one. Nobody is buying it to satisfy a form, so it only gets bought when it will change something. Security Brigade maintains the paragraph-level reading at red teaming requirements.

One piece of the supervised model does carry over: who is allowed to hold the tools. Under ¶156 the institution assesses the qualification, professional expertise, credentials and competency of the testing firm and of the assigned personnel, at every selection, appointment, engagement and renewal. Where a CERT-In empanelled auditor is engaged, ¶159 brings CERT-In's audit policy guidelines into the supervisory relationship. Empanelment is how that competency gets evidenced, and every Indian regulator that accepts an audit report accepts it from a CERT-In empanelled auditor. Ask for the named people, not the letterhead: ¶156 reaches the personnel as well as the firm. We have held empanelment continuously since 2008.

An exercise of this kind sits alongside the testing calendar. ¶151 sets vulnerability assessment at least every six months and penetration testing at least every twelve months for information systems that are critical and / or sit in the DMZ with a customer interface, and the scope test is disjunctive, so either limb pulls a system in. ¶150 extends testing across the lifecycle, including after changes. Plan the adversary simulation on top of that, with the obvious surface already assessed, or you will pay a red team to find what a scanner names. The line between the two is drawn in red team versus penetration testing.

Decide in advance what happens when your own people conclude they are in a real incident, because in a regulated Indian entity that conclusion starts a clock. ¶182 requires cyber incidents to be reported on the DAKSH platform within six hours of detection. The rules of engagement should name who inside the institution can confirm that activity is authorised, how that person is reached at two in the morning, and the point at which the exercise pauses instead of running on into a notification. Both documents matter here: scoping and rules of engagement and what the exercise tells you about detection.

Anyone operating across borders should establish which regime binds each entity separately. A group with a European or UK-regulated arm may face a supervised programme there and nothing equivalent in India, for the same business.

Who closes it when nobody is supervising

In a supervised programme, closure is somebody else's job to check. Without a supervisor, closure is a promise the organisation makes to itself, and it is the phase that quietly fails. Settle before the exercise starts: who owns each class of finding (identity, network, application, physical, and the detection gaps that belong to your monitoring team), who funds the fix, who is allowed to accept a risk and sign for it, and when the retest happens. Put the retest date in the contract, while nobody yet has a reason to argue about it.

The RBI Directions also put ongoing review of the testing firm's performance on the institution, and ¶158 addresses what follows when a system that was tested is later compromised through something the testing missed. Practically, keep the evidence: what was in scope, what was reached, what was reported, and what you did about it.

When to leave it alone

Either version of this is the wrong purchase in four situations.

• Nobody is watching. With no team monitoring and responding, the exercise measures nothing about detection, and you have bought a penetration test by a longer route. Build the response capability first, or run a purple team, where testers and defenders sit together and the learning lands the same week.
• The obvious surface has never been assessed. Unpatched perimeter services and default credentials make an adversary simulation trivial and uninformative. Clear them on the VA and PT cadence, then simulate.
• The exercise exists to produce a document. Red teaming is permissive under the 2026 Directions. Buying one to fill a slot in a checklist spends the budget on the wrong control.
• The secret cannot hold. A control group that leaks turns the result into a measurement of how fast internal news travels. If the organisation cannot keep a handful of people quiet for the duration, announce the exercise and run it openly instead.