DORA ICT third-party provisions: what changes in vendor management

DORA's ICT third-party provisions don't just update contracts, they reshape governance, evidence, and oversight. See what changes and how to act.

If your vendor management process today looks like a spreadsheet of questionnaires and a folder of signed MSAs, DORA's ICT third-party provisions are going to feel like a significant gear change. Not because the regulation is hostile to what you've already built, but because it raises the bar from "we asked the vendor about their controls" to "we can prove it, report it, and act on it."

This post is aimed squarely at Compliance Officers and CISOs who manage ICT vendor risk. The focus isn't on explaining what DORA is, it's on what concretely changes in your day-to-day workflows once Articles 28–30 (and the broader CTPP framework in Articles 31–44) are in effect.

ICT third-party risk moves inside your governance structure

Under DORA, you can't treat vendor risk as a procurement sideshow. Third-party ICT risk must be formally integrated into your ICT risk management framework, which means it sits alongside your internal controls, gets reviewed in the same governance cycle, and is owned at the right level in your organisation.

In practice, this changes a few things. Your risk taxonomy needs to accommodate ICT third-party categories. Your governance bodies (risk committee, CISO function, board where relevant) need visibility of material vendor exposures, not just a list of suppliers. And critically, vendor reviews can't live only in procurement, they need to feed your ICT risk picture.

For organisations already running multi-standard programmes, this is where a Single Audit, Multiple Standards approach pays off. If your vendor evidence is already structured to satisfy ISAE 3402 or ISO 27001, much of that control and assurance work maps directly into DORA's evidence expectations, rather than building a parallel process from scratch.

Article 28 register of information: your single source of truth

The DORA Register of Information (ROI) is a documented, supervised master register of all ICT contractual arrangements. It goes well beyond a contracts list. Per Article 28, it needs to capture the type of service, whether the function is critical or important, data locations, subcontracting chains, and key contract metadata.

Regulators use your ROI, including for the Critical ICT Third-Party Provider (CTPP) supervision regime under Articles 31–44, where the AFM and peer regulators can identify systemic exposure across the sector. So the ROI isn't just an internal housekeeping document; it's supervisory evidence.

Operationally, this means you need a maintained data model, not a static spreadsheet. Fields to capture include: provider name, service description, function criticality flag, data storage and processing locations, subcontractor identities (4th parties), contract start/end dates, audit rights clauses, and last assessment date. If your current vendor register doesn't hold all of this, the gap analysis starts here.

For further reading on how third-party risk and ISAE 3402 interact, particularly around evidence from service organisations, that's worth exploring alongside your ROI build.

Pre-contract analysis: due diligence before you sign

One of the more operationally disruptive changes is that Article 28 requires structured risk analysis before contract signature. This isn't a checkbox, it's an assessment that must feed into what you negotiate.

Specifically, you need to evaluate the ICT provider's security posture, the scope of audit rights you'll need, concentration risk (are you already over-exposed to this provider or cloud ecosystem?), subcontracting arrangements (and whether the sub-service provider is separately assessable), and exit feasibility.

The practical shift: your procurement and legal teams need to be working from a risk brief before the commercial conversation starts. Getting to "what does this vendor actually process, where, and for which of our critical functions?" is the prerequisite for negotiating anything meaningful.

Article 30 mandatory contract clauses: the biggest day-to-day change

Article 30 of Regulation (EU) 2022/2554 (DORA) sets out key contractual provisions that must appear in every ICT third-party contract. For all contracts, the mandatory categories include:

• A clear description of the services and service levels
• Data location and processing jurisdiction
• Provisions on data accessibility, availability, integrity and confidentiality
• Notice and cooperation obligations for ICT incidents
• Cooperation on supervisory access and inspections
• Termination rights and exit assistance obligations
• Participation in security testing where required

For contracts covering critical or important functions, the requirements intensify. You need detailed SLAs with quantifiable KPIs, reporting on ICT incidents, business continuity and contingency arrangements, subcontracting transparency (and your right to object), and, critically, contractual cooperation for Threat-Led Penetration Tests.

Tie this to your contract lifecycle: every renewal or new agreement is an opportunity to embed the right clauses. For existing agreements, a clause gap analysis against Article 30 categories tells you where to prioritise re-papering. Not every contract needs to be renegotiated urgently, but anything supporting a critical or important function should be at the top of the queue.

For context on how supplier obligations flow through audit frameworks, the dealing with suppliers in ISAE 3402 and SOC 1 context is a useful reference.

Threat-Led Penetration Testing: contracting for cooperation

TLPT (Threat-Led Penetration Testing) under DORA creates a specific vendor contracting problem: you need your ICT providers to cooperate in a controlled, scoped attack simulation that may target their own infrastructure as it interfaces with yours. Many suppliers will push back on scope, timing, or liability.

What DORA-driven contracting should secure:

• Explicit consent for inclusion in TLPT scope
• Rules of engagement agreed in advance (notification protocols, safe-testing clauses)
• Obligation to provide relevant documentation (architecture, data flows) to support red team scoping
• Post-test cooperation on remediation timelines

