CONTRACT ADDENDUM FROM THE BANK

Why the addendum arrived and what the other side is discharging with it

Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, DORA for short, applies from 17 January 2025 under Article 64. Its obligations fall on financial entities — banks, insurers, payment institutions, investment firms and others. As a provider of information and communication technology you usually take on no obligations directly from the regulation. You take them on through the contract, because a financial entity may neither conclude nor maintain a contract that lacks certain provisions.

That is the whole reason these addenda keep arriving. It is not an initiative of the legal department and, for the most part, not room for the other side to invent things either: Article 30 sets out a list that has to be in the contract. The practical difference from ordinary negotiation is that on these points the argument "this does not suit us" simply does not work — the other side cannot drop them even if it wanted to.

The definition of a provider is broad and has no size threshold. Under Article 3(19) an ICT third-party service provider is any undertaking providing ICT services, and under Article 3(21) ICT services are digital and data services provided on an ongoing basis through ICT systems to one or more internal or external users, including hardware as a service and hardware services with technical support through software or firmware updates. Only traditional analogue telephone services are expressly excluded. A three-person software house is therefore an ICT provider in exactly the same way as a global cloud provider.

The second source of requirements is the register. Under Article 28(3) the financial entity maintains a register of information on all contractual arrangements on the use of ICT services, at entity level and at sub-consolidated and consolidated level. That is why questionnaires contain items that seem to have nothing to do with the contract: a legal entity identifier, the country where the service is provided, notice periods in days, or a list of subcontractors. These are not inquisitive questions, they are fields in a supervisory return.

• One document, not five annexes. Under Article 30(1) the rights and obligations have to be clearly allocated and set out in writing, and the full contract, including the service level agreements, has to be documented in one written document available to the parties on paper or in another downloadable, durable and accessible format. Hence the pressure for a consolidated text instead of a chain of e-mail attachments.
• The decision was taken before the addendum. Under Article 28(4) the financial entity assesses, before entering into the contract, whether the arrangement supports a critical or important function, what risks arise from it including concentration risk, and it carries out due diligence on the provider. The questionnaire that arrived before the addendum is exactly that.
• Responsibility does not move. Under Article 28(1)(a) the financial entity remains fully responsible for compliance with the regulation no matter how much it has bought in from outside. That is why it wants evidence from you rather than statements — a statement will not discharge its responsibility.
• What in the addendum does not come from the regulation. Security questionnaires, certificates, contractual penalties, insurance limits or a requirement for a specific standard are commercial requirements. They may be legitimate and they may follow from the other side's internal policy, but they are not a rendering of Article 30 — and in negotiation that is a fundamental difference.
• A critical provider is a different story altogether. The separate regime of direct oversight under Article 31 applies to providers designated by the European Supervisory Authorities against the criteria in Article 31(2): the systemic impact of a failure, the systemic character of the entities that rely on the provider, the degree of reliance for critical or important functions, and substitutability. For an ordinary software house that scenario is out of reach.

A useful first question to send by e-mail, before you start reading the addendum paragraph by paragraph: does our service support a critical or important function? The answer decides half of the text you have received, and the other side knows it — that is precisely how it assembled the addendum.

Two tiers of the addendum: nine elements, or nine plus six

Article 30 is built in two tiers and it pays to see that straight away. Paragraph 2 contains nine elements, points (a) to (i), which every contractual arrangement on the use of ICT services has to contain — regardless of what your service supports. Paragraph 3 adds six further topics, points (a) to (f), and does so expressly "in addition to the elements referred to in paragraph 2". For a service supporting a critical or important function, both therefore apply cumulatively.

What a critical or important function is follows from Article 3(22): a function whose disruption would materially impair the financial performance of the financial entity or the soundness or continuity of its services and activities, or whose discontinued, defective or failed performance would materially impair its continuing compliance with the conditions and obligations of its authorisation or with its other obligations under financial services law. The assessment is made by the financial entity, not by you — and you will recognise the result from how tough an addendum you get.

