TLPT lessons for the whole firm

TLPT lessons should not stay confined to the functions and systems that were tested. A monitoring gap found during an attack on a payments function may also affect lending, trading or claims. A supplier access weakness found in one connection may exist in others. A response failure found in one incident playbook may reflect a firm wide problem with escalation or out of hours cover. Generalising lessons means asking, for each finding, whether the same cause could produce the same effect elsewhere, and then checking rather than assuming the answer.

Generalisation requires a deliberate process. Findings should be reviewed not only by the owners of the tested systems, but by owners of comparable systems and by the teams that set standards for identity, monitoring, supplier management and incident response. Without that review, remediation will fix the tested instance and leave the pattern untouched. With it, a single exercise can improve resilience across the firm, which is a far better return on the effort and disruption that TLPT involves.

A pattern is recognised by looking for common causes across findings. If several findings involve excessive privileges, the pattern is privilege management, not the individual accounts concerned. If several findings involve alerts that fired but were not acted on, the pattern is alert handling, not the individual alerts. If several findings involve supplier accounts, the pattern is supplier access governance. Grouping findings by cause, as the remediation guide suggests, is the first step toward seeing patterns.

Sharing should be tailored to the audience. Technical teams need detail: timelines, log patterns, detection rules and control changes. Senior management needs a function level summary: which functions were affected, what the pattern implies, and what investment is required. Other business lines need to know whether the pattern affects them and what they should check. Sharing the full TLPT report with everyone is neither necessary nor safe, given its sensitivity. Sharing a sanitised lesson, with the pattern and the required action but without attack details, is usually more effective.

Sharing also needs a record. A lesson that is mentioned in a meeting but never written down, owned or tracked will be forgotten. Lessons should be logged alongside findings, with an owner, a scope for the wider check, and a completion criterion. That log allows the firm to show, at the next TLPT cycle or supervisory discussion, which lessons were generalised, which were checked and found not to apply, and which remain open.

The most durable lessons change standards and processes, not only individual systems. A finding about supplier access should lead to a revised supplier onboarding standard, with narrower default privileges and periodic review. A finding about alert handling should lead to a revised monitoring standard, with clearer escalation and cover requirements. A finding about incident escalation should lead to a revised playbook, rehearsed with the teams who will use it. Standards changes spread the lesson automatically to future systems, whereas system fixes alone must be repeated each time a new system is built.

Some TLPT lessons concern behaviour rather than technology. Staff may have shared credentials for convenience, bypassed a control to meet a deadline, or hesitated to escalate an incident for fear of blame. Those behaviours will not be fixed by a technical control alone. They require attention to training, to workload, to incentives and to the tone set by management. A firm that punishes staff for reporting incidents will learn less from TLPT than a firm that rewards early escalation, even if their technology is identical.

Culture lessons should be handled sensitively. TLPT findings about behaviour should focus on systems and processes that allowed the behaviour, rather than on blaming individuals. If staff share credentials because the approved access process is slow, the process needs fixing. If staff hesitate to escalate because previous escalations were criticised, the escalation culture needs attention. Framing lessons in that way encourages openness, which in turn makes the next exercise more informative.

Wider impact can be measured by tracking how many systems or processes were checked as a result of a lesson, how many were found to share the weakness, and how many have been fixed and verified. Those counts, presented by pattern rather than by individual finding, give boards a sense of whether TLPT is changing the firm or merely fixing the tested systems. They also help supervisors judge whether the firm treats TLPT as a programme or as an event.