What a DORA Addendum Actually Asks You to Sign

A DORA addendum is not a negotiation over whether terms apply. It is your customer transcribing Articles 28 to 30 of Regulation (EU) 2022/2554 into your contract because they are not permitted to buy ICT services without those terms in place. Article 30(2) sets nine baseline items that every ICT arrangement must carry. Article 30(3) adds six more whenever the service supports what the regulation calls a critical or important function, and one of them, unrestricted rights of access, inspection, and audit, is where roughly every deal we have watched slow down. The productive move is not to argue about whether a clause belongs in the contract. It is to work out which of the two sets applies to you, then negotiate how each right gets exercised.

Below is the clause-by-clause read, what each item means operationally, and the three places a vendor can reasonably push back.

Key takeaways

• A DORA addendum is your customer transcribing Articles 28 to 30 into your contract because they are not permitted to buy ICT services without those terms in place.
• Article 30(2) sets nine baseline terms for every ICT contract. Article 30(3) adds six more whenever the service supports a critical or important function.
• The trigger is the function, not the contract value or the data volume, and the determination belongs to the financial entity rather than to you.
• The existence of the audit right is not negotiable; the manner of exercise is. Lead with a proposed audit protocol, a current assurance report and a named contact rather than a redline.
• The exit plan is an engineering deliverable, not a paragraph. Ask whether a customer could extract their full dataset in a documented format, with no professional services engagement, while terminating for cause.

The baseline set: Article 30(2)

These nine apply to every ICT contract a financial entity holds, whatever the service does.

• A clear and complete description of all functions and ICT services, including whether subcontracting is permitted for services supporting critical or important functions and under what conditions
• The locations, meaning the regions or countries, where the contracted and subcontracted services are provided and where data is processed
• Provisions on availability, authenticity, integrity, and confidentiality of data, including personal data
• Provisions on access, recovery, and return of data in an easily accessible format on the provider's insolvency, resolution, discontinuation of business, or contract termination
• Service level descriptions, including their updates and revisions
• An obligation to provide assistance at no additional cost, or at a cost determined ex ante, when an ICT incident related to the contracted service occurs
• An obligation to cooperate fully with the entity's competent authorities and resolution authorities
• Termination rights and associated minimum notice periods in line with supervisory expectations
• Participation in the financial entity's ICT security awareness programmes and digital operational resilience training

Read that list as a specification for four artifacts rather than nine paragraphs: a service and data-flow description, a processing-locations record, a data export and return capability, and a written incident support commitment. Vendors who already maintain a solid security addendum have three of the four in some form. The one almost nobody has is the export capability described in a way an auditor could test.

The enhanced set: Article 30(3)

Whenever the ICT services support a critical or important function, six more terms attach:

• Full service level descriptions with precise quantitative and qualitative performance targets so that performance can actually be monitored and corrective action taken without undue delay when targets are missed
• Notice periods and reporting obligations for developments that could materially affect the provider's ability to deliver effectively
• An obligation to implement and test business contingency plans and ICT security measures appropriate to the entity's regulatory framework
• Participation in and full cooperation with the entity's threat-led penetration testing under Article 26
• Unrestricted rights of access, inspection, and audit, exercisable by the entity, an appointed third party, or the competent authority, with unrestricted rights to take copies of relevant documentation
• Exit strategies, in particular a mandatory adequate transition period during which the provider continues to supply the service while the entity migrates or moves in-house

The trigger is the function, not the contract value or the data volume, and the determination belongs to the financial entity. This is worth saying twice because vendors routinely negotiate against the wrong set: a small contract supporting a payment authorization path carries the enhanced terms, while a large contract supporting internal marketing analytics may not.

Unrestricted audit rights, and what is actually negotiable

"Unrestricted rights of access, inspection and audit" reads, to a vendor with two hundred customers, like an invitation for two hundred auditors. That is not how it works in practice, and it is not what the regulation is optimizing for.

What is not negotiable is the existence of the right. Your customer cannot lawfully hold the contract without it, so a redline that strikes the clause asks them to choose between the regulation and your product. They will choose the regulation.

What is negotiable, and routinely agreed, is the manner of exercise. Reasonable notice periods. Frequency caps outside of cause-based triggers. Scope limited to the services actually provided to that customer. Pooled audits, where a group of financial customers appoints one auditor and shares the output, which DORA's own supervisory expectations contemplate. Reliance on independent third-party assessments, including a current SOC 2 Type II or ISO 27001 certificate, as the first line of evidence, with on-site inspection reserved for what those reports do not cover. Confidentiality and safety controls governing what an auditor may access in a multi-tenant environment.

Vendors who lead with a redline lose weeks. Vendors who lead with a proposed audit protocol, an existing assurance report, and a named contact usually close.

Subcontracting: the chain has to be visible

Article 30(2)(a) requires the contract to state whether subcontracting of services supporting critical or important functions is permitted, and under what conditions. Article 28(3) then requires your customer to record the arrangement, and its chain, in the register of information they file with their supervisor.

The operational consequence for a vendor is a list you probably do not maintain in a usable form: every subprocessor and infrastructure provider that touches the service, what each does, and where. Most companies have a privacy subprocessor list built for GDPR, which is a good start and not the same thing, because DORA's interest is operational resilience rather than personal data. A cloud region, a CDN, a managed database, an observability vendor with production access, and an offshore support desk all belong in the resilience picture whether or not they process personal data.

