Most of what DORA asks of a software vendor is paperwork: clauses, registers, reports. Threat-led penetration testing is the part that is not. Article 26 of Regulation (EU) 2022/2554 makes the financial entities its authorities identify run a threat-led penetration test, TLPT, at least every 3 years, on live production systems supporting critical or important functions, and paragraph 2 says the scope includes the systems supporting those functions that have been outsourced or contracted to ICT third-party service providers. If your product supports such a function at a bank that has been identified, a red team hired by the bank may spend three months attacking your production environment while your operations staff are not told. Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025, published on 18 June 2025 and in force since 8 July 2025, specifies how, in seventeen articles and eight annexes. This article reads Articles 26 and 27 of DORA and the Delegated Regulation from the Official Journal on CELLAR on 12 September 2026, from the vendor's side. It is not legal advice.
Who gets tested, and why your customer might be one of them
Not every financial entity runs a TLPT. Article 26(8) of DORA has the competent authorities identify the entities required to, on impact-related factors, financial stability concerns and the entity's ICT risk profile, and Article 2 of the Delegated Regulation lists the criteria: size, interconnectedness, the criticality and substitutability of the services the entity provides, the complexity of its business model, whether it is part of a systemic group, and on the ICT side its risk profile, threat landscape, the degree of dependence of its critical or important functions on ICT, the complexity of its architecture, and, point (b)(v), the ICT services and functions supported by ICT third-party service providers and the quantity and type of contractual arrangements with them. Microenterprises and the small entities of Article 16(1) are excluded. So the customers that reach you with a TLPT are the large ones, and the number of vendors they depend on is one of the reasons they were chosen.
What the contract already says
Point (d) of Article 30(3) of DORA requires every contract for a service supporting a critical or important function to contain the vendor's obligation to participate and fully cooperate in the customer's TLPT under Articles 26 and 27. It is one of the six clauses of the Article 30 checklist for critical or important functions, and it is not negotiable in principle, only in mechanics. Article 26(3) adds that where providers are included in the scope, the entity takes the measures and safeguards needed to ensure their participation and stays fully responsible, and Article 26(5) requires the entity, with the cooperation of its providers and the testers, to apply risk management controls against impact on data, damage to assets and disruption of critical or important functions, at the entity, its counterparts and the financial sector.
The mechanics: the control team, the blue team and the 12 weeks
The Delegated Regulation defines the roles. The control team, Article 1(1), is the staff of the tested entity and, where relevant to the scope, staff of its third-party service providers, who manage the test; the blue team, Article 1(3), is the entity's and, where relevant, its providers' staff who defend the systems and who are not aware of the TLPT. Article 4 requires the entity's organisational arrangements to ensure that the control team is informed of any detection of the test by staff of the entity or of its providers. So a vendor in scope has people on both sides: one or two who know, inside the control team, and an operations team that must not.
Article 9 sets the preparation phase: the entity submits initiation information within 3 months of the authority's notification and a scope specification within 6 months, approved by its management body, and the control team selects the threat intelligence provider and the testers. Article 10 is the threat intelligence phase, producing a targeted threat intelligence report on the entity and its scope. Article 11 is the red team test: an active red team phase proportionate to the scope and to the number of entities and providers involved, and in any case at least 12 weeks. If any staff member of the entity or of its providers detects the testing, the control team proposes measures to continue while keeping it secret. Under exceptional circumstances that risk data, assets or the disruption of critical or important functions of the entity or of its providers, the control team lead may suspend the test or, as a last resort and with the authority's validation, continue it as a limited purple teaming exercise.
Article 12 is the closure: the blue team is told; the testers deliver a red team report within 4 weeks; the blue team delivers its report within 10 weeks; within the same 10 weeks both replay the offensive and defensive actions and run a purple teaming exercise on the vulnerabilities found; and the entity submits a summary report to the authority within 8 weeks of the authority's assessment of the two reports. Article 13 requires a remediation plan within 8 weeks of that, with, for each finding, the shortcomings, the measures with priority and completion dates, a root cause analysis, the responsible staff and the risks of not remediating. Article 14 and Article 26(7) of DORA give the entity an attestation for mutual recognition between authorities.
Article 7 protects the vendor as much as the entity: the testers and the threat intelligence provider may not perform blue team tasks for the entity or for a provider involved in the test, may not be employed by a threat intelligence provider that does, and must not engage in unauthorised destruction of equipment or uncontrolled modification of information and ICT assets of the entity or of its providers. Article 27 of DORA requires the testers to be of the highest suitability, certified or bound by a code of conduct, covered by professional indemnity insurance, and contractually bound to sound handling of the results, including the protection of confidential information.
The pooled test, Article 26(4): the option written for SaaS
A multi-tenant vendor has a problem the Regulation anticipated: a red team attacking its production environment for one bank attacks the environment of every other customer, including customers outside DORA. Article 26(4) answers it. Where the vendor's participation in a customer's TLPT is reasonably expected to have an adverse impact on the quality or security of the services it delivers to customers outside the scope of DORA, or on the confidentiality of their data, the entity and the vendor may agree in writing that the vendor directly contracts an external tester and runs, under the direction of one designated financial entity, a pooled TLPT for several financial entities to which it provides the services. The pooled test covers the relevant range of services supporting critical or important functions contracted by those entities, and counts as the TLPT of every participating entity. Article 16 of the Delegated Regulation has the authorities agree which entity leads, considering the services the vendor provides and the efficiency of the test, and Articles 6 and 8 set the risk management and the specificities of pooled tests.
For a vendor with several financial customers this is the sentence to negotiate into every contract: one pooled test every 3 years, led by one customer, with a tester the vendor selects under Article 27, instead of a separate red team per customer. Write it into the Article 30(3)(d) clause when the addendum arrives, not when the notification does.
What you cannot refuse, and what you can
You cannot refuse participation: the clause is mandatory and the entity's authority validates the scope. You can, under Article 26(4), refuse to have your shared production environment attacked on behalf of one customer, provided you offer the pooled test. You can require, under Article 27(3) and Article 7, that the tester's contract binds it to the protection of your confidential information and to the prohibition on destruction and uncontrolled modification. You can have your own staff in the control team, and you should, because the control team is where the suspension decision of Article 11 is taken when the test threatens other customers. And you can insist that the closure phase's replay and purple teaming include your blue team, because the findings that concern your infrastructure are yours to remediate.
What an ISO 27001 system already holds
The Delegated Regulation names no standard, and what follows is StandardOS's reading of where an ISO/IEC 27001:2022 management system produces what a TLPT will look for, with no presumption of conformity. The threat intelligence phase reads your own A.5.7 threat intelligence record and your attack surface as the asset inventory, A.5.9, describes it. The red team phase tests the logging and monitoring of A.8.15 and A.8.16, which is what the blue team defends with, and the incident management planning of A.5.24, which is what the blue team follows when it detects. The closure phase's remediation plan maps onto the vulnerability management control, A.8.8, and the corrective-action record of clause 10.2, with root cause, owner and dates already in the format Article 13 asks for. The risk management controls of Article 26(5) are the business continuity controls, A.5.29 and A.5.30, applied to the test window. And the confidentiality terms you impose on the tester are supplier agreement terms, A.5.20. What the standard does not give you is the secrecy: a blue team that is not told is an organisational arrangement under Article 4, and it has to be designed with the customer.
What to do before the notification
Decide now whether a red team may attack your production environment at all, and if not, put the Article 26(4) pooled test into the Article 30(3)(d) clause of every financial contract. Choose, under Article 27, the external tester you would contract for a pooled test, and settle the confidentiality and no-destruction terms with it in advance. Name the two people who would sit in a customer's control team and keep them apart from operations. Rehearse a suspension: who decides, on what evidence, within how many minutes, when the test threatens another customer. And keep the incident record and the vulnerability record in a shape that produces a remediation plan within 8 weeks, because the major-incident article shows the same records answering a different clock. The DORA hub holds the dates of the Regulation and its acts.