Article 30 Key contractual provisions

Article 30 sets the clauses every ICT services contract under DORA must contain, with extra terms for critical or important functions. This page explains each group, how assessors test them and what evidence passes.

On this page

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.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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 areaWhat the assessor checks and asks forCommon findings
Written contract completenessWhether 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 functionsEach 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 reviewWhether 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 checkWhether 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 practiceWhether 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 useWhether 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 componentWho is paid or who spends timeOne-time or recurringWhat drives it and what to ask for
Internal legal and procurement reviewYour legal, procurement and risk staffOne-time per contract, then recurring at renewalDriven 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 rewritesInternal legal or external counselOne-time, with periodic refreshStandard 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 negotiationOutside law firm, billed by time or fixed feeOne-time per negotiated contractRises 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 effortYour team and the provider's contract staffOne-time per contract, plus amendmentsRises when providers refuse audit rights, TLPT participation or exit periods. Ask which clauses are non-negotiable and where standard clauses are available.
Subcontracting chain reviewYour legal team and provider's compliance staffOne-time per chain, recurring when subcontractors changeGrows with subcontracting depth. Ask for written confirmation of subcontractor flow-down terms and notice of material changes.
Register and clause trackingInternal third-party risk or compliance ownerRecurringDriven 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 renewalInternal legal, risk and procurement staff, plus counsel if terms changeRecurringTriggered 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.

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.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.