Build the list once, keep it current, and publish it. It converts a recurring diligence scramble into a URL. The vendor risk management program guide covers the mechanics of maintaining that inventory on your side of the relationship.

Exit plans are an engineering deliverable, not a paragraph

Article 28(8) requires financial entities to put in place exit strategies for ICT services supporting critical or important functions, accounting for provider failure, deteriorating service quality, business disruption, and the risk that the service becomes inappropriate. The entity has to identify alternative solutions and develop transition plans that let them remove the service and their data from you without disrupting their business or their own regulatory compliance.

Their obligation becomes your deliverable through Article 30(3)(f): the mandatory transition period during which you keep the service running while they migrate.

Vendors consistently underestimate this one. It is not a clause, it is a capability. Can a customer extract their full dataset, including historical records, in a documented format, without a professional services engagement? Can they do it while their contract is being terminated for cause, when the relationship is not friendly? Is the format documented well enough that a competitor could ingest it? If the honest answer to any of those is no, the exit clause you signed is a commitment you cannot currently honor, and that is a discovery best made before an incident rather than during one.

What your customer needs from you for their register

Give this to your account team as a standing checklist, because the same six items come back on every questionnaire:

• A precise description of the service and the functions it supports
• The countries and regions where the service is provided and where data is processed and stored
• The subcontracting chain, by name, with what each subcontractor does
• Service levels and the performance targets that back them
• Your incident notification commitments and the support you provide at no additional cost during an incident
• Your data return format and the transition support you will provide on exit

Publish all six in one document and refresh it quarterly. Every hour spent standardizing that pack is an hour not spent answering the same questions in six different customer templates.

Where a vendor should push back

Three places, and they are worth holding.

Unlimited free professional services. "Assistance at no additional cost" under Article 30(2)(f) attaches to ICT incidents related to the contracted service. It is not an open-ended commitment to unpaid engineering for anything the customer calls an incident. Define the trigger, and define it against the reporting clocks your customer is actually working to.

Scope creep past the services you actually provide. Audit and inspection rights attach to the contracted ICT services. A request to inspect infrastructure that has no relationship to that customer's service is outside the clause, and saying so politely is not obstruction.

The wrong function determination. If your service does not support a critical or important function and your customer has applied the enhanced set by template, ask for the determination in writing. Whether DORA reaches you at all turns on that answer. You are not asking them to lower their standards. You are asking them to apply the standard the regulation actually sets, and their risk function will usually agree.

What is not worth holding: the existence of audit rights, subcontracting transparency, and data return. Those are load-bearing, and a vendor known for fighting them acquires a reputation in a small market.

Where Top Floor fits

Most of what we do here is unglamorous and finite. We read the addendum against the regulation, tell you which clauses are Article 30(2) baseline and which are Article 30(3) enhanced, map each to evidence you already hold, and produce the standing pack your account team hands out. That is our DORA practice applied from the vendor side, and it is often a matter of weeks rather than a program.

If your bigger problem is that nobody in the company owns these questions, that is a security-leadership gap rather than a regulatory one, and a vCISO engagement is the better-fitting answer. If you have a strong internal security lead and a current assurance report, you may need a review rather than an engagement, and we would rather tell you that early.

How to decide this week

Take the addendum on your desk. Split every obligation into Article 30(2) baseline and Article 30(3) enhanced, using the two lists above. For each item, write the artifact that would evidence it and where that artifact lives today. Anything with no artifact is your project, and it is usually three or four items rather than fifteen.

Then send your customer one question: does this service support a critical or important function, and can you confirm that determination in writing? The answer decides half the list.

Frequently asked questions

Can we negotiate DORA audit rights out of the contract?

No, and pushing for that wastes the goodwill you will need elsewhere. Article 30(3) requires unrestricted rights of access, inspection, and audit for ICT services supporting critical or important functions, so your customer cannot lawfully hold the contract without them. Negotiate the exercise instead: notice, frequency, scope, pooled audits shared across financial customers, and reliance on existing independent assessment reports before on-site inspection.

Does DORA require us to accept on-site audits at our own premises?

The right extends to access, inspection, and audit, and can be exercised by the entity, a third party it appoints, or the competent authority. In practice most financial entities satisfy it through assurance reports and remote evidence review, reserving on-site work for cause or for the highest-criticality services. Agreeing a written audit protocol up front, including what triggers an on-site visit, is the normal way to make the right workable in a multi-tenant environment.

What is the register of information and why does our customer keep asking for data?

Article 28(3) requires every financial entity to maintain a register of all contractual arrangements on the use of ICT services, at entity and consolidated level, separating those that support critical or important functions from those that do not, and to report on it to their competent authority at least yearly. The questions you receive about service descriptions, processing locations, and subcontractors are the fields of that register. Publishing a standing pack that covers them turns a recurring scramble into a link.

How long does a DORA exit and transition period have to be?

The regulation requires an adequate transition period rather than a fixed number, and adequacy is judged against how long a realistic migration of that specific service would take. In negotiated contracts we see terms measured in months rather than weeks for anything supporting a critical or important function. The number matters less than whether your export and handover capability can actually be executed inside it by a customer who is leaving unhappily.