Een kritieke SaaS-dienst ligt eruit. De IT-manager en de contractmanager zitten samen in een gedeelde drive te zoeken naar het juiste contract. Wat was ook alweer de afgesproken hersteltijd? Hebben we recht op service credits? Loopt dit contract binnenkort af? Veertig minuten later hebben ze de PDF gevonden, maar de storing duurt nog steeds voort. Dit is het moment waarop je merkt dat je je SLA’s niet echt beheert. Je bewaart ze alleen.
SLA IT-leveranciers monitoren betekent iets anders dan controleren of een dienst technisch draait. Het gaat om de vraag of de contractuele afspraak wordt nagekomen: de beschikbaarheid, de responstijd, de hersteltijd en de compensatie bij afwijking. Die afspraken staan in PDF’s, niet in je systeem. En daar begint het probleem. Volgens onderzoek van WorldCC, PwC en McKinsey heeft 95 procent van de organisaties geen volledig inzicht in de eigen contractuele verplichtingen. Bij IT-contracten met hun stapels bijlagen is dat probleem het grootst.
Je ERP weet wie je IT-leverancier is, maar niet wat je hebt afgesproken
Je ERP of spend-systeem doet precies waarvoor het gebouwd is. Het registreert de leverancier, het contractbedrag en de facturen. Het matcht inkooporders en houdt de looptijd bij. Voor de administratieve basis is dat prima.
Maar het ERP kent de SLA-normen niet. Het weet niet dat je met deze hostingpartij 99,9 procent beschikbaarheid hebt afgesproken. Het weet ook niet dat de responstijd bij een prioriteit-1-incident vijftien minuten is. Die inhoud zit in de bijlage van het contract. En die bijlage leest niemand op het moment dat het misgaat.
Het verschil is dat tussen registratie en management. Je systeem registreert dát je een contract hebt. De inhoud van dat contract, de afspraken en de openstaande verplichtingen, leeft ergens anders. Meestal in Word, PDF en de hoofden van een paar mensen. Registratie blijft in je systeem. Managen doe je in een contractdashboard boven op dat systeem.
Waarom technische monitoring geen SLA-monitoring is
Als IT-manager heb je waarschijnlijk uptime-monitoring draaien. Een dashboard dat pingt of een dienst bereikbaar is en een melding stuurt bij downtime. Nuttig, maar het beantwoordt een technische vraag: draait het nog?
Dat is iets anders dan de contractuele vraag: wordt de afspraak nagekomen? Een dienst kan technisch beschikbaar zijn en tóch buiten de afgesproken norm vallen, bijvoorbeeld doordat de responstijd bij incidenten structureel overschreden wordt. Uptime meten vertelt je niets over service credits, escalatieprocedures of herstelverplichtingen.
Er is nog een probleem. De maandrapportage over de prestatie komt vaak van de leverancier zelf. Dat is de slager die zijn eigen vlees keurt. Zonder een eigen bron waarin de afgesproken norm naast de gemeten prestatie staat, heb je geen onafhankelijke tegenhouder. Je gelooft wat de leverancier rapporteert, of je zoekt het handmatig uit.
Welke SLA-afspraken je bij IT-leveranciers op contractniveau bewaakt
Om je SLA IT-leveranciers te monitoren op contractniveau, leg je per contract vast wat er is afgesproken en of dat gehaald wordt. De kern:
- Beschikbaarheid: het afgesproken uptime-percentage en de service windows waarbinnen dat geldt
- Responstijd: de tijd waarbinnen de leverancier op een incident reageert, per prioriteitsniveau
- Hersteltijd (MTTR): de tijd waarbinnen een incident opgelost moet zijn
- Incidentaantallen: hoeveel storingen zijn er, en blijft dat binnen de afgesproken grenzen
- Service credits: op welke compensatie je recht hebt bij structurele afwijking, en of die daadwerkelijk verrekend wordt
Begin niet met alle vijf tegelijk. Zet eerst de beschikbaarheid en de hersteltijd naast de werkelijke prestatie, want dat zijn de afspraken die tijdens een storing tellen. Service credits volgen daarna, want die kun je pas verrekenen als je de afwijking hard kunt maken. Bij elk punt hoort dezelfde vraag: wie meet, en waar staat die afspraak vastgelegd? Een SLA-norm die je niet kunt terugvinden op het moment dat het telt, is geen sturingsmiddel. Het is een dossier.
Wat betekent de Cyberbeveiligingswet voor je IT-contracten?
De Cyberbeveiligingswet (Cbw), de Nederlandse invulling van NIS2, is op 15 augustus 2026 in werking getreden. Zonder algemene overgangstermijn. Circa 8.000 tot 10.000 organisaties zijn direct verplicht, met registratie in het entiteitenregister via het NCSC.
Voor jou als contracteigenaar draait het om de ketenverantwoordelijkheid. De wet verplicht je om cyberrisico’s uit je leveranciersketen aantoonbaar te beheersen. Concreet: je moet weten welke ICT-leveranciers je hebt, welke beveiligings- en continuiteitseisen in die contracten staan, en welke afspraken openstaan. Dat is precies de informatie die nu versnipperd in PDF’s leeft.
GRIP is geen cybersecuritytool en maakt niemand NIS2-compliant. GRIP geeft grip op de contractkant van die zorgplicht, zodat je kunt aantonen welke eisen in welk contract staan en wat er openstaat. De rest van je beveiligingsbeleid staat daar los van. Meer over die contractkant lees je in deze uitleg over NIS2 en leverancierscontracten.
Het echte probleem: meerdere leveranciers, één dienst
In de praktijk levert zelden één partij een complete dienst. Neem een bedrijfskritische applicatie: die draait bij de ene leverancier, de hosting loopt via een tweede, en het beheer ligt bij een derde. Elk met een eigen SLA en een eigen definitie van beschikbaarheid. Drie contracten, drie normen, drie meetmethodes.
Bij een storing lopen de verantwoordelijkheden door elkaar. De hostingpartij wijst naar de applicatieleverancier, die weer naar de beheerpartij. En jij zoekt intussen in drie verschillende contracten wie waarvoor aan de lat staat. Zonder één overzicht waarin die afspraken naast elkaar staan, verlies je de discussie voordat die begint.
SLA-afspraak en prestatie in één bron
De oplossing begint niet bij een strengere SLA of een extra monitoringtool. Die heb je waarschijnlijk al. De oplossing begint bij één bron waarin de afgesproken norm, de gemeten prestatie, de openstaande verplichtingen en de contracttermijn samenkomen.
Dat is wat het contractdashboard van GRIP doet. Je legt per ICT-contract vast welke SLA’s zijn afgesproken en zet de prestatie ernaast. Bij een storing zie je binnen seconden wat de afgesproken hersteltijd is en of je recht hebt op compensatie. Bij een verlenging weet je of deze leverancier zijn SLA de afgelopen jaren gehaald heeft. Je onderhandelt dan op cijfers, niet op onderbuikgevoel.
GRIP meet niet je uptime. GRIP is de plek waar de afspraak, de verplichtingen en de prestatie bij elkaar komen. De registratie blijft in je ERP, het managen doe je in GRIP. Volgens de eigen cijfers van GRIP besparen organisaties die dit gestructureerd oppakken tot 30 procent op hun contractadministratie. GRIP is ISO 27001 gecertificeerd voor informatiebeveiliging en ISO 9001 voor kwaliteitsmanagement, met alle contractdata verwerkt binnen Europa.
Veelgestelde vragen
Wat is het verschil tussen SLA-monitoring en uptime-monitoring?
Uptime-monitoring meet of een dienst technisch bereikbaar is. SLA-monitoring bewaakt of de contractuele afspraak wordt nagekomen: responstijd, hersteltijd, service credits en escalatieprocedures. Een dienst kan draaien en tóch buiten de afgesproken norm vallen.
Kan mijn ERP mijn SLA’s van IT-leveranciers monitoren?
Je ERP registreert de leverancier, het contractbedrag en de facturen, maar kent de SLA-normen en openstaande verplichtingen niet. Die inhoud leeft in de contractbijlagen. Daarvoor heb je een contractmanagement-laag boven je ERP nodig.
Welke SLA-KPI’s moet ik bij IT-leveranciers bewaken?
De kern is beschikbaarheid, responstijd, hersteltijd (MTTR), incidentaantallen en de service credits waarop je bij afwijking recht hebt. Leg per contract vast wie meet en waar de afspraak is vastgelegd.
Wat betekent de Cyberbeveiligingswet voor mijn leverancierscontracten?
Sinds 15 augustus 2026 verplicht de Cbw je om cyberrisico’s uit je leveranciersketen aantoonbaar te beheersen. Je moet weten welke ICT-leveranciers je hebt, welke beveiligings- en continuiteitseisen in de contracten staan en welke afspraken openstaan.
Maakt GRIP mijn organisatie NIS2-compliant?
Nee. GRIP is geen cybersecurity- of compliancetool. GRIP geeft grip op de contractkant van de zorgplicht, zodat je aantoonbaar in beeld hebt welke eisen in welk contract staan en wat er openstaat.
Hoe houd ik overzicht als meerdere IT-leveranciers samen één dienst leveren?
In multi-vendor omgevingen leg je de SLA’s van alle betrokken contracten naast elkaar in één bron. Zo zie je bij een storing direct wie waarvoor verantwoordelijk is, in plaats van in meerdere contracten te zoeken.
Kan ik SLA-prestaties gebruiken bij contractverlenging?
Ja. Als je per contract vastlegt of de SLA gehaald is, heb je bij een verlenging of heronderhandeling een feitelijke onderhandelingspositie in plaats van onderbuikgevoel.
Wil je zien hoe je SLA-afspraken en prestaties van je IT-leveranciers in één overzicht samenbrengt? Bekijk het contractdashboard of boek een demo van GRIP.