Common supplier pushback includes limiting test scope to "your environment only" and restricting access to shared infrastructure documentation. Your contract terms need to address this directly, a vague "cooperation in security testing" clause won't hold up when you're trying to scope a TIBER-EU or equivalent exercise. For more on how penetration testing protects against cyber threats and the evidence it generates, that's worth reviewing alongside your TLPT preparation.

Exit strategies: not a static clause

Articles 29 and 30 require that exit and termination provisions are operationally credible. This means minimum notice periods, data portability obligations, and a transition assistance period. But DORA goes further in spirit: a good exit strategy isn't one that sits in a contract, it's one you've actually tested.

"Testable exit" means you can demonstrate that if you needed to migrate away from a critical ICT provider within a defined timeframe, you have the data, the run-books, and the alternate capacity to do it. Regulators will expect this to be evidenced, not assumed.

Concentration risk and the CTPP effect

Concentration risk is the sleeper issue in DORA vendor management. If several of your critical functions run through the same cloud provider, or even the same regional data centre, that's a concentration exposure that Article 29 requires you to assess and manage.

The CTPP designation regime (Articles 31–44) adds a supervisory layer: regulators can designate ICT providers as Critical Third-Party Providers based on the systemic exposure they represent across the sector. Your ROI contributes to that picture. This means your vendor monitoring can't stop at onboarding, criticality reassessment needs to happen when a provider's role in your environment changes, when subcontractor chains shift, or when sector-wide concentration signals emerge.

For operational risk management more broadly, ongoing monitoring cadence and reassessment triggers are the same discipline applied to third parties.

A practical 90/180/365-day roadmap

0–90 days: Inventory all ICT contracts. Define criticality criteria for functions and providers. Build your ROI data model. Run a contract-clause gap analysis against Article 30 categories.

90–180 days: Negotiate or refresh Article 30 clauses for high-risk and critical-function vendors. Formalise your pre-contract risk assessment workflow. Start evidence capture processes (assessment outputs, audit rights exercised, incident cooperation tested).

180–365 days: TLPT readiness, identify in-scope providers, draft rules of engagement, embed TLPT cooperation in contracts. Test exit strategies for priority vendors. Establish review routines and update triggers (renewal dates, criticality changes, incident events).

DORA-ready vendor management: a quick checklist

• ROI is complete, maintained, and includes criticality flags, data locations, and subcontractor chains
• Pre-contract risk analysis is documented before each new ICT agreement
• Concentration risk is assessed for all critical-function providers
• All ICT contracts contain the Article 30 mandatory clause categories
• Critical/important function contracts include SLAs with KPIs, incident reporting, business continuity, and TLPT cooperation terms
• Exit strategy for each priority vendor is documented and has been tested or tabletop-exercised
• Subcontractor (4th party) visibility is maintained and changes are notifiable under contract
• Evidence of vendor assessments and audit rights exercised is retained for supervisory requests
• ROI is reviewed at least annually, with interim updates on new agreements

FAQ

Do we need to re-paper every vendor contract? Not necessarily all at once. Prioritise contracts covering critical or important functions, those face the most demanding Article 30 requirements. Use renewal cycles as the natural trigger for others, and run a gap analysis to identify which non-critical contracts have material clause shortfalls.

What counts as an ICT third-party service provider for DORA purposes? Any entity providing digital and data services on a continuous basis, including cloud platforms, software providers, data analytics services, and managed security providers. The scope is deliberately broad.

How do we treat subcontractors and 4th parties? DORA requires subcontracting transparency: your contracts should require the vendor to notify you of material subcontracting arrangements and give you the right to object. 4th-party chains feeding critical functions need to appear in your ROI. You can't achieve DORA readiness while treating the supply chain as a black box.

How do TLPT requirements flow down to vendors? Your Article 30 contract terms for critical/important function providers should include an explicit obligation to cooperate in TLPT exercises: scope agreement, rules of engagement, documentation access, and post-test remediation. The TIBER-EU framework (the EU's TLPT methodology) provides a reference architecture for how this is structured in practice. See also does NIS2 require penetration testing for how similar obligations flow across regulatory frameworks.

What evidence should we keep for audits and supervisory requests? At minimum: pre-contract risk assessment outputs, the ROI in a retrievable format, records of audit rights exercised (or formally waived with rationale), incident cooperation correspondence, TLPT scoping and results documentation, exit strategy test records, and a log of criticality reassessments. Structuring this evidence within a unified compliance programme (covering DORA alongside ISO 27001 or NIS2) avoids duplication and makes it retrievable under pressure. Securance's Single Audit, Multiple Standards approach is designed precisely for this, consolidating assurance evidence across frameworks so you're not maintaining separate artefact libraries for each regulator.

The shift DORA demands isn't punishing, it's clarifying. Vendor risk that was always real but often informal becomes structured, evidenced, and reportable. The organisations that adapt fastest are those treating it as a process upgrade rather than a compliance burden.