2026-10-02 DORA

The DORA Article 30 addendum. 12 clauses you will sign as an ICT provider

Your bank sent a DORA contract addendum? We break Article 30 of Regulation 2022/2554 down into the 12 clauses you will find in it, and show what you can negotiate and what you need in place before you sign.

So, the addendum has arrived. A dozen pages, a heading that says “pursuant to the DORA Regulation”, and sentences like “The Provider grants unrestricted rights of access, inspection and audit”. Deadline for signature… yesterday, of course.

Relax. Almost everything in that addendum comes from a single provision, Article 30 of Regulation (EU) 2022/2554. Take it apart and you get 12 clauses. Each one can be understood, some can be negotiated, and every one of them needs something behind it in your company, so you do not sign an empty promise.

TL;DR

Article 30(2) DORA is the minimum for every ICT services contract with a financial entity; Article 30(3) adds more when your service supports a critical or important function
Add the points up, merge the ones that overlap, and you get 12 addendum clauses
Costs, deadlines, how audits are run and the length of the transition period are negotiable; the presence of the clauses is not, because the bank gets them straight from the regulation
Every clause needs a document or a process on your side: SLAs, an incident procedure, a BCP, a subcontractor register, an exit plan

Where the DORA addendum comes from

The DORA addendum is Article 30 translated into your contract. The regulation is addressed to the bank, but Article 30 states explicitly what must be in a contract with an ICT third-party service provider. The bank has no choice, so it sends you an addendum.

Article 30(1) requires the rights and obligations of both parties to be clearly allocated and set out in writing, and the full contract, service levels included, to sit in one written document, on paper or in a downloadable, durable and accessible format. That is why the addendum often pulls together things that used to be scattered across emails, terms of service and annexes.

Then there are two levels. Paragraph 2 applies to every ICT services contract, even if all you build for the bank is an internal shift-planning app. Paragraph 3 applies on top when the service supports a critical or important function. Whether it does is the bank’s call, not yours… and it is worth asking directly, because half of the addendum depends on the answer.

How we count to 12: paragraph 2 has nine points (a to i), paragraph 3 has six (a to f). Three pairs cover the same topic, so we merge each pair into one clause: service levels (2(e) and 3(a)), termination (2(h) and 3(b)), and data plus exit (2(d) and 3(f)). Fifteen minus three is twelve.

Paragraph 2 clauses: the minimum for every ICT contract

1. Service description and subcontracting

Article 30(2)(a) requires a clear and complete description of all functions and ICT services. It also requires a statement on whether you may subcontract an ICT service supporting a critical or important function (or material parts of it), and if so, under what conditions.

In practice this is the end of descriptions like “IT services as needed”. The bank has to enter your service in its register of information, so the description must be specific: what, in what scope, on what infrastructure. For subcontracting, Commission Delegated Regulation (EU) 2025/532 sets out what the bank must assess before it accepts a subcontractor.

This is where a subcontractor register pays off. Cloud provider, external SOC, a freelancer with production access… if they take part in delivering the service, the bank wants to know.

2. Service and data locations

Point (b) covers the locations, meaning the regions or countries, where you provide the services and process data, storage location included. Plus an obligation to notify the bank in advance if you plan to change those locations.

Sounds simple, until someone on the team moves backups to a cheaper cloud region. Done without telling the client, that change breaches the addendum. You need a map: service, environment, region, backups, subcontractor.

You can negotiate how far in advance you notify and through which channel. The obligation itself is not up for discussion.

3. Data protection

Point (c) requires provisions on the availability, authenticity, integrity and confidentiality of data, personal data included. This is the clause where the bank usually refers to its own security requirements or attaches a list of technical measures.

If you process personal data on the bank’s behalf, this clause goes hand in hand with the GDPR data processing agreement. Ideally the two do not contradict each other… same description of security measures, same locations, same subcontractor list. We covered the traps of processing agreements in the data processing agreement article.

4. Service levels (SLA)

