TIBER-EU for ICT third-party providers: scope and contracts

Does a TIBER-EU test reach our ICT provider's systems?

Provider systems are in scope when they support in-scope critical or important functions, and the customer must secure the provider's participation. If your financial entity relies on a cloud, outsourcing or intra-group ICT provider for a function that the test covers, the provider's infrastructure, processes and people supporting that function should be considered for inclusion. Where the provider's involvement is needed, the entity settles it during the preparation phase, for example by seating a provider representative on the control team. Where a provider's participation could harm its other customers or their data, a pooled test directed by one designated entity can be used instead, and the provider may contract directly with an external tester for it.

The answer varies by service, by contract and by whether a pooled test is used. A provider supporting a narrow function may appear in one scenario only, while a provider running shared platforms for several entities may need a multi-party test. Where a multi-party test involves a provider, at least one selected scenario should cover the provider's systems, processes and technologies that support the entities' critical or important functions. The tested entity owns the test and its decisions, while the provider prepares its own systems, evidence and staff. Ask your provider now whether its contracts allow testing on its infrastructure, and check whether existing clauses cover unrestricted access, inspection and audit rights for the entity and the competent authority, since the framework recommends adding such clauses to future contracts where they are missing.

How cloud, outsourcing and intra-group providers differ

Cloud and hosting providers usually supply infrastructure the entity configures itself, such as virtual machines, managed databases, identity services, networking and storage. The entity controls its own configurations and data, but the physical facilities, hypervisors and shared control planes sit with the provider. That split is what makes scoping harder, because a red team scenario can reach a critical function through a component the entity does not operate directly.

Typical in-scope components: tenant configurations, identity and access services, virtual networks, managed databases and the management plane used to administer the entity's resources.
Likely control team role: usually a named technical contact who explains the provider's shared responsibility boundaries and can confirm what logs and alerts the provider exposes to the customer.
Scoping questions for preparation: whether the provider's shared control plane is in scope, whether the provider accepts testing against its infrastructure, and how tests will avoid affecting other tenants.
Contract check: confirm whether the agreement allows testing on the provider's infrastructure and whether it names an approach for pooled tests if other customers would be affected.

Confirm these points with your provider's contract team and account manager before the authority's notification, since provider terms often take longer to agree than the internal approvals do.

Which contract clauses a TIBER-EU test requires

When a provider supports critical or important functions, the customer's contracts decide whether a threat-led test can reach the provider's systems and people. The cards below set out the clauses Article 30(3) expects, the testing access the framework recommends, and how to fold these terms into existing agreements. Confirm final wording with counsel before signing.

Precise service level targets

For services supporting critical or important functions, the contract must set precise service level targets, not general commitments to good service. Check that each target is measurable, has a reporting cadence and states the remedy when it is missed. A threat-led test can only show whether recovery and detection hold up if the targets it is measured against are written down.

Tested business contingency plans

The provider must implement and test business contingency plans for the service. Ask for the date of the last test, the scenarios covered and the recovery results, and confirm the plan names the customer's critical functions it protects. Contingency plans that exist only on paper will not hold up when a red team targets the provider's dependencies.

Full participation in the customer's TLPT

The contract should oblige the provider to take part fully in the customer's threat-led test. That covers joining control team discussions where the provider's systems are in scope, supplying staff and logs, and accepting test activity against its environment. Agree the named contacts and response times in advance so that participation does not depend on who happens to be available.

Access, inspection and audit rights

The customer, its appointed third parties and the competent authority must each receive unrestricted access, inspection and audit rights over the service. Check that these rights extend to premises, systems, documentation and personnel, and that they are not limited to annual reviews. Without them, a regulator's request to inspect the provider cannot be met in practice.

Testing on the supplier's infrastructure

Where part of the customer's ICT infrastructure is run by a supplier, the framework recommends that service contracts allow testing on that supplier's infrastructure. Confirm that the clause covers red team activity, not only vulnerability scans, and that it sets rules for notice, safe-stop conditions and who can halt the test. Pooled tests rely on the same clause to include several customers.

Reviewing existing contracts at renewal

Most providers already hold contracts without these terms. Start with an inventory of every agreement that supports a critical or important function, then mark which clauses are missing. Where the contract is not up for renewal, ask counsel whether an amendment or a side letter can add the terms, and add the clauses to any new or renewed contract as a standard requirement.

Pooled tests when provider participation affects other customers

