Partnerblog
De Service Level Agreement (SLA) was lange tijd vooral een commercieel en operationeel instrument: een afspraak tussen een IT-leverancier en een klant over de kwaliteit, beschikbaarheid en continuïteit van een dienst. Die functie blijft onverkort gelden, maar het regelgevend landschap is de voorbije jaren grondig veranderd. Met DORA- en de NIS2-wetgeving is de SLA voor heel wat ondernemingen niet langer een louter onderhandelbaar kwaliteitsdocument, maar mede een instrument om aan dwingende wettelijke verplichtingen te voldoen.
Voor de bedrijfsjurist betekent dit dat het opstellen en herzien van SLA’s vandaag op twee sporen tegelijk gebeurt: het klassieke contractuele spoor én het compliance-spoor.
De SLA blijft in essentie maatwerk
Een SLA is een overeenkomst, meestal gekoppeld aan een hoofdcontract, die vastlegt aan welke dienstniveaus de leverancier moet voldoen. Die niveaus worden uitgedrukt in Service Level Objectives, geoperationaliseerd via concrete en meetbare Key Performance Indicators. Beschikbaarheidspercentages, hersteltijden, reactietermijnen en onderhoudsvensters zijn de klassieke voorbeelden.
Een goede SLA omschrijft nauwkeurig de scope van de diensten, de meetmethode en rapportering, de gevolgen van wanprestatie (de zogenaamde service credits of andere sancties, te onderscheiden van een schadevergoeding), een wijzigingsprocedure die de SLA tot een “levend document” maakt, en een geschillenregeling met eventueel een escalatiemechanisme. Een standaard-SLA bestaat niet: het blijft maatwerk dat afhangt van de aard van de dienst en het belang ervan voor de klant. Hieraan is niets veranderd. Wel nieuw in vergelijking met vroeger is dat een aantal van die bouwstenen voor bepaalde sectoren niet langer vrij onderhandelbaar zijn, maar wettelijk worden voorgeschreven.
DORA: de SLA als verplicht onderdeel van het ICT-contract
Sinds 17 januari 2025 is de Digital Operational Resilience Act (Verordening (EU) 2022/2554, “DORA”) van toepassing. DORA viseert de financiële sector in brede zin, met name banken, verzekeraars, betalingsinstellingen, beleggingsondernemingen, pensioeninstellingen en… hun ICT-dienstverleners. Het opzet is om de digitale operationele weerbaarheid van de financiële sector te verzekeren, ook wanneer kritieke of belangrijke functies worden uitbesteed. Een functie geldt volgens artikel 3, 22 als kritiek of belangrijk wanneer de verstoring wezenlijk afbreuk zou doen aan de financiële prestaties van een financiële entiteit of aan de soliditeit of de continuïteit van haar diensten en activiteiten, of waarvan de beëindiging of gebrekkige of mislukte uitvoering wezenlijk afbreuk zou doen aan de permanente naleving door een financiële entiteit van de voorwaarden en verplichtingen uit hoofde van haar vergunning of haar andere verplichtingen uit hoofde van het toepasselijke recht inzake financiële diensten.
Voor de SLA-praktijk zijn vooral de artikelen 28 en 30 DORA van belang, verder uitgewerkt in technische reguleringsnormen -de zogenaamde regulatory technical standards (RTS). DORA verplicht om de afspraken met derde ICT-dienstverleners vast te leggen in een schriftelijk document, waarvan de SLA een vast onderdeel uitmaakt. Het contract moet een reeks verplichte clausules bevatten omschreven in artikel 30 DORA, en die clausules raken rechtstreeks aan de inhoud van wat traditioneel in de SLA stond. Denk aan een volledige en duidelijke beschrijving van alle ICT diensten, gedetailleerde dienstniveaus die zowel kwalitatief als kwantitatief worden vastgelegd, bepalingen over de locatie waar gegevens worden verwerkt, toegangs-, inspectie- en auditrechten voor de financiële entiteit en de toezichthouder, medewerking aan toezicht, regels rond onderaanneming van kritieke of belangrijke functies, en exitstrategieën die de continuïteit en de gegevensoverdracht bij beëindiging waarborgen.
Bijzondere aandacht verdienen de beëindigingsgronden. DORA schrijft voor dat de overeenkomst in welbepaalde omstandigheden moet kunnen worden beëindigd zonder dat de bedrijfsvoering van de financiële entiteit wordt verstoord.
Het onderscheid tussen gewone en “kritieke of belangrijke” functies is bepalend voor de zwaarte van het regime. Ondersteunt de uitbestede dienst zulke functie, dan gelden strengere eisen in artikel 30 lid 3. De verantwoordelijkheid voor de naleving blijft daarbij bij de financiële instelling liggen, ook al wordt de feitelijke uitvoering uitbesteed. Voor de leverancierszijde is de boodschap: standaard algemene voorwaarden volstaan niet langer, en bestaande contracten moesten in principe al tegen begin 2025 zijn heronderhandeld.
NIS2: cyberbeveiliging doorheen de hele keten
Waar DORA sectoraal is, heeft de NIS2-wet een veel horizontale, en dus bredere weerslag. De Belgische wet van 26 april 2024 zette de NIS2-richtlijn om en trad in werking op 18 oktober 2024. De wet onderscheidt “essentiële” en “belangrijke” entiteiten en breidt het toepassingsgebied fors uit ten opzichte van de oude NIS-regeling, met een groottecriterium (in de regel middelgrote en grote ondernemingen in de geviseerde sectoren). Daarnaast vallen bepaalde categorieën entiteiten ongeacht hun grootte automatisch onder de wet, zoals onder meer aanbieders van openbare elektronische-communicatienetwerken, DNS[1] dienstaanbieders en verleners van gekwalificeerde vertrouwensdiensten.
De voor de SLA meest relevante verplichting is die rond de beveiliging van de toeleveringsketen, of de zogenaamde supply chain. Een NIS2-entiteit moet de cyberbeveiligingsrisico’s in haar leveranciersketen beoordelen en beheersen, en beveiligingseisen contractueel vastleggen met haar dienstverleners. Het gevolg reikt verder dan de entiteiten die zelf onder de wet vallen: ook een onderneming die zelf buiten het toepassingsgebied valt, maar zich in de keten van een NIS2-entiteit bevindt, kan via haar contract met die entiteit alsnog gehouden worden om cyberbeveiligingsmaatregelen na te leven. Voor wie aan de leverancierszijde staat, is dit een belangrijk aandachtspunt: de NIS2-verplichtingen “stromen door” via contractuele weg, ook als ze niet rechtstreeks op de leverancier wegen.
Concreet betekent dit dat de beveiligingsbepalingen in een SLA aan belang winnen. De Belgische NIS2 wet legt in artikel 30 een reeks minimummaatregelen op: risicoanalyse, incidentenbehandeling, beveiliging bij aankoop en onderhoud van systemen, toegangscontrole, encryptie en dergelijke. Die vertalen zich naar concrete afspraken over beveiligingsniveaus, meldingstermijnen bij incidenten en medewerkingsverplichtingen. Voor ondernemingen die niet zeker zijn of ze in de keten vallen, raadt het Centrum voor Cybersecurity België aan om ten minste het CyberFundamentals (CyFun®) Framework van het niveau “Basic” te hanteren[2]. Bovendien introduceert NIS2 een verscherpte bestuurdersaansprakelijkheid: het toezicht op de naleving is een verantwoordelijkheid van het bestuursorgaan, wat de inzet van een correcte contractuele vertaling verder verhoogt.
Wat dit betekent voor uw SLA-praktijk
De rode draad is dat de SLA haar klassieke contractuele functie behoudt maar er een laag bijkomt. Wie vandaag een SLA opstelt of herziet, doet er goed aan om in een vroeg stadium drie vragen te beantwoorden. Valt (een van) de partijen onder DORA, NIS2, of geen van beide? Ondersteunt de dienst een kritieke of belangrijke functie? Betreft het een dienst waarvan de beveiliging onder NIS2 contractueel moet worden vastgelegd als deel van de toeleveringsketen? En bevindt de leverancier zich in de keten van een gereguleerde entiteit, ook al is hij zelf niet rechtstreeks geviseerd? De antwoorden bepalen welke clausules niet langer vrij onderhandelbaar zijn, en waar de speelruimte wel blijft bestaan.
Auteurs
[1] Domain Name System.
