Wanneer je ICT-diensten of SaaS levert, moeten klanten kunnen vertrouwen op beschikbaarheid en support. Een Service Level Agreement (SLA) legt vast wat je levert, hoe je dat meet en wat er gebeurt bij storingen. Zo voorkom je ruis in de samenwerking en beperk je juridische risico’s.
Wanneer de basisafspraken duidelijk zijn, verschuift de aandacht naar de operationele werkelijkheid. Bij ICT- en SaaS-diensten draait het om continuïteit, voorspelbaarheid en het kunnen sturen op risico’s. Juist op momenten van verstoring of capaciteitsproblemen ontstaan verschillen in verwachting. Een Service Level Agreement brengt die situaties terug tot concrete, toetsbare afspraken, zodat je dienstverlening niet afhankelijk wordt van interpretatie.
Voor veel leveranciers vormt de SLA daarmee een complementair document bij de hoofdovereenkomst of SaaS-overeenkomst. De SLA beschrijft hoe de dienstverlening feitelijk wordt uitgevoerd, terwijl de hoofdovereenkomst bepaalt wat er commercieel en juridisch is afgesproken. Door die documenten op elkaar af te stemmen voorkom je tegenstrijdigheden en krijg je een kader dat zowel voor de klant als voor jouw organisatie werkbaar blijft.
Een Service Level Agreement is een contract waarin je de kwaliteit en continuïteit van jouw ICT- of SaaS-dienstverlening vastlegt. Je beschrijft onder meer de beschikbaarheid van de dienst, responstijden en oplostijden bij incidenten, onderhoudsprocedures, beveiligingsmaatregelen en afspraken over aansprakelijkheid. Zo wordt helder wat een klant mag verwachten en onder welke voorwaarden jij kunt leveren.
Continuïteit is daarbij een belangrijk thema. Organisaties zijn steeds afhankelijker van digitale dienstverlening en willen voorkomen dat een storing of beveiligingsincident hun bedrijfsvoering raakt. Een SLA biedt dan houvast: het maakt concreet hoe snel er wordt gehandeld, welke stappen worden gezet en hoe risico’s worden beheerst.
Dat sluit ook aan bij de verplichtingen uit NIS2. Deze regelgeving legt specifieke zorgplichten op aan “essentiële” en “belangrijke” entiteiten, waaronder het beheersen van risico’s in de toeleveringsketen. In de praktijk worden die verplichtingen vaak doorgelegd naar de ICT-dienstverleners waarop deze organisaties vertrouwen. Een SLA is daarbij een effectief instrument. Zonder zulke afspraken is het lastig om aantoonbaar te voldoen aan de eisen van NIS2.
Kort gezegd: een goede SLA verbindt jouw technische realiteit met de continuïteitseisen van de klant en helpt beide partijen risico’s beheersbaar te houden.
Zodra jouw dienst door organisaties wordt gebruikt, wordt continuïteit een kritische factor. Veel incidenten leiden tot discussies omdat de verwachtingen onduidelijk waren. Denk aan vragen zoals:
Zonder heldere afspraken loop je het risico op claims, geschillen of reputatieschade. Een SLA brengt structuur in deze verwachtingen en maakt afspraken toetsbaar.
SLA’s bestaan in verschillende vormen, afhankelijk van de dienst die je levert en de mate van afhankelijkheid bij de klant. Het type SLA bepaalt welke afspraken noodzakelijk zijn en hoe gedetailleerd je die moet vastleggen.
Bij SaaS draait het om continue beschikbaarheid, snelle incidentafhandeling en voorspelbare releases. Klanten verwachten dat jouw software altijd bereikbaar is, dat updates geen verstoringen veroorzaken en dat beveiliging op orde is.
ICT-dienstverlening omvat veel verschillende processen: beheer, monitoring, helpdesk, remote support, escalaties en onsite werkzaamheden. Een SLA voorkomt dat klanten iets anders verwachten dan wat je daadwerkelijk kunt leveren.
Een SLA werkt alleen als deze begrijpelijk is voor klanten en uitvoerbaar is voor jouw team. Vermijd juridisch of technisch jargon dat klanten mogelijk verkeerd interpreteren. Leg uit wat prioriteiten betekenen, hoe storingen worden gemeld en welke stappen je neemt bij incidenten.
Evalueer je SLA regelmatig. Producten veranderen, klanten groeien en nieuwe wetgeving (zoals NIS2) vraagt soms om aanvullende bepalingen.
Nee, een SLA is niet wettelijk verplicht. Maar zodra je structureel ICT- of SaaS-diensten levert, is een SLA vrijwel onmisbaar. Het document voorkomt discussies en geeft houvast wanneer iets misgaat. Veel grotere organisaties en overheden eisen bovendien een SLA voordat zij een aanbieder toelaten als leverancier.
Een percentage zonder meetregels is juridisch onhoudbaar. Laat vastleggen welk tijdvak, welke tool, welke storingen en welke uitzonderingen gelden.
Klanten ervaren geen waarde als alleen “binnen één uur reageren” is beloofd. Oplostijd is minstens zo belangrijk.
Een vage onderhoudsclausule leidt tot discussies als updates op ongewenste tijden plaatsvinden. Definieer daluren en aankondigingstermijnen.
Een creditregeling van enkele euro’s staat niet altijd in verhouding tot de schade bij kritieke downtime.
Een SLA kan onbedoeld strengere of soepelere afspraken creëren dan de DPA of NIS2 verlangt. Afstemming is cruciaal.
De NIS2-richtlijn verplicht essentiële en belangrijke entiteiten om hun digitale keten aantoonbaar te beheersen. Die verplichting stopt niet bij de voordeur. Organisaties moeten kunnen laten zien dat ook hun ICT-dienstverleners, cloudleveranciers en SaaS-partners voldoende maatregelen treffen om incidenten te voorkomen en de continuïteit te waarborgen. In de praktijk leidt dit tot strengere contractuele eisen richting leveranciers.
Een SLA is een logisch instrument om die verplichtingen concreet te maken. Het document beschrijft hoe snel beveiligingsincidenten worden opgepakt, hoe en wanneer meldingen worden gedaan, welke maatregelen gelden bij verstoringen en op welke manier de dienstverlener zorgt voor beschikbaarheid en herstel. Het geeft ook duidelijkheid over de verantwoordelijkheidsverdeling wanneer meerdere partijen betrokken zijn, bijvoorbeeld bij cloudhosting of een extern dataplatform.
Voor organisaties die onder de NIS2 wetgeving vallen, helpt een SLA om hun zorgplicht richting de toezichthouder inzichtelijk te maken. Voor ICT- en SaaS-leveranciers zorgt dezelfde SLA ervoor dat verwachtingen duidelijk zijn en dat risico’s niet stilzwijgend bij hen komen te liggen. Zo ontstaat een werkbare inrichting van beveiliging, incidentrespons en continuïteit, passend bij zowel de technische realiteit als de compliance-eisen van NIS2.
Veel ICT- en SaaS-bedrijven zoeken naar een Service Level Agreement voorbeeld om grip te krijgen op hoe zo’n document er in de praktijk uitziet. Begrijpelijk, maar belangrijk om te benadrukken: een SLA hoort altijd maatwerk te zijn. Elke dienst kent eigen risico’s, afhankelijkheden, uptime-verwachtingen en supportprocessen. Toch kan een blik op een voorbeeldclausule helpen om de abstractie van een SLA concreter te maken.
Daarom delen we hieronder twee representatieve voorbeeld-clausules die laten zien hoe afspraken over incidentafhandeling en downtime eruit kunnen zien in een professionele SLA.
Het melden van een incident kun je doen door een ticket aan te maken via ons ticketsysteem. Natuurlijk kun je ook even mailen naar (…), maar je zult alsnog altijd een ticket moeten aanmaken wanneer er sprake is van een incident.
Het is voor ons belangrijk om de aard en de ernst van het incident te begrijpen. Daarom moet je bij het melden van een incident de volgende informatie verstrekken:
We kunnen je om aanvullende informatie vragen om het incident goed te begrijpen, en je zult dergelijke gevraagde informatie zo snel mogelijk verstrekken.
We streven ernaar om downtime tot een minimum te beperken en de dienst zo snel mogelijk weer online te krijgen als er iets verkeerd gaat. Er is sprake van downtime wanneer de dienst niet beschikbaar is, tenzij er sprake is van gepland onderhoud.
99,9% uptime staat gelijk aan ongeveer 43 minuten uitval per maand. Leg altijd vast welke periode je meet, welke meetmethode wordt gebruikt, of onderhoud meetelt en welke incidenten worden uitgesloten.
Responstijd is hoe snel je bevestigt dat je een melding hebt ontvangen. Oplostijd gaat over het moment waarop de storing daadwerkelijk is verholpen of gestabiliseerd. Voor P1-incidenten is oplostijd cruciaal.
Ja. Verschillende serviceniveaus horen bij verschillende abonnementen. Een basispakket kan bijvoorbeeld e-mailsupport hebben, terwijl enterprise klanten telefonische P1-support krijgen.
Definieer onderhoudsvensters, aankondigingstermijnen en maximale duur. Beschrijf noodonderhoud apart, zodat beide partijen weten wat ze mogen verwachten.
De SLA regelt prestaties; de verwerkersovereenkomst voor SaaS regelt AVG-taken. Laat rangordeclausules niet botsen. Bij NIS2 moet je in de SLA laten zien hoe monitoring, incidentmelding en beveiliging zijn ingericht.
Meestal via service credits. Leg vast wanneer credits gelden, hoe ze worden berekend en of aanvullende schadevergoeding is uitgesloten. Dit voorkomt onduidelijkheid bij ernstige verstoringen.
Voor veel SaaS-bedrijven wel, mits je met duidelijke pakketverschillen werkt. Voor grotere klanten kun je aanvullende afspraken opnemen via een addendum.
Minimaal jaarlijks of wanneer je dienst verandert, klanten groeien of wettelijke verplichtingen wijzigen. Een verouderde SLA is juridisch riskant.
De NIS2-richtlijn verplicht essentiële en belangrijke entiteiten om risico’s in hun digitale keten aantoonbaar te beheersen. Dat betekent dat zij strengere eisen stellen aan hun ICT- en SaaS-leveranciers. Een SLA speelt daarbij een belangrijke rol, omdat je hierin afspraken vastlegt over incidentrespons, beveiliging, meldtermijnen, continuïteit en samenwerking bij storingen of cyberincidenten.
Lever jij diensten aan een organisatie die onder NIS2 valt, dan is de kans groot dat jouw SLA moet worden aangescherpt om aan deze ketenverplichtingen te voldoen. Een goede SLA helpt zowel de afnemer als de leverancier om risico’s beheersbaar te houden én om aan NIS2-verwachtingen te voldoen.
Wij helpen SaaS-leveranciers en ICT-dienstverleners met het vertalen van hun dienstverlening naar juridisch solide en uitvoerbare afspraken. Geen dikke rapporten, maar duidelijke teksten die passen bij jouw technische realiteit en aansluiten op de compliance-eisen waar steeds meer klanten onder vallen, zoals de ketenverplichtingen uit NIS2.
Wil je dat jouw SLA ook overeind blijft wanneer prestaties, beveiliging of continuïteit ter discussie staan? Neem gerust contact met ons op.
Co-founder & Senior Legal Counsel
We zijn gevestigd op de Vijzelstraat 68 (1017 HL) in het mooie Amsterdam en sinds 2018 ingeschreven in het register van de Kamer van Koophandel onder nummer: 71533230.
Ons BTW-nummer: NL858752530B01.
Vijzelstraat 68
1017 HL, Amsterdam
KvK: 71533230
BTW-nummer: NL858752530B01
Privacy- en cookieverklaring
Hester is een van de oprichters van SenS juristen en werkt als General Legal Consultant. Ze heeft meerdere masters in het recht afgerond aan de Universiteit van Amsterdam en het voorrecht gehad een half jaar aan de University of Hong Kong te mogen studeren. Gefrustreerd over de stoffige juridische wereld, besloot ze destijds het heft in eigen hand te nemen en als ondernemer te starten.
Inmiddels werkt ze al zo’n 8 jaar bij SenS juristen en heeft ze honderden ondernemers mogen bijstaan met vraagstukken op het snijvlak van IT en recht.
Haar passie voor tech (en met name AI!) is van grote waarde bij het ‘vertalen’ van juridische regelgeving op het gebied van ICT/internet-en privacyrecht naar de dagelijkse technische realiteit. Klanten omschrijven haar als doortastend, vakkundig en pragmatisch. Om haar kennis op peil te houden is ze o.a. lid van de Vereniging voor Auteursrecht.
Lucia is mede-oprichter van SenS juristen en werkt gedreven samen met het team aan het leveren van onze juridische diensten op top niveau.
Ze is enorm gemotiveerd en een perfectioniste (soms, oké, dikwijls, op het irritante af) die alles tot in de puntjes geregeld wil zien. Haar passie voor het recht kwam al naar voren tijdens haar studietijd in Amsterdam, waar ze ervoor koos om twee juridische masters te volgen. Het liefst controleert ze alle juridische stukken en correspondentie die dagelijks bij SenS juristen de deur uitgaan meerdere malen, zodat de cliënt er zeker van kan zijn dat alles perfect geregeld is.
Verder is ze een groot fan van koffie, reist ze graag en is ze actief als gitariste (ja, echt).