What Article 30 DORA requires in ICT services contracts
Article 30 of DORA requires financial entities to set out the rights and obligations for each ICT service in writing, with the full contract, including service level agreements, held in one written document that can be provided on paper or in a durable, downloadable format. Every ICT services contract must carry a baseline set of clauses. Services that support critical or important functions must carry more demanding ones. For a compliance lead preparing the register of information, the practical question is simple: which of your existing supplier terms already contain each required element, and which need an amendment, a side letter or a renegotiation before the register can be defended to a supervisor. Most gaps appear in three places: legacy outsourcing templates that predate DORA, standard terms from cloud and SaaS providers written for a global customer base, and subcontracting chains that the signed contract never describes.
The baseline applies to all ICT services. It requires a description of the services and of any permitted subcontracting, the locations where services are provided and data is processed (with advance notice of changes), data protection and data return on insolvency or termination, incident assistance at no cost or at a pre-agreed cost, cooperation with competent authorities, and termination rights with notice periods. The additional layer for critical or important functions adds full service levels with precise quantitative and qualitative targets, business contingency plans, participation in the entity's threat-led penetration testing, unrestricted access, inspection and audit rights (including for the competent authority), and exit strategies with a mandatory adequate transition period. Confirm with your legal team which of your contracts fall into the critical or important category, because that classification decides which clause set applies and is documented separately under Article 28.
The risk Article 30 addresses is weak contractual control over outsourced ICT: an entity that cannot audit, exit or recover data from a provider cannot demonstrate that it manages that dependency. Before you open a renegotiation, run a clause-by-clause check against the Article 30 list for each in-scope contract, record the gaps in a single tracker, and identify which provider will accept standard contractual clauses and which will not. Ask every provider in writing to confirm its subcontractors for critical services, since the subcontracting terms in Delegated Regulation (EU) 2025/532 build on this baseline. Where a provider refuses audit or exit terms, that refusal is itself a finding to escalate to the management body.
Which contracts Article 30 reaches and where the scope decisions change the work
Article 30 does not apply the same clause set to every ICT contract. Four scoping questions decide how much of the contract must be written out, which audit and exit terms apply, and whether a derogation is available. Work through them in this order before drafting or renegotiating any agreement.
Is it an ICT service?
The first question is whether the arrangement is an ICT service at all. Article 30 sits in the ICT third-party framework, so software licences, hosted platforms, data processing and support contracts usually fall in, while purely non-ICT goods and services do not. Self-hosted open-source software deployed by the entity may still require a contract with a support or implementation provider, and that contract is in scope. Record the decision and the reasoning in the register of information so an assessor can trace it.
Does it support a critical or important function?
This decision adds the heaviest layer of clauses. Where the service supports a critical or important function, Article 30(3) requires full service levels with quantitative and qualitative targets, participation in the entity's threat-led penetration testing, unrestricted access and audit rights, and a documented exit strategy with an adequate transition period. Confirm the classification with the function owner and the risk assessment, and treat a change in use as a trigger to reopen the contract.
Is the provider a microenterprise?
A microenterprise and its provider may agree that the entity's access, inspection and audit rights are delegated to an independent third party appointed by the provider. This derogation applies only to the audit right and only when both parties are microenterprises as defined for DORA. It does not remove the other critical-function clauses, so check each one separately. Ask the provider to evidence its size status before relying on the derogation.
Intra-group and cloud arrangements
Intra-group ICT services and cloud contracts are not exempt because the parties are related or the provider is a hyperscaler. Intra-group contracts still need written terms, and the entity should not assume that shared group policies replace them. Cloud contracts often rely on standard terms, so review whether the provider will accept the Article 30 clauses or whether the entity needs to document its reliance on standard contractual clauses under Article 30(4).
Subcontracting chains
When critical services may be subcontracted, Article 4 of Delegated Regulation (EU) 2025/532 sets what the contract must specify. The provider remains responsible and monitors its subcontractors, subcontractors grant the same access and audit rights, and material changes trigger notice and termination rights. Map the chain before signing, because each link can change which clauses bind the service.
The baseline clauses every ICT services contract must carry
Article 30 starts from a simple requirement: the rights and obligations of both sides must be set out in writing, and the full contract, including its service level agreements, must sit in one written document. That document can be on paper or in a downloadable, durable and accessible format. An assessor will check this first by asking for the single master agreement and its schedules, then confirming that nothing material lives only in an email thread, a portal screenshot or a separate order form. Any service levels referenced by link but not included in the document are a finding waiting to happen.
Article 30(2) then lists the clauses every ICT services contract must contain, whatever the service. In plain terms, the contract must describe the services and say whether the provider may subcontract; state where the services are delivered and where data is processed, with advance notice before those locations change; cover data protection, including how data is returned if the provider becomes insolvent or the contract ends; set out incident assistance, either at no cost or at a pre-agreed cost; require the provider to cooperate with competent authorities; and give the financial entity termination rights and notice periods. For each element, an assessor looks for a named clause, a schedule reference and a measurable obligation, not a general promise. Ask legal and procurement to map every element to a clause number before negotiation closes.
For self-hosted open-source platforms, the same clauses apply, but the provider's role often shifts. An implementation partner may deploy, harden and support the system inside your own cloud account or data center, which changes what the contract must say about data location, subcontracted cloud hosting and who holds the keys. Confirm with counsel and the partner exactly which party operates each component, and write that split into the service description, so the locations and subcontracting clauses describe reality. Also confirm the exact notice period for location changes and the data return format, because these are the clauses most often left vague.
Extra clauses for services supporting critical or important functions
Article 30(3) requires full service level descriptions for these services, with precise quantitative and qualitative targets so the entity can measure performance and take action when it falls short. The point is measurability: a target the entity cannot verify from data it receives is not a target. Service levels should sit inside the single written contract described in Article 30(1), not in a separate document that can drift.
- Quantitative targets: availability, response and recovery times expressed as measurable values, with the measurement method, reporting period and the systems in scope named.
- Qualitative targets: commitments such as quality of support, change handling or cooperation, described specifically enough to be assessed.
- Measurement source: who measures, which tooling produces the data and whether the entity can see raw logs or only the provider's summary.
- Remedies: credits, remediation plans or escalation steps that apply when targets are missed.
A weak version uses phrases such as 'commercially reasonable efforts' or refers to a service level that is defined elsewhere. Ask whether each target can be checked from evidence the entity holds.
The contract must oblige the provider to notify the entity and report on matters that affect the service, so the entity can meet its own incident, risk and oversight duties. The clause should set the trigger, the timing and the content of each notice, and it should cover events at subcontractors as well as at the provider itself. Notice periods must allow the entity to inform its management body and competent authority within the timelines that apply to it.
- Event triggers: incidents, service degradation, material changes to the service, financial distress and changes of control, each listed explicitly.
- Timing: notice periods expressed in hours or days from awareness, with an interim update obligation until resolution.
- Regular reporting: periodic reports on service levels, security posture and open findings, in a format the entity can load into its register and risk processes.
- Subcontractor events: the same duties applied to material subcontractors.
A weak version says the provider will 'inform the customer in a timely manner' with no trigger list or deadline. Confirm that the notice periods fit the entity's own reporting clock.
The provider must maintain business contingency plans appropriate to the service and implement security measures that match the risk of the function it supports. For a critical or important function, the entity should not accept generic assurances. The contract should describe the recovery commitments, the testing the provider performs and the security measures it operates, and it should give the entity a right to see evidence of both.
- Contingency plans: documented plans covering the services supplied, with recovery objectives that align with the entity's own impact tolerances.
- Plan testing: a commitment to test contingency arrangements and share results or summaries with the entity.
- Security measures: the controls the provider operates for the service, referenced to a recognized baseline or to an annex the entity can review.
- Change notification: advance notice before security or hosting changes that could alter the risk profile.
A weak version promises a plan 'exists' without stating recovery targets or any right to review it. Ask for the most recent test summary before signature.
Article 30(3) requires the provider to participate in the entity's threat-led penetration testing where the entity runs TLPT, and it requires unrestricted access, inspection and audit rights for the entity and its competent authority. These are the clauses that most often fail in negotiation because providers resist open-ended testing. The contract should define how participation works in practice, including the scope the provider accepts, the rules of engagement and who bears the cost of the provider's time.
- TLPT participation: a duty to take part in tests of the entity's systems that support the service, with a defined role in scoping and remediation.
- Unrestricted access: access to premises, data, systems and personnel relevant to the service, without arbitrary limits.
- Authority access: explicit rights for the competent authority, which cannot be narrowed by the provider's standard terms.
- Cost allocation: who pays for provider effort during testing and audits, stated in the contract rather than left to later negotiation.
A weak version limits audits to 'once a year with 30 days notice' or refers all requests to the provider's own certificate. Confirm that the wording covers the competent authority, not only the entity.
Article 30(3) requires exit strategies for these services and a mandatory adequate transition period, so the entity can move the function to another provider or bring it in-house without losing continuity. The exit clause is the practical test of whether the entity can leave. It should set out what happens on termination, how data returns, how the provider supports migration and how long the provider must keep the service running during the transition.
- Transition period: a defined period during which the service continues on existing terms, with the option to extend it.
- Data return: formats, completeness checks and deletion certificates, aligned with the data return duties in Article 30(2).
- Migration support: documented assistance, its pricing basis and the named responsibilities on both sides.
- Exit testing: a plan the entity can test, with the provider's cooperation during the exercise.
A weak version ties the transition to the provider's convenience or allows termination without any run-off period. Ask for a written exit plan and check that its timelines match the transition period in the contract.
How to review and amend contracts to meet Article 30
This sequence turns an unstructured set of ICT contracts into a documented, gap-tracked and signed set of amendments that address the Article 30 clauses for every relevant provider. Each step produces a record that the organization can show to its management body, internal audit and competent authority.
Build the clause inventory from the register
Start from the register of information and list every ICT services contract, including intra-group arrangements and contracts that were signed before DORA applied. For each contract, record the provider, the functions supported, whether those functions are critical or important, and whether any subcontracting is in use. The owner is usually the third-party risk function, with procurement and business owners confirming the facts. The step closes when every contract in the register has one inventory line and no contract is held outside the register.
Map each contract against baseline and critical clauses
Compare each contract against the Article 30(2) baseline clauses, then add the Article 30(3) clauses for services that support critical or important functions. Check for a complete description of services, locations of service and data processing, advance notice of changes, data return on insolvency or termination, incident assistance, cooperation with authorities, termination rights and notice periods. For critical services, also check service levels, participation in TLPT, access and audit rights, and exit strategies with a transition period. The output is a gap list per contract that names each missing or weak clause and its risk rating.
Check whether standard clauses apply
Article 30(4) asks entities and providers to consider standard contractual clauses developed by public authorities for specific services. Review whether any such clauses exist for the service types in your inventory and record the decision for each contract, whether adopted, partly adopted or not used, with the reason. Confirm the current status of any relevant clauses with the issuing authority, since the set may change. The output is a short decision note added to the gap list.
Negotiate addenda for each gap
Where a contract lacks required clauses, draft a written addendum that addresses the gaps identified in the previous step and send it to the provider with a deadline agreed internally. Prioritize contracts that support critical or important functions and any where the provider refuses audit or TLPT participation terms, since those points usually need escalation to senior management. Ask providers for their own evidence, such as certifications or independent assurance reports, to support the negotiation, but do not treat a certificate as a replacement for the contractual right. The output is a negotiation log per contract showing each clause requested, the provider's response and any agreed fallback.
Align subcontracting terms with Delegated Regulation (EU) 2025/532
Where critical services may be subcontracted, check that the contract reflects Article 4 of Delegated Regulation (EU) 2025/532. The provider should remain responsible for the service and monitor its subcontractors, subcontractors should grant the same access and audit rights, material changes to subcontracting should be notified in advance, and the entity should keep its termination rights. Confirm the exact requirements against the regulation text, as it is the authoritative source. The output is a subcontracting clause set per critical contract and a list of subcontractors the provider has named or confirmed.
Record approvals and sign off each amendment
Route each addendum through the approval path defined in the ICT third-party policy, which usually includes the business owner, the third-party risk function, legal and, for critical services, the management body or a delegated committee. Record who approved what and when, and note any residual risk the organization has accepted with its rationale. Keep the decision record separate from the contract so that auditors can trace the reasoning. The output is an approval record per amendment that a reviewer can follow without asking the contract owner for context.
Store signed versions and update the register
Store each fully signed contract and addendum in a controlled repository with version history, and confirm that the consolidated contract, including service levels, is available in a durable and accessible format as Article 30(1) requires. Update the register of information so that it reflects the amended terms, then schedule a review trigger for when services, subcontractors or locations change. Confirm the storage approach and retention periods with your legal and records teams. The output is a current, versioned contract file for each provider and a register that matches the signed documents.
Subcontracting terms under RTS 2025/532 and the microenterprise derogation
Where an ICT service supports a critical or important function, the contract must do more than allow subcontracting. Article 4 of Delegated Regulation (EU) 2025/532 sets out what the contract has to specify before a provider can pass part of that service to a subcontractor. The provider remains fully responsible for the services it delivers, including those performed by subcontractors, and must monitor each subcontractor against the terms agreed with the financial entity. The contract should also require the provider to pass down the same access, inspection and audit rights the entity holds, so that the entity and its competent authority can test the whole chain rather than only the first contracting party. Ask the provider to list every subcontractor in the chain that supports the critical function, and check that each one is bound by these terms in writing.
The contract must also oblige the provider to notify the entity of material changes to subcontracting arrangements in advance, giving the entity time to assess the new risk. Pair that notice duty with the entity's own termination rights: if a change introduces risk the entity cannot accept, or the provider does not give notice, the entity must be able to exit without penalty within the notice periods set in the contract. Confirm these rights in the termination clause itself, not only in the subcontracting clause, and align them with the exit plan, since a subcontractor change can trigger the need to move the service.
The microenterprise derogation under Article 30(3) allows a microenterprise and its provider to agree that the entity's access, inspection and audit rights are delegated to an independent third party appointed by the provider. Treat this as a narrow exception, not a default. The entity should confirm with its competent authority whether it qualifies as a microenterprise, whether the appointed third party is genuinely independent, and whether the delegation still allows the entity and its authority to obtain the information they need. Record the agreed arrangement in the contract and keep evidence of the third party's independence and scope.
How an assessor tests Article 30 contract provisions
This table compares what an assessor checks in each Article 30 area, the evidence they ask for, and the findings that most often come up. Read each row as a question the contract file must answer before an assessor will accept it. The main takeaway is that a clause existing on paper is rarely enough; assessors test whether the contract, the subcontracting chain and the exit arrangements work together in practice.
| Test area | What the assessor checks and asks for | Common findings |
|---|---|---|
| Written contract completeness | Whether rights and obligations, including service levels, sit in one written document in a durable, accessible format. Assessors ask for the signed master agreement with all schedules and annexes. | Service levels held in a separate portal or email chain; schedules unsigned or referenced but missing from the file. |
| Clause-by-clause check for critical functions | Each mandatory Article 30(2) and 30(3) element is traced to a specific clause for services supporting critical or important functions. Assessors expect a clause map or checklist with section references. | Quantitative service level targets absent; no participation clause for the entity's TLPT; business contingency plan described only in general terms. |
| Subcontracting chain review | Whether the contract lists permitted subcontracting, and whether Article 4 of Delegated Regulation (EU) 2025/532 terms flow down: provider responsibility, subcontractor monitoring, equal access and audit rights, and notice of material changes. Assessors request the subcontractor list and the subcontract terms. | No subcontractor flow-down of audit or access rights; notice periods for material subcontracting changes not stated; subcontractors in third countries not disclosed. |
| Exit plan and transition period check | Whether exit strategies exist for critical functions and whether the contract sets an adequate, mandatory transition period. Assessors ask for the exit plan and evidence it has been tested or reviewed. | Transition period missing or undefined; exit plan written but not linked to data return; termination rights without matching notice periods. |
| Audit rights in practice | Whether unrestricted access, inspection and audit rights cover the entity and the competent authority, and whether they extend to subcontractors. Assessors look for past audit requests, scope letters or security reports the entity has actually used. | Audit rights limited to annual certificates; no authority access clause; access exercised only through the provider's own reports. |
| Microenterprise derogation use | Whether the entity qualifies as a microenterprise and whether the provider has validly delegated access, inspection and audit rights to an independent third party. Assessors check the entity's size status and the written delegation. | Derogation assumed without confirming microenterprise status; delegation agreed informally; independent third party not named or lacking appropriate independence. |
Contract evidence that passes review and how to keep it current
A reviewer testing Article 30 looks for a complete written contract, clauses that match the service's criticality, and proof that the documents still reflect how the service runs. The cards below cover the artifacts to collect and the routines that keep the contract register and clause map accurate between audits.
Signed master agreement and addenda
The reviewer expects one written document that holds the full contract, with service level agreements included, as Article 30(1) requires. Collect the signed master agreement, every addendum, and any order forms, then confirm they are read together with a clear order of precedence. Check that the signatory had authority to bind the provider and that the entity can retrieve the complete set in a durable, downloadable format.
Service level schedules with targets
For services supporting critical or important functions, Article 30(3) requires full service levels with precise quantitative and qualitative targets. Keep a schedule that states each metric, how it is measured, the reporting frequency, the measurement source, and the remedy when a target is missed. Ask the provider to confirm which monitoring data feeds each metric, since a target that cannot be measured will not satisfy a reviewer.
Subcontractor lists and flow-down clauses
Article 4 of Delegated Regulation (EU) 2025/532 sets what a contract must specify where critical services may be subcontracted. Maintain a current subcontractor list with locations and the services each one supports, plus flow-down clauses that pass down the provider's responsibility, the access and audit rights, and notice of material changes. Confirm that subcontractors are bound by these terms in their own contracts, not only by a statement from the provider.
Exit plans and transition periods
Article 30(3) requires exit strategies with a mandatory adequate transition period for critical or important functions. Store the exit plan with the contract, listing data return formats, the transition timeline agreed in writing, the named replacement options, and the trigger conditions for using the plan. Record when the plan was last tested, since an untested exit path is weak evidence for a reviewer.
Audit and access clause text
Article 30(3) requires unrestricted access, inspection and audit rights, including for the competent authority. Keep the clause text that grants these rights to the entity, its auditors and the competent authority, and note any delegation to an independent third party under the microenterprise derogation. Record which rights were exercised, the dates, and the findings, because a clause that has never been used tells a reviewer little about whether access works in practice.
Incident assistance and version history
Article 30(2) requires incident assistance at no cost or at a pre-agreed cost, so keep the schedule that states response channels, escalation contacts and fees. Pair it with the version history of every contract document, showing what changed, when, and who approved it. Confirm with the provider how amendments are recorded and whether the entity holds a signed copy of each version, because a reviewer will ask which clause applied on a given date.
What meeting Article 30 costs in legal review, negotiation and upkeep
This table breaks down the cost components of putting Article 30 clauses into ICT contracts, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to shape your quote requests and to decide which work to keep in-house. No prices or durations are given because none are supported by researched facts, so ask each party for a written estimate tied to your contract count and scope.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Internal legal and procurement review | Your legal, procurement and risk staff | One-time per contract, then recurring at renewal | Driven by contract count and whether each contract touches a critical or important function. Ask partners to split effort by Article 30(2) and 30(3) clauses. |
| Template rewrites | Internal legal or external counsel | One-time, with periodic refresh | Standard templates reduce per-contract work. Ask whether a quote covers mapping your templates to Article 30(2), 30(3) and Article 4 of Delegated Regulation (EU) 2025/532. |
| External counsel for negotiation | Outside law firm, billed by time or fixed fee | One-time per negotiated contract | Rises with provider leverage, such as large cloud providers that offer standard terms. Ask for fee basis, assumptions on negotiation rounds and what is excluded. |
| Provider negotiation effort | Your team and the provider's contract staff | One-time per contract, plus amendments | Rises when providers refuse audit rights, TLPT participation or exit periods. Ask which clauses are non-negotiable and where standard clauses are available. |
| Subcontracting chain review | Your legal team and provider's compliance staff | One-time per chain, recurring when subcontractors change | Grows with subcontracting depth. Ask for written confirmation of subcontractor flow-down terms and notice of material changes. |
| Register and clause tracking | Internal third-party risk or compliance owner | Recurring | Driven by the number of contracts and clauses to track. Ask whether tooling is included and who maintains the record after go-live. |
| Periodic re-review and renewal | Internal legal, risk and procurement staff, plus counsel if terms change | Recurring | Triggered by renewals, service changes and regulatory updates. Ask how the provider will notify you of changes that affect contract terms. |
How self-hosted tooling supports the contract evidence
Article 30 contracts are assembled from a set of clauses that must be consistent across providers, so many entities keep a master library of approved wording. A self-hosted wiki can hold that library with a record of every edit, which helps when a supervisor or internal auditor asks which version of a subcontracting clause applied at a given date. The wiki stores the history but does not decide whether the wording is legally sufficient.
- Versioned clause pages: XWiki keeps each change under version control, recording what changed, when and by whom.
- Version comparison: Reviewers can compare any two versions of a clause to see exactly what moved between negotiations.
- Rollback: A clause can be restored to an earlier approved version if a later edit is found to be wrong.
- Approval references: Each clause page can link to the approval record or ticket kept in the entity's own governance system, so the sign-off trail lives beside the wording.
- Clause mapping notes: Teams can record which Article 30(2) or 30(3) requirement each clause addresses, written by the entity rather than generated by the tool.
Before relying on this, confirm with legal counsel that the library is the approved source and that the wiki's retention and backup settings meet your record-keeping rules.
Contract documentation is only useful if the people editing it are the people authorized to do so. Role-based permissions in a self-hosted knowledge base let an entity separate those who draft clauses from those who approve them and from readers who only consult them. Access rules can then be tightened on sensitive areas, such as templates for critical or important function contracts, without restricting the whole organization.
- Role assignment: BookStack derives each user's abilities from the roles assigned to them.
- Scoped overrides: Permissions can be overridden per role at the shelf, book, chapter or page level, so a contract template book can be locked more tightly than a general policy book.
- Separation of drafting and approval: Drafting roles can be limited to edit access while approval roles hold publish rights, which supports a two-person review.
- Read-only access for auditors: External or internal reviewers can be given view rights without edit rights to the clause library.
- Access review: Role assignments can be exported or reviewed periodically to confirm that departed staff no longer hold editing rights.
Confirm that your identity integration and role design match your internal segregation-of-duties policy, and test the permissions with a real user from each role before the library goes live.
Clauses only show compliance when they are tied to the requirements they serve and to the evidence that a provider actually meets them. CISO Assistant is an open-source governance tool that ships a DORA framework and can run assessments against it, which lets an entity link each ICT services contract to the framework requirements and the evidence collected for that provider. The tool holds the assessment record. The conclusion that a contract is adequate remains a decision for the entity and its advisers.
- Framework library: The tool ships more than 200 frameworks, including DORA, so the entity can work from the framework it is already obliged to address.
- Assessment records: Assessments can be run against DORA and linked to individual provider contracts and their supporting evidence.
- Automatic mapping: The tool performs automatic mapping between frameworks, which should be checked against the entity's own reading of each requirement before it is relied upon.
- Evidence attachment: Signed contracts, audit reports and due diligence records can be attached to the relevant assessment items.
- Licensing: CISO Assistant is licensed under AGPL-3.0-only, which governs how modified versions must be shared if the entity distributes them or offers them as a network service.
Before use, ask your implementation partner which DORA framework version the tool ships and confirm that the mappings reflect the Article 30 wording your legal team has adopted.
Open-source tools reduce licence cost but add obligations that must be understood before they hold contract evidence. The three tools covered here carry different licences, and each licence affects how an entity can modify, host and share the software. None of them makes a contract compliant, and none replaces the legal review that Article 30 expects for each agreement.
- XWiki (LGPL-2.1-or-later): Modified library components may need to be shared under the same terms, while the wider deployment is governed by the licence's linking rules.
- BookStack (MIT): The permissive licence allows broad use and modification with the copyright notice retained.
- CISO Assistant (AGPL-3.0-only): Network-facing modifications may trigger source disclosure obligations, so hosting it for internal users should be checked against the licence.
- Limits of the tools: Software stores clauses, roles and assessments, but it cannot negotiate terms, verify a provider's security or decide whether an exit plan is workable.
- Cost components: Hosting, backup, integration with identity systems and staff time for maintenance are paid to the entity or its partner, while the licence itself carries no fee.
Ask legal counsel to confirm how each licence applies to your planned use, and ask your implementation partner to document the hosting and maintenance responsibilities in writing.
Where Article 30 contracts usually fall short
Most ICT contracts were written for general commercial use, not for the specific clauses Article 30 requires. The six gaps below recur in reviews of cloud and software agreements, and each one can leave a financial entity unable to show supervisors that it controls its ICT provider.
Standard cloud terms without audit rights
Standard terms often grant the customer a right to certified reports but no right to inspect, audit or access the provider's premises, systems and staff. For services supporting critical or important functions, Article 30(3) requires unrestricted access, inspection and audit rights, including for the competent authority. Check whether the clause covers the entity's own auditors and regulators, and whether it extends to subcontractors. Where the provider is a microenterprise, confirm whether an independent third party has been appointed to exercise these rights.
Missing exit transition periods
Many agreements end on termination with a short data export window and no defined support during migration. Article 30(3) requires exit strategies with a mandatory adequate transition period, so the entity can move the service without disrupting the function it supports. Ask for a written transition period, a defined exit assistance scope and the format in which data will be returned. Test whether the exit plan can be executed within that period before signing.
Vague service levels
Contracts frequently describe availability in general terms such as commercially reasonable or industry standard. Article 30(3) requires full service levels with precise quantitative and qualitative targets, along with notice and reporting duties. Specify measurable targets, measurement methods, reporting frequency and the remedies for missed targets. Confirm that the service levels are part of the single written document described in Article 30(1), not a separate schedule that can be changed unilaterally.
Unmanaged subcontractors
Providers often reserve a broad right to subcontract without notice, leaving the entity unaware of who processes its data or runs its systems. Delegated Regulation (EU) 2025/532 requires that the provider stay responsible for subcontractors, that they grant the same access and audit rights, and that material changes be notified. Require a current subcontractor list, advance notice of material changes, and a termination right if the entity objects to a new subcontractor.
Incident assistance costs not agreed in advance
Article 30(2) requires incident assistance at no cost or at a pre-agreed cost. Many contracts leave the charge open, so the entity may learn during a live incident that support is billable at rates it never reviewed. Ask the provider to state in the contract whether incident assistance is included, what additional work is charged and at what rates, and how that interacts with the entity's reporting obligations. Agree these terms before the service starts, not during an outage.
Data return clauses that fail on insolvency
Data return clauses often assume the provider will still be operating at termination. Article 30(2) requires data protection and data return on insolvency or termination, so the entity can recover its data even if the provider fails. Check who holds the data, in what format it can be retrieved, whether retrieval works without the provider's cooperation, and whether escrow or export arrangements exist. Confirm the clause against the provider's insolvency position and the entity's own data recovery tests.
Questions buyers ask about Article 30 contract work
How much effort does an Article 30 contract review take?
The effort depends mainly on how many ICT contracts the entity holds, how many support critical or important functions, and how far each contract departs from the Article 30 clauses. A standard-terms agreement for a non-critical tool mostly needs a clause checklist and a gap list. A contract supporting a critical or important function needs service levels, access and audit rights, TLPT participation, exit terms and subcontracting terms checked line by line, followed by negotiation. Other drivers include whether the entity uses its own template or the provider's paper, how many subcontractors sit in the chain, the number of governing jurisdictions, and whether the register of information must be updated at the same time. Ask any partner to break the work down by contract, clause and negotiation round before agreeing a total.
Can our own legal and procurement team do this without outside help?
Often yes for the clause mapping, provided lawyers who understand DORA and procurement staff who run the contract lifecycle do the work. The entity owns its contracts and the legal interpretation, so counsel must sign off on every position. Outside technical help is most useful for the parts that need engineering evidence: documenting service levels and how they are measured, describing security measures and business continuity arrangements, mapping the subcontracting chain, and writing down exit steps that can actually be tested. DeployOpen prepares systems, controls and evidence for assessments, but it does not give legal advice or issue opinions. If you use a compliance platform such as CISO Assistant, confirm for yourself how fully its DORA framework covers Article 30 before relying on it.
What should a fixed-scope quote for contract work include?
A useful fixed-scope quote lists the work in terms you can check against delivery. It should name the contracts in scope by identifier, state which functions each one supports, and set out the deliverables, such as:
- A clause gap assessment against the Article 30(2) and 30(3) requirements for each contract
- Drafted addenda or updated templates for the gaps you agree to close
- A review of subcontracting terms against Article 4 of Delegated Regulation (EU) 2025/532 where critical services may be subcontracted
- An evidence pack for service levels, exit plans and business continuity clauses
The quote should also state exclusions, including negotiation with providers, legal opinions and regulator submissions, along with assumptions about provider cooperation and a change process for new contracts. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Does the microenterprise derogation apply to our ICT contracts?
It applies only if your organization is a microenterprise under the size definition in DORA, and only where the provider agrees to it. Its effect is narrow: the entity's access, inspection and audit rights may be delegated to an independent third party appointed by the provider. It does not remove the other Article 30 clauses, and it does not apply automatically to every contract. Because the derogation sits within the rules for services supporting critical or important functions, check whether any of your contracts fall in that category before relying on it. Confirm your size classification and how your national competent authority reads the arrangement, and record the agreement in writing in the contract itself.
How do we handle cloud provider standard terms under DORA?
Start by checking whether the provider's standard terms already contain the Article 30(2) items, including data location, data return, incident assistance, cooperation with authorities and termination rights. Terms often cover some of these but leave gaps, usually around audit and access rights, transition periods on exit, and visibility of subcontractors. Where terms fall short, the options are to negotiate an addendum, to use a regulatory addendum if the provider offers one (confirm this in writing), or to accept a documented gap as a management risk decision. Article 30(4) asks entities to consider standard contractual clauses developed by public authorities for specific services, so check whether one applies. Standard terms still count as ICT service contracts even when you run self-hosted open-source platforms in your own cloud account.
How often do ICT contracts need re-review under DORA?
The frequency is set by your third-party policy and by what your supervisor expects, so confirm both rather than relying on a single date from this page. In practice, most organizations re-review a contract on renewal and whenever a trigger occurs. Common triggers include a material change in the service or where data is processed, a new or changed subcontractor, a significant ICT incident involving the provider, a change to the register of information, findings from testing or audits, and a change in the regulatory technical standards that applies. Record each review, the date and the decision taken, so the file shows that the contract was checked against the current requirements.
Do contracts signed before 17 January 2025 need updating?
DORA has applied since 17 January 2025, so contracts signed earlier may fall short of Article 30 even if they were valid when signed. Check the Regulation's transitional provisions and confirm how your competent authority expects existing contracts to be handled, because this page does not set out those rules in full. In most cases you will need to identify the gaps, agree a plan with each provider, and prioritize contracts that support critical or important functions. Keep a dated record of each contract's status, the gaps found, and the amendments agreed, since the file is the evidence your supervisor will ask for.
How DeployOpen prepares contract evidence for DORA reviews
DeployOpen prepares the contract evidence that a financial entity's review team needs when it tests its ICT services contracts against Article 30. The work is fixed-scope: the client and DeployOpen agree in writing which contracts, which services and which deliverables are included before any work starts. For the client's own agreements, DeployOpen can build a clause map that lists each Article 30(2) and, where a critical or important function is supported, Article 30(3) element, then records where the wording in each contract satisfies it, where it is missing and where a schedule or side letter holds the answer. The same map can show which ICT services fall under which contract, so the review starts from one inventory rather than from a folder of PDFs.
DeployOpen also assembles the inputs that feed the register of information, the subcontracting evidence required under Article 4 of Delegated Regulation (EU) 2025/532, and the exit plan records for each contract in scope. For subcontracting, that means the list of subcontractors the provider has disclosed, the notices of material changes, and the clauses that give the entity its termination rights and the same access and audit rights along the chain. For exit, it means the documented transition period, the data return and deletion terms, and the step records from any exit test the client has run. The client decides what the evidence says and whether a gap is accepted, mitigated or escalated to the provider.
DeployOpen does not issue audit reports, attestations or certifications, and it does not give legal advice on contract wording. Whether a clause is legally sufficient is a question for the organization's legal counsel, and whether the control environment meets DORA is a question for the competent authority or the independent auditor the entity appoints. Before engaging, ask for the written scope, the list of deliverables, the named client owners who will approve the clause map, and confirmation of which contracts are excluded. Confirm with your counsel and with your competent authority which supervisory expectations apply to your entity type.

