Why the customer has suddenly stopped negotiating
The usual reading of the addendum is that the other side's legal team is over-insuring itself. Most of the time that is wrong.
DORA Article 28(1)(a) says the financial entity remains fully responsible for compliance with the Regulation, including for the services it has contracted out to you. It cannot transfer that responsibility. It can only secure, by contract, the means to discharge it. That is what the clauses are.
Article 30 goes further and names what the contract must contain. The wording is "shall include at least the following elements". There is no threshold for supplier size, no carve-out for small contracts. If your customer signs an ICT services contract without those elements, the next supervisory review records a deficiency against them, not against you.
The required elements constrain the negotiation. Their practical implementation still needs agreement: scope, evidence, service levels and costs must work for both parties within the legal requirements.
Telling those two apart is the whole of your position.
Which clauses are the law and which are the customer's preference
DORA Article 30(2) contains nine minimum contractual elements. The table is a negotiation checklist, not a substitute for the legal wording or the actual contract.
| Element | Reference | Practical preparation |
|---|---|---|
| Description of functions and ICT services, including relevant subcontracting conditions | 30(2)(a) | Maintain a service schedule and change process |
| Service and data-processing locations, including storage, and advance notice of changes | 30(2)(b) | Identify countries or regions as required and check subcontractors |
| Availability, authenticity, integrity and confidentiality of data | 30(2)(c) | Describe the safeguards and how they are evidenced |
| Access, recovery and return of data in the specified disruption or termination circumstances | 30(2)(d) | Test usable export and recovery arrangements |
| Service-level descriptions, including updates | 30(2)(e) | Agree measurable service commitments |
| Assistance for an ICT incident related to the service | 30(2)(f) | Agree no additional cost or a price determined in advance |
| Cooperation with competent and resolution authorities | 30(2)(g) | Define contacts and a cooperation procedure |
| Termination rights and related minimum notice periods | 30(2)(h) | Check continuity and exit implications |
| Conditions for participation in security-awareness and digital-resilience training | 30(2)(i) | Agree participation conditions and responsibilities |
For services supporting critical or important functions, Article 30(3) adds service targets, reporting and notice duties, tested contingency arrangements and security measures, TLPT cooperation, access/inspection/audit rights and exit arrangements with transition. The clause on tested contingency plans does not itself prescribe a universal annual supplier test.
The required subject cannot simply be deleted. Its implementation, evidence, notice and cost may still need negotiation within the legal constraints. Alternative assurance under Article 30(3)(e)(ii) is conditional, particularly where other clients’ rights are affected; a certificate does not automatically replace all audit rights.
"Critical or important function" is the phrase that decides half the contract
The financial entity determines which functions are critical or important using the Article 3(22) criteria and a documented assessment. Ask which function your service supports and why the classification applies.
Article 30(3) adds requirements for those services. If your service does not support such a function, those additions are not automatically mandatory under that paragraph. The customer may nevertheless request similar terms for risk or commercial reasons. Separate the legal minimum from the proposed contractual commitment.
For microenterprise customers, Article 30(3) allows delegation of access, inspection and audit rights to an independent third party appointed by the provider, while preserving the financial entity’s right to request information and assurance on performance. This is a conditional arrangement, not a blanket removal of customer oversight.
What they will ask for outside the contract
The addendum is only the first part. Three other things usually arrive alongside it.
A security questionnaire, often several hundred rows. How to meet one without rewriting your answers for every customer is covered separately in the article on answering a customer security questionnaire.
Data for the register of information. Article 28(3) of DORA obliges the financial entity to maintain a register of all contractual arrangements on the use of ICT services. Implementing Regulation (EU) 2024/2956 sets the templates and requires providers to be identified by a valid LEI or EUID. They will ask you for that identifier, your exact locations, your subcontracting chain and the dates. What that register holds, and why the questions look so oddly specific, is set out in the piece on the DORA register of information.
Evidence. Not statements — records. A test result, a date, a scope, and who performed it. The difference between a declared control and a verified one is the practical difference between an answer that closes and an answer that generates ten more questions.
What to do first
- Map each proposed clause to a legal requirement or a customer-specific request. Discuss workable implementation of both.
- Ask for the supported function and its criticality classification in writing.
- Agree the incident-assistance service and price mechanism before an incident.
- Test data export and return, including the format the customer can actually use.
- Organise current evidence using the questionnaire evidence guide; adapt the scope and confidentiality arrangements for each customer.
- Confirm the identifier required for the register. Legal-person ICT providers established in the EU can be identified using a valid active LEI or EUID under the applicable rules; non-EU legal-person providers require an LEI. Natural persons use the specified alternative identifiers. Do not buy an LEI merely because somebody assumed it was the only option.
The DORA control-evidence guide helps connect a contract promise with the record showing that it works.
The boundary: a contractual obligation is not a direct legal obligation
Supplying a financial entity does not by itself turn the supplier into a financial entity under DORA. The customer retains its responsibilities and secures necessary commitments through the contract. Designation as a critical ICT third-party provider brings the separate DORA oversight framework; do not confuse that designation with a customer's classification of one function as critical.
A supplier may also have direct duties under NIS2, GDPR or other applicable law because of its own activities and circumstances. Assess those separately. See NIS2 in Bulgaria and the DORA/NIS2 comparison.
The commercial argument
If you are negotiating with a financial entity, the speed of your answer is a competitive advantage, not an administrative cost. Deals stall for months because the supplier cannot show where data is processed, who the subcontractors are, and when the recovery plan was last tested. A supplier who answers that in a week takes the work from a supplier who answers in three months.
A maintained evidence library reduces repeated work. Each new customer still requires a scope check, current records and a review of additional terms.
If the addendum is already on your desk, an Evidence Sprint assembles exactly that evidence into a pack you can send to this customer and reuse for the next one.
Note. This is general information, not legal advice. Applicability depends on the specific entity, its activity, licence, size, group structure and national implementation.