De introductie van het Compliance Addendum: Alle wetten in een contract

Stel je voor: je bent een softwareleverancier die een CRM-systeem levert aan een grote Nederlandse bank. Je levert je diensten al een poosje en in 2018 kreeg je het eerste nieuwe document voorgeschoteld: een verwerkersovereenkomst. Hierna was het een lange tijd stil, maar in 2024 was het weer raak met dit keer een DORA addendum voor kritieke functies. Wie weet dat het volgende document sneller langskomt, want met het in werking treden van de Cyberbeveiligingswet en de meldplicht die ook in de CRA naar voren komt, kijken veel organisaties hoe ze deze nieuwe verplichtingen het beste kunnen ondervangen in zowel de overeenkomst op papier als in de praktijk.

Een verwijzing naar de Blue Wall is op zijn plaats. Een muur van wet- en regelgeving waar men spreekwoordelijk tegen stuk loopt. Je moet met steeds meer wet- en regelgeving rekening houden; de AVG, NIS2/Cbw, DORA, CRA of misschien ook wel de CER/Wwke. Als klap op de vuurpijl kan ook nog de AI Act om de hoek komen kijken. Is er een manier om met al die wetten in één keer rekening te houden? Misschien wel. In dit blog maak ik een pleidooi voor een evaluatie en herziening van de standaard overeenkomsten met betrekking tot compliance, die misschien wel beter in één document te vatten zijn.

Vier wetten, een melding

Wie de gedachte (de ‘ratio’) achter al deze verschillende wetten en regels probeert te doorgronden, komt er al snel achter dat zij allemaal redelijk vaak vergelijkbare doelen nastreven: het verhogen van de algemene (cyber)beveiliging van verschillende sectoren. Veel wetten hebben dan ook hoog-over verplichtingen die in grote lijnen hetzelfde beogen. Hierbij zet ik, mogelijk ten overvloede, een kanttekening; de AI Act, deze zet in op het creëren van een juridisch kader ter stimulering van kunstmatige intelligentie.

Als voorbeeld het melden van incidenten:

  • De AVG verplicht verwerkingsverantwoordelijke om een inbreuk in verband met persoonsgegevens binnen 72 uur te melden aan de desbetreffende toezichthouder (art. 33 AVG).

  • De DORA verplicht financiële entiteiten om ernstige ICT-gerelateerde incidenten uiterlijk binnen 24 uur te melden bij de Europese toezichthoudende autoriteiten en binnen 72 uur een voorlopige rapportage van het incident te overhandigen (art. 20 lid 1 DORA jo. RTS JC 2024/33).

  • De NIS2/Cbw verplicht organisaties (die hieronder vallen) om (binnen dezelfde termijnen als bij de DORA) significante incidenten te melden als vroegtijdige waarschuwing bij de desbetreffende toezichthouder (art. 23 NIS2 jo. art. 26 e.v. Cbw).

  • De CRA legt fabrikanten twee meldplichten op, waarbij weer vergelijkbare termijnen gelden als bij de DORA en de NIS2.

Wanneer al deze wetten dezelfde termijnen hanteren, is het niet een gek idee om bij een ICT-contract dit in een keer af te dekken. Een eerste stap richting efficiënter contracteren zou dan ook het gelijktrekken van de meldplichten onder verschillende wet- en regelgeving zijn. Dezelfde gedachte geldt ook voor intern beleid, processen en werkinstructies die kunnen zorgen voor een uniforme aanpak.

Vier zorgplichten, één contract

Eenzelfde opsomming als bij meldplicht kan ook gemaakt worden voor de maatregelen die organisaties dienen te nemen om hun systemen passend beveiligd te houden. Waar de AVG dit nog redelijk hoog-over regelt (“passende technische en organisatorische maatregelen”), gaat de sectorale wet- en regelgeving daar dieper op in. Ik nodig de lezer uit om bijvoorbeeld de Uitvoeringsverordening NIS2 of de regelgevende technische normen voor ICT-risicobeheer (DORA) door te nemen.

Uiteindelijk gaat het er in alle gevallen om dat de genomen maatregelen passend moeten zijn in verhouding tot de risico’s die zij afdekken. Voordat je ze neemt, wordt een risicobeoordeling dan ook ten zeerste aanbevolen, op basis waarvan de juiste maatregelen genomen kunnen worden.

Dat deze maatregelen voor onder andere de financiële sector al snel de diepte in kunnen gaan, neemt niet weg dat de essentie van deze wetsartikelen in beginsel gelijk is. Gelet op de sector, de organisatie en de diensten die geleverd worden, kan er in veel gevallen gewerkt worden met een modulaire set aan beveiligingsmaatregelen die zowel rekening houden met de zorgplicht uit artikel 21 NIS2 jo. artikel 21 Cbw, als met de verplichtingen omtrent risicomanagement uit artikel 6 DORA.

Het Compliance Addendum

De verwerkersovereenkomst uit 2018 zou zomaar het startpunt kunnen zijn om de vele verplichtingen die in de Europese richtlijnen en verordeningen die na de AVG in werking zijn getreden te kunnen vatten. Ook een verwerkersovereenkomst is tenslotte vormvrij en zou door een uniforme aanpak in definities, het gelijktrekken en een modulaire aanpak voor beveiligingsmaatregelen al snel een efficiëntere manier zijn om te contracteren onder de genoemde wetten. Met iedere aanpassing van de verwerkersovereenkomst zal deze langzaam veranderen naar een breder Compliance Addendum.

Met dit Compliance Addendum moet geborgd worden dat de verwerking van (persoons)gegevens door een ingeschakelde leverancier voldoet aan de van toepassing zijnde wetgeving en faciliteert het Compliance Addendum ook dat de afnemer bij gebruikmaking van de producten of diensten ook meteen kan voldoen aan zijn eigen wettelijke plichten.

Langzaamaan kan dit uitgebreid worden. Afspraken op papier zetten is vaak de laatste stap. Voordat je overeenkomt dat je beveiligingsmaatregelen hebt geïmplementeerd, is het een belangrijke eerste stap om deze ook daadwerkelijk te implementeren. De (enigszins standaard) bepalingen die men zou moeten opnemen in een Compliance Addendum moeten gelinkt zijn aan daadwerkelijke handelingen, die op hun beurt het beste gecontroleerd kunnen worden via maturity assessments. Op deze manier kan men nagaan in hoeverre zowel aan de afnemers- als leverancierszijde voldaan wordt aan de wettelijke verplichtingen die contractueel overeengekomen worden.

In de praktijk wordt er vaak verwezen naar standaarden aangaande risicomanagement en de genomen maatregelen om de risico’s in verband met (digitale) informatieverwerking te beperken. Denk aan de ISO 27001 en/of 27005, 31000, of IRAM(2), die voorbeelden van methodes hiervoor zijn. In de toekomst is het de bedoeling dat er Europese standaarden op basis van de CRA worden vastgesteld waarin ook het risicobeheer in de context van CRA-compliance aan bod zou moeten komen.

Het herzien van standaardcontracten gaat niet over één nacht ijs. Heeft jouw organisatie behoefte aan een revisie van templates, standaardcontracten of misschien wel een algeheel Compliance Addendum? Neem gerust contact op, dan vertellen we je alles over de beste aanpak.

Neem contact op

Terug naar overzicht