Veel softwareleveranciers en IT-dienstverleners bieden hun diensten aan met onder meer een Service Level Agreement (SLA). In de praktijk blijkt dat veel SLA's vooral bestaan uit technische termen, zonder dat duidelijk is welke rechten en verplichtingen partijen daadwerkelijk hebben.

Een goede SLA is veel meer dan een lijst met responstijden. Het document vormt de basis voor de verwachtingen tussen leverancier en klant en voorkomt discussies wanneer zich storingen, beveiligingsincidenten of beschikbaarheidsproblemen voordoen.

Maar wat moet er nu eigenlijk in een SLA staan?

Wat is een SLA?

Een Service Level Agreement (SLA) is een overeenkomst waarin afspraken worden vastgelegd over de kwaliteit van dienstverlening. Vaak vormt de SLA een aanvulling op een hoofdovereenkomst voor software, cloud-diensten, hosting, managed services of IT-support.

De SLA beschrijft onder meer:

  • welke diensten worden geleverd;

  • welke serviceniveaus gelden;

  • hoe storingen worden afgehandeld;

  • welke verantwoordelijkheden partijen hebben;

  • welke prestaties verwacht mogen worden.

Een SLA biedt daarmee zowel juridische duidelijkheid als operationele houvast.

1. Een duidelijke omschrijving van de dienstverlening

Een van de meest voorkomende fouten is dat onvoldoende wordt beschreven welke diensten precies onder de SLA vallen.

Beschrijf daarom concreet:

  • de software of systemen waarop de SLA betrekking heeft;

  • de omgeving (on-premise, cloud of hybride);

  • de supportdiensten;

  • eventuele monitoring;

  • onderhoudswerkzaamheden;

  • beveiligingsdiensten;

  • back-updiensten.

Hoe duidelijker de scope, hoe kleiner de kans op interpretatieverschillen.

2. Beschikbaarheid (Uptime)

Voor veel organisaties is beschikbaarheid de belangrijkste SLA-afspraak.

Dit gebeurd aan de hand van percentages, bijvoorbeeld 99,5%.

Belangrijk is niet alleen het percentage zelf, maar vooral ook hoe dit wordt berekend.

Denk daarbij aan de meetperiode (maand of jaar), geplande onderhoudsvensters, uitzonderingen wegens overmacht en storingen bij derde partijen zoals Microsoft Azure of AWS.

Een uptime-garantie zonder duidelijke meetmethode biedt weinig juridische waarde.

3. Incidentclassificaties en prioriteiten

Niet iedere storing heeft dezelfde impact.

Daarom werken professionele SLA's vaak met prioriteitsniveaus. Geregeld wordt gebruik gemaakt van de volgende prioriteitslevels:

  • Prioriteit 1 (Kritiek) - volledige uitval van bedrijfskritische systemen

  • Prioriteit 2 (Hoog) - belangrijke functionaliteit werkt niet

  • Prioriteit 3 (Normaal) - beperkte impact

  • Prioriteit 4 (Laag) - kleine fouten en cosmetische issues

Door vooraf prioriteiten vast te leggen ontstaat duidelijkheid over de ernst van meldingen.

4. Reactietijden en oplostijden

Een SLA moet onderscheid maken tussen de reactietijd (de tijd waarbinnen de leverancier een melding oppakt) en de oplostijd (de tijd waarbinnen de leverancier de storing daadwerkelijk verhelpt of een werkbare oplossing biedt).

Bij een melding op het hoogste prioriteitsniveau (P1) zullen de reactie- en oplostijd korter zijn dan bijvoorbeeld een melding op niveau P4. Dit kan lopen van een tijdsbestek van een reactietijd van 1 uur bij P1 tot een oplostijd ‘planning bij volgende release’ bij P4.

5. Onderhoud en updates

Bij cloudsoftware vinden updates vaak automatisch plaats.

Leg daarom vast wanneer onderhoud mag worden uitgevoerd en hoe klanten worden geïnformeerd daarover. Daarnaast is goed om op te nemen welke onderhoudsvensters gelden, hoe noodonderhoud wordt afgehandeld en hoe nieuwe softwareversies worden uitgerold.

