DORA Article 30 checklist: the mandatory contract clauses and the vendor documents that prove them

A clause in the contract isn't the same as a control in place

Here's a scenario most DORA teams will recognise. The contract with a payments vendor says the vendor will maintain and regularly test a business continuity plan. Article 30(3)(c): tick. Then a supervisor asks for the most recent test report, and the newest one anyone can find is from 2024.

The clause was there. The evidence wasn't. That gap between contract language and proof is where most Article 30 reviews fall short, and it's what this checklist is built around.

For each of the 15 provisions you'll find three things: what to check in the clause itself, which vendor document shows the obligation is being met, and the gap reviewers find most often.

First: nine provisions or fifteen?

Article 30(2) lists nine provisions that every contract for ICT services must contain. Article 30(3) adds six more when the service supports a critical or important function. The six are additional, not a replacement, so a critical function contract carries all fifteen.

Article 30(1) also sets a format rule people skip past: the rights and obligations must be in writing, in one document available on paper or in a downloadable, durable and accessible format. A master agreement plus an order form, a DPA, an SLA page on the vendor's website and three emails is not one document. If your contract set is scattered, start by pulling it into a single, consolidated agreement.

30(2)(a): Service description and subcontracting

The contract needs a clear and complete description of every function and ICT service, and it must say whether subcontracting of a service supporting a critical or important function is allowed and, if so, on what conditions.

• Check the clause: services are named specifically, not just the Services described in the Order Form with no order form attached. Subcontracting is explicitly allowed or prohibited, with conditions.
• Evidence: the order form or statement of work, and the system description in the vendor's SOC 2 report, to confirm the audited scope matches what you actually buy.
• Watch for: a SOC 2 report covering a different product line or a different hosting region from the one in your contract.

30(2)(b): Where services run and where data lives

The contract must state the regions or countries where services are provided and where data is processed and stored, and the vendor must notify you in advance if it plans to change them.

• Check the clause: named countries or regions, plus an advance notice obligation for changes.
• Evidence: the location annex of the DPA, the sub-processor list with countries, and the subservice organisations listed in the SOC 2 report.
• Watch for: wording such as data may be processed wherever our sub-processors operate. That isn't a location, and it makes the advance notice obligation meaningless.

30(2)(c): Protecting availability, authenticity, integrity and confidentiality

The contract must include provisions on availability, authenticity, integrity and confidentiality in relation to data protection, including personal data.

• Check the clause: concrete security commitments, usually in a security annex, rather than a general promise of industry standard security.
• Evidence: SOC 2 controls under CC6 (logical access and encryption), the ISO 27001 Statement of Applicability, and the technical and organisational measures annex of the DPA.
• Watch for: coverage gaps such as encryption at rest that is evidenced for production databases but not for backups.

30(2)(d): Getting your data back

The contract must ensure access, recovery and return of personal and non-personal data in an easily accessible format if the vendor becomes insolvent, is resolved, discontinues its business or the contract is terminated.

• Check the clause: return of data in a usable format, covering insolvency, resolution and discontinuation as well as normal termination.
• Evidence: data export documentation, the return and deletion clause in the DPA, and the vendor's continuity plan.
• Watch for: clauses that only cover termination. Insolvency is the scenario this provision exists for, and it's the one most often missing.

30(2)(e): Service level descriptions

The contract must include service level descriptions, including updates and revisions.

• Check the clause: service levels are part of the agreement, and changes require notice or agreement.
• Evidence: the SLA document and the vendor's historical availability reporting.
• Watch for: an SLA hosted on the vendor's website that it can change unilaterally.

30(2)(f): Incident assistance at a known cost

The vendor must help you when an ICT incident related to its service occurs, either at no additional cost or at a cost determined in advance.

• Check the clause: an assistance obligation with a fixed or pre-agreed price, plus a notification window.
• Evidence: the vendor's incident response plan summary and SOC 2 controls under CC7 covering incident detection and response.
• Watch for: assistance billed at then-current professional services rates, which isn't a cost determined in advance, and notification windows that are longer than your own reporting clock.

Why the notification window deserves its own line

Article 30(2)(f) doesn't set a notification deadline for the vendor. Your own reporting obligations do. For a major ICT incident, you must send an initial notification within 4 hours of classifying it as major and no later than 24 hours after becoming aware of it. A vendor that may take 72 hours to tell you about an incident on its side puts that clock at risk before you can start it. Set the vendor's window with your own deadlines in mind, and check that the vendor's internal incident procedure actually supports the promise in the contract.

30(2)(g): Cooperation with authorities

The vendor must cooperate fully with the competent authorities and resolution authorities of the financial entity, including persons they appoint.

• Check the clause: full cooperation, not limited to what the vendor is legally compelled to provide.
• Evidence: mostly contractual, though vendors that already serve regulated customers often have a regulator engagement policy.
• Watch for: cooperation that depends on the vendor's prior written consent.

30(2)(h): Termination rights and notice periods

The contract needs termination rights and minimum notice periods that match your supervisor's expectations, including the triggers in Article 28(7): significant breaches of law or contract, circumstances that change the service, weaknesses in the vendor's ICT risk management, and situations where the authority can no longer supervise effectively.

• Check the clause: termination rights that map to each Article 28(7) trigger.
• Evidence: contractual only.
• Watch for: termination limited to material breach with a long cure period, which covers none of the regulatory triggers.

30(2)(i): Security awareness and resilience training