The nine elements of paragraph 2 look innocent on a first read, and a sensible software supply contract has most of them anyway. Two of them, however, change the pricing model and one changes the operating regime, so there is no point in waving them through as formalities. Paragraph 3 is then the part over which addenda are negotiated for months; separate sections below are devoted to it.

• (a) Description of functions and services — clear and complete, stating whether subcontracting of ICT services supporting critical or important functions, or material parts of them, is permitted and, if so, on what conditions. This is the statutory hook the whole subcontracting regime hangs on.
• (b) Locations — namely the regions or countries where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, plus the duty to give advance notice of any planned change of those locations.
• (c) Protection of data — provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data. Careful, this is not a duplicate of the data processing agreement: it covers all data, not only personal data.
• (d) Access, recovery and return of data in an easily accessible format in the event of the provider's insolvency, resolution or discontinuation of business operations, and on termination of the contract.
• (e) Service level descriptions including updates and revisions. For a service outside critical functions a description is enough; for a critical function the requirement gets stricter, see paragraph 3.
• (f) Assistance in the event of an ICT incident related to the service provided, and that at no additional cost, or at a cost determined ex ante. In practice this means crisis support must not be priced only once the fire has started.
• (g) Cooperation with authorities — full cooperation with the competent authorities and the resolution authorities of the financial entity, including persons appointed by them.
• (h) Termination and notice periods — termination rights and related minimum notice periods, in line with the expectations of the competent authorities and the resolution authorities.
• (i) Training — the conditions for the provider's participation in ICT security awareness programmes and digital operational resilience training under Article 13(6).

Of the nine elements of paragraph 2, point (f) is the one most often underestimated in practice. The sentence about assistance at no additional cost or at a cost determined ex ante reads like a truism, but it means that extraordinary support during an incident has to have a price agreed in advance — and if you do not agree one in advance, the no-additional-cost variant is what applies.

Rights of access, inspection and audit: what cannot be refused

For services supporting critical or important functions, Article 30(3)(e) gives the financial entity the right to monitor the provider's performance on an ongoing basis and breaks that right down into four points. Point (i) is an unrestricted right of access, inspection and audit exercised by the financial entity or an appointed third party and by the competent authority, together with the right to take copies on site of documentation critical to the provider's operations. And it adds immediately that the effective exercise of those rights must not be impeded or limited by other contractual arrangements or implementation policies.

That last sentence is why the customary clause along the lines of "audits are carried out solely under the provider's audit policy" does not survive in an addendum. It is not obstinacy on the other side: accepting it would mean concluding a contract that contradicts the text of the regulation. The same goes for references to general terms and conditions that in effect rule audits out.

The remaining three points read far better, because they are exactly where the room is. Point (ii) expressly contemplates the right to agree alternative assurance levels where other clients' rights are affected — typically in a shared environment. Point (iii) requires full cooperation during on-site inspections and audits performed by the competent authorities, the Lead Overseer, the financial entity or an appointed third party. Point (iv) then requires details on the scope, the procedures to be followed and the frequency of those inspections and audits, which cuts both ways: once the frequency is described, it stops being unrestricted in any practical sense.

The other side of the same coin is in the regulatory technical standard governing the financial entity's policy, that is in Regulation (EU) 2024/1773. Under its Article 8(2) the financial entity has four methods available: its own internal audit or an audit by an appointed third party, where appropriate pooled audits and pooled testing organised jointly with other clients of the same provider, where appropriate third-party certifications, and internal or third-party audit reports. Under Article 8(3), however, it must not rely on certifications or audit reports alone over time, and may do so in the short term only under the conditions listed in that same paragraph.

