How do ICT third-party providers take part in DORA testing?
Where an ICT third-party service provider is in scope of a financial entity's testing, the entity must secure that provider's participation, and where including the provider would affect its other customers, a pooled test run by an external tester under the direction of one designated financial entity can share the work. Under Article 26(4) of DORA, the provider and the entity may agree such a pooled test, which then counts as threat-led penetration testing (TLPT) for every participant. For group entities that share ICT systems, Delegated Regulation (EU) 2025/1190 prefers a joint test where it reduces costs and resources, so the same provider may only need to be tested once for several entities.
The financial entity owns its testing programme, its scope decisions and its remediation. The provider contributes access, staff time, environment support and cooperation, and it may also take part in continuity tests, for example by walking through a failure scenario. Ask each critical provider which of its systems, sites and people the entity needs during a test, and confirm these rights in the contract. Article 30(3) requires contracts for services supporting critical or important functions to include participation in the entity's TLPT, so check whether the agreement already covers this and what notice period it sets. Your pooled or joint test plan should name who directs it, who may access which systems, and how findings on the provider's side reach the entity.
Cost and timing depend heavily on the provider contract and on the provider's other customers, since a pooled test must be coordinated across all of them. Confirm the provider's willingness to participate, its scheduling constraints and any fees it charges for participation before you commit to a date. Only an independent tester or auditor can issue a test result or attestation. Under Article 26(7), the authority-issued attestation that a TLPT met the requirements applies only to TLPT, so a provider's participation in a yearly test outside TLPT produces evidence for your own records, not an attestation. An implementation partner can help prepare systems, access arrangements and evidence, but it does not issue reports.
Which testing model fits a shared provider?
Where a critical or important function depends on an ICT third-party service provider, the financial entity must secure that provider's participation in its threat-led penetration test. In this model the entity directs the test, as it would for any TLPT, and the provider takes part directly in the scope, the threat intelligence phase and the testing itself. The entity normally bears the cost of its own test and the provider's contribution, and the contract should say so in writing.
- Direction: the financial entity, with its TLPT testers, keeps control of scope, rules of engagement and reporting.
- Contract terms: the provider's participation duty should appear in the contract, as Article 30(3) expects for services supporting critical or important functions.
- Access: agree in advance which systems, staff and environments the provider will expose to testers.
- Cost: confirm in the quote who pays the provider's time and any additional tester effort.
- Information flow: define how findings about the provider's platform reach the provider and how remediation is tracked.
Before relying on this model, confirm with your provider that it has the capacity and willingness to participate, since the contract clause alone does not guarantee a workable schedule.
Where including a provider in your own test would affect its other customers, the provider and the entity may agree on a pooled TLPT. An external tester runs the test under the direction of one designated financial entity, and that test counts as TLPT for every participating entity under Article 26(4). The model spreads the testing effort across customers, but it puts real coordination weight on the designated entity, which becomes the point of contact for the others.
- Direction: one designated financial entity directs the pooled test, and the external tester works under that direction.
- Contract terms: each participant's agreement should record the designation, the shared scope, the data handling rules and how each entity receives its results.
- Cost: participants should agree on how the external tester's fees are split, and who pays any provider-side costs.
- Governance: agree a decision process for scope changes, incident handling during the test and disputes.
- Result use: confirm that each non-designated entity may rely on the pooled test as its own TLPT and what documentation it will receive.
Ask the provider which other customers are in the pool and whether the designated entity has the authority the others expect.
Where several entities in a group share ICT systems, Delegated Regulation (EU) 2025/1190 Article 16(2) prefers a joint test where it reduces costs and resources. A single test of shared infrastructure can cover all group entities, avoiding repeated testing of the same systems. The group still has to show that each entity's own obligations are met, so the joint test works best when each entity's systems, functions and risk are mapped clearly.
- Direction: the group normally nominates a lead entity or group function to coordinate the test, and the entities agree the responsibilities in writing.
- Contract terms: intra-group service agreements should cover test participation, access rights and cost allocation between entities.
- Scope mapping: list which systems each entity relies on, so that no entity's critical functions fall outside the test.
- Cost: group policies usually allocate costs by entity, service use or revenue, so agree the method before the test starts.
- Evidence: keep entity-level records so that each supervisor can see the test covered that entity's systems.
Confirm with your competent authority how it expects the group to document a joint test before you commit to the model.
How provider failure scenarios enter continuity testing
Article 25 of Delegated Regulation (EU) 2024/1774 requires continuity testing built from the business impact analysis, using severe but plausible scenarios. When a critical or important function depends on an ICT provider, the provider's failure belongs in those scenarios. The cards below set out the scenario types to build, what each one should test, and what evidence shows the result.
Provider insolvency scenario
This scenario assumes the provider stops trading or enters insolvency proceedings with little notice. Test whether the entity can still reach its data, whether an exit plan can be executed within the transition the contract provides, and whether a second provider or in-house capability can take over the function. Check that data export formats, escrow arrangements and contractual access rights work in practice, not only on paper. Evidence is a dated test log showing the data restored or migrated, the time taken, and the gaps found.
Provider service outage scenario
This scenario assumes the provider's platform is unavailable for longer than the recovery time objective set in the business impact analysis. Test the failover to backup regions or alternative services, the manual workarounds for the affected function, and the notice the provider gives under the contract. Confirm that staff know who to call and which fallback procedure applies. Evidence is the recorded outage timeline, the recovery steps performed, and a comparison of actual recovery time against the stated objective.
Provider jurisdictional political risk scenario
This scenario assumes sanctions, export controls, a data localization order or a conflict prevents the provider from delivering service or the entity from using it lawfully. Test whether the entity can move data and workloads out of the affected jurisdiction, whether contracts allow a change of hosting location, and whether subcontractors in that jurisdiction can be replaced. Evidence is a documented decision path, the location of data and processing as recorded in the register, and the result of a tabletop or technical exercise on relocation.
Concentrated subcontractor failure scenario
This scenario assumes a subcontractor or underlying cloud region used by several providers fails at once, which can break the entity's function even when its direct provider remains solvent. Test whether the entity has mapped the chain of subcontractors that support critical functions and whether any single point of dependency exists. Check that the continuity plan names alternatives for shared components. Evidence is the dependency map, the test record showing which functions were affected, and the remediation decisions taken.
Provider unable to support recovery scenario
This scenario assumes the provider remains operational but cannot assist during a major incident, for example because its own staff are overloaded or its ICT systems are compromised. Test whether internal teams can restore the function without provider engineers, whether runbooks and credentials are held by the entity, and whether the contract's participation and cooperation duties are enforceable during a crisis. Evidence is the restoration record run without provider support, plus notes on which dependencies still required the provider.
Verifying a provider's vulnerability handling
Under Article 10(2) of Delegated Regulation (EU) 2024/1774, a financial entity must verify that its ICT third-party service providers handle vulnerabilities properly and report critical ones in a timely way. The word that matters is verify. A contract clause promising patching is a starting point, not evidence. For any provider supporting a critical or important function, the entity should be able to show what the provider reports, how often, and what happened to the last critical vulnerability that touched the service.
The practical request starts in the contract and the due diligence file. Ask for the provider's vulnerability reporting duties in writing: what counts as critical, how quickly the entity is notified, and which channel is used. Then ask for recent evidence: patch records for the components the entity relies on, dated advisories issued to customers, and the provider's own remediation timelines. Where the provider runs software the entity cannot inspect, request a software bill of materials or a library inventory covering third-party and open-source components in the service. The entity then tracks those libraries against published vulnerability sources, as the same article expects for services supporting critical or important functions.
Treat each request as a test. Compare the provider's reported dates with public disclosure dates for a sample of recent vulnerabilities, and check whether the inventory matches what the provider's architecture documentation says it runs. Gaps should go into the entity's ICT third-party risk register with an owner and a follow-up date. Confirm with your legal team which of these rights your current contracts already give you and which need amending, because the entity can only enforce reporting it has contracted for. Your own testing plan should record each verification as evidence for the competent authority.
Who is paid for provider testing, and what recurs
This table compares each party that carries cost when an ICT provider takes part in a DORA test, from the entity's own staff to an independent assessor. Read the second column for who pays and the third for whether the cost is one-time or recurs. No figures are given because none were supplied, so use the last column to know what to request in a quote.
| Cost component | Who is paid or who carries the effort | One-time or recurring, and what to request in a quote |
|---|---|---|
| Financial entity's internal staff | Entity security, risk and continuity teams plan scope, approve the test and coordinate provider participation | Recurring each test cycle. Ask the implementer to state which entity roles the work assumes and hours by role. |
| Provider's participation effort | The ICT provider, under the contract clause that secures its participation, bears its own staff time and any access arrangements | Recurring where the contract requires participation each cycle. Ask whether the provider's effort is included in your quote or must be agreed separately in the contract. |
| External tester in a pooled test | The external tester engaged for a pooled test run under one designated entity's direction, with cost shared or allocated among participants as agreed | Largely recurring per pooled test. Ask how the allocation among participating entities and the provider is calculated and who holds the contract. |
| Implementation partner | A partner such as DeployOpen prepares systems, test environments, logging and evidence packs under a written, fixed scope | One-time for initial setup of evidence and test environments, recurring for retests and updates. Ask for deliverables, assumptions and exclusions in writing. |
| Independent auditor or assessor | Engaged by the organization only if it seeks an independent review. Auditors and assessors issue reports; partners do not | Typically recurring per review cycle. Ask for scope, sampling approach and whether the work covers provider evidence. |
| Provider failure scenario exercises | Entity continuity teams and the provider jointly design and run scenarios, with the provider supplying its contingency information | Recurring per continuity test cycle. Ask who maintains scenario libraries and who pays when a provider change alters the scenario. |
What makes provider testing longer or costlier
Provider participation in a DORA test is set by contract, infrastructure and the provider's other customers long before a tester is engaged. The factors below decide how many parties must be coordinated, how many tests run, and how much evidence has to be gathered. Each one can be negotiated or checked early, which is usually cheaper than resolving it mid-cycle.
Scope of critical providers
The number of ICT third-party providers that support critical or important functions, and the number of services each one delivers, sets how many participation arrangements and test scopes you need. A provider supplying several services to several business lines may need one agreed scope covering all of them. Build an inventory from the register of information before negotiating, and confirm which providers are in scope for each test cycle so that no participation clause is missing when the test starts.
Shared provider infrastructure
When a provider runs the same platform for several financial entities, testing one entity's environment can affect the others. Ask the provider to describe which components are dedicated to you and which are shared, such as tenancy layers, identity services, and network segments. Shared infrastructure is the main reason a pooled test may be considered, and it changes who must agree to the test window, the rules of engagement and the reporting.
Existing contract terms
Participation rights, audit access and testing obligations either already exist in the contract or must be added by amendment. Contracts signed before DORA often lack explicit TLPT participation language, notice periods or rules for threat-led testing. Review each critical contract now for these terms, because a missing clause can stall a test while both parties negotiate. Confirm with counsel whether the amendment or a separate testing addendum is the right vehicle.
Provider's other customers
A provider serving many financial entities has to protect the interests of each of them, so its willingness to take part depends on how a test would affect them. DORA recognizes this through the pooled test option under Article 26(4), where one designated entity directs an external tester on behalf of several participants. Ask early whether the provider will require a pooled arrangement, and who will act as the designated entity, because that choice determines the cost sharing and the coordination load.
Number of group entities
Where several entities in one group use the same ICT systems, a joint test can cover them together, and Delegated Regulation (EU) 2025/1190 prefers that approach where it reduces costs and resources. Each additional legal entity adds its own governance sign-off, scope confirmation and reporting. Agree in advance which entity leads, how costs are split, and which findings each entity receives, so that the group does not run the same provider test several times.
Maturity of provider evidence
Testing goes faster when the provider can produce current evidence of its security controls, vulnerability handling and open-source library tracking. Under Article 10(2) of Delegated Regulation (EU) 2024/1774, entities must verify that providers handle vulnerabilities and report critical ones in a timely way. Where a provider cannot show patch history, vulnerability reports or continuity test results, the entity must fill those gaps through extra testing, which adds time and expert effort. Request this evidence before scoping, not during the test.
How a provider test cycle runs from contract to closure
The sequence moves a provider from scoping and contract terms through a pooled or joint test to a report the financial entity owns and can show its supervisor. Each phase ends with a documented output that the next phase depends on.
Confirm which providers are in scope
The entity's ICT risk and business owners list every ICT third-party provider that supports a critical or important function, then mark which ones would be covered by a threat-led test or by the entity's own resilience testing. The output is a scoping register that names each provider, the function it supports, and the reason it is or is not in scope. Ask the provider to confirm its service map, so the register reflects how the service is actually delivered, including any subcontractors. The step is complete when the compliance lead and the function owner have both signed the register.
Update contracts with participation and access terms
Legal and procurement review each in-scope contract against the Article 30 requirements for services that support critical or important functions, including the provider's duty to take part in the entity's TLPT and the entity's access, inspection and audit rights. Where the contract predates DORA, the entity negotiates an amendment that also covers exit strategies with a transition period. The output is a signed amendment or a documented gap list with an agreed remediation route. The step is complete when the contract clauses reference the test types the entity expects, not only general audit language.
Agree a pooled or joint test model where needed
Where including the provider would affect its other customers, the entity and the provider agree a pooled test under Article 26(4), run by an external tester under the direction of one designated financial entity. Where several group entities share ICT systems, the group prefers a joint test under Delegated Regulation (EU) 2025/1190, which reduces cost and resources. The output is a written agreement that names the directing entity, the participating entities and the tester, and sets out how results are shared. Confirm with the competent authority how the pooled result will be treated for each participant.
Scope the test and designate the directing entity
The participants agree the test scope, the critical functions in view, the threat scenarios and the rules of engagement, including what the provider may and may not be asked to do in its production environment. The directing entity is formally designated in writing, and the provider's named contacts for testing and incident handling are recorded. The output is an approved scope document and a rules of engagement sheet that every participant signs. The step is complete when the provider has confirmed that its own customers' data and services are protected by the agreed boundaries.
Run the test under agreed controls
The external tester runs the test within the approved scope while the provider's security team follows the escalation path set out in the rules of engagement. The directing entity monitors progress and stops activity that goes beyond the agreed boundaries. The output is a log of test activity, a record of any operational impact, and a list of preliminary findings shared with the provider. The step is complete when testing ends and both sides have confirmed the activity log matches what was approved.
Validate findings and remediation with the provider
The tester's findings are reviewed with the provider so that each one is confirmed, disputed with evidence, or accepted as a risk. The provider commits to remediation owners and dates for critical issues, and the entity checks that its own vulnerability handling process covers the provider's reporting obligations under Article 10(2) of Delegated Regulation (EU) 2024/1774. The output is a validated findings list with an agreed remediation plan for each item. The step is complete when the entity has recorded the status of every finding and the provider has accepted its share in writing.
Close with a report the entity owns
The entity, as the party accountable for its own digital operational resilience, prepares the closing report, which summarizes scope, method, findings, validated remediation and residual risk for the management body. The provider reviews the report for factual accuracy before it is finalized. The output is a signed report stored with the entity's testing records and fed into the ICT risk management framework. Where a TLPT attestation applies, the entity should confirm with its competent authority which document it must hold, because only the authority-issued attestation under Article 26(7) is provided for in the Regulation.
Who owns the controls, who prepares the evidence, who attests
The financial entity remains accountable for its digital operational resilience testing programme, including every test that touches an ICT provider. The management body approves the testing approach, the entity decides which providers are in scope, and the entity signs off on remediation of findings. Under the contract, the entity must secure the provider's participation wherever a provider supports its ICT services, so the obligation to arrange participation sits with the entity even when the provider performs the work.
- Scope decisions: Deciding which provider services support critical or important functions and therefore need provider participation in testing.
- Contract terms: Writing testing, access and cooperation rights into provider agreements before testing starts.
- Test ownership: Setting objectives, approving scenarios and deciding when a pooled test is directed by one designated entity.
- Remediation: Owning the fix plan, deadlines and board reporting for issues found in provider services.
- Evidence file: Keeping the test reports, provider correspondence and remediation records that a supervisor may request.
Before testing, check that the contract gives the entity the participation, access and audit rights the testing plan assumes.
The ICT provider owns the security of its own platform and the controls it operates on the entity's behalf. Under the entity's contract, the provider takes part in the entity's testing, makes its environments and people available within agreed limits, and handles vulnerabilities in its services in a timely way. Where a provider serves many customers, it may prefer a pooled test instead of separate tests for each client, which needs its agreement and a single designated entity to direct the work.
- Participation: Making systems, staff and runbooks available for scenario-based and continuity tests.
- Vulnerability handling: Triaging, fixing and reporting critical vulnerabilities in the services the entity depends on.
- Pooled testing: Agreeing with other customers on a shared test run when individual participation would affect them.
- Continuity support: Taking part in failure scenarios, including insolvency, outage and jurisdictional risk, where these apply.
- Open-source components: Tracking third-party and open-source libraries used in services that support critical functions.
Confirm in writing which provider controls the entity may test directly and which must be verified through the provider's own assurance evidence.
An implementation partner such as DeployOpen works on the entity's side of the boundary. Typical work includes preparing a self-hosted platform, configuring logging and access controls, building a test environment that mirrors production, supporting continuity test setup and collecting the evidence that the entity and its tester will review. The partner does not issue test reports, attestations or certifications, and it does not decide whether a provider or the entity meets DORA. Those judgments belong to the entity, its tester and, where applicable, the competent authority.
- Test preparation: Building test environments, accounts and data handling rules that the independent tester can use.
- Evidence preparation: Configuring logs, inventories and change records so the entity can show what was tested and when.
- Remediation support: Implementing fixes in the self-hosted stack and documenting each change.
- Continuity setup: Documenting failover steps and recovery paths for scenarios the entity selects.
- Fixed scope: Agreeing in writing which preparation tasks are included, with deliverables and timelines set before work begins.
Ask any partner to state in writing that it prepares evidence but does not attest to it.
Independent testers carry out the testing itself, and the competent authority supervises whether the entity meets DORA. The independence requirement means the tester should not be the team that built or operates the system under test, and the tester writes its own findings. For threat-led penetration testing, the regime under Article 26 uses an external tester under defined requirements, and the only authority-issued attestation DORA provides for is confirmation that a TLPT met its requirements. Outside that case, supervisors review evidence during inspections rather than issuing certificates.
- Independent testing: Running the attacks, scenario exercises or reviews and documenting results without editing them to suit the entity.
- Tester requirements: Confirming testers meet the qualification and independence rules in the applicable technical standards.
- Pooled test direction: Where a pooled TLPT is used, one designated entity directs the external tester on behalf of all participants.
- Authority role: Supervising compliance under Chapter VII, with powers to request records and evidence.
- No DORA certificate: Recognising that DORA itself sets no certification scheme for ordinary compliance.
Before engaging a tester, confirm its independence from the systems under test and whether any attestation you need is one the Regulation actually provides for.
Where provider testing usually stalls
Most delays in provider testing start long before a test window opens, in contracts, inventories and roles that were never agreed. The five pitfalls below are the ones that most often block participation or leave an entity unable to show its testing was complete. Each card names the check that prevents it.
Contracts without participation clauses
If a contract with an ICT provider supporting critical or important functions does not oblige the provider to take part in the entity's threat-led penetration test, the entity has little leverage when a test is scheduled. Article 30(3) expects services supporting critical or important functions to carry participation in the entity's TLPT, along with access and audit rights. Check every such contract, including renewals and framework agreements, for explicit wording on test participation, cooperation timelines and who bears the provider's cost.
Late discovery of blocked participation
A provider may agree to join a test and then find that its other customers would be affected, because the same platform or infrastructure is shared. Discovering this during the test preparation phase can push the schedule back and leave the entity without a valid test. Ask providers early whether shared infrastructure would be touched, and if so, agree in advance on a pooled test under Article 26(4) so the workaround is ready before the timetable is fixed.
Missing inventory of provider services
Entities often cannot say which provider services support which critical or important functions, which makes it impossible to decide which providers must take part in testing. The asset and service inventory should map each provider service to the systems, data and functions it touches, including subcontractors and open-source components inside the provider's stack. Reconcile this inventory against the register of information before scoping any test, and confirm it with the provider in writing.
Unclear directing entity in pooled tests
A pooled test is run by an external tester under the direction of one designated financial entity, and that entity's test counts as TLPT for every participant. When the designation is vague, participants disagree on scope, reporting and who signs off findings, and the result may not satisfy each entity's own obligations. Put the designation, the decision rights over scope and the owner of the final report into a written agreement before the test starts.
No vulnerability reporting duty
Article 10(2) of Delegated Regulation (EU) 2024/1774 requires entities to verify that providers handle vulnerabilities and report critical ones in a timely way. If the contract says nothing about this, the entity has no basis for demanding patch timelines or disclosure when a test or a live incident exposes a weakness in the provider's platform. Add a duty to report critical vulnerabilities within a defined period, to share remediation status and to notify the entity of open-source libraries affecting the service.
Questions buyers ask about provider testing under DORA
Do ICT third-party providers have to take part in every test under DORA?
No. Where ICT third-party service providers are in scope of a test, the financial entity must secure their participation, but that duty sits within the threat-led penetration testing (TLPT) and continuity testing context rather than applying to every routine test. For services supporting critical or important functions, the contract should provide for participation in the entity's TLPT. Routine security testing of systems you control may not need the provider at all. Confirm with your competent authority and your legal team which tests in your programme require provider involvement, and write those duties into contracts before the tests are scheduled.
Who pays for a pooled TLPT when several institutions share one provider?
The cost is shared among participants, but the contract must say how. Under Article 26(4), a provider and the entity may agree on a pooled test run by an external tester under the direction of one designated financial entity, and that pooled test counts as TLPT for all participants. The designated entity usually coordinates the tester, scope and reporting, and the other participants pay their share of tester fees, provider effort and internal time. Ask for a written allocation of costs, a statement of what each participant receives, and who signs off the scope. Fees depend on scope, system count and tester time, so request a written quote for each participant.
Can our team run the provider testing in-house instead of buying outside help?
Partly, depending on what the test requires. Your team can prepare scope, collect the provider evidence, run basic security testing of systems you control, and manage the contract obligations. A TLPT, however, must be carried out by testers who meet the requirements of the TLPT regulatory technical standard, and the test must be directed as the regulation requires. Testing a provider's platform may also need the provider's written consent and rules of engagement. External help is most often used for scoping, tester selection, technical testing and remediation support. An implementation partner such as DeployOpen can prepare systems, controls and evidence and run security testing, but it does not issue reports or attestations.
How long does a provider testing cycle take?
The duration depends on scope, the number of providers and systems involved, and how quickly the provider can respond to requests. No fixed figure applies. A cycle typically includes agreeing scope and rules of engagement with each provider, preparing the testing environment, running the tests, reporting, and remediation. Provider consent and pooled coordination often take the longest, so start those conversations early. Ask any partner for a written timeline tied to the agreed scope and dependencies, and confirm the provider's notice periods and change windows before committing dates.
What must an ICT provider supply to support our testing?
At minimum, the provider should supply its service description, architecture and data flow documentation for the services you use, its vulnerability handling process, and a timely channel for reporting critical vulnerabilities. Under Article 10(2) of Delegated Regulation (EU) 2024/1774, you must verify that providers handle vulnerabilities and report critical ones in a timely way, so ask for evidence of that process. Contracts for services supporting critical or important functions also cover participation in your TLPT, unrestricted access and audit rights, business continuity arrangements, and an exit strategy. Confirm each item in the contract and request the evidence before testing starts.
Does a DeployOpen engagement give us a DORA attestation?
No. DeployOpen plans, implements and supports self-hosted open-source platforms, runs security testing, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Under DORA, the only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements of Article 26(7), and that is issued by the competent authority after an approved test. Independent testers and your supervisory authority decide whether your testing meets the requirements. Ask any partner to state in writing what it delivers and what remains your responsibility.
Primary sources for DORA testing and provider duties
Start with the Regulation itself. The DORA text on EUR-Lex is the authoritative source for provider duties in this topic. Article 30(3) sets the contract terms for services supporting critical or important functions, including participation in your TLPT and unrestricted access and audit rights, and Article 26(4) governs the pooled test option. Delegated Regulation (EU) 2024/1774 is the second document to pull. Its Article 10(2) requires you to verify that providers handle vulnerabilities and report critical ones in a timely way, and its Article 25 sets continuity testing scenarios that include provider insolvency, failure and political risk in the provider's jurisdiction. Confirm the current consolidated text on EUR-Lex before you cite article numbers in contracts or test plans.
Delegated Regulation (EU) 2025/1190 holds the TLPT technical standards you need when a provider must join your test or a pooled test is proposed. Review its provisions on scope, testers and results handling with legal counsel and your provider's contract owner, because they determine who directs the test and who sees the findings. Check also whether group entities that share ICT systems can run one joint test, since Article 16(2) prefers that route where it reduces cost and resources. The Delegated Regulation 2025/1190 on EUR-Lex is the document to bookmark for this work.
The ECB's TIBER-EU framework page is the practical companion for designing a threat-led test that involves providers. Its preparation, testing and closure phases show where provider consent, scope agreements and test control arrangements must be settled before any red team begins. Ask each provider early which of its systems, staff and sites fall within scope, who acts as its point of contact, and how it will handle findings about its own platform. Confirm with your competent authority how the attestation under Article 26(7) is obtained, because the framework guides the test but the attestation is issued by the authority.
How DeployOpen works on this
DeployOpen helps financial entities prepare their self-hosted open-source platforms and the evidence that shows how provider testing was set up and run. The organization keeps ownership of its testing programme, its provider contracts and its conclusions, while DeployOpen prepares systems, test environments and documentation inside the client's own infrastructure.
How we scope
- Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which ICT providers, platforms and services are covered by each provider test or continuity scenario.
- We confirm with the client which provider participation clauses, pooled test arrangements or joint group tests apply to each system.
How we build
- We prepare test environments and access arrangements in the client's own cloud accounts, data centers or air-gapped networks.
- We configure logging and records so that each provider test, failover exercise and vulnerability notification can be traced.
- We document provider failure scenarios and the dependencies of self-hosted platforms so the continuity tests reflect real service chains.
How we hand over
- We deliver test plans, scenario records, results and remediation tracking in formats the client's teams and assessors can review.
- We document how provider vulnerability reports were requested, received and verified, with dates and owners recorded.
- The client owns the controls and conclusions, and an independent assessor or competent authority reviews the evidence.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- We can repeat provider failure scenarios and vulnerability verification as platforms, providers or contracts change.
- Quotes follow from the written scope, so we recommend asking for a quote that lists each deliverable and its recurring elements.