The vendor must take part in your ICT security awareness programmes and digital operational resilience training, as set out in Article 13(6).

• Check the clause: participation conditions are defined.
• Evidence: records of participation, or the vendor's own training programme if your clause allows it to count.
• Watch for: the clause missing entirely. Pre-DORA templates rarely contain anything like it, so it's the provision most often absent from vendor paper.

30(3)(a): Full service levels with real numbers

For critical or important functions, service level descriptions aren't enough. The contract must include full service levels with precise quantitative and qualitative performance targets, so you can monitor the service and act without undue delay when targets are missed.

• Check the clause: measurable targets for availability, response and resolution times, plus consequences for missing them.
• Evidence: monthly service reports and availability history.
• Watch for: commercially reasonable efforts, which is a promise to try, not a target.

30(3)(b): Notice and reporting duties

The vendor must give notice and report to you, including about any development that could materially affect its ability to deliver the service as agreed.

• Check the clause: reporting covers changes of ownership, financial distress, key subcontractor changes and major security events.
• Evidence: past notifications, if the relationship is not new.
• Watch for: reporting limited to security incidents, with nothing on the business changes that often come first.

30(3)(c): Tested business contingency plans

The vendor must implement and test business contingency plans and maintain ICT security measures, tools and policies that give an appropriate level of security.

• Check the clause: an obligation to test, not just to maintain a plan, ideally with a frequency.
• Evidence: the BCP and disaster recovery plan plus a test report dated within the last 12 months; SOC 2 availability criteria if they're in scope; the business continuity controls in the ISO 27001 Statement of Applicability.
• Watch for: a current plan with stale test evidence, the scenario from the start of this post.

30(3)(d): Threat-led penetration testing

The vendor must take part in, and fully cooperate with, your threat-led penetration testing under Articles 26 and 27 of DORA.

• Check the clause: participation and cooperation are explicit.
• Evidence: contractual, plus the vendor's own penetration test summaries as supporting assurance.
• Watch for: vendors that only offer their own annual pen test report. That's useful evidence, but it doesn't meet this obligation.

30(3)(e): Access, inspection and audit rights

You, an appointed third party and your competent authority need unrestricted rights of access, inspection and audit, including the right to take copies of relevant documents. Where other clients' rights could be affected, the contract can agree alternative assurance levels, and it must define the scope, procedure and frequency of audits.

• Check the clause: unrestricted rights for you and your regulator, with any alternative assurance clearly framed as an addition, not a substitute.
• Evidence: SOC 2 and ISO 27001 reports as alternative assurance where the contract allows it.
• Watch for: audit rights limited to once a year, on 60 days' notice, at your cost, with a SOC 2 report offered in lieu. That's the most common vendor draft, and it doesn't meet this requirement.

30(3)(f): Exit strategy and transition period

The contract must support an exit strategy with a mandatory, adequate transition period. During it, the vendor keeps providing the service so you can move to another provider or bring it in-house without disruption.

• Check the clause: a defined transition period with continued service and migration assistance.
• Evidence: your own exit plan for the service, the vendor's export formats and any transition assistance terms.
• Watch for: transition periods shorter than a realistic migration. If moving off the vendor would take nine months, a 30-day transition clause won't hold up.

The clause behind the clauses: subcontracting

If a service supporting a critical or important function relies on subcontractors, Delegated Regulation (EU) 2025/532 sets out what you must assess: the risks the subcontracting adds, whether the vendor can oversee its subcontractors, and the conditions under which subcontracting is permitted. The final standard dropped a draft requirement for contracts to cover monitoring of the full subcontracting chain, but the assessment duty stays.

In practice, this is where the sub-processor list, the SOC 2 subservice organisations and the vendor's own Article 30 flow-down terms meet. If those three documents disagree about who's involved, you have a finding.

How to run this across a whole vendor portfolio

Fifteen provisions multiplied by every critical vendor gets heavy fast. A few habits keep it manageable:

• Start with vendors supporting critical or important functions. They carry the full fifteen and the most supervisory attention.
• Work from signed documents, not the negotiation tracker. Drafts and redlines don't count.
• Record a clause or page reference for every provision you mark as met. Met with no reference isn't evidence.
• Log every gap as a finding with an owner, a severity and a date, so it can be tracked to closure or formally accepted.
• Re-check when documents change: a new SOC 2 period, a revised DPA or an updated sub-processor list can open or close a gap.

Where software helps

This is the kind of clause and page matching ProcureCortex automates. It reads the contract, DPA, SOC 2 report and continuity plan, maps them to your requirement set, and raises findings that show the requirement, the clause or page it came from and a confidence score. A reviewer still makes the decision; the platform does the reading. You can see how findings look in the sample workspace at procurecortex.com/explore.

Sources

• Regulation (EU) 2022/2554 (DORA), Articles 28 to 30, on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services supporting critical or important functions: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202500532
• European Commission, DORA implementing and delegated acts, including incident reporting standards: https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/implementing-and-delegated-acts/digital-operational-resilience-regulation_en
• Bird & Bird, DORA: what in-house lawyers need to know when updating their contracts: https://www.twobirds.com/en/insights/2024/global/dora-what-do-in-house-lawyers-need-to-know-when-updating-their-contracts
• Jones Day, uniform standards for ICT subcontracting in the EU financial sector: https://www.jonesday.com/en/insights/2025/07/uniform-standards-for-ict-subcontracting-in-eu-financial-sector-new-obligations