Voor SaaS-oplossingen is dit een essentieel onderdeel van de SLA.

6. Security en informatiebeveiliging


Cybersecurity speelt een steeds grotere rol. Een moderne SLA bevat daarom afspraken over toegangsbeveiliging, encryptie, monitoring, logging en incidentrespons.

Daarnaast is het verstandig te verwijzen naar relevante normen (indien van toepassing) zoals ISO 27001, NIS2 of branche-specifieke beveiligingsstandaarden.




7. Back-ups en herstel

Van belang is om vast te leggen of er back-ups worden gemaakt en zo ja, wat de klant daar van mag verwachten.

Een SLA moet daarom duidelijk aangeven:

  • hoe vaak back-ups worden gemaakt;

  • hoe lang gegevens worden bewaard;

  • waar back-ups worden opgeslagen;

  • hoe herstelprocedures werken.

Hierbij worden vaak afspraken gemaakt over RPO (Recovery Point Objective), namelijk over hoeveel data maximaal verloren mag gaan.

En ook over hoe snel systemen weer operationeel moeten zijn, de zogenaamde RTO (Recovery Time Objective),.

8. Rollen en verantwoordelijkheden

Een SLA werkt alleen wanneer duidelijk is wie waarvoor verantwoordelijk is.

Leg vast wat voor rekening van de leverancier komt en welke rol de klant heeft.

Veel geschillen ontstaan doordat deze verantwoordelijkheden onvoldoende zijn beschreven.

9. Escalatieprocedures

Wat gebeurt er wanneer een storing niet tijdig wordt opgelost?

Een SLA moet beschrijven wie de contactpersoon is, wanneer wordt geëscaleerd en welke managementniveaus betrokken worden. Een goede escalatieprocedure voorkomt frustratie aan beide kanten.

10. Rapportages en evaluaties

Professionele SLA's bevatten vaak afspraken over periodieke rapportages.

Denk aan uptime-statistieken, incidentoverzichten en beveiligingsrapportages.

Daarnaast kan een periodiek service-overleg worden opgenomen om prestaties en verbeteringen te bespreken.

11. Aansprakelijkheid en service credits

Een SLA moet aansluiten op de algemene voorwaarden en de hoofdovereenkomst.

Daarbij is het belangrijk vast te leggen:

  • welke gevolgen gelden bij het niet behalen van serviceniveaus;

  • of er service credits worden verstrekt;

  • welke aansprakelijkheidsbeperkingen gelden;

  • welke uitsluitingen van toepassing zijn.

Service credits zijn vaak een commerciële compensatie en vormen doorgaans geen erkenning van aansprakelijkheid.

12. Looptijd en beëindiging

Tot slot moet een SLA duidelijk maken wanneer deze ingaat en wat er gebeurt na beëindiging van de dienstverlening.

Vooral bij cloudsoftware is het belangrijk afspraken te maken over data-export en gegevensverwijdering.

Conclusie

Een goede SLA is geen technisch document dat ergens onderin een contract wordt toegevoegd. Het is een essentieel onderdeel van iedere professionele IT-overeenkomst.

Door duidelijke afspraken te maken over beschikbaarheid, support, beveiliging, incidentafhandeling en verantwoordelijkheden weten beide partijen precies wat zij van elkaar mogen verwachten.

Juist in een tijd waarin organisaties steeds afhankelijker worden van cloudsoftware, AI-oplossingen en digitale dienstverlening, vormt een goed opgestelde SLA een belangrijk instrument om risico's te beheersen en discussies te voorkomen.

Heeft u vragen of ondersteuning nodig?

Onze ICT-juristen kunnen u van dienst zijn met het inhoudelijk juridisch beoordelen van een SLA of met het opstellen ervan. Daarbij maken wij gebruik van de jarenlange ervaring die wij hebben opgebouwd bij het opstellen en beoordelen van SLA's voor zowel leveranciers als voor afnemers.

Neem vandaag nog contact met ons op via 010 2290 646 of klik op onderstaande button