TLPT scoping and target systems

Scoping is the decision that determines whether TLPT is meaningful. The scope should start from the firm's critical functions, trace each function to the systems, people, data and suppliers that support it, and then select target systems that genuinely represent that function in live production. A scope that is drawn around convenient systems, familiar infrastructure or the areas a test team already knows will produce a report, but it will not produce evidence about the functions whose failure would matter most. Scoping is therefore a governance decision, not a technical convenience.

Good scoping also makes exclusions visible. Some systems may be excluded for safety, legal or practical reasons, but each exclusion should be reasoned, recorded and reviewed. An exclusion that is buried in an appendix, or justified only by difficulty, undermines confidence in the whole exercise. The test report should allow a reader to see what was in scope, what was out of scope and why, and what the next cycle should do differently.

Critical functions are the services whose disruption would cause significant harm to customers, markets or the firm itself. Examples in an illustrative firm might include retail payments, settlement of trades, or the payment of insurance claims. Each function depends on a chain of systems: customer channels, authentication, processing engines, data stores, messaging networks and supplier platforms. Scoping from the function outward ensures that the chain is tested as a chain, rather than as a collection of unrelated components.

Starting from technology instead reverses the logic. A firm might test its newest platform because it is well documented, while leaving a legacy settlement system untested because it is poorly understood. That legacy system may be exactly where an attacker would focus, precisely because it is poorly understood and less closely monitored. Function-led scoping forces the firm to confront its least comfortable systems, and to explain any decision not to include them.

Mapping begins with a service map that shows, for each critical function, the systems it relies on and the dependencies between them. The map should include internal systems, group platforms, third party providers and the data flows that connect them. It should also show where a single system supports several functions, because a compromise there could have wider effects than a compromise in a system used by only one function. The map does not need to be elaborate, but it does need to be accurate and current.

From that map, the test team and the firm select targets that allow plausible attack paths to be followed end to end. A target set that includes only perimeter systems will never show whether internal segmentation, monitoring or response works. A target set that includes a core processing system, its supporting data store and the access paths into them will. The selection should be documented with reasons, so that later reviewers can judge whether the targets matched the functions and the threat scenarios.

Exclusions are sometimes unavoidable. A system may be undergoing a critical change, a supplier may impose a restriction, or a safety assessment may show that testing a particular component in production carries unacceptable risk. In each case, the exclusion should name the system, state the reason, describe the alternative assurance obtained, and set out how the gap will be addressed in a future cycle. That record turns an exclusion from a weakness in the exercise into a managed decision.

Supplier systems are often the hardest part of scoping, and often the most important. A cloud hosted platform, a payment gateway or a market data feed may sit outside the firm's direct control, yet a disruption there would halt the critical function. Scoping should therefore address supplier involvement early, including what the supplier will permit, what safeguards apply, and how findings concerning supplier controls will be shared and remediated. Early engagement usually produces a workable arrangement; late engagement usually produces a refusal.

Shared systems raise a similar point inside groups. A platform that serves several entities cannot be tested for one entity in isolation without considering the others. Scoping should record which entities are affected, how their data is protected during the test, and who owns any findings that cut across entities. The goal is a scope that is honest about shared risk, rather than a scope that pretends a shared platform belongs to a single firm.

A reader judging a TLPT scope can ask a few direct questions. Does the scope name the critical functions and trace them to systems? Does it include the core processing and data systems, not only the perimeter? Are exclusions explicit and reasoned, with a plan to close them? Does it cover supplier and group dependencies that the function relies on? Would an attacker, reading the scope, recognise it as covering the paths they would actually take?