Point (e) requires service level descriptions, including updates and revisions. For a critical or important function, Article 30(3)(a) goes further: full service level descriptions with precise quantitative and qualitative performance targets, so the bank can monitor the service effectively and take corrective action without undue delay when service levels are missed.

So “we use our best efforts” is a museum piece. The bank needs numbers: availability, response time, restoration time, how it is measured, how it is reported. And a procedure for what happens when the numbers do not add up.

There is real room to negotiate here. SLA values, maintenance windows, how availability is calculated, penalties… all of that is agreed between you. Just put in only what your team can actually deliver and measure.

5. Assistance with ICT incidents

Point (f) is the obligation to assist the bank when an ICT incident related to your service occurs. At no additional cost, or at a cost determined ex ante.

This is one of the most important decisions in the whole addendum. Banks often default to “at no additional cost”, while the regulation explicitly allows the other option. If incident assistance means real hours of senior engineers’ time, propose a rate fixed in the contract.

Then there is timely notification. Article 30 does not set specific hours; the bank does, because it has tight reporting deadlines towards its supervisor. Reportedly the most common provider mistake is agreeing to a deadline the team cannot meet at the weekend. An incident procedure with on-call duty and an incident register is the bare minimum here.

6. Cooperation with supervisors and resolution authorities

Point (g) obliges you to cooperate fully with the bank’s competent authorities and resolution authorities, including persons they appoint. In Poland, the competent authority for DORA is the Polish FSA (KNF), and the resolution authority for banks is the Bank Guarantee Fund (BFG).

You will not negotiate this clause away, and there is no point trying. What you can agree is who your contact person is and how the bank gives notice of such activities. Better one person with common sense than five who keep passing the ball.

7. Termination and reporting obligations

Point (h) requires termination rights and related minimum notice periods, in line with the expectations of competent authorities and resolution authorities. On top of that, Article 28(7) DORA requires the bank to be able to terminate, among other cases, for a significant breach of law or contract by the provider, for weaknesses in the provider’s ICT risk management, or when the contract’s terms prevent the supervisor from effectively supervising the bank.

For a critical or important function, Article 30(3)(b) adds notice periods and reporting obligations for the provider. That includes notification of any development that might materially affect your ability to deliver the service in line with the agreed service levels. An acquisition, the core team leaving, a cloud provider switch… the bank wants to hear it early, not from LinkedIn.

You cannot remove the termination grounds from Article 28(7). You can negotiate your own termination rights and a sensible period during which the bank keeps paying after notice.

8. Participation in the bank’s training

Point (i) covers the conditions for your participation in the bank’s ICT security awareness programmes and digital operational resilience training (linked to Article 13(6)). Where appropriate, the bank includes providers in its training, and the contract must set the conditions.

Agree who attends, how often, how many hours and whether that time is billable. Keep a training register, because at audit time the bank will ask who on your team completed it.

Paragraph 3 clauses: when you support a critical or important function

9. Business contingency plans and ICT security measures

Article 30(3)(c) requires the provider to implement and test business contingency plans and to have ICT security measures, tools and policies that provide an appropriate level of security for the service, in line with the bank’s regulatory framework.

The key word is “test”. A business continuity plan nobody has exercised is worth as much as the paper it is printed on. You need a BCP, a backup policy and a record of a restore test, with a date and a result.

The bank may also attach a list of its own security requirements. Read it before signing, point by point, and mark what you do not meet. Better to say so now, with a plan to close the gap, than to have it surface at an audit.

10. Participation in TLPT

Article 30(3)(d) is the obligation to participate and fully cooperate in the bank’s threat-led penetration testing (TLPT) under Articles 26 and 27. Not every bank runs TLPT, only entities identified by the supervisor, but the clause goes into the contract anyway.

If your service is in TLPT scope, testers may target your part of it too. Agree up front how coordination works, who is the contact during the test, who bears the costs on your side and how other clients on the same infrastructure are protected.

11. Access, inspection and audit rights

Article 30(3)(e) is the clause that scares people most. The bank must be able to monitor your service on an ongoing basis, including unrestricted rights of access, inspection and audit (for itself, an appointed third party and the competent authority) and the right to take copies of relevant documentation on site. Other contractual arrangements must not impede or limit those rights.