• Non-negotiable: the existence of the right. The right of access, inspection and audit for the financial entity, for a third party it appoints and for the competent authority has to be in the contract and must not be hollowed out by a reference to another arrangement or to your internal policy.
• Non-negotiable: cooperation and information on scope. Full cooperation during on-site inspections and the duty to state the scope, procedures and frequency of audits follow directly from points (iii) and (iv).
• Room: how the right is exercised. A pooled audit organised for several clients, which Article 8(2)(b) of Regulation (EU) 2024/1773 expressly contemplates, is usually more sensible for a shared platform than ten individual visits a year.
• Room: evidence instead of visits. The other side may use certifications and audit reports, but it has to be satisfied with your audit plan, verify that the scope covers the systems and key controls concerned, keep assessing whether the reports have not become obsolete, and hold a contractual right to request an extension of the scope as well as the right to run its own audit. Offering a report therefore makes sense; relying on it to release you from the audit right does not.
• Room: alternative assurance in a shared environment. Point (ii) is the one place where the regulation itself acknowledges that other clients' rights may be an obstacle — and offers a substitute solution.
• Room: the operational conditions. Notice period, number of auditors, working hours, confidentiality, protection of other customers' data when copies are taken and the extent of documentation are ordinary subjects of negotiation. You cannot turn them into a ban on audits, but you can turn them into a regime.
• Room: a sensible cap on frequency. An unrestricted right does not mean an audit every month. An agreed planned frequency with the option of an extraordinary audit upon a specific event is a common and workable solution.

There is one derogation and it is regularly confused. Under the subparagraph following Article 30(3)(f), a provider and a financial entity that is a microenterprise may agree that the rights of access, inspection and audit are delegated to an independent third party appointed by the provider, with the microenterprise able to request information and assurance from that third party at any time. The derogation hangs on the size of the financial entity, not the size of the provider, and it concerns point (e) only.

Subcontractors: the hardest part of the addendum

The basis is Article 30(2)(a): the description of the services has to state whether subcontracting of ICT services supporting critical or important functions, or material parts of them, is permitted and, if so, on what conditions. Hanging on that hook is Delegated Regulation (EU) 2025/532, adopted under Article 30(5), which has seven articles and specifies what the financial entity has to determine and assess in relation to subcontracting.

Three of them matter to a provider. Under Article 3(1) of that regulation the financial entity has to decide, before entering into the contract, whether it will permit subcontracting at all, and may only conclude the contract if all the conditions in points (a) to (j) are met. Among them: that the subcontractor grants the financial entity, the competent authorities and the resolution authorities the same contractual rights of access and inspection as you do yourself, that the financial entity has assessed concentration risk under Article 29 of DORA, and that there are no impediments to the exercise of audit and access rights.

Article 4 then describes what has to be in the contract for that to work — twelve items under points (a) to (l). Alongside responsibility for the services provided by subcontractors and the duty to monitor them, it also requires your contracts with subcontractors to contain business contingency plan requirements under Article 30(3)(c) of DORA and to specify ICT security standards, and the subcontractor to grant rights of access, inspection and audit to the same extent as Article 30(3)(e). This is what is meant by passing the requirements down the chain, and it is the most laborious part of the whole addendum, because it concerns contracts you have already signed.

Article 5 introduces an approval mechanism for material changes: you have to give sufficient advance notice of intended material changes to subcontracting arrangements, the contract contains a reasonable notice period for approval or objection, and you may only implement the change once the financial entity has approved it or has not objected by the end of that period. Article 6 adds the grounds on which the other side may terminate the contract — among them where you subcontract a service supporting a critical or important function although the contract does not expressly permit it.

• Non-negotiable: express permission. Subcontracting for a critical or important function has to be expressly permitted in the contract. Silence is not read in your favour, and unpermitted subcontracting is, under Article 6(c) of Regulation (EU) 2025/532, a standalone ground for termination.
• Non-negotiable: knowing your own chain. You have to be able to identify every subcontractor providing services that support critical or important functions, notify them and supply the information needed for the assessment. Without a maintained list you will not meet that condition.
• Non-negotiable: passing the rights down the chain. Audit and inspection rights and the requirements for business contingency plans and security standards have to make their way into your contracts with subcontractors. This is work nobody will do for you, and it is worth starting before the addendum arrives.
• Room: a list of pre-approved subcontractors as an annex to the contract, with a change regime. It is markedly more workable than ad hoc approvals and at the same time gives the other side what it needs.
• Room: the definition of a material change. The regulation does not quantify the term. Agreeing what counts as a material change (a new subcontractor for a critical function, a change of processing country, a change of service category) and what is merely notified is legitimate and saves both sides time.
• Room: the length of the notice period. The regulation asks for a "reasonable" period. The number goes into the contract and is a matter for negotiation — bearing in mind that the other side has to fit an assessment into it, not just a record entry.
• Room: the scope of the regime. The strict regime applies to subcontractors providing services that support critical or important functions or material parts of them. Delimiting which of your suppliers fall outside that category is legitimate and usually shrinks the list to a manageable size.

