Een goede SLA voor IT-diensten bevat minimaal de volgende onderdelen: een duidelijke beschrijving van de dienst, meetbare prestatie-indicatoren (KPI’s), beschikbaarheidsgaranties, incidentprocedures, verantwoordelijkheden van beide partijen, beveiligingsafspraken en exitbepalingen. Zonder deze bouwstenen biedt een service level agreement weinig houvast bij conflicten of tegenvallende prestaties.
Voor finance- en businesscontrollers die IT-budgetten beheren, is een waterdichte SLA geen juridische formaliteit maar een financieel instrument. Het bepaalt wat je krijgt voor je geld, wanneer je recht hebt op compensatie en hoe je de relatie kunt beëindigen zonder ongewenste verrassingen. In dit artikel behandelen we de meest gestelde vragen over SLA opstellen en de clausules die echt het verschil maken.
Welke onderdelen zijn verplicht in een goede SLA?
Een goede SLA voor IT-diensten bevat altijd een servicebeschrijving, prestatienormen, meetmethodiek, incidentclassificaties, verantwoordelijkheidsverdeling, rapportageverplichtingen en een escalatieprocedure. Ontbreekt één van deze elementen, dan ontstaan interpretatieverschillen die bij een conflict vrijwel altijd in het voordeel van de leverancier uitvallen.
Concreet betekent dit dat een solide IT-contract de volgende basisonderdelen bevat:
- Servicebeschrijving: wat levert de leverancier precies, inclusief scope en uitsluitingen
- Beschikbaarheidsgaranties: uitgedrukt in percentages per maand of jaar, met definitie van geplande en ongeplande downtime
- Incidentclassificaties: prioriteiten (P1 t/m P4) met bijbehorende respons- en oplostijden
- Meetmethodiek: hoe en door wie worden prestaties gemeten, en welke tools worden gebruikt
- Rapportage: frequentie, format en wie de rapportages ontvangt
- Escalatieprocedure: stapsgewijze aanpak bij structurele onderprestatie
- Wijzigingsprocedure: hoe worden aanpassingen aan de SLA overeengekomen
Let er ook op dat de SLA aansluit op de werkelijke bedrijfsprocessen. Een beschikbaarheidsnorm van 99,5% klinkt indrukwekkend, maar als die downtime altijd op maandagochtend valt, heeft dat een heel andere impact dan willekeurig verdeelde uitval.
Wat is het verschil tussen een SLA, OLA en UC?
Een SLA (Service Level Agreement) is de overeenkomst tussen een dienstverlener en een klant over de te leveren dienst. Een OLA (Operational Level Agreement) is een interne afspraak binnen de leveranciersorganisatie zelf. Een UC (Underpinning Contract) is een contract tussen de leverancier en zijn eigen toeleveranciers. Samen vormen deze drie documenten de keten die de SLA-prestaties mogelijk maakt.
Als afnemer van IT-diensten ben je primair gebonden aan de SLA. Toch is het waardevol om te begrijpen hoe de keten erachter werkt. Als een leverancier zijn SLA-verplichtingen niet nakomt, kan de oorzaak liggen bij een zwakke OLA intern of een ontoereikende UC met een onderaannemer. Bij kritische diensten is het verstandig om bij het opstellen van een SLA ook te vragen naar de onderliggende OLA’s en UC’s, zodat je weet hoe robuust de hele keten is.
Hoe stel je meetbare KPI’s op voor een IT-SLA?
Meetbare SLA-KPI’s voor IT-diensten zijn gebaseerd op vier principes: ze zijn specifiek gedefinieerd, objectief meetbaar, direct gerelateerd aan bedrijfsimpact en realistisch haalbaar voor de leverancier. Vage normen als “snelle respons” of “hoge beschikbaarheid” zijn geen KPI’s maar marketingteksten.
Gebruik bij het opstellen van KPI’s de volgende aanpak:
- Begin bij bedrijfsimpact: welke IT-processen zijn kritisch voor de bedrijfsvoering, en wat kost elke minuut uitval?
- Vertaal naar meetbare normen: stel concrete drempelwaarden vast, zoals een maximale responstijd van 15 minuten voor P1-incidenten
- Definieer de meetmethode: leg vast welk systeem meet, wie toegang heeft tot de data en hoe geschillen worden opgelost
- Stel het rapportageritme vast: maandelijkse rapportage is een minimum; voor kritische diensten is wekelijkse monitoring aan te raden
- Bouw een reviewmoment in: KPI’s verouderen; plan elk jaar een evaluatie om normen bij te stellen op basis van veranderde bedrijfsbehoeften
Veelgebruikte KPI’s in een IT-SLA zijn: uptimepercentage, Mean Time to Respond (MTTR), Mean Time to Repair (MTTR), First Call Resolution Rate en Change Success Rate. Zorg dat elke KPI een duidelijke definitie heeft van wat wel en niet meetelt, om discussies achteraf te voorkomen.
Welke boeteclausules en credits horen in een IT-SLA?
Een IT-SLA moet boeteclausules of service credits bevatten die automatisch in werking treden bij het niet halen van afgesproken normen. De hoogte van de credit moet in verhouding staan tot de impact van de tekortkoming, en de procedure voor het claimen ervan moet helder zijn vastgelegd.
In de praktijk werken service credits beter dan boetes. Bij credits ontvangt de klant een korting op de volgende factuur of extra dienstverlening, terwijl boetes juridisch complexer zijn en de relatie met de leverancier sneller beschadigen. Zorg in elk geval dat de SLA-clausules het volgende regelen:
- De drempelwaarde waarbij credits van toepassing worden (bijvoorbeeld bij beschikbaarheid onder 99%)
- De berekeningswijze van de credit (percentage van de maandfactuur per uur uitval)
- Een maximumplafond voor credits per periode
- De procedure voor het indienen van een claim, inclusief termijnen
- Uitsluitingen waarbij de leverancier niet aansprakelijk is, zoals force majeure of fouten aan klantzijde
Wees alert op SLA’s waarbij de maximale credit zo laag is dat er voor de leverancier geen financiële prikkel bestaat om te presteren. Een credit van 5% van de maandfactuur bij een dag volledige uitval is voor veel leveranciers goedkoper dan de investering in betere infrastructuur.
Wat moet er in een SLA staan over security en compliance?
Een IT-SLA moet expliciete afspraken bevatten over informatiebeveiligingsnormen, incidentrespons bij datalekken, naleving van relevante wet- en regelgeving (zoals de AVG), auditrechten en de verantwoordelijkheidsverdeling bij beveiligingsincidenten. In 2026 zijn security-afspraken geen bijlage meer maar een kernonderdeel van elke serieuze SLA voor IT-dienstverlening.
Concreet gaat het om afspraken op de volgende vlakken:
- Beveiligingsnormen: welke certificeringen heeft de leverancier (ISO 27001, NEN 7510, SOC 2) en wat is de geldigheidsduur
- Datalekprocedure: binnen welke termijn meldt de leverancier een datalek, en welke informatie verstrekt hij daarbij
- AVG-verplichtingen: is er een verwerkersovereenkomst, en hoe wordt omgegaan met subverwerkers
- Auditrechten: heeft de klant het recht om audits uit te voeren of te laten uitvoeren bij de leverancier
- Penetratietesten: wie is verantwoordelijk voor periodieke beveiligingstesten en wie ontvangt de resultaten
Koppel de security-afspraken ook aan de KPI’s. Een maximale meldtermijn van 72 uur bij een datalek is niet alleen een wettelijke verplichting onder de AVG maar ook een meetbare norm die je in de SLA kunt vastleggen.
Hoe regel je exitbepalingen in een IT-SLA?
Exitbepalingen in een IT-SLA regelen hoe de samenwerking wordt beëindigd, welke data wordt overgedragen, wat de opzegtermijnen zijn en welke kosten de leverancier in rekening mag brengen bij beëindiging. Goede exitbepalingen worden onderhandeld bij het aangaan van het contract, niet op het moment dat de relatie al onder druk staat.
Een complete exitregeling bevat minimaal de volgende elementen: een opzegtermijn die past bij de complexiteit van de dienst, een overdrachtsplan voor data en systemen, afspraken over de medewerking van de leverancier tijdens de transitieperiode en een overzicht van eventuele exit fees. Zorg ook dat de SLA vastlegt in welk formaat data wordt aangeleverd bij vertrek. Leveranciers die data alleen in een proprietair formaat teruggeven, creëren feitelijk een lock-in die de exitkosten enorm verhoogt.
Wanneer moet je een bestaande SLA herzien?
Een bestaande SLA voor IT-diensten moet worden herzien bij contractverlenging, bij significante wijzigingen in de dienst of het gebruik, na herhaalde SLA-overtredingen en minimaal eenmaal per jaar als onderdeel van contractbeheer. Een SLA die twee jaar oud is zonder herziening weerspiegelt vrijwel nooit meer de huidige situatie.
Concrete aanleidingen voor een SLA-herziening zijn onder meer: een fusie of overname, de introductie van nieuwe technologieën (zoals cloudmigratie), gewijzigde wet- en regelgeving, structurele onderprestatie door de leverancier of een significante groei of krimp in het gebruik van de dienst. Een jaarlijkse SLA-review is een goede gewoonte waarbij je de KPI’s evalueert, de prestatiehistorie doorneemt en de normen aanpast aan de veranderde bedrijfsbehoeften.
Hoe Thornstein Groep helpt bij het opstellen en beoordelen van IT-SLA’s
Een SLA is uiteindelijk zo sterk als de kennis van degene die hem onderhandelt. IT-leveranciers beschikken over uitgebreide juridische en commerciële expertise; als afnemer sta je zonder gespecialiseerde ondersteuning vaak op achterstand. Thornstein Groep helpt organisaties die kennisongelijkheid te overbruggen.
Wat wij concreet doen bij IT-contracten en SLA-vraagstukken:
- Beoordelen van bestaande SLA’s op ontbrekende clausules, ongunstige boeteregelingen en zwakke exitbepalingen
- Ondersteunen bij het opstellen van meetbare KPI’s die aansluiten op de bedrijfsprocessen
- Onderhandelen met IT-leveranciers over betere prestatienormen en commerciële voorwaarden
- Adviseren over softwarelicenties en de contractuele risico’s die daarbij horen
- Begeleiden van SLA-reviews en contractverlengingen om kostenreductie en betere voorwaarden te realiseren
Wil je weten of jouw huidige IT-SLA’s voldoen aan de eisen van 2026? Neem contact op met Thornstein Groep voor een vrijblijvend gesprek.
