Article 30 of DORA is the part of the regulation that lands on a provider's desk as a redline. A financial entity sends a DORA addendum, the provider's legal team compares it with the master agreement, and both sides discover they have different views on audit rights, exit support and who pays for incident assistance.
Most of those disagreements are avoidable. Article 30 is specific about what a contract must contain. It is much less specific about how each clause is implemented, and that is where the negotiation belongs.
This article goes through the form requirements, the baseline clauses for every ICT services contract, the additional clauses for services supporting critical or important functions, and the points a provider can reasonably negotiate. For the risk assessment and register work that comes before the contract, see DORA third-party risk and the register of information.
The form the contract must take
Article 30(1) requires the rights and obligations of the financial entity and the provider to be clearly allocated and set out in writing. The full contract, including the service level agreements, must be documented in one written document available to the parties on paper, or in another downloadable, durable and accessible format.
In practice, many arrangements implement this with a DORA addendum attached to the existing master agreement. Whether a particular structure meets the one-document requirement depends on how the parts are incorporated and kept together, and that is a question to confirm with counsel. What fails in any structure is a service level agreement that lives only on a web page the provider can change.
Clauses required in every ICT services contract
Article 30(2) lists the elements every contract for ICT services must include, whether or not the service supports a critical or important function.
| Article 30(2) requirement | What a provider should check |
|---|---|
| (a) A clear and complete description of all functions and ICT services, stating whether subcontracting of services supporting critical or important functions is permitted and on what conditions | Your service descriptions match what you deliver, and your subcontracting terms are written down |
| (b) The locations, meaning regions or countries, where services are provided and data is processed, including storage locations, and an obligation to notify in advance of a change | Your hosting regions are accurate and you can give advance notice before moving them |
| (c) Provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data | These align with your security commitments and your data processing agreement |
| (d) Ensuring access, recovery and return of data in an easily accessible format if the provider becomes insolvent, is resolved, discontinues its business, or the contract ends | You have a defined export format and a process to deliver it |
| (e) Service level descriptions, including updates and revisions | Your service levels are in the contract, not only in a linked document |
| (f) Assistance when an ICT incident related to the service occurs, at no additional cost or at a cost determined in advance | You have decided which, and priced it if needed |
| (g) Full cooperation with the entity's competent and resolution authorities, including persons they appoint | You know who handles a supervisor's request |
| (h) Termination rights and minimum notice periods, in line with the expectations of competent and resolution authorities | Your notice periods are compatible with your customer's exit strategy |
| (i) Conditions for participating in the entity's ICT security awareness programs and digital operational resilience training | You understand which staff are expected to take part, and how often |
Two of these rows cause the most friction. Clause (d) requires data return in scenarios such as insolvency, when the provider may not be in a position to cooperate, so customers will ask how it works in practice. Clause (f) forces a pricing decision that many providers have never made explicitly.
The data protection clause overlaps with your GDPR terms. If you already have a data processing agreement, cross-reference it rather than writing a second, inconsistent set of security commitments.
Additional clauses for critical or important functions
Where the ICT service supports a critical or important function, Article 30(3) requires the contract to include, in addition to everything above:
Full service level descriptions with precise quantitative and qualitative performance targets, so the entity can monitor the service and take corrective action when targets are missed.
Notice periods and reporting obligations from the provider to the entity, including notice of any development that might materially affect the provider's ability to deliver the service effectively.
Business contingency plans the provider must implement and test, and ICT security measures, tools and policies providing an appropriate level of security.
Participation in threat-led penetration testing. The provider must participate and fully cooperate in the entity's TLPT, as described in DORA resilience testing and TLPT.
Unrestricted rights of access, inspection and audit by the entity, a third party it appoints, and its competent authority, with the right to take copies of relevant documentation on-site if critical to the provider's operations. The contract must also give the right to agree alternative assurance levels if other clients' rights are affected, oblige the provider to cooperate fully during inspections and audits, and set out their scope, procedures and frequency.
Exit strategies, in particular a mandatory adequate transition period. During it, the provider continues delivering the service to reduce the risk of disruption, and the entity migrates to another provider or to an in-house solution, consistent with the complexity of the service.
Article 30(4) asks entities and providers to consider using standard contractual clauses developed by public authorities for specific services when negotiating these terms. Article 30 also mandates further technical standards on the subcontracting of ICT services supporting critical or important functions, so check the current standards when you draft your subcontracting language.
The termination circumstances in Article 28(7), such as a significant breach or evidenced weaknesses in the provider's ICT risk management, also have to be reflected in the contract. Expect them in the addendum alongside the Article 30 terms.
What a provider can reasonably negotiate
The clause list is fixed. Its implementation is not. A provider can negotiate the following without asking the entity to accept a contract that falls short of Article 30.
Audit rights
Unrestricted audit rights from every customer would be unmanageable for a provider with many financial customers. Article 30(3) itself allows the parties to agree alternative assurance levels where other clients' rights are affected. Offer a structured path: independent audit reports and certificates first, pooled audits on request, and direct audits with reasonable notice and scope. Do not offer to exclude the competent authority's access. That right is not the customer's to waive.
Incident assistance
Decide whether assistance is free or priced in advance, and define what it includes: named contacts, update intervals, and the facts you will supply. Your customer needs those facts on the deadlines described in DORA incident reporting, so vague commitments help neither side.
Location changes
Advance notice of location changes is mandatory. The length of the notice and what happens if the customer objects are negotiable. Agree both, and make sure your infrastructure team knows the commitment exists.
Transition period
The transition period must be adequate for the complexity of the service. Agree a length, the service level during transition, and the fees. An open-ended obligation is a commercial risk. A short fixed period may not satisfy the customer's exit strategy.
Training participation
Clause (i) requires conditions for participating in the entity's training programs. Agree which of your staff are covered, typically those with access to the customer's environment or data, and how completion is evidenced.
Building a DORA addendum template
Providers that sell to several financial entities save time with their own addendum. A workable sequence:
Map each Article 30(2) and 30(3) element to the clause in your master agreement, data processing agreement or security schedule that already covers it.
Write new clauses only for the gaps, typically data return on insolvency, incident assistance pricing, authority cooperation, TLPT participation and transition periods.
Split the template into a baseline section and a critical or important function section, so customers apply only what fits their classification.
Have the template reviewed once by your legal team, and record the positions you will and will not move on.
Track each signed addendum's commitments, such as notice periods and assistance terms, so operations teams honor what legal agreed.
The last step is the one most often skipped. A notice obligation that exists only in a signed PDF will be missed the first time it applies. Our DORA framework page sets the contract rules in the context of the whole regulation.
How TrustLynce helps
TrustLynce's customer commitments feature tracks contractual obligations, such as notice periods and assistance terms, against the controls that fulfill them. The Trust Center shares audit reports and certificates behind gated access, which supports the alternative assurance path for audit requests.