DORA Article 30: The 15 Contractual Provisions Every ICT Agreement Must Include
Why Article 30 Changes Everything for ICT Procurement
Before DORA, ICT outsourcing contracts in the financial sector were governed by a patchwork of EBA Guidelines, national regulations, and institutional best practices. The result was inconsistency: some contracts included robust audit rights and exit provisions; others — particularly those signed with dominant technology vendors — contained whatever terms the vendor's standard agreement offered.
Article 30 eliminates this ambiguity. It prescribes a mandatory set of contractual provisions that must appear in every arrangement where a financial entity uses ICT services provided by a third party. Not guidelines. Not best practices. Legal requirements that competent authorities will verify.
For institutions with hundreds of ICT vendor relationships, many governed by contracts signed years before DORA's adoption, this creates a material contract remediation challenge. This guide maps each provision to practical implementation, providing a framework for legal and procurement teams conducting contract reviews.
The 15 Mandatory Contractual Provisions
1. Clear and Complete Service Level Descriptions (Art. 30(2)(a))
The contract must include "a clear and complete description of all functions and ICT services to be provided." This goes beyond a generic statement of work. Supervisors expect service descriptions that are specific enough to measure performance against, including quantitative service levels, availability targets, and support response times.
Practical implication: Vague descriptions like "cloud hosting services" are insufficient. The contract must specify the exact services, environments, and performance parameters. If the vendor provides infrastructure, application hosting, data processing, and disaster recovery, each must be described with measurable commitments.
2. Data Processing and Storage Locations (Art. 30(2)(b))
The contract must specify "the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed." This includes both primary processing locations and disaster recovery sites.
Practical implication: The provision requires specificity — not "EU data centres" but specific countries or regions. If the vendor processes data in Ireland, Germany, and the Netherlands, all three must be named. Any change in location must trigger a notification obligation.
3. Data Security and Availability Provisions (Art. 30(2)(c))
Contracts must include "provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data." This encompasses encryption standards, access controls, and data handling procedures.
Practical implication: The contract should specify encryption standards (at rest and in transit), access management requirements, data classification handling, and breach notification procedures. Reference to the vendor's security certifications (SOC 2, ISO 27001) is helpful but not sufficient without specific contractual commitments.
4. Data Portability and Return (Art. 30(2)(d))
The agreement must ensure "the right of the financial entity to monitor, on an ongoing basis, the ICT third-party service provider's performance" and guarantee return of data "in an easily accessible format" upon contract termination.
Practical implication: Define the exact data formats, export mechanisms, and timelines for data return. Specify that data must be returned in industry-standard, machine-readable formats — not proprietary archives requiring the vendor's tools to extract. Establish a data destruction timeline and certification after return is complete.
5. Service Level Agreements with Quantitative Targets (Art. 30(2)(e))
Contracts must contain "agreed service levels" that are "precise, quantitative" where possible and include "appropriate remedies" for non-compliance. This is a significant elevation from typical commercial SLAs that may offer service credits but no contractual remediation rights.
Practical implication: Define uptime targets (e.g., 99.95%), response times (P1: 15 minutes, P2: 1 hour), resolution times, and recovery targets (RTO/RPO). Specify remedies that go beyond service credits: escalation procedures, right to require remediation plans, and termination rights for persistent SLA breaches.
6. Exit Strategy and Transition Assistance (Art. 30(2)(f))
This is one of the most demanding provisions. The contract must include "notice periods and reporting obligations of the ICT third-party service provider" and "exit strategies, in particular the establishment of a mandatory adequate transition period" during which the vendor must continue providing services while the entity migrates.
Practical implication: Define a minimum transition period (12-24 months for critical services is common), during which the vendor must maintain full service levels, provide migration assistance, and cooperate with replacement vendors. Specify knowledge transfer obligations, documentation handover, and service continuity guarantees during transition.
7. Sub-outsourcing Chain Transparency (Art. 30(2)(a) and Art. 29(2))
The contract must address the vendor's use of sub-contractors. Financial entities must have visibility into the sub-outsourcing chain and the right to object to or terminate the arrangement if sub-outsourcing creates unacceptable risk.
Practical implication: Require advance notification (minimum 30-60 days) before any sub-outsourcing change that affects the services. Include the right to review and approve or reject new sub-contractors. Maintain a register of all sub-contractors with their locations, services provided, and criticality assessment.
8. Audit and Access Rights (Art. 30(3)(e))
Financial entities must retain "unrestricted rights of access, inspection and audit" over the ICT third-party service provider. This extends to the entity, its competent authority, and any third party appointed by either.
Practical implication: The audit clause must be unconditional — no advance notice requirements exceeding 30 days, no vendor right to refuse or limit audit scope, no prohibition on competent authority access. For cloud providers that resist individual audit rights, pooled audit arrangements or reliance on independent certifications may be acceptable if they meet the supervisory standard, but the contractual right must exist.
9. Incident Notification Obligations (Art. 30(2)(e) and Art. 17)
The vendor must commit to notifying the financial entity of ICT incidents affecting the services within defined timelines. This obligation must align with the entity's own incident reporting obligations under Articles 17-23.
Practical implication: Specify notification timelines that give the entity sufficient time to assess regulatory reporting obligations. For critical services, initial notification within 30-60 minutes of incident detection is recommended, with structured interim updates at defined intervals. Define what constitutes a notifiable incident (not just service outages but security events, data integrity issues, and near-misses).
10. Business Continuity Provisions (Art. 30(2)(c) and Art. 11)
The contract must include provisions ensuring the vendor's ICT services support the entity's business continuity requirements. This includes the vendor's own BC/DR capabilities, testing obligations, and recovery commitments.
Practical implication: Specify RTO and RPO targets that align with (or exceed) the entity's requirements for the supported business functions. Require the vendor to maintain and regularly test disaster recovery capabilities. Include the right to participate in or observe the vendor's DR testing. Define escalation procedures and communication protocols for business continuity events.
11. Cooperation with Competent Authorities (Art. 30(3))
For arrangements supporting critical or important functions, the vendor must cooperate fully with the entity's competent authorities. This includes providing information, granting access, and supporting supervisory activities.
Practical implication: Include an explicit clause requiring the vendor to cooperate with supervisory requests without requiring the entity to seek additional vendor consent. The vendor must treat competent authority access with the same priority as the entity's own audit rights.
12. Termination Rights (Art. 30(2)(f) and Art. 28(7))
The contract must include clear termination provisions, including termination for cause (material breach, insolvency, regulatory action) and termination for convenience with appropriate notice periods.
Practical implication: Define specific termination triggers: persistent SLA breaches, security incidents, failure to cooperate with audits, material change in control, regulatory designation as a critical ICT third-party provider (Art. 31), or sub-outsourcing without consent. Specify that termination does not release the vendor from transition assistance obligations.
13. Governing Law and Jurisdiction (Art. 30(2))
The contract should specify governing law and dispute resolution mechanisms. For ICT services supporting critical functions, this takes on heightened importance.
Practical implication: Prefer governing law and jurisdiction within the EU, ideally in the entity's home member state. Avoid arbitration clauses that would prevent competent authority access to dispute resolution proceedings. Ensure that the governing law does not conflict with DORA requirements.
14. Performance Monitoring Rights (Art. 30(3)(d))
The financial entity must retain the right to continuously monitor the vendor's performance, not just through periodic reports but through real-time access to service health data, incident logs, and security event information.
Practical implication: Require the vendor to provide access to dashboards, APIs, or regular reports covering service performance, incident history, security events, and capacity utilization. Specify reporting frequency (monthly for standard services, weekly or real-time for critical services) and format requirements.
15. Confidentiality and Intellectual Property (Art. 30(2))
The contract must address confidentiality obligations (bidirectional) and clarify intellectual property rights, particularly regarding data, configurations, and customizations developed during the engagement.
Practical implication: Ensure that the entity retains ownership of its data and any configurations or customizations specific to its environment. Confidentiality provisions must survive termination. Define the handling of the entity's confidential information upon contract expiry — return, deletion, and certification.
Renegotiation Strategy for Existing Contracts
Most financial institutions have a portfolio of ICT contracts signed before DORA's application date. A structured renegotiation approach is essential:
Phase 1 — Inventory and Prioritise (Months 1-2): Catalogue all ICT agreements and classify them by criticality (critical/important/standard). Prioritise renegotiation for contracts supporting critical or important functions, where Art. 30(3) imposes enhanced requirements.
Phase 2 — Gap Analysis (Months 2-4): For each prioritised contract, map existing provisions against the 15 requirements above. Identify gaps and draft amendment language. Use a structured tracking system — platforms that maintain third-party registers with contract clause tracking can accelerate this process significantly.
Phase 3 — Vendor Engagement (Months 4-12): Approach vendors with specific amendment requests. For large technology vendors, coordinate with other financial entity clients (many are receiving identical requests). For vendors resistant to audit rights or exit provisions, escalate to senior procurement and involve legal counsel familiar with DORA requirements.
Phase 4 — Ongoing Governance (Continuous): Embed Art. 30 requirements into standard contract templates for all new agreements. Establish a review cadence for existing contracts, with triggers for renegotiation upon renewal, material change, or regulatory guidance.
Common Pitfalls
Accepting "standard terms" from dominant vendors. Major cloud providers, SaaS platforms, and technology vendors offer standardised contracts that may not include all Art. 30 provisions. DORA does not exempt any ICT third-party arrangement based on the vendor's market position.
Treating audit rights as theoretical. The audit clause must be exercisable, not decorative. If the contract includes audit rights but the vendor's operational procedures make audits impractical (excessive advance notice, limited scope, vendor-selected evidence), the provision does not satisfy Art. 30(3)(e).
Ignoring sub-outsourcing chains. A vendor's sub-contractors are within scope. If your cloud provider uses third-party data centres, security operations centres, or support providers, you need visibility into those arrangements and the right to assess their risk.
Deferring exit strategy planning. Art. 30(2)(f) requires exit strategies to be defined at contract inception, not when you decide to terminate. Building transition plans after the decision to exit is too late — you need contractual guarantees in place from day one.
The institutions that approach Article 30 as a contract governance exercise — systematic, tracked, and evidenced — will build third-party risk management programmes that satisfy supervisors. Those that treat it as a legal checkbox will discover, during their first examination, that a clause in a contract and a capability in practice are two very different things.
This guide provides general implementation guidance for DORA Article 30 contractual provisions. It does not constitute legal advice. Financial entities should engage qualified legal counsel familiar with DORA requirements and their specific jurisdictional context when drafting or amending ICT service agreements.