Veel SLA’s zijn in de praktijk moeilijk afdwingbaar omdat ze te vaag zijn geformuleerd, meetcriteria ontbreken of de bewijslast bij de verkeerde partij ligt. Dit probleem speelt bij vrijwel elke organisatie in het MKB die afhankelijk is van een IT-dienstverlener. In dit artikel beantwoorden we de meest gestelde vragen over SLA-handhaving, zodat je weet waar je op moet letten.
Wat maakt een SLA juridisch gezien moeilijk te handhaven?
Een SLA is juridisch moeilijk te handhaven wanneer de afspraken te algemeen zijn geformuleerd, essentiële definities ontbreken of de overeenkomst geen duidelijke meetmethode bevat. Zonder concrete, objectief toetsbare normen heeft een rechter of arbiter weinig houvast om te bepalen of een dienstverlener zijn verplichtingen is nagekomen.
Een veelvoorkomend probleem is dat termen als “redelijke responstijd” of “optimale beschikbaarheid” niet juridisch bindend zijn. Ze klinken professioneel, maar als er geen getal aan vasthangt, kun je er niets mee in een geschil. Hetzelfde geldt voor begrippen als “hoge prioriteit” of “kritieke storing” die niet zijn gedefinieerd in de overeenkomst zelf.
Daarnaast speelt de bewijslast een grote rol. Als jij als klant moet aantonen dat de dienstverlener tekortgeschoten is, maar je hebt geen toegang tot de monitoringdata of logging van de IT-partij, sta je juridisch zwak. Een goed opgestelde SLA regelt ook wie de meetdata beheert en hoe die data beschikbaar wordt gesteld.
Hoe worden SLA-prestaties in de praktijk gemeten?
SLA-prestaties worden in de praktijk gemeten aan de hand van vooraf vastgelegde KPI’s zoals uptime-percentages, gemiddelde responstijden en oplostijden per prioriteitsklasse. Deze metingen zijn alleen betrouwbaar als ze worden uitgevoerd via onafhankelijke of gedeelde monitoringtools waarvan beide partijen de uitkomsten kunnen inzien.
In de ideale situatie werkt jouw IT-dienstverlener met een ticketsysteem dat automatisch tijdstempels registreert: het moment van melding, de eerste reactie en de uiteindelijke oplossing. Op basis van die data kun je achteraf controleren of de afgesproken normen zijn gehaald.
Waar het in de praktijk misgaat, is dat veel IT-partijen alleen intern meten. Jij als klant ziet dan alleen een samengevatte rapportage, zonder de onderliggende data te kunnen verifiëren. Zorg er daarom voor dat je in de SLA afspreekt dat je recht hebt op inzage in de ruwe meetdata, of dat er periodieke rapportages worden geleverd met een vaste structuur en onderbouwing.
Wat zijn de meest voorkomende conflictpunten in een SLA?
De meest voorkomende conflictpunten in een SLA zijn onduidelijke prioriteitsclassificaties, discussie over wat een “storing” is versus een “gebruikersfout”, en onduidelijkheid over wat wel en niet binnen de scope van de dienstverlening valt. Deze grijze gebieden leiden tot frustratie aan beide kanten.
Een klassiek voorbeeld: jij meldt een storing, maar de IT-dienstverlener classificeert het als een lage prioriteit omdat het systeem “technisch beschikbaar” is. Jij ervaart echter een volledig stilgelegde werkplek. Als de SLA geen functionele definitie van beschikbaarheid bevat, heeft geen van beide partijen gelijk of ongelijk.
Andere veelgehoorde conflictpunten zijn:
- Onduidelijkheid over wie verantwoordelijk is bij problemen met derde partijen zoals cloudleveranciers
- Geen afspraken over geplande onderhoudsmomenten die buiten de uptime-berekening vallen
- Verschillende interpretaties van “oplossing”: is een tijdelijke workaround ook een oplossing?
- Geen heldere escalatieprocedure bij herhaalde overschrijdingen
Al deze punten zijn te voorkomen door de SLA vóór ondertekening grondig door te nemen en elk scenario concreet te laten uitwerken.
Welke rol spelen boeteclausules bij SLA-handhaving?
Boeteclausules, ook wel malus-bepalingen of service credits genoemd, spelen een beperkte maar nuttige rol bij SLA-handhaving. Ze creëren een financiële prikkel voor de dienstverlener om afspraken na te komen, maar ze lossen een structureel probleem niet op als de onderliggende normen niet deugen.
In de praktijk zijn boeteclausules in IT-contracten vaak gemaximeerd op een klein percentage van de maandelijkse factuurwaarde. Dat betekent dat de financiële consequentie voor een IT-partij beperkt is, zelfs bij herhaalde overschrijdingen. Voor jou als klant is de schade door downtime of slechte service vaak veel groter dan de boete die je kunt claimen.
Toch hebben boeteclausules waarde. Ze dwingen beide partijen om helder te zijn over normen en gevolgen, en ze geven jou als klant een formeel instrument om een gesprek te openen over structurele tekortkomingen. Gebruik ze niet als doel op zich, maar als onderdeel van een bredere aanpak waarbij je ook escalatiemogelijkheden en evaluatiemomenten hebt vastgelegd.
Wanneer is een SLA wél effectief afdwingbaar?
Een SLA is effectief afdwingbaar wanneer alle normen meetbaar en objectief zijn, de meetmethodiek is vastgelegd, beide partijen toegang hebben tot de data, en er een duidelijke escalatieprocedure bestaat. Kort gezegd: wanneer er geen ruimte is voor interpretatie en de bewijslast eerlijk is verdeeld.
Concrete kenmerken van een afdwingbare SLA zijn:
- Uptime en responstijden uitgedrukt in harde getallen per prioriteitsklasse
- Een gedeeld ticketsysteem of monitoringplatform dat beide partijen kunnen raadplegen
- Duidelijke definities van alle gebruikte begrippen, inclusief wat buiten scope valt
- Een vastgelegde escalatieprocedure met namen en contactgegevens
- Periodieke evaluatiemomenten waarop de SLA-prestaties gezamenlijk worden besproken
Een goede IT-dienstverlener is transparant over zijn prestaties en heeft er geen moeite mee om meetbare afspraken vast te leggen. Bij managed IT-diensten is die transparantie extra belangrijk, omdat jij als klant volledig afhankelijk bent van de kwaliteit van het beheer. Wil je weten hoe een goed servicecontract eruitziet en wat je daarin kunt vastleggen? Neem contact op met Symbis voor een eerlijk en concreet gesprek over jouw situatie.
Veelgestelde vragen
Hoe begin ik met het herzien van een bestaande SLA die niet goed werkt?
Begin met het documenteren van alle incidenten waarbij de SLA tekortschoot: welke afspraken waren onduidelijk, welke normen ontbraken en waar ontstond discussie? Gebruik deze lijst als basis voor een gesprek met je IT-dienstverlener. Vraag om een formele herzieningsronde waarbij elk knelpunt concreet wordt uitgewerkt met meetbare definities en heldere verantwoordelijkheden.
Wat moet ik doen als mijn IT-dienstverlener weigert meetdata met mij te delen?
Als een dienstverlener toegang tot monitoringdata weigert, is dat een serieus signaal. Controleer eerst of het recht op inzage contractueel is vastgelegd — als dat niet zo is, heb je juridisch weinig grond. Is het wél afgesproken maar wordt het niet nagekomen, dan kun je de dienstverlener formeel in gebreke stellen. Overweeg daarnaast om een onafhankelijke monitoringtool aan te schaffen die jouw eigen systemen bewaakt, zodat je altijd over eigen bewijsmateriaal beschikt.
Is een SLA alleen relevant voor grote bedrijven, of ook voor kleine MKB-organisaties?
Een SLA is juist voor kleine MKB-organisaties cruciaal, omdat zij vaak geen eigen IT-afdeling hebben en volledig afhankelijk zijn van externe dienstverleners. Hoe kleiner de organisatie, hoe groter de impact van downtime of trage respons op de dagelijkse bedrijfsvoering. Een goed opgestelde SLA geeft ook kleinere bedrijven de tools om hun dienstverlener verantwoordelijk te houden, zonder dat daar een juridisch team voor nodig is.
Wat is het verschil tussen een SLA en een DPA, en heb ik beide nodig?
Een SLA (Service Level Agreement) regelt de kwaliteit en beschikbaarheid van de geleverde diensten, terwijl een DPA (Data Processing Agreement of Verwerkersovereenkomst) de verwerking van persoonsgegevens regelt conform de AVG. Als jouw IT-dienstverlener toegang heeft tot persoonsgegevens van medewerkers of klanten, heb je juridisch gezien beide nodig. Ze vullen elkaar aan: de SLA borgt de servicekwaliteit, de DPA borgt de privacyverplichtingen.
Hoe voorkom ik dat mijn IT-dienstverlener geplande onderhoudsmomenten misbruikt om slechte uptime-cijfers te verdoezelen?
Leg in de SLA expliciet vast hoeveel geplande onderhoudsuren per maand of kwartaal zijn toegestaan, en bepaal dat deze minimaal 48 uur van tevoren worden gecommuniceerd. Spreek ook af dat gepland onderhoud buiten kantooruren moet plaatsvinden, tenzij jij als klant uitdrukkelijk akkoord gaat. Zo voorkom je dat de dienstverlener ruime onderhoudsvensters gebruikt als ontsnappingsroute bij het berekenen van de daadwerkelijke uptime.
Wat is een realistisch uptime-percentage om op te nemen in een SLA voor MKB-organisaties?
Voor de meeste MKB-organisaties is een uptime van 99,5% per maand een realistische en afdwingbare norm, wat neerkomt op maximaal circa 3,6 uur uitval per maand. Hogere normen zoals 99,9% zijn technisch mogelijk maar vereisen duurdere infrastructuur en strikte redundantie, wat de kosten aanzienlijk verhoogt. Bespreek met je dienstverlener welk uptime-niveau aansluit bij jouw bedrijfskritische processen en wat de bijbehorende investeringen zijn.
Kan ik mijn contract ontbinden als mijn IT-dienstverlener de SLA structureel niet nakomt?
Ja, structurele niet-nakoming van een SLA kan juridisch gezien grond zijn voor ontbinding van het contract, maar alleen als de tekortkoming voldoende ernstig en aantoonbaar is. Zorg daarom dat je een schriftelijk dossier opbouwt met gedateerde meldingen, reactietijden en overschrijdingen. Stel de dienstverlener eerst formeel in gebreke en geef een redelijke termijn voor herstel — pas daarna is ontbinding juridisch sterker onderbouwd. Raadpleeg bij twijfel een juridisch adviseur met ervaring in IT-contracten.