TLPT findings and remediation plans

A TLPT finding describes a step, or a chain of steps, by which testers progressed toward a critical function, together with what detected, slowed or failed to stop them. Findings are not grades, and a long list does not automatically mean a firm is unsafe, just as a short list does not automatically mean it is safe. What matters is the path: how access was gained, how long the testers remained undetected, which systems they reached, and how the firm responded. A remediation plan should address the causes behind that path, with an owner, a sequence and a way to verify that the fix works.

Remediation is where TLPT either changes resilience or becomes paperwork. A plan that lists actions without owners, dates or verification will drift. A plan that patches the final system in the chain while leaving the initial access method open will fail against the next attacker who follows the same path. Good remediation therefore starts from the attack path, works back to root causes, and checks the fix by retesting or by evidence that the control now behaves as intended.

Read a finding as a story with evidence. The story should state the scenario, the technique used, the systems touched, the timeline, and the detection and response at each stage. Evidence may include log extracts, alert records and timelines, presented in a way that allows the firm's own teams to verify what happened. A finding without a timeline is hard to act on, because the firm cannot tell whether detection was slow, whether escalation failed, or whether the response team simply lacked the information to act.

Most TLPT findings have more than one cause. An attacker may have gained access because a credential was exposed, moved laterally because segmentation was weak, and remained undetected because an alert was misconfigured. Fixing only the exposed credential leaves the segmentation and monitoring weaknesses for the next attacker to exploit. Root cause analysis should therefore examine identity, network design, monitoring, supplier access and response procedures together, rather than treating each finding as an isolated defect.

An illustrative insurance claims example shows the point. Testers might reach a claims payment system after exploiting a supplier account with excessive privileges. The immediate fix is to reduce those privileges. The root causes, however, may include a supplier onboarding process that grants broad access by default, a review process that never revisits that access, and monitoring that does not flag supplier activity outside normal hours. A remediation plan that addresses all three causes will be longer, but it will also be more durable.

A remediation plan should group findings by cause and by function, so that related fixes are sequenced sensibly. It should name an owner for each action, describe the intended change in concrete terms, state the order in which actions will be taken, and define how completion will be verified. Verification matters: a control that has been changed but not tested may still fail, and a process that has been rewritten but not rehearsed may still break under pressure. Retesting, targeted exercises and monitoring evidence can all serve as verification, depending on the nature of the fix.

Tracking should be regular, visible and owned at a senior level. A remediation tracker that lives only with the security team, and is reviewed only when the next TLPT cycle approaches, will not drive action. Progress should be reported to the committee that oversees resilience, with overdue actions explained and re-planned rather than quietly carried forward. Actions that are closed should show evidence of verification, not merely a statement that work was done.

Governance also needs to handle disagreement. A system owner may dispute a finding, argue that a control already exists, or propose a different fix from the one testers suggested. Those discussions should be recorded, with the reasoning for the chosen approach. A finding that is closed by disagreement without evidence is not a closed finding. A finding that is closed by an alternative fix, with evidence that the alternative addresses the root cause, is a legitimate outcome. The record should allow a later reviewer to tell the difference.

Remediation should not be confined to the systems in scope. If a finding reveals a monitoring gap, the firm should check whether the same gap affects other functions. If a finding reveals a supplier access weakness, the firm should review supplier access more broadly. That wider learning is discussed in the guide on lessons for the whole firm, but it begins here, in the remediation plan: each action should note whether it applies to a single system, a class of systems, or a firm wide process.