Service Level Agreement: uitleg, voorbeeld, checklist

Wat is een Service Level Agreement?

Laten we eerst kijken naar wat een Service Level Agreement precies is. Een SLA is een overeenkomst tussen een IT-leverancier en een klant. En daarin gaat het specifiek over de kwaliteit van de diensten die worden afgenomen. Dit gaat dus nog een stapje verder dan het ICT contract zelf. Een SLA wordt ook wel een Diensten Niveau Overeenkomst of Service Niveau Overeenkomst genoemd. 

Het afsluiten van een SLA geeft duidelijkheid. Zowel voor de leverancier als voor jou als klant. Je spreekt in de overeenkomst namelijk af wat de normen zijn voor de beschikbaarheid en ondersteuning van de dienst. En die maak je meetbaar. Zo is het eenvoudig te controleren of de juiste kwaliteit wordt geleverd. De kans op onenigheid maak je hiermee kleiner.

Stel je sluit een contract af voor webhosting. In een SLA maken jullie vervolgens afspraken over de bereikbaarheid van de server. Is 99% voor jou voldoende? Of heb je met jouw bedrijf liever de garantie van 99,8%? En wat als er problemen zijn. Wil je dan gebruik maken van telefonische 24-uursservice of enkel bereikbaarheid tijdens kantooruren? Dit zijn onderdelen die thuishoren in een SLA.

Service Level Agreement: Checklist

Uit welke onderdelen bestaat een SLA? Dat hangt af van een aantal factoren. Denk aan welke diensten er worden afgenomen, in welke mate en hoe afhankelijk je als klant bent van de dienstverlening. Er komt dus altijd een stukje maatwerk bij kijken. 

De meest voorkomende onderdelen zijn:

• Diensten. Welke diensten worden er afgenomen? Wat wel en wat niet?
• Contactgegevens van betrokken partijen. Wie is wanneer te bereiken?
• Responsibility matrix. Wie is waarvoor verantwoordelijk? En wie mag problemen melden?
• Classificatie matrix. Hoe classificeer je verschillende storingen?
• Responstijden. Welke responstijd verwacht je bij welke storing? 
• Oplossingstijden. Wat zijn realistische oplossingstijden? Het is altijd lastig een precieze oplossingstijd in te schatten. Om deze reden wordt er ook wel eens voor gekozen om dit onderdeel te laten vervallen in een SLA.
• Uptime garanties. Hoe vaak en hoe lang mag er een storing zijn? 
• Onderhoud. Wanneer vindt onderhoud plaats? En hoe wordt die aangekondigd?
• Bugs en updates. Hoe wordt er omgegaan met fouten in de software? Wie lost dit op en hoe snel? Wordt er extra onderhoud gepland? En wat wordt er gedaan als er een kritische beveiligingslek wordt ontdekt?
• Beveiliging. Hoe wordt ervoor gezorgd dat de beveiliging op orde is? 
• Monitoring. Hoe worden alle onderdelen in de gaten gehouden? Denk aan servers, websites en verbindingen. En wie doe dat?
• Back-ups. Welke back-ups worden bewaard? En hoe lang mag het maximaal duren voordat een back-up wordt teruggezet?
• Rapportages. Van welke onderdelen zie je graag een rapportage? En hoe vaak? Rapportages kunnen gaan over security incidenten, vraag naar support of in hoeverre de afspraken in de SLA zijn nagekomen.
• Evaluaties. Hoe vaak evalueren jullie de SLA? Welke afspraken zijn nagekomen? 

Welke onderdelen zijn van toepassing op jouw bedrijfssituatie? Schrijf ze uit en voeg ze samen zoals onderstaande voorbeeld van een Service Level Agreement. Vervolgens kijk je samen met je leverancier wat haalbaar is, wat acceptabele oplossingen zijn en welke aanvullingen eventueel nodig zijn. 

Service Level Agreement: Voorbeeld

Hieronder geven we je een globaal voorbeeld van hoe een SLA opgebouwd kan zijn.  De details hangen af van jouw bedrijfssituatie en zullen dus altijd maatwerk zijn. Wil je een  

Service omschrijving

Leverancier zorgt voor:
Beschrijf welke diensten je graag bij de leverancier neer wilt leggen. Bijvoorbeeld monitoring van hard- en software, 24/7 ondersteuning bij onderbrekingen van dienstverlening en back-up van de database.

Klant zorgt voor:
Beschrijf hier welke verantwoordelijkheden jij neemt zodat de leverancier aan de gestelde kwaliteit kan voldoen. Denk aan het verlenen van toegang tot netwerk en hardware, het op tijd vervangen van hardware en contact opnemen met de leverancier in geval van problemen.

Responsibility matrix

Verantwoordelijkheden maak je eenvoudig zichtbaar met een responsibility matrix. Zoals het voorbeeld hier onder.

Incidenten

Met een incidentenmatrix geef je aan hoe je wilt dat er gehandeld wordt. Bijvoorbeeld zo.

Beschrijf hoe er melding dient te worden gemaakt van een incident. Per telefoon of per e-mail. Welke categorie incidenten kunnen niet wachten om opgelost te worden binnen kantoortijden? En welke maximale responstijd geldt daarvoor?

Voor reactietijden tijdens kantoortijden zou je onderstaande aan kunnen houden.

Back-up

Beschrijf puntsgewijs van welke data er wanneer een back-up moet worden gemaakt. En hoe lang je een back-up wilt bewaren. Het is ook handig een jaarlijkse restore test te laten uitvoeren door de leverancier.

Hersteltijd

Beschrijf hier de afspraken over het herstellen van data vanuit een back-up. Onderstaand schema is een voorbeeld hoe je dit zou kunnen weergeven.

Beveiliging

Welke afspraken maken jullie over beveiliging? Wanneer en door wie worden updates gedaan? Welke encryptie technologieën worden minimaal toegepast? Bijvoorbeeld: iedereen is verplicht voldoende veilige wachtwoorden te gebruiken. Of alle beheer en ondersteuning wordt gedaan via beveiligde verbindingen.

Servicemanagement

Beschrijf hier de afspraken met betrekking tot evaluatie, verbeteringen en rapportage.

Ben jij goed voorbereid?

Als ICT experts met een ISO 27001 certificaat voor informatiebeveiliging op zak weten we als geen ander hoe je informatie goed beveiligt. Ben je benieuwd naar de risico’s voor jouw bedrijf? Neem vandaag nog vrijblijvend contact op. Wij denken graag met je mee.