DORA TLPT Scope: Map Critical Functions Before Assets

The decision this guide helps you make

Begin with the function that must remain resilient, then trace its people, processes, systems and external dependencies. Record proposed coverage and exclusions with their rationale. The relevant authority validates the proposed scope; a supplier cannot approve it on the authority’s behalf.

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.

Use technical assessments to improve the dependency map

A critical function can depend on identities and background services that are easy to miss in a business-level diagram. Ask application and infrastructure owners which principals move data, approve transactions, publish releases or restore service. Record the owner and permission boundary for each material handoff. The map should explain why a dependency matters to the function, rather than simply increasing the number of systems in scope.

The bank privileged access guide separates identity, reach and authority. The fintech workload identity guide extends that reasoning to deployment and runtime services. Both can inform technical preparation; neither determines the authority-validated TLPT scope.

Maintain a decision record for difficult boundaries

For a shared platform or sensitive dependency, record the proposed treatment, operational risk, permission owner and evidence limitation. State whether the dependency is included, requires coordinated participation or remains unresolved. Avoid reducing the decision to a colour on a diagram. The rationale needs to survive changes in personnel and allow the test managers and control team to understand what the proposed exercise can demonstrate.

When the scope changes, preserve the earlier decision and explain the new information. Identify affected scenarios, safety controls and provider responsibilities, then follow the applicable approval process before adapting execution. At closure, use the same map to show where observations were obtained and where uncertainty remains. That continuity makes the scope a working governance artefact throughout the engagement, rather than a document signed once and forgotten.

Continue your preparation

• The testing methodology
• ICT third parties and TLPT