Under Article 3(3) of Regulation (EU) 2025/532, relying on the results of assessments that providers carry out on their own subcontractors does not relieve the financial entity of ultimate responsibility for discharging its obligations. That is why the other side wants evidence from you rather than statements — and why it pays to keep that evidence in usable form instead of assembling it afresh for every questionnaire.

Data locations and notification of changes

Article 30(2)(b) is one of the nine elements mandatory in every contract on ICT services, including those that have nothing to do with a critical function. The contract has to state the locations — namely the regions or countries — where the contracted or subcontracted ICT functions and services are to be provided and where data is to be processed, including the storage location. And with it the duty to notify the financial entity in advance if you envisage changing those locations.

The phrase "namely the regions or countries" is why wording such as "within the European Union" usually does not pass. It is connected to the register of information: in Annex I, template B_02.02, Implementing Regulation (EU) 2024/2956 asks for the country of provision of the ICT services, the location of data storage and the location of management, that is of data processing. It is reported as a two-letter ISO 3166-1 code, so the answer "EU" does not belong in the field and the other side cannot use it.

Third countries deserve particular attention. Under Article 29(2), for contracts covering critical or important functions the financial entity weighs the benefits and risks of subcontracting, especially where the subcontractor is established in a third country, duly considers the insolvency law provisions and the constraints that may arise on urgent recovery of data, and assesses whether and how potentially long or complex subcontracting chains may affect its ability to monitor the contracted functions and the authorities' ability to supervise effectively. So if your architecture includes a service operated outside the EU, expect the addendum to tighten in this part.

• Non-negotiable: stating the locations in the contract. The regions or countries of service provision, of data processing and of data storage have to be stated in the contract. A reference to the provider's general policy will not meet the requirement.
• Non-negotiable: advance notice. A change of location has to be notified in advance, not retrospectively. Point (b) speaks of notification, not consent — which is at the same time what you can use in negotiation.
• Room: notification versus consent. A requirement for prior written consent to a change of location goes beyond point (b). It is legitimate to refuse it for non-critical services and to accept it where a critical function is involved and where the other side is pushed by the material-change regime for subcontracting.
• Room: granularity. The country or region is what the regulation asks for. The address of a specific data centre is a requirement on top of that — for some operations it makes sense, for shared infrastructure it tends to be impossible to meet.
• Room: the notice period. The regulation puts no number on it. The number in the contract is a matter for negotiation and should match how long the other side needs for its assessment and any update of the register.
• Room: a list of approved regions. Delimiting in advance the set of countries you may move within without further approval is markedly more workable for both sides than one-off notifications.
• Do not forget the edges of your architecture. Backups, replication, the content delivery network, monitoring, the error reporting system and out-of-hours support are all places where data actually sits — and where it most often turns out that the map in the addendum does not match the operation.

Point (b) is often confused with the data processing agreement. They are two different layers: personal data protection has its own legal regime, whereas DORA asks about all data processed by the financial entity and about the locations of service provision as such. The two usually sit in the same addendum, but the provisions do not substitute for one another.

Incidents: the deadlines in the addendum are not yours, they are derived

The regulation sets no incident reporting deadline for providers. The number you find in the addendum is derived from the deadlines the other side has to meet. Under Article 5 of Delegated Regulation (EU) 2025/301, the financial entity submits the initial notification as early as possible and in any event within four hours of classifying the incident as major, and no later than 24 hours from becoming aware of it. The intermediate report follows no later than 72 hours after the initial notification, and the final report no later than one month after the intermediate report or its last update.