Add to that the obligation to cooperate fully during on-site inspections, supervisors included, and the requirement to set out the scope, procedures and frequency of inspections and audits. That is where you have room to manoeuvre: advance notice, scheduling, a named contact, confidentiality rules.

Point (ii) matters. The regulation provides for agreeing alternative assurance levels where an audit would affect other clients’ rights. For a shared service, a typical SaaS, that is the argument for third-party audit reports, certifications and pooled audits instead of ten audit teams in your server room.

There is one exception, and it only applies when the bank, insurer or other financial entity is itself a microenterprise. Then the parties may delegate audit rights to an independent third party appointed by the provider. Your own size does not matter here.

12. Data return and exit strategy

Article 30(2)(d) requires provisions on access to, recovery and return of personal and non-personal data in an easily accessible format if you become insolvent, go through resolution, discontinue your business or the contract is terminated. That applies to every ICT contract.

For a critical or important function, Article 30(3)(f) adds exit strategies with a mandatory, adequate transition period. During it you keep providing the service while the bank migrates to another provider or in-house, consistent with the complexity of the service.

You negotiate the length of the transition period, the rates during it, the export format and the scope of migration support. You do not negotiate whether the bank has a real way out. A well-described exit plan is also a sales argument, because it shows you are not holding the client hostage.

Trap: agreeing to "export of all data within 7 days in any format specified by the Bank". If your system has no export, you have just committed to building one at your own cost, under time pressure, at the worst moment in the client relationship.

What is negotiable and what is not

You will not negotiate the Article 30 clauses out of the contract. The bank gets them from the regulation and answers to its supervisor if they are missing. If you hear “we cannot delete that”, it is usually true.

What you can negotiate are the parameters. The cost of incident assistance (Article 30 allows a cost fixed ex ante), SLA values, notification deadlines, audit procedure and alternative assurance, the length of the transition period and its rates, training conditions. Article 30(4) also asks the parties to consider standard contractual clauses developed by public authorities… if the bank uses them, the conversation tends to be shorter.

The second thing is classification. If your service supports no critical or important function, clauses 9 to 11 and parts of clauses 4, 7 and 12 do not have to be in your contract. Ask the bank directly how it has classified you. Reportedly there are addenda with the full paragraph 3 for a company that prints leaflets :D

What to have ready before you sign

Each of the twelve clauses is a commitment. To be able to deliver on them you need a handful of documents and registers, not a full ISMS with a certificate. A service description and a subcontractor register with locations cover clauses 1 and 2. An ICT security policy covers clause 3 and part of 9.

An incident procedure with an incident register covers 5. An SLA description with a measurement method covers 4. A BCP with a backup policy and a restore test record covers 9. A training and testing register covers 8 and 10, and an exit plan with a data export description covers 12.

Once you have all that, the addendum stops being scary. You read a clause, check the document, then sign or negotiate the parameter. Job done.

Not sure where your gaps are? Run the free DORA gap analysis; it has a separate section for ICT service providers and shows what is missing straight away. The table mapping bank questionnaire questions to the documents that answer them is on our DORA for ICT providers page (in Polish). Ready-to-edit DORA documentation with procedures, registers and an exit plan is in the DORA Documentation package.

Rule: only sign what you can prove with a document or a log. The DORA addendum gives the bank audit rights, so sooner or later every clause gets checked.

Sources

Regulation (EU) 2022/2554 of the European Parliament and of the Council on digital operational resilience for the financial sector (DORA), Article 30 (key contractual provisions), Article 28(7), Article 13(6), Articles 26 and 27
Commission Delegated Regulation (EU) 2025/532 (elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions)
Commission Implementing Regulation (EU) 2024/2956 (standard templates for the register of information)

This article describes the law and market practice; it is not legal advice on any specific contract. For a large contract, have the addendum reviewed by a lawyer who knows DORA.

Written by someone on the RealSec team. Want to talk specifics ; get in touch.

← All notes