DORA TLPT Third Parties: Permissions & Pooled Testing

The decision this guide helps you make

A service contract does not necessarily authorise offensive testing of a provider’s infrastructure. Identify relevant ICT dependencies and resolve participation, permissions and shared-environment constraints early. Keep the financial entity’s responsibilities visible when assessing any pooled-testing arrangement.

A critical function rarely ends at the entity’s boundary

Financial entities rely on ICT third-party providers for functions that may be included in a TLPT. DORA addresses this involvement and requires arrangements for relevant participation. Outsourcing a dependency does not remove the financial entity’s responsibility.

Scoping needs to distinguish the function being tested, the systems supporting it and the legal permissions required to test those systems. A contract for using a service is not necessarily authorisation to conduct offensive testing against it.

Identify the dependency before selecting scenarios

Document what the provider supports, which systems or processes could be involved, and whether the service is shared with other customers. Establish the contractual and operational contact routes early.

A scenario may depend on identity services, hosting, communications or an outsourced operational process. If the engagement assumes participation that has not been agreed, its schedule and evidential value can both suffer.

Agree participation and operational safeguards

• Identify the relevant provider and any material subcontracting dependency.
• Obtain the permissions and contractual arrangements required for the proposed activity.
• Clarify tenant boundaries, prohibited actions and effects on other customers.
• Set escalation routes, stop conditions and incident coordination.
• Agree evidence handling, access, confidentiality and report distribution.

Do not expose unrelated customers to the exercise or treat the provider’s entire platform as automatically in scope. The control team, provider and authority process need a shared understanding of boundaries.

When pooled testing may be relevant

DORA provides for pooled testing arrangements in the circumstances described in Article 26, including where participation in a test could affect service quality or security for other customers or confidentiality. Such arrangements need to follow the applicable conditions and oversight process.

A generic vendor penetration-test report is not automatically a pooled TLPT or a substitute for an entity’s obligations. Determine what functions, participants and risks the proposed arrangement actually covers, and how recognition will be handled.

Bring the issue into the first brief

Tell potential testing providers which ICT dependencies are likely to be material and which participation arrangements are already in place. Show unresolved approvals as dependencies, not as hidden exclusions.

The strongest next step is often a better map and an agreed contact route. Detailed scenarios can then be developed around a scope that is both meaningful and authorised.

Prepare a dependency-specific participation brief

Describe the function supported by the provider, the relevant service boundary, proposed participation and expected evidence. Identify the contacts who can discuss technical scope, contractual permission and operational safeguards. A broad request to “support our TLPT” leaves too much to interpretation. Distinguish activity against the entity's own service configuration from activity affecting a shared platform or another customer's environment.

The fintech cloud identity guide helps articulate a narrow principal-resource-operation comparison. The bank procurement scope guide shows how to preserve missing permissions as visible assumptions. These are useful preparation methods within the wider TLPT coordination process.

Agree how provider evidence enters closure

Determine which observations the provider can supply, who may access them and how they will be correlated with the exercise timeline. Record any limits imposed by shared infrastructure, confidentiality or retention. Evidence supplied by a provider should be identified as such, with the relevant context and limitations, rather than presented as an action independently observed by the testing team.

If participation or a proposed method cannot be agreed, escalate the dependency through the applicable governance process. Do not silently omit it while retaining a broad claim about the covered function. Preserve the reason, impact on scenarios and any approved alternative. This gives test managers and the entity a clear basis for deciding how the boundary should be treated and prevents a commercial assumption from becoming an undocumented testing permission.

Continue your preparation

• Scoping a TLPT
• Procurement questions