That is where the demand for reporting in hours or in tens of minutes comes from. The other side does not need it in order to police you, but because without your information it cannot classify the incident — while its own classification clock is running. This is worth knowing in negotiation: the aim is not the shortest number, but that the other side gets usable information in time.

Two provisions of the contract deal with this. Article 30(2)(f) requires assistance during an ICT incident at no additional cost or at a cost determined ex ante. Article 30(3)(b) then adds, for critical or important functions, notice periods and reporting obligations, including notification of any development that might have a material impact on your ability to provide the service at the agreed service levels. That last part is often overlooked: it is not only about incidents, but also about changes on your side that may yet turn into one.

• Non-negotiable: you will report. The duty to report and to notify developments with a material impact follows from Article 30(3)(b) and has to be in a contract covering a critical or important function.
• Non-negotiable: the price of assistance up front. Assistance during an incident is either at no additional cost or at a cost determined ex ante. The price of crisis support therefore has to be agreed beforehand, not offered during the incident.
• Room: the specific deadline and when it starts. The regulation puts no number on the provider's deadline. Both the number and the starting point are negotiable — detection, confirmation, or internal classification on your side.
• Room: what counts as a reportable event. It is sensible to tie the definition to the impact on the service provided to the other side, rather than to every internal event. Without that you will report things that do not concern it at all, and what matters will drown in the noise.
• Room: the channel and the content of the first report. An agreed format — what happened, what is affected, what you do not know yet, when the next update comes — helps the other side classify the incident more than a faster but empty message.
• Room: escalation and availability. Who is reachable outside working hours, how the shift is handed over and who on your side has authority to decide can all be described concretely. It is better protection against disputes than a general clause about "informing without delay".
• Prepare for the questions afterwards. After an incident the other side will need material for its intermediate and final reports. If you know what will be in them, you can keep records as you go — instead of reconstructing them a month after the event.

Weekends have a special regime. Under Article 5(4) of Regulation (EU) 2025/301, where a deadline falls on a weekend or a public holiday the financial entity may submit the notification by noon of the following working day, but under paragraph 5 that extension does not apply to the initial notification and the intermediate report of credit institutions, central counterparties, trading venues and other entities considered essential or important under Directive (EU) 2022/2555. If your customer is a bank, do not count on the weekend relief.

Exit, transition period and return of data

For services supporting critical or important functions, Article 30(3)(f) requires exit strategies, in particular the establishment of a mandatory adequate transition period. During it the provider continues to provide the functions or services concerned so as to reduce the risk of disruption, and the financial entity can migrate to another provider or move to an in-house solution consistent with the complexity of the service provided. It is therefore not merely a notice period: it is a commitment to keep operating at the very moment the relationship has already been decided to end.

Hand in hand with that goes Article 30(2)(d), mandatory in every contract on ICT services: ensuring access, recovery and return of personal and non-personal data in an easily accessible format in the event of the provider's insolvency, resolution or discontinuation of business operations, and on termination of the contractual arrangement. The phrase "in an easily accessible format", left unspecified, is a source of disputes, and it is therefore worth spelling it out in the contract.

The pressure on this part of the addendum does not come from Article 30 alone. Under Article 28(7) the contract has to be terminable in four sets of circumstances — a significant breach of law or of the contractual terms, circumstances identified that are capable of altering the performance of the contracted functions, evidenced weaknesses in the provider's overall ICT risk management, and a situation in which the competent authority can no longer effectively supervise the financial entity because of the arrangement. Under Article 28(8) the financial entity has to be able to terminate without disrupting its activities and its compliance with regulatory requirements or harming the continuity and quality of services to clients, and exit plans have to be documented, sufficiently tested and reviewed periodically.

The practical consequence for you: the other side will want an exit described in a way that can be rehearsed. Article 10 of Delegated Regulation (EU) 2024/1773 requires it to have a termination plan for every contractual arrangement, drawn up for three scenarios — unforeseen and persistent interruption of services, inadequate or failed provision of services, and unexpected termination of the arrangement — and requires the plan to be realistic, feasible and to have a timeline compatible with the termination conditions in the contract.

