What is threat-led penetration testing for banks?

Threat-led penetration testing for banks is a controlled security exercise that uses threat intelligence to simulate attacks relevant to a bank and assess whether it can prevent, detect and respond to them. It focuses on critical business functions and the technology, people, processes and external services that support them. The test follows agreed rules of engagement and safety controls.

How threat-led penetration testing for banks works

The bank first identifies the critical functions in scope, such as customer payments, account access or settlement. The team maps the applications, infrastructure, identities, data flows and third-party dependencies that support those functions. This scoping determines which systems can be tested and where testing must stop.

Threat intelligence informs the attack scenarios. Testers consider relevant threat actors, their likely objectives and their tactics, techniques and procedures. The resulting plan might examine how an attacker could gain access, move between systems, reach a sensitive service and affect a critical function. Each action needs authorisation, defined limits and a safe way to pause or stop the exercise.

A red team carries out the simulated attack. A small coordinating group, often called the white team, manages safety, permissions and communications. The bank may keep operational defenders unaware of the exact test activity so the exercise can assess detection and response. The level of awareness depends on the agreed design. After execution, a debrief can bring testers and defenders together to review what happened and validate the evidence.

Testing may involve live services where the bank and relevant parties have approved the approach and controls. A production-like environment can reduce operational risk, although it may not reproduce every dependency or control found in production. The choice affects what the results can demonstrate, so the report should record the environment, exclusions and limitations.

How TLPT differs from routine penetration testing

Routine penetration testing commonly targets a defined application or infrastructure estate to identify exploitable weaknesses. Threat-led penetration testing follows an intelligence-based attack path and evaluates how security controls work together across a critical function. A vulnerability assessment typically identifies and classifies known weaknesses; it does not, by itself, test the bank's end-to-end ability to detect and respond to a realistic attack.

The terms threat-led penetration testing and threat-led penetration testing (TLPT) are used in regulatory and industry contexts. TIBER-EU is an intelligence-led red-team testing framework used in the European Union. The Digital Operational Resilience Act (DORA) includes TLPT requirements for certain financial entities. Applicability, oversight and implementation depend on the relevant rules and competent authorities, so a bank should confirm its obligations for its jurisdiction.

Example: testing a payment function

Suppose a bank selects customer payments as a critical function. The test team could design a scenario based on a threat actor seeking access through a compromised staff account. Under approved rules, testers would attempt the agreed access and movement steps, then assess whether identity controls, monitoring and response processes work as intended.

Useful evidence could include authentication and application logs, alerts generated, incident tickets, escalation times and the decisions made by responders. The team should verify that the test did not cause unauthorised payment changes, expose customer data or disrupt service. If a control blocks the planned route, testers should record the evidence and follow the agreed rules for any alternative scenario.

What makes the results useful

A credible result depends on accurate scope, relevant threat intelligence and safe execution. Environment drift, incomplete asset maps or missing third-party permissions can leave important paths untested. Other limitations include test accounts that do not reflect real permissions, monitoring configured differently from production, or response staff who have been briefed in ways that change normal behaviour.

The final report should link observed actions to evidence, explain scope gaps and describe the effect on the critical function. Findings need owners and remediation plans. Banks can then retest important weaknesses and use the results to improve security controls and operational response. A TLPT result is evidence about the tested scenarios and conditions, not a guarantee that every possible attack will be detected or prevented.