TLPT testers and independence

TLPT testers are specialists who plan and execute the attack scenarios, observe how the firm detects and responds, and report what they found. Their independence is essential: if testers are too close to the firm's security team, they may unconsciously avoid the most revealing paths, accept explanations too readily, or soften findings. Independence does not mean hostility. It means a clear separation of roles, a mandate to follow the evidence, and a reporting line that is not controlled by the teams whose controls are being tested.

Independence also has practical dimensions. Testers should not have designed the controls they are testing, should not be responsible for day to day security operations in the scoped systems, and should be free to escalate findings without fear that a commercial relationship will suffer. Firms should select testers on skill and track record, agree the mandate in writing, and protect the testers' ability to challenge. A test that is comfortable for everyone involved is unlikely to be a rigorous one.

Testers need a combination of technical skill, threat knowledge and judgement. Technical skill covers the methods in the scenarios: initial access, privilege escalation, movement inside networks, and actions against target systems. Threat knowledge allows testers to recreate attacker behaviour faithfully, rather than relying on automated tools that bear little resemblance to a real intrusion. Judgement covers safety: knowing when to pause, when a technique risks production harm, and when a finding is significant enough to report immediately.

Testers also need communication skill. They must explain their plans to the firm and the authorities in advance, coordinate with control teams during the test, and write findings that a board member and a system owner can both understand. A technically brilliant test that produces an unreadable report wastes its own value. Firms should therefore look beyond tool certifications and ask how testers have handled live production testing before, how they manage risk, and how they report.

Separation begins with selection. A firm should not ask its usual penetration testing supplier to run TLPT as a routine extension of an existing contract without examining independence. If the same team advises on controls, monitors incidents and then tests those controls, the lines blur. The framework arrangements for tester selection and approval exist to prevent that blur, and firms should follow them rather than treating tester choice as a procurement convenience.

During the exercise, separation is maintained through agreed working arrangements. Testers plan scenarios with the firm and the intelligence provider, but they execute them independently. The firm's detection teams respond as they would to a real incident, without being coached by the testers. A control team oversees safety and can halt the test, but does not direct the attack paths. These boundaries are written down before testing starts, so that disagreements during the test can be resolved by reference to the plan rather than by negotiation under pressure.

A productive relationship balances openness with challenge. The firm should give testers the access, information and system knowledge they need to plan realistic scenarios, including details of suppliers and dependencies that affect the scope. Withholding information to make the test harder may sound realistic, but it usually produces a test that wastes time on discovery that real attackers would have completed long before, and it deprives the firm of evidence about its core systems.

A TLPT team typically divides into roles: those who execute the attack scenarios, those who provide threat intelligence, and those who oversee safety and reporting. In smaller exercises the same organisation may provide several roles, but the roles themselves should remain distinct, so that the person who designs a scenario is not the only person who judges whether it succeeded. Quality assurance within the testing organisation matters too: findings should be reviewed for accuracy, for evidence and for proportion before they reach the firm.

An illustrative trading firm example shows why structure matters. If the tester who gains access to a settlement system also writes the finding without review, a misreading of a log entry could become a board level conclusion. A reviewed finding, checked against logs and timelines, is slower to produce but far more reliable. Firms should ask testers how they review findings, how they handle disputed findings, and how they protect the confidentiality of what they learn.

Independence does not end when testing ends. Testers should not be asked to help implement remediation in a way that compromises their ability to test the same controls in a future cycle. A tester who has rebuilt a detection rule may be reluctant to report that the rebuilt rule still fails. Firms should therefore separate remediation support from future testing roles, or at least record the overlap and manage it explicitly.