• Non-negotiable: the existence of a transition period. For critical or important functions it has to be in the contract and has to be adequate to the complexity of the service. Dropping it entirely is not an option.
• Non-negotiable: return of data. Access, recovery and return of data in an easily accessible format applies to every contract on ICT services, not only those covering critical functions, and it also covers the situation where it is you who ceases to operate.
• Room: the length of the transition period. The regulation sets no specific number of months. It follows from the complexity of the migration, which is why it pays to have your own estimate grounded in how long a real handover of the service takes.
• Room: payment for the transition period. The fact that the service continues does not mean it continues free of charge. The regulation does not govern price — the commercial terms of the transition period are a matter for the contract.
• Room: what an easily accessible format means. Describing specifically what you will hand over (export format, schema, documentation, configuration) and by when is better for both sides than a vague commitment. For formats tied to your platform, expect the question of how the data gets out of them afterwards.
• Room: the extent of migration support. How many days of expert capacity, who runs the project, how the handover is tested. This is the classic place for tiered, pre-agreed rate-card work.
• Expect a rehearsal. The other side has to test its termination plans. In practice that means a request for a trial data export or for verification that the described procedure works — with a large customer it is better to have it ready than to improvise.

Specific data from this section find their way into the register of information: the notice period for the financial entity and for the provider in days, whether a termination plan exists, and how demanding it would be to reintegrate the service back inside the organisation. In other words, what you negotiate shows up in the data the other side sends to its supervisor.

What else the other side will want: the register, LEI and testing

Alongside the addendum, a spreadsheet usually arrives too. The format of the register of information is set by Implementing Regulation (EU) 2024/2956, and the data the other side needs from you is largely machine-checked — which is why it asks in such a formalised way. Under Article 3(5), all providers that are legal persons are identified by a valid and active legal entity identifier (LEI) or European Unique Identifier (EUID), or both. The exception is natural persons acting in a business capacity.

For services supporting critical or important functions the requirement goes further. Under Article 3(6) the financial entity ensures, through the direct provider, that a valid and active LEI is used or an EUID provided by all subcontractors that effectively underpin those services. In other words: the identifier requirement travels down the chain through you, and it is a practical matter worth flagging to subcontractors before the reporting date arrives.

The second thing that comes as a surprise is threat-led penetration testing. Under Article 30(3)(d), a contract covering a critical or important function has to oblige the provider to participate and fully cooperate in the threat-led penetration testing carried out by the financial entity, as referred to in Articles 26 and 27. It is not the same thing as the penetration test you may be commissioning yourself: under Article 3(17) it is a controlled test of critical live production systems that mimics the tactics, techniques and procedures of real attackers.

The scope of that testing also carries weight in time. Designated financial entities carry it out at least every three years under Article 26(1), on systems actually used in production under Article 26(2), and the active red team testing phase lasts in any event at least twelve weeks under Article 11(5) of Delegated Regulation (EU) 2025/1190. If you are within scope, this is not half a day of assistance.

• Non-negotiable: the identifier. Without a valid and active LEI or EUID the other side cannot enter you in the register. Obtaining the code is an administrative step with no alternative in the form of some other number.
• Non-negotiable: participation in testing for critical functions. The duty to participate and fully cooperate in threat-led penetration testing follows from Article 30(3)(d).
• Room: the conditions of participation in the test. Scope, environment, testing window, escalation rules and contact persons are all agreed. Regulation (EU) 2025/1190 also anticipates that several customers will be testing you. Article 26(4) of DORA allows a pooled test of several financial entities under the direction of one of them, agreed in writing, but only where your participation in individual tests could reasonably be expected to have an adverse impact on the quality or security of services provided to customers outside the scope of DORA or on the confidentiality of their data; the contract with the external tester is then entered into by you directly. For a shared platform that is more feasible than a sequence of separate tests.
• Prepare your service type from the code list. Annex III to Regulation (EU) 2024/2956 contains a closed list of ICT service types with codes S01 to S19, and only the code is reported. Your service will fall into one of the categories — it is better to propose it yourself than to argue about the classification after the fact.
• Prepare your group data. The register also records the provider's ultimate parent undertaking and the rank of each link in the ICT service supply chain, where the direct provider always has rank 1 and a subcontractor always higher.
• Expect it to repeat. The register is updated, and the data quality requirements are listed in Article 3(4) of that regulation as accuracy, completeness, consistency, integrity, uniformity and validity. A spreadsheet filled in once, with no owner on your side, will not survive that regime.
• Training is not a formality. Under Article 30(2)(i) the contract contains the conditions for the provider's participation in the financial entity's ICT security awareness programmes and digital operational resilience training. The extent and frequency are a matter for agreement; the existence of the clause is not.

What the register looks like exactly, which templates it contains and what goes into them is covered by the separate page on the register of information in this category. For negotiating the addendum it is enough to know which data the other side has to obtain from you and why it cannot accept a general answer.

How to work through the addendum without signing blind

The fastest way to find your bearings in an addendum is to split it into three piles. The first holds provisions that literally track Article 30(2) and (3) — there the substance is not negotiable, at most the wording and the operational detail. The second holds what follows from the technical standards, mainly Regulation (EU) 2025/532 on subcontracting and Regulation (EU) 2024/1773 on audits and monitoring — there the room lies in how the obligation is met. The third holds everything else: commercial requirements, penalties, insurance, certificates. That third pile is ordinary commercial negotiation.

It helps in negotiation to know that Article 30(4) expects financial entities and providers to consider the use of standard contractual clauses developed by public authorities for specific services. It is a duty to consider, not a duty to use such clauses, but it is a legitimate argument against every counterparty drafting its own wording of the same requirement.

The second thing that pays off: answer once. Most requirements repeat across customers, so a single pack of materials — a list of subcontractors with processing locations, a service level description with quantitative targets, the data export procedure, the incident contact channel, evidence of security measures and any audit reports or certifications — saves more time than individual answers to individual questionnaires. It is also exactly what the other side will need again at every update of the register.

And a final note on what the addendum actually means. The provisions of Article 30 are not paper: they describe an operation that has to exist. Signing up to report developments with a material impact, or to a transition period with continued operation, is a commitment that someone on your side has to be able to meet on a particular day. That is why it makes sense to read the addendum with the operations team, not only with a lawyer.

• Establish how the service is classified. Does it support a critical or important function? The answer determines whether the six topics of paragraph 3 apply to you, or only the nine elements of paragraph 2.
• Compare the addendum against the text of the regulation. Side by side, point by point. Sentences with no counterpart in Article 30 belong in the commercial pile.
• Check what the addendum requires you to do, not just to promise. Reporting within a deadline, exporting data, passing rights into subcontracts, availability outside working hours.
• Walk the chain. Who provides part of the service beneath you, where they are established, where they process data and what their contract says. For critical functions you will have to evidence it.
• Work out the impact on price. Incident support, the transition period, audits and participation in testing are all capacity. Either you price it in advance or you will deliver it for free.
• Name an owner on your side. Someone has to maintain the materials, watch the notification deadlines for subcontractor changes and answer queries about the register. Without that, the addendum is met only on the day it is signed.
• Do not sign wording you cannot meet. A commitment that cannot be met is worse than a negotiated compromise — and with provisions the other side needs for its own supervision, the failure will be noticed.

When there are two addenda and each bank's is different, it pays to describe your own situation first — services, chain, locations, deadlines, exit — and only then read the addenda against it, rather than negotiating each one separately. A description written once serves for the next customer and for the register update as well.

A working order for dealing with the addendum

The sequence that works for us with providers who have just received their first addendum. It is not a requirement of the regulation — it is a way to find your bearings in the text before the negotiation over individual sentences starts. The steps overlap, and with the second and every further customer most of them fall away, because you will already have the materials.

Official sources

The statements about obligations on this page are based on the following legal acts, as of 9 August 2026. This material does not replace their wording — the binding text is the one published in the Official Journal, in which every language version is equally authentic; the links point to the English one.