TLPT for critical functions

A critical function is a service whose disruption would cause significant harm to customers, to markets, or to the firm itself. TLPT exists to test those functions, because a failure there matters more than a failure in an isolated system that supports no important service. The test therefore begins with functions, traces each function to the systems and suppliers that support it, and follows attack paths that could disrupt, corrupt or halt that function. A TLPT exercise that does not name its critical functions, or that tests systems without connecting them to a function, has lost its anchor.

Function level thinking also changes how findings are judged. A weakness in a system that supports a critical function is more consequential than the same weakness in a peripheral system, because the impact of exploitation is greater. Remediation, reporting and supervisory discussion should all use the function as the unit of analysis, so that the firm, the testers and the authorities are discussing the same risk in the same terms.

Identification starts with the firm's services and their users. What services do customers rely on? What services do markets rely on? What services, if halted, would prevent the firm from meeting its obligations? Those questions, answered in plain language, produce a candidate list. The list is then refined by considering impact: how many users would be affected, how severe the effect would be, whether alternatives exist, and how quickly harm would follow from a disruption.

An illustrative example helps. A retail bank might identify customer payments, access to deposits, and settlement of transactions as critical functions. A wealth manager might identify client asset custody and trade execution. An insurer might identify claims payment and policy administration. The lists differ because the businesses differ, and that difference is expected. What matters is that the list reflects the firm's actual services, not a generic catalogue copied from another firm.

Once a function is named, the firm traces what it depends on. That trace includes customer channels, authentication systems, processing engines, data stores, messaging and settlement networks, staff teams, and suppliers. It also includes dependencies that are easy to overlook: a single data centre, a shared identity platform, a market data feed, or a supplier that provides a small but essential component. Attackers often target those overlooked dependencies, precisely because they receive less attention.

Tracing should produce a map that a non specialist can follow. The map should show the function, its main systems, and the links between them, with suppliers clearly marked. It should be kept current, because functions change as products, systems and suppliers change. A map that is updated only for TLPT, and then left to decay, will mislead the next exercise. The map is a resilience asset in its own right, useful for incident response and recovery planning as well as for testing.

Testing a function means following an attack path that could affect that function from end to end. Testers might begin with access through a customer channel or a supplier connection, move through internal systems, and attempt to reach the processing or data system at the heart of the function. At each stage, detection and response are observed. The test shows not only whether the core system can be reached, but whether the journey there would be noticed and stopped.

Many firms have systems that support several critical functions: a shared identity platform, a common data store, a central payment hub. A weakness in a shared system can therefore affect multiple functions at once, and a test that covers only one function may understate the risk. Scoping should recognise shared systems explicitly, and findings concerning them should be assessed for their effect across all the functions they support.

Shared systems also complicate remediation. A fix that protects one function must not break another, and a change that is prioritised for one function may need to be sequenced with changes for others. The firm should therefore maintain a view of shared dependencies alongside its function maps, so that remediation plans can be coordinated. Supervisors will often ask about shared systems, because they represent concentration risk: a single point of failure that, if compromised, could disrupt several important services simultaneously.

Reporting by function makes TLPT results understandable to boards and supervisors. Instead of a list of technical findings organised by system, the report can state, for each critical function, how far attack paths progressed, where detection worked, where response failed, and what remediation is planned. That structure allows a board to judge whether its most important services are resilient, rather than trying to infer resilience from a catalogue of defects.