Het antwoord is pijnlijk eenvoudig: er was een single point of failure. Te vaak wordt bij het sluiten van een IT-contract onvoldoende nagedacht over een fatsoenlijke uitwijkvoorziening naar een ander datacenter. Wanneer wij dat punt aan de orde stellen, klinkt het verweer al snel vertrouwd. "Is toch allemaal niet nodig? Het is toch een professionele partij? Ze hebben toch fantastische uptime-cijfers?" Waarna het onderwerp van tafel verdwijnt en er niets meer gebeurt. Totdat het wél fout gaat. Dan wordt er gewezen: intern, extern, over en weer. Er volgen schadeclaims en juridische procedures, en ondertussen lijden waardevolle relaties ernstige schade.
Waarom schiet uw SLA tekort bij een datacentercrisis?
Wij reviewen en onderhandelen regelmatig over SLA's bij IT-outsourcing, cloud- en datacentercontracten. Wat ons keer op keer opvalt: SLA's zijn bijna altijd louter reactief van aard. Ze beschrijven wat er gebeurt nádat er iets misgaat: hersteltijden (RTO), de terugzetsnelheid van data (RPO) en boeteclausules bij overschrijding van beschikbaarheidspercentages. Met andere woorden: de SLA regelt de financiële afwikkeling van een storing die al heeft plaatsgevonden. Wat er structureel ontbreekt, zijn de proactieve en preventieve afspraken. Wie zorgt ervoor dat er überhaupt uitwijkmogelijkheden zijn? Waar draaien de systemen naartoe als dit datacenter, om welke reden dan ook, wegvalt? Is die uitwijkomgeving actueel? Is er ooit getest of uitwijk daadwerkelijk werkt?
Een beschikbaarheidspercentage van 99,9% in een SLA klinkt indrukwekkend. Maar het zegt niets over wat er bij een calamiteit feitelijk gebeurt. Of er een tweede locatie beschikbaar is. Of die locatie up-to-date is. En al helemaal niet of u en uw leverancier die uitwijk daadwerkelijk kunnen activeren wanneer het erop aankomt: onder tijdsdruk, met gestreste mensen aan de knoppen.
Wanneer is een rampenoefening meer dan een vinkje?
In de contracten die uitwijk wél benoemen, is de periodieke rampenoefening zelden serieus geregeld. Soms staat er een bepaling die de leverancier verplicht om jaarlijks een test uit te voeren. Maar wie controleert de uitkomsten? Wie is aanwezig namens de klant? Aan welke minimale eisen moet de test voldoen? En wat zijn de consequenties als de uitwijk bij die test faalt?
Een rampenoefening die louter als compliance-vinkje fungeert, heeft weinig waarde. Een goede oefening simuleert realistische scenario's, van brand en hardwarestoring tot een ransomware-aanval of een firewallwijziging die al het verkeer blokkeert. En zij test niet alleen of systemen technisch worden overgenomen, maar ook of de organisatie operationeel kan blijven functioneren tijdens en na de overschakeling. Resultaten moeten worden vastgelegd, verbeterpunten opgevolgd en de hele cyclus moet contractueel zijn verankerd.
Hoe verplichten NIS2, de CRA en de AVG u tot uitwijk?
Uitwijk en bedrijfscontinuïteit zijn al lang geen vrije keuze meer. De Europese wetgever heeft de afgelopen jaren een dwingend regelgevend kader opgebouwd dat concrete verplichtingen oplegt aan zowel aanbieders als afnemers van IT-diensten. Wie dat negeert, riskeert niet alleen operationele chaos bij een storing, maar ook handhaving door toezichthouders. De kernvraag in elke outage-discussie wordt daarmee ook een zorgplichtvraag: wat had u contractueel moeten regelen?
NIS2: bedrijfscontinuïteit is een juridische verplichting
NIS2 onderscheidt twee categorieën. Essentiële entiteiten, zoals KPN (telecom) en NorthC (datacenter), vallen onder de zwaarste verplichtingen. Belangrijke entiteiten, waaronder onderzoeksinstellingen, volgen kort daarna. Een grote universiteit als UU is dan ook niet alleen de benadeelde partij: zij heeft mogelijk zélf een wettelijke plicht om uitwijkvoorzieningen te treffen. NIS2 verplicht tot concrete maatregelen op het gebied van bedrijfscontinuïteit (back-upbeheer, noodherstel, crisismanagement), beveiliging van de toeleveringsketen en passende incidentrespons, inclusief een meldplicht bij significante verstoringen. Eén aspect landt in de bestuurskamer nog te weinig: de zorgplicht behoeft de goedkeuring van het bestuur, en ieder bestuurslid wordt persoonlijk geacht te beschikken over de kennis en vaardigheden om cyberbeveiligingsrisico's te beoordelen. Dat staat letterlijk in het wetsvoorstel Cyberbeveiligingswet (artikel 24 CBW). Als het misgaat en de toezichthouder onderzoek instelt, is het bestuur aanspreekbaar, niet alleen de CISO of de IT-afdeling. De maximale boete voor essentiële entiteiten bedraagt €10 miljoen of 2% van de wereldwijde jaaromzet; voor belangrijke entiteiten is dat €7 miljoen of 1,4%. Dat zijn geen abstracte bedragen. De verwachting is niet dat toezichthouders meteen naar het maximale boeteplafond grijpen, maar de hoogte ervan onderstreept dat dit thema nadrukkelijk thuishoort op de bestuurstafel.
Cyber Resilience Act: ook de infrastructuur van uw leverancier moet deugen
De Cyber Resilience Act (Verordening EU 2024/2847) richt zich op fabrikanten, importeurs en distributeurs van producten met digitale elementen: de hardware en software die in uw datacenter draaien. De verordening richt zich niet rechtstreeks tot de afnemers van die diensten. Toch heeft u er direct belang bij dat de infrastructuur die uw leverancier inzet CRA-conform is. De meeste verplichtingen gelden vanaf december 2027, maar de richting is nu al helder. Wie vandaag contracten sluit, doet er verstandig aan de CRA-conformiteit van onderliggende componenten contractueel te borgen.
AVG: ook persoonsgegevens staan op het spel
Een datacenteruitval raakt vrijwel altijd ook persoonsgegevens. Artikel 32 AVG verplicht verwerkingsverantwoordelijken om de beschikbaarheid van persoonsgegevens te waarborgen, expliciet inclusief het vermogen om bij een incident de toegang tot die gegevens tijdig te herstellen. Geen uitwijk is ook hier geen optie. Bovendien geldt bij een significante uitval veelal een meldplicht aan de Autoriteit Persoonsgegevens binnen 72 uur. U heeft dus niet alleen een leveranciersprobleem. U heeft ook een compliance-probleem.
Welke afspraken horen nu in uw IT-contract?
Al deze regelgeving wijst dezelfde kant op: de lat voor wat contractueel geregeld moet zijn, ligt hoger dan ooit. NIS2 verplicht afnemers actief te sturen op de weerbaarheid van hun leveranciers. De CRA vraagt aandacht voor de kwaliteit van de onderliggende technologie. De AVG vereist dat de continuïteit van gegevensverwerking is gewaarborgd. Samen maken zij van uitwijkafspraken, rampenoefeningen en ketenaansprakelijkheid geen nice-to-have, maar een juridische noodzaak. De vraag is dus niet óf u dit moet regelen, maar of uw contract dat al doet.
Daarbij speelt timing een rol. De Cyberbeveiligingswet treedt naar verwachting op korte termijn in werking. Contracten aanpassen kost tijd, zeker als er een leverancier bij betrokken is die zijn eigen juridische afdeling moet raadplegen. Wie nu begint, heeft de ruimte om dit zorgvuldig te doen. Wie wacht tot er een incident is, heeft die ruimte niet meer.
En dan is er nog het praktische punt: als het misgaat en de toezichthouder klopt aan, wilt u kunnen laten zien dat u uw verplichtingen serieus heeft genomen. Dat begint bij het contract. Concreet pleiten wij voor de volgende elementen in datacenter- en outsourcingcontracten, naast de gebruikelijke SLA-bepalingen:
- Uitwijk. Leg vast dat er een secundaire locatie is, waar die is, hoe die wordt onderhouden en onder welke omstandigheden en binnen welke termijn uitwijk wordt geactiveerd.
- Herstelparameters. RTO en RPO zijn nuttig, maar alleen als ze specifiek zijn per systeem of dienst (kritieke bedrijfsprocessen stellen andere eisen dan archiefsystemen) én als aan overschrijding daadwerkelijke contractuele consequenties zijn verbonden.
- Periodieke uitwijk-tests. Minimaal jaarlijks, met deelname van en rapportage aan de klant, met vooraf afgesproken slagingscriteria en opvolging van bevindingen.
- Ketenaansprakelijkheid. Maakt uw leverancier gebruik van subcontractors voor datacenterruimte of infrastructuur? Zorg dan dat uw contract regelt hoe storingen in die keten worden doorvertaald naar uw positie als klant. En laat uw leverancier borgen dat ook de subcontractor aan gelijkwaardige eisen voldoet.
- Meldplichten. Wie informeert wie, wanneer en hoe bij een calamiteit? Wie voert de regie over de externe communicatie? Onduidelijke communicatielijnen zijn bij incidenten minstens zo schadelijk als de technische uitval zelf.
Is uw IT-contract klaar voor een datacenteruitval?
De casus van UU en KPN is een dure herinnering dat de echte risico's niet in de beschikbaarheidsstatistieken zitten, maar in de witte vlekken van uw SLA. Afspraken over uitwijk, rampenoefeningen en ketenverantwoordelijkheid zitten daar te vaak niet in, of zijn te vaag om iets mee te doen op het moment dat het erop aankomt. Daar bovenop legt de huidige regelgeving (NIS2, AVG en de naderende CRA) aanvullende verplichtingen op die u als afnemer én als aanbieder serieus moet nemen.
Stel uzelf drie vragen:
- Weet u waar uw systemen naartoe gaan als uw primaire datacenter uitvalt, en binnen welke termijn?
- Weet u of uw leverancier gebruikmaakt van subcontractors voor datacenterruimte, en of die keten contractueel is geborgd?
- Wanneer heeft u uw IT-contracten voor het laatst laten reviewen op uitwijk, continuïteit en ketenaansprakelijkheid?
Kunt u één van deze vragen niet met zekerheid beantwoorden, dan is dit het moment om actie te ondernemen, niet pas na een incident. Neem contact met ons op voor een gerichte contractreview. Liever nu een uur investeren dan een week operationele chaos, gevolgd door een juridisch traject waarvan de uitkomst allesbehalve zeker is.
Vragen? Neem gerust contact op.
