Start with what the organisation must keep doing
A useful TLPT scope begins with critical or important functions, then traces the people, processes and technology that support them. An asset inventory is an input, but it does not by itself explain what failure would mean for the business.
DORA requires the financial entity to identify the relevant underlying ICT systems, processes and technologies and assess which functions need to be covered. The resulting proposed scope is validated by the relevant authority. A provider cannot approve this scope on the authority’s behalf.
Build a function-to-dependency map
- Name the function and its accountable business owner.
- Explain the operational outcome that must be maintained.
- Trace the systems, identities, processes and teams supporting the function.
- Identify ICT third-party providers, shared services and cross-border dependencies.
- Record boundaries, assumptions and any dependency that could affect the test.
For example, a payment-related function may depend on applications, identity infrastructure, operational procedures and an external service. Testing only the public application would leave the relationship between those dependencies unexplored. This is an illustrative scoping pattern, not a claim about any client environment.
Make exclusions and permissions reviewable
An exclusion should state why it is proposed, what risk or dependency it affects and how it will be considered in the test design. Unexplained exclusions can undermine the realism of the exercise.
Permission to test the financial entity does not automatically authorise activity against a third party. Resolve contracts, provider participation, shared-environment boundaries and points of contact before execution. The financial entity remains responsible for arranging the required participation and coordination.
Connect the scope to the threat
Threat intelligence should help explain which adversaries and paths are credible for the chosen functions. A scenario should have a meaningful objective and a defensible relationship to the entity’s exposure, rather than simply showcase a technique.
Keep a traceable relationship between function, dependency, threat assumption, scenario, risk control and expected evidence. This makes later changes easier to evaluate and helps the closure reports explain what the test did and did not demonstrate.
Plan for controlled change
Production estates and threats change. Establish who can request, review and approve a scope adjustment, and when authority involvement is required. Preserve the rationale and assess operational risk before adapting activity.
A clear initial scope reduces uncertainty; it does not eliminate the need for judgment during the engagement. Use the readiness checklist to organise the first scoping discussion.
Continue your preparation
Primary sources
General information, not legal advice. Confirm the applicable requirements and test arrangements with your relevant authority.
