The Compliance Addendum: All Laws in One Contract

Imagine: you are a software supplier providing a CRM system to a large Dutch bank. You have been delivering your services for a while, and in 2018 you were presented with the first new document: a data processing agreement. After that, things were quiet for a long time, but in 2024 it happened again, this time with a DORA addendum for critical functions. The next document may arrive sooner than expected, because with the entry into force of the Cybersecurity Act and the reporting obligation also emerging from the CRA, many organisations are looking at how best to address these new obligations both in the written agreement and in practice.

A reference to the Blue Wall is appropriate here, a wall of laws and regulations that people figuratively run into. You have to take into account an ever-growing body of laws and regulations: the GDPR, NIS2/Cbw, DORA, CRA, or perhaps even the CER/Wwke. To top it all off, the AI Act may also enter the picture. Is there a way to address all these laws at once? Perhaps. In this blog, I make a case for evaluating and revising standard agreements with regard to compliance, which may well be better captured in a single document.

Four Laws, One Notification

Anyone who tries to understand the rationale behind all these different laws and regulations will quickly discover that they all pursue broadly similar goals: raising the general (cyber)security of various sectors. Many laws therefore contain high-level obligations that, broadly speaking, aim for the same thing. I would like to add a caveat here, possibly an obvious one: the AI Act focuses on creating a legal framework to promote artificial intelligence.

Take incident reporting as an example:

• The GDPR requires controllers to report a personal data breach to the relevant supervisory authority within 72 hours (Art. 33 GDPR).

• DORA requires financial entities to report serious ICT-related incidents to the European supervisory authorities within 24 hours at the latest, and to submit a preliminary incident report within 72 hours (Art. 20(1) DORA in conjunction with RTS JC 2024/33).

• NIS2/Cbw requires organisations (falling within its scope) to report significant incidents as an early warning to the relevant supervisory authority within the same timeframes as under DORA (Art. 23 NIS2 in conjunction with Art. 26 et seq. Cbw).

• The CRA imposes two reporting obligations on manufacturers, with timeframes again similar to those under DORA and NIS2.

When all these laws apply the same timeframes, it is not a far-fetched idea to cover this in one go within an ICT contract. An important point to note here is that what is covered must actually align across frameworks. A first step towards more efficient contracting would therefore be to harmonise the reporting obligations under the various laws and regulations. The same logic applies to internal policies, processes, and working instructions, which can ensure a uniform approach.

Four Duty-of-Care Obligations, One Contract

A similar overview to the one for reporting obligations can also be drawn up for the measures organisations are required to take in order to keep their systems appropriately secured. While the GDPR still regulates this at a fairly high level ("appropriate technical and organisational measures"), sector-specific legislation goes into greater depth. I invite the reader to consult, for example, the NIS2 Implementing Regulation or the Regulatory Technical Standards for ICT risk management (DORA).

Ultimately, in all cases, the measures taken must be proportionate to the risks they address. Before implementing them, a risk assessment is therefore strongly recommended, on the basis of which the appropriate measures can be taken.

The fact that these measures can quickly become quite detailed for the financial sector, among others, does not change the fact that the essence of these legal provisions is essentially the same. Taking into account the sector, the organisation, and the services being provided, it is in many cases possible to work with a modular set of security measures that takes into account both the duty of care under Article 21 NIS2 in conjunction with Article 21 Cbw, and the risk management obligations under Article 6 DORA.

The Compliance Addendum

The 2018 data processing agreement could well serve as the starting point for capturing the many obligations arising from the European directives and regulations that have entered into force after the GDPR. After all, a data processing agreement is also free in form, and through a uniform approach to definitions, harmonisation, and a modular approach to security measures, it could quickly become a more efficient way to contract under the aforementioned laws. With each amendment to the data processing agreement, it will gradually evolve into a broader Compliance Addendum.

This Compliance Addendum should ensure that the processing of (personal) data by an engaged supplier complies with applicable legislation, and it also facilitates the customer's ability to meet its own legal obligations when using the products or services.

This can gradually be expanded upon. Putting agreements down on paper is often the final step. Before agreeing that security measures have been implemented, an important first step is to actually implement them. The (somewhat standard) provisions that should be included in a Compliance Addendum must be linked to actual actions, which in turn can best be verified through maturity assessments. In this way, it is possible to assess the extent to which both the customer and the supplier are meeting the legal obligations agreed upon contractually.

In practice, reference is often made to standards relating to risk management and the measures taken to mitigate risks associated with (digital) information processing. Examples include ISO 27001 and/or 27005, 31000, or IRAM(2), which are examples of methodologies for this purpose. In the future, it is intended that European standards based on the CRA will be established, which should also address risk management in the context of CRA compliance.

Revising standard contracts is not something that happens overnight. Does your organisation need a revision of templates, standard contracts, or perhaps a comprehensive Compliance Addendum? Feel free to get in touch and we will tell you everything about the best approach.