Some providers cannot simply join a customer's threat-led test. If a provider's participation could harm its other customers or their data, DORA Article 26(4) lets the provider contract directly with an external tester for a pooled test that covers several financial entities, directed by one designated entity. For a provider, this is the route that protects shared infrastructure while still putting its services under threat-led testing. Before the customers' preparation phases begin, the provider and its customers should agree in writing who the designated entity is, how the pooled scope is drawn, and how each customer's control team will be involved. Ask the provider to show, in writing, what testing on shared platforms could disrupt for other tenants, since that analysis drives whether a pooled test is needed.

The TIBER-EU multi-party principles set the limits for any such test. The entities in one test must rely on common ICT systems in substance, so a pooled test on a provider's shared platform fits the rules only where the customers genuinely depend on the same systems. The number of parties should be kept small, with one control team leading. Each entity's control team still conducts its own risk assessment, while the lead control team assesses the joint aspects, and the same threat intelligence provider and red team testers serve the whole test. Scenarios, active testing duration and provider resources must be proportionate to the number of entities. Customers should check that the proposed scenarios on the provider's infrastructure actually reflect their own critical or important functions, not only the provider's general estate.

Cross-border cases add a further layer. Under Article 16, authorities in host member states have 20 working days from being informed to follow a cross-border test as observers or to assign a test manager. The framework prefers joint testing where entities share ICT systems or an intra-group provider, because one shared test can reduce duplicated effort and cost. Confirm with each relevant authority which of these roles it intends to take, and confirm the cost arrangements for joint testing with the lead entity, since the cost split depends on the national rules and the contracts in place. A pooled test does not remove any customer's obligations, so each entity should keep its own records of its participation and its own remediation plan.

What happens when provider staff detect the red team

When staff at the tested entity or at an ICT provider spot the red team, the framework routes the response through the control team, the test manager and, only in exceptional cases, the control team lead, so the test keeps producing useful evidence without being exposed to the wider organization. The sequence ends either with the test continuing as normal or as a limited purple teaming exercise.

Detection is reported to the control team
Detection can come from staff at the tested entity or from staff at an ICT third-party provider whose infrastructure or processes are in scope. The person or team that notices the activity raises it through the channel agreed in the preparation phase, and the control team records what was seen, where, and when. Provider staff need to know this route in advance, so the contract and the initiation documents should name who they contact. The step is complete when the control team has a logged account of the detection that it can act on.
Control team assesses whether the test is compromised
The control team checks whether the detection exposes the red team, the flags or the scenario, and whether the activity could affect live services at the provider or at its other customers. It compares the detected activity with the red team's documented actions so it can separate test traffic from unrelated incidents. Responses that could harm other customers or their data are a provider concern that the control team must weigh before any next step. The step closes with a written assessment that states whether the test can carry on unchanged.
Control team proposes measures to continue
If the test can continue, the control team proposes measures that let the red team keep working while the detection is handled. These might include adjusting how the team's activity is labelled to staff, or agreeing a way for the provider's responders to confirm test activity without revealing the test to the wider team. Any proposal that touches provider systems needs the provider's agreement, since the provider must participate fully in the test. The output is a written proposal that names the measures, the people who will apply them and the systems they affect.
Test manager validates the proposal and keeps the test secret
The test manager at the authority reviews the control team's proposal and decides whether it keeps the test secret and preserves its validity. The test manager's sign-off is needed before the measures take effect, and the control team must not change the approach on its own authority. Keeping the test secret means the proposal should not expose the red team to people outside the agreed circle. The step is complete when the test manager has approved the measures in writing and the control team has recorded that approval.
Control team lead may suspend the test
In exceptional circumstances, the control team lead can suspend the test, but only after consulting the test manager. Suspension is the response when the detection cannot be handled without risk to live services, to the provider's other customers or to the test's integrity. The lead records the reason, the consultation and the expected conditions for resuming. Pausing the test does not end it, and the control team should confirm with the provider how any suspended activity is contained. The step closes with a suspension record or a decision to continue.
Test continues as a limited purple teaming exercise
As a last resort, testing may continue as a limited purple teaming exercise rather than as covert red team activity. In this mode the red team and the blue team work together on the detected activity, and the exercise counts toward the period of active testing. The control team and test manager agree the limits of the exercise in advance, and provider staff take part only in the parts that touch their systems. The output is a documented change of mode, with the agreed limits and the time it covers.
Detection is recorded for the closure phase
Every detection, decision and change of mode is written into the record that feeds the closure phase, including the blue team test report, the red team test report and the replay. The record shows how provider staff detected the activity, how quickly it reached the control team and what the response cost the provider's operations. Organizations preparing for a test can use this record to check their provider's detection and escalation routes before the next test. The step is complete when the detection record is part of the closure documentation.

What providers should prepare before a customer's test

A customer's TIBER-EU or DORA threat-led test can reach into a provider's infrastructure, staff and processes when those support the customer's critical or important functions. The cards below cover what a provider should have in place before the customer's preparation phase begins, so that its participation is settled early and its own controls and evidence hold up under test.

Named control team representative

Where a provider's involvement is agreed in the preparation phase, the provider should name a representative who can sit on the customer's control team and speak for the provider's systems, processes and people. This person needs authority to approve provider-side actions and enough technical knowledge to explain how services are run. Confirm the name, deputy and decision rights in writing before the scoping discussions start.

Mapped service boundaries and components

Providers should maintain a current map of which infrastructure, applications, networks, data stores and staff support each customer's critical or important functions. The map should show where a customer's scope ends and the provider's shared platform begins, since a red team scenario can cross that line. Ask the customer which of these components it expects to be included in the scope specification document.

Tested contingency plans

The service level targets and business contingency plans a provider has committed to for critical or important functions should be tested, not only written. A test scenario that disrupts provider systems may trigger a failover or recovery, so the provider should know which steps it would run, who decides and how the customer is informed. Record the results of each exercise so they can be shown to the customer and, where needed, the authority.

Logging and detection coverage

Provider staff and tooling are a common source of detection during a test, so the provider should confirm that logs from its hosts, identity systems, network devices and security tools are collected, retained and searchable. Gaps in these sources make it harder to explain what was detected and why. Review alert routing and check that the people who triage alerts know a sanctioned test may be running without being told the details.

Access, inspection and audit procedures

For services supporting critical or important functions, the customer, its appointed third parties and the competent authority need unrestricted access, inspection and audit rights. Providers should document the procedure for granting access to systems and premises, including who approves it, how it is logged and how sensitive data is protected during the test. Confirm that these procedures match what the contract already allows.

Internal escalation for suspected red team activity

If provider staff detect activity that may be the red team, they need a short, rehearsed path to report it without alerting the test team by accident. Under the framework, the control team proposes measures to continue while the test stays secret, and the test manager validates them. Provider staff should know who to call, what to preserve and when to stop their own response. Practice this path with the on-call team before the test window opens.

What tested entities should verify with their providers

Before any notification arrives, the tested entity should know which provider services support critical or important functions, because those are the services that can bring a provider into scope. Start with an inventory that maps each ICT third-party service to the function it supports, including intragroup providers and any cloud or outsourcing arrangement where infrastructure, processes or staff sit outside the entity's own perimeter. For each mapped service, record the contract owner, the renewal or expiry date, and whether the contract already contains clauses that allow testing on the supplier's infrastructure. The framework recommends that these clauses exist in current contracts or are added to future ones, so a renewal date that falls inside the test window is a planning risk worth recording now.

Next, check the contract terms against what a test will ask of the provider. Look for service level targets, business contingency testing obligations, full participation in the customer's threat-led test, and access, inspection and audit rights for the customer and the competent authority. Where the provider serves other customers, confirm whether its participation could affect them, since that determines whether a pooled test directed by one designated entity is the more practical route. Then confirm in writing that the provider is willing to take part, and who its named representative would be, since its involvement, such as a seat on the control team, is settled during preparation. Agree roles early: who speaks for the provider, who approves access to its systems, and who receives its evidence.

Finally, confirm the rules of your own authority before relying on any general reading. TIBER-DE, aimed mainly at banks, insurers, financial market infrastructures and their key service providers, and the TIBER-IT National Guide, which covers ICT service providers where they are included in scope, both address this topic in their own terms. Ask your authority or test manager whether it expects provider systems in scope, how it treats pooled tests, and what documentation it wants on provider participation. Because national documents can add to the European framework, the answers you receive, not a summary, should set the provider plan.

Questions providers and tested entities ask about TIBER-EU scope

Does a cloud provider have to take part in a TIBER-EU or DORA threat-led test?

Not automatically, but it often has to if its services support critical or important functions at a tested entity. The framework expects the entity to consider provider infrastructure, processes and people that support those functions, and the provider's role is settled during the preparation phase. Whether a given cloud service falls in scope depends on how the customer uses it, so the tested entity and its test manager at the authority decide the boundary, and the provider should ask to see the written scope specification before work starts.

What is a pooled threat-led test for an ICT provider?

A pooled test is one threat-led test covering several financial entities that all rely on the same provider, directed by one designated entity. Under DORA, a provider can contract directly with an external tester for a pooled test when its participation in an individual test could harm other customers or their data. In a multi-party test, the entities must rely on common ICT systems in substance, the parties should be limited, and one control team leads. Providers should confirm with their customers which entity leads and how the results are shared.

Can an ICT provider refuse to take part in a customer's test?

A provider cannot simply opt out of a customer's test when the services support critical or important functions, because the customer must secure its participation. The practical route is to raise a concern before the test, such as risk to other customers or their data, and move to a pooled test where the rules allow it. Providers should review their contracts now, because the strongest terms in the framework apply to services supporting critical or important functions and are easier to negotiate before a test is announced.

What does Article 30(3) of DORA require from a provider?

Article 30(3) sets contractual terms for ICT services that support critical or important functions. The provider must accept precise service level targets, implement and test business contingency plans, participate fully in the customer's threat-led test, and grant unrestricted access, inspection and audit rights to the customer, appointed third parties and the competent authority. Legal and procurement teams should read the article directly in the EUR-Lex text of DORA, and check each clause against the provider's current master agreement and any sub-outsourcing terms.

Can a provider run its own threat-led red team test?

A provider can test its own environment with its own staff for its own purposes, but a test that counts toward a TIBER-EU or DORA threat-led test must follow the framework, including an independent threat intelligence provider and external red team testers and oversight by the test manager. Internal testers may take part under the rules on their independence and roles, which are set out in the framework and national documents. Providers should confirm with the authority which internal work will be accepted and how it is recorded.

How is the cost of a provider's participation shared?

Costs usually follow the work each party does. The tested entity pays for its own control team, its providers for threat intelligence and red teaming, and any remediation it owns. A provider's staff time, infrastructure access and cooperation during the test are costs the provider carries unless the contract says otherwise, and some national programmes charge fees to the entity. Cost rises with the number of systems in scope, the number of entities in a pooled test and the length of active testing. Ask the tested entity for a written breakdown of who pays for what before agreeing terms.

Who issues the attestation at the end of a TIBER-EU test?

The attestation is issued by the authority or its test manager at the end of the closure phase, not by the provider or any consultant. A TIBER-EU test does not produce a pass or fail result. The attestation confirms that the test was carried out under the framework, and the test summary report and remediation plan describe strengths and weaknesses. Providers should ask the tested entity for a copy of the attestation and the relevant parts of the remediation plan, which may affect their own obligations.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside a client's own infrastructure, and it prepares systems and evidence for compliance assessments. For ICT third-party service providers, the work centers on defining which provider systems, processes and people fall within a test, preparing them so the tested customer and the provider can meet their obligations, and documenting what was done. DeployOpen does not run the test, issue reports or attest to results; the authority, the tested entity and independent testers keep those roles.

How we scope

Written scope defines which provider platforms, environments and support processes are covered for each customer.
We map the provider's services to the customer's critical or important functions so the scope matches what customers need tested.
Scope documents record provider contract clauses, access rights and participation terms that must be agreed before work starts.

How we build

We configure self-hosted platforms with logging, detection and access controls that let provider staff recognize and report test activity.
We document provider runbooks for incident escalation, backup and contingency procedures that a tested customer will ask to review.
We prepare test-ready environments and evidence folders so provider controls can be shown to the control team and an independent assessor.

How we hand over

Handover packs include configuration records, architecture diagrams, control mappings and the evidence index for each provider system.
Each deliverable is reviewed with the provider's named owners, and open gaps are recorded with agreed remediation owners.
Documentation is delivered in formats the customer's control team and the independent assessor can review directly.

How we support

Fixed-scope engagements have agreed deliverables and timelines set in writing before work begins, and a quote follows from that scope.
Ongoing support, upgrades and continuous testing are available as retainers for providers that expect repeated tests.
Ask any implementation partner to confirm in writing which parts of the provider's participation remain the provider's own responsibility.

TIBER-EU for ICT third-party service providers