Toekomstige wetgeving meenemen in langjarige cloudcontracten doe je door expliciete aanpassingsclausules op te nemen die bepalen hoe contractpartijen reageren als nieuwe regelgeving de afspraken raakt. Dit is geen luxe, maar een noodzaak: cloudcontracten lopen vaak drie tot zeven jaar, terwijl het Europese wetgevingslandschap rondom data, beveiliging en cloudgebruik zich in hoog tempo ontwikkelt. In dit artikel beantwoorden we de meestgestelde vragen over cloudcontracten en wetgeving, zodat je weet waar je op moet letten.
Welke nieuwe EU-wetgeving heeft direct impact op cloudcontracten?
Drie Europese wetten hebben de meest directe impact op cloudcontracten: de Data Act, de NIS2-richtlijn en de AI Act. Samen bepalen ze hoe data mag worden opgeslagen en gedeeld, welke beveiligingseisen gelden voor cloudproviders en welke verplichtingen er gelden rondom AI-systemen die in de cloud draaien. Organisaties die nu contracten afsluiten of verlengen, moeten rekening houden met alle drie.
De Data Act, die in 2025 volledig van kracht is geworden, verplicht cloudproviders om klanten in staat te stellen data gemakkelijk over te zetten naar een andere aanbieder. Dit heeft directe gevolgen voor hoe portabiliteits- en exitbepalingen in cloudcontracten worden geformuleerd. Leveranciers mogen overstapkosten niet langer onbeperkt doorberekenen, wat de onderhandelingspositie van afnemers versterkt.
De NIS2-richtlijn legt strengere cybersecurityverplichtingen op aan organisaties in kritieke sectoren en aan hun toeleveranciers, waaronder cloudproviders. Als jouw organisatie onder NIS2 valt, moet je cloudcontract aantoonbaar aansluiten op die eisen: denk aan incidentrapportage, beveiligingsstandaarden en aansprakelijkheidsafspraken bij datalekken.
De AI Act voegt daar nog een laag aan toe. Wie AI-diensten afneemt via een cloudplatform, zoals machinelearningservices van AWS, Azure of Google Cloud, moet vastleggen wie verantwoordelijk is voor de classificatie en naleving van AI-systemen. Dit is een relatief nieuw vraagstuk dat in veel bestaande cloudcontracten nog volledig ontbreekt.
Grip op uw IT-contracten en kosten?
Onze experts helpen u met IT-sourcing, contracten, licenties en kostenoptimalisatie.
Hoe verwerk je toekomstige wetgeving als clausule in een cloudcontract?
Toekomstige wetgeving verwerk je in een cloudcontract via vier typen clausules: een regulatory change clause, een compliance-aanpassingsprocedure en een heronderhandelingsbepaling. Samen zorgen ze ervoor dat het contract niet bevroren raakt als de wet verandert, maar dat beide partijen een duidelijk pad hebben om de afspraken bij te stellen.
Concreet betekent dit het volgende:
- Regulatory change clause: Een bepaling die expliciet benoemt dat als nieuwe wet- of regelgeving de contractuele verplichtingen raakt, partijen verplicht zijn binnen een afgesproken termijn (bijvoorbeeld 60 of 90 dagen) in overleg te treden over aanpassing.
- Compliance-aanpassingsprocedure: Een beschrijving van hoe wijzigingen worden doorgevoerd, wie ze initieert, wie de kosten draagt en hoe eventuele meningsverschillen worden opgelost.
- Heronderhandelingsbepaling: Een clausule die het recht geeft om commerciële voorwaarden opnieuw te bespreken als nalevingskosten significant stijgen door nieuwe regelgeving. Dit voorkomt dat de financiële last volledig bij één partij terechtkomt.
- Definitie van toepasselijke regelgeving: Leg vast welke jurisdicties en welke categorieën wetgeving onder de clausule vallen, zodat er geen discussie ontstaat over de reikwijdte.
Een veelgemaakte fout is om wetgevingsclausules te breed te formuleren zonder concrete procedures. Dat leidt tot contractuele patstelling op het moment dat aanpassing daadwerkelijk nodig is.
Wat zijn de risico’s van cloudcontracten zonder wetgevingsclausules?
Cloudcontracten zonder wetgevingsclausules laten organisaties met twee onaantrekkelijke opties achter als nieuwe regelgeving van kracht wordt: óf de leverancier accepteert eenzijdig de kosten en aansprakelijkheid, wat zelden vrijwillig gebeurt, óf de klant draait op voor de gevolgen zonder contractuele basis voor verhaal. In de praktijk betekent dit hogere kosten, compliancerisico’s en afhankelijkheid van de goodwill van de leverancier.
De meest concrete risico’s zijn:
- Compliancegaten: Als de leverancier zijn dienstverlening niet aanpast aan nieuwe eisen, maar het contract hem daartoe niet verplicht, staat de klant juridisch zwak.
- Onverwachte kostenverhoging: Leveranciers kunnen nalevingskosten doorberekenen als het contract daar geen begrenzing aan stelt.
- Contractueel conflict: Zonder aanpassingsprocedure leidt elke wetswijziging tot een moeizame ad-hoconderhandeling, met alle tijdverlies en juridische kosten van dien.
- Reputatie- en boeterisico: Als jouw organisatie aantoonbaar niet voldoet aan NIS2 of de Data Act, terwijl de leverancier contractueel niet verplicht was te helpen, ligt de aansprakelijkheid volledig bij jou.
Hoe lang zijn cloudcontracten gemiddeld en waarom maakt dat wetgeving urgenter?
Cloudcontracten bij grote enterprise-organisaties lopen gemiddeld drie tot vijf jaar, met uitschieters naar zeven jaar bij complexe outsourcingtrajecten. In een periode van drie jaar kan het Europese wetgevingslandschap ingrijpend veranderen. De Data Act, NIS2 en de AI Act zijn daar het bewijs van: alle drie zijn ze in de afgelopen jaren definitief vastgesteld en van kracht geworden.
Hoe langer de looptijd van een cloudcontract, hoe groter de kans dat er minimaal één significante wetswijziging plaatsvindt die de afspraken raakt. Zonder aanpassingsclausules is het contract op dat moment feitelijk verouderd, maar juridisch nog volledig bindend. Dit creëert een situatie waarin de schriftelijke afspraken en de operationele realiteit uiteen gaan lopen, met alle risico’s van dien.
Langjarige contracten bieden weliswaar voordelen op het gebied van prijsstabiliteit en leveringszekerheid, maar die voordelen mogen niet ten koste gaan van flexibiliteit op het gebied van EU-cloudwetgeving. De oplossing is niet om kortere contracten te sluiten, maar om langjarige contracten slimmer in te richten met de juiste clausules en periodieke reviewmomenten.
Wie is verantwoordelijk voor compliance in een cloudcontract: klant of leverancier?
De verantwoordelijkheid voor cloudcompliance is gedeeld, maar de verdeling verschilt per type verplichting. De cloudprovider is verantwoordelijk voor de beveiliging en compliance van het platform zelf. De klant is verantwoordelijk voor wat er op dat platform wordt gedaan: welke data erin staat, hoe toegang is geregeld en of het gebruik voldoet aan sectorspecifieke regelgeving. Dit principe heet het gedeelde verantwoordelijkheidsmodel.
In de praktijk ontstaan de meeste problemen in het grijze gebied tussen deze twee lagen. Denk aan:
- Wie is verantwoordelijk als de leverancier een beveiligingsupdate vertraagt en daardoor een NIS2-incident optreedt?
- Wie draagt de kosten als de leverancier zijn infrastructuur moet aanpassen om te voldoen aan de Data Act?
- Wie classificeert AI-diensten onder de AI Act: de provider die ze levert of de klant die ze inzet?
Het antwoord op deze vragen moet expliciet in het contract staan, niet worden overgelaten aan interpretatie. Leg in het contract vast welke nalevingsverplichtingen bij welke partij liggen, hoe dit wordt aangetoond (audits, certificeringen, rapportages) en wat de gevolgen zijn als een partij tekortschiet.
Wanneer is het verstandig om een exitstrategie op te nemen in een cloudcontract?
Een exitstrategie is verstandig in elk cloudcontract met een looptijd van meer dan twee jaar of waarbij de afhankelijkheid van de leverancier groot is. De Data Act versterkt dit argument: portabiliteit en het recht om over te stappen zijn nu wettelijk verankerd, maar de praktische invulling ervan moet contractueel worden geregeld om daadwerkelijk bruikbaar te zijn.
Een goede exitstrategie in een cloudcontract bevat minimaal:
- Dataportabiliteitsafspraken: In welk formaat wordt data aangeleverd bij vertrek, binnen welke termijn en tegen welke kosten?
- Transitieondersteuning: Is de leverancier verplicht mee te werken aan een gecontroleerde overgang naar een andere provider?
- Opzegtermijnen en boeteclausules: Zijn deze proportioneel en realistisch, ook als vertrek wordt ingegeven door nieuwe wetgeving die de leverancier niet kan of wil naleven?
- Kennisoverdracht: Wie draagt de documentatie, configuraties en integratiekennis over, en hoe?
Een exitstrategie is geen teken van wantrouwen richting de leverancier. Het is een teken van professioneel contractbeheer. Juist als de samenwerking goed verloopt, is het makkelijker om heldere exitafspraken te maken. Wacht je tot er een conflict of een wetswijziging is, dan onderhandel je vanuit een zwakkere positie.
Hoe Thornstein Groep helpt bij cloudcontracten en toekomstige wetgeving
Langjarige cloudcontracten opstellen of heronderhandelen met oog voor toekomstige EU-regelgeving vereist gedetailleerde kennis van zowel het contractuele speelveld als de wetgevingsontwikkelingen. Wij helpen organisaties bij precies dat snijvlak.
Wat wij concreet voor je doen:
- Bestaande cloudcontracten doorlichten op ontbrekende wetgevingsclausules en compliancegaten
- Onderhandelen met grote cloudproviders zoals Microsoft, AWS en Google over aanpassingsclausules, exitbepalingen en kostenverdeling bij nalevingswijzigingen
- Adviseren over de verdeling van verantwoordelijkheden tussen klant en leverancier in het licht van NIS2, de Data Act en de AI Act
- Inrichten van periodieke contractreviews zodat je cloudcontract actueel blijft gedurende de volledige looptijd
- Ondersteunen bij exittrajecten wanneer een leverancier niet langer aan jouw eisen voldoet
We werken als onafhankelijke partij, zonder belang bij een specifieke leverancier. Dat maakt ons advies objectief en volledig gericht op jouw positie. Wil je weten hoe jouw huidige cloudcontracten ervoor staan? Neem vrijblijvend contact met ons op voor een oriënterend gesprek.
Veelgestelde vragen
Wat is het verschil tussen een regulatory change clause en een force majeure-clausule?
Een force majeure-clausule dekt onvoorzienbare omstandigheden die nakoming van het contract tijdelijk of permanent onmogelijk maken, zoals natuurrampen of oorlog. Een regulatory change clause is specifieker: die regelt juist wat er gebeurt als nieuwe wet- of regelgeving de contractuele verplichtingen inhoudelijk raakt, ook als nakoming technisch nog mogelijk is. Voor cloudcontracten heb je beide nodig, maar ze dienen een fundamenteel ander doel. Verwar ze niet in de contracttekst, want dat leidt tot interpretatieconflicten op het slechtst mogelijke moment.
Hoe vaak zou je een bestaand cloudcontract moeten reviewen op wetgevingswijzigingen?
Een jaarlijkse contractreview is voor de meeste organisaties het minimum, maar voor sectoren die onder NIS2 vallen — zoals energie, financiële dienstverlening en gezondheidszorg — is een halfjaarlijkse review aan te raden. Koppel reviewmomenten bij voorkeur aan vaste EU-wetgevingskalenders, zoals de implementatiedeadlines van nieuwe richtlijnen. Leg deze reviewmomenten contractueel vast als verplichte mijlpalen, zodat ze niet afhankelijk zijn van intern initiatief maar automatisch worden getriggerd.
Kunnen cloudproviders zoals Microsoft, AWS of Google zomaar weigeren om wetgevingsclausules op te nemen?
Grote cloudproviders werken doorgaans met standaardcontracten en zijn niet altijd bereid om op alle punten te onderhandelen, maar dat betekent niet dat aanpassingen onmogelijk zijn. Enterprise-klanten met significante contractwaarde hebben meer onderhandelingsruimte dan kleinere afnemers. Bovendien verplicht de Data Act providers al tot bepaalde vormen van portabiliteit en transparantie, wat jouw onderhandelingspositie versterkt. Een onafhankelijke adviseur die ervaring heeft met deze leveranciers kan helpen om de juiste clausules alsnog geaccepteerd te krijgen, of alternatieve contractstructuren voor te stellen.
Wat moet ik doen als mijn bestaande cloudcontract geen enkele wetgevingsclausule bevat?
Begin met een grondige contractanalyse om te bepalen welke compliancegaten er zijn en hoe groot het risico is gezien jouw sector en de looptijd die nog resteert. Vervolgens zijn er twee routes: heronderhandelen met de leverancier over een addendum dat de ontbrekende clausules toevoegt, of het contract op een natuurlijk verlengmoment grondig herzien. Wacht niet tot een wetswijziging je dwingt te handelen, want dan onderhandel je vanuit een reactieve en zwakkere positie. Een contractdoorlichting door een onafhankelijke partij geeft je snel inzicht in de prioriteiten.
Hoe leg je de kostenverdeling bij nalevingswijzigingen eerlijk vast in een cloudcontract?
Een eerlijke kostenverdeling begint met het onderscheid tussen kosten die voortkomen uit de infrastructuurverantwoordelijkheid van de provider en kosten die voortkomen uit het specifieke gebruik door de klant. Leg contractueel vast dat kosten voor platformaanpassingen — zoals het technisch mogelijk maken van dataportabiliteit onder de Data Act — voor rekening van de provider komen, terwijl implementatiekosten aan klantzijde voor de klant zijn. Voeg een drempelwaarde toe: pas bij kostenverhoging boven een afgesproken percentage (bijvoorbeeld 10-15%) treedt de heronderhandelingsbepaling in werking. Zo voorkom je zowel misbruik als eindeloze discussies over kleine aanpassingen.
Geldt de AI Act ook als je alleen standaard AI-functies gebruikt die in een cloudplatform zijn ingebouwd?
Ja, ook het gebruik van ingebouwde AI-functionaliteiten — zoals automatische classificatie, voorspellende analyses of generatieve AI-tools binnen platforms als Microsoft 365 of Google Workspace — kan onder de AI Act vallen, afhankelijk van het risiconiveau van de toepassing. De organisatie die de AI-dienst inzet, wordt in veel gevallen beschouwd als ‘deployer’ en draagt daarmee eigen nalevingsverplichtingen. Dit betekent dat je in het cloudcontract moet vastleggen welke informatie de provider verstrekt over de classificatie van zijn AI-diensten en hoe jij als afnemer kunt aantonen dat je aan de vereisten voldoet.
Is het verstandig om een multi-cloudstrategie te hanteren als buffer tegen leveranciersafhankelijkheid en wetgevingsrisico's?
Een multi-cloudstrategie verlaagt de leveranciersafhankelijkheid en verkleint het risico dat één provider niet kan voldoen aan nieuwe wetgeving, maar introduceert ook nieuwe complexiteit op het gebied van contractbeheer, beveiliging en interoperabiliteit. De strategie is zinvol als de operationele en juridische complexiteit beheersbaar blijft en als de workloads zich lenen voor verdeling over meerdere providers. Overweeg een multi-cloudbenadering niet als vervanging van goede contractclausules, maar als aanvullende risicomaatregel. Zorg er wel voor dat de contracten bij alle betrokken providers onderling consistent zijn wat betreft verantwoordelijkheidsverdeling en exitbepalingen.
