Business Brief
SLA-breach: wat het je écht kost
Boete, response-overhead, contractrisico — en waarom de boete de kleinste van de drie is.
De werkelijke kost van een SLA-breach voor een mkb-MSP zit zelden in de contractueel afgesproken boete. Bij veel mkb-MSPs vertegenwoordigt de boete slechts een minderheid van de totale breach-kost — response-overhead en relatieverlies zijn vaak groter. Die boete is doorgaans gekapt op een fractie van de maandelijkse contractwaarde — typisch 5 tot 10 procent — en is daarmee de meest zichtbare maar kleinste van drie componenten die samen het werkelijke risico vormen. Een MSP die alleen op boete-blootstelling stuurt, onderschat structureel het financiële risico dat in zijn portefeuille zit ingebakken.
1. Waarom de SLA-boete de slechtste maatstaf is
In de meeste MSP-contracten staat de SLA-boete er om twee redenen: hij geeft de klant een formele genoegdoening bij uitval, en hij geeft de MSP een gekwantificeerd plafond op zijn aansprakelijkheid. Beide partijen begrijpen dat de boete niet bedoeld is om de werkelijke schade te dekken. Toch is het de boete die de meeste MSP-eigenaren mentaal hanteren als maatstaf voor "wat een breach mij kost" — vaak omdat het het enige getal is dat in een spreadsheet zichtbaar wordt.
Het probleem met die mentale maatstaf is dat hij twee kosten onzichtbaar maakt die in elke breach optreden, ongeacht of er een boete wordt geheven. De eerste is de operationele overhead die de breach veroorzaakt: de uren die engineers steken in resolutie, de afstemming met de klant, de interne rapportage, de root-cause analyse achteraf. De tweede is de relatiekost: de erosie van vertrouwen die bij elke breach optreedt, zelfs als de klant geen formele klacht indient en de boete niet opeist.
Deze twee onzichtbare kosten staan niet op een factuur. Ze tappen niet rechtstreeks uit de cashpositie. Ze hebben geen post in de boekhouding. Maar ze zijn — voor het overgrote deel van de mkb-MSPs — vele malen groter dan de boete zelf, en ze accumuleren over tijd op een manier die de boete niet doet.
Wie de werkelijke breach-kost wil sturen, moet daarom eerst loskomen van de boete als hoofdmaatstaf. Niet omdat de boete er niet toe doet — maar omdat hij zelden de doorslaggevende factor is.
2. De drie componenten van een breach-kost
Een werkbare breach-kost-berekening bestaat uit drie onderscheiden componenten. Ze gedragen zich verschillend qua zichtbaarheid, schaalbaarheid en stuurbaarheid — en moeten daarom afzonderlijk worden geadresseerd.
Component 1
Directe boete
Het contractueel afgesproken bedrag dat de MSP terugbetaalt of crediteert bij een vastgestelde breach. Typisch 5 tot 10 procent van de maandelijkse contractwaarde, vaak met een jaarlijks plafond. Volledig zichtbaar, juridisch hard, en bijna altijd de kleinste van de drie componenten.
Component 2
Response-overhead
De engineering-uren plus management-tijd die elke breach activeert: detectie, escalatie, resolutie, klantcommunicatie, interne rapportage, root-cause analyse, eventueel een post-mortem. Bij een typische breach in een mkb-MSP loopt dit op tot 4 tot 12 uur, afhankelijk van complexiteit en escalatieniveau. Bij volledig belaste uurkosten van richtwaarde 60 tot 80 euro is dat een bedrag dat de directe boete vaak ruim overstijgt.
Component 3
Relatiekost
De verhoogde kans dat een klant — bij een volgende contractronde, bij een aanbieding van een concurrent, of bij een bredere herziening van zijn IT-strategie — de samenwerking heroverweegt of beëindigt. Niet zichtbaar bij één breach. Zwaar voelbaar bij twee tot drie breaches binnen een contractperiode, vooral als die hetzelfde patroon vertonen. Geuit in een verloren contract is dit veruit de zwaarste van de drie componenten, omdat een klantverlies niet de maandwaarde maar de resterende contractwaarde plus de niet-gerealiseerde verlengingen kost.
Een SLA-credit is zelden het grootste probleem. De operationele response-kost en de commerciële relatiekost zijn meestal groter — vaak een veelvoud van de boete zelf, en cumulatief over de looptijd van het contract.
De drie componenten zijn niet additief in elke breach — niet elke breach genereert alle drie. Een eenmalige breach veroorzaakt vrijwel altijd component 1 en 2, maar zelden component 3. Herhaalbreaches op dezelfde klant activeren alle drie. Dat onderscheid is de basis voor de scenario-analyse verderop.
3. Wat een breach je werkelijk kost
De berekening is per component eenvoudig; het totaalbeeld ontstaat door de drie te combineren tegen een realistisch scenario.
Totale breach-kost = Directe boete + Response-overhead + Verwachte relatiekost
Waarbij:
Component 3 is de moeilijkste om te schatten en tegelijk degene die de uitkomst het sterkst beïnvloedt. Een werkbare benadering: gebruik een churn-kans-schatting per breach-categorie, gekalibreerd op je eigen klantenbestand. Eén breach binnen een contractperiode: typisch lage verhoging van churn-kans, orde van grootte 1 tot 3 procentpunt. Twee tot drie breaches: aanzienlijk hogere kans, orde van grootte 10 tot 25 procentpunt. Vier of meer breaches binnen een contractperiode: churn wordt waarschijnlijker dan voortzetting, vooral bij klanten met alternatieve leveranciers in zicht.
Concreet uitgewerkt voorbeeld
Stel: een mkb-MSP-contract van €1.500 per maand. SLA-boete gekapt op 8 procent van de maandfactuur. Volledig belaste engineering-uurkost €65 (werkhypothese). Resterende contractduur 18 maanden, met een verwachte verlengingskans van 70 procent en een verwachte vervolgcontract-waarde van €30.000.
Eén breach, gemiddelde response van 6 uur, churn-kans-verhoging 2 procentpunt:
Het patroon herhaalt zich: ongeacht of je de variabelen aanscherpt of versoepelt, de boete blijft de kleinste van de drie. Bij herhaalbreaches verschuift het zwaartepunt nog verder naar component 3.
Werkhypothese, geen marktnorm. Werkelijke uitkomsten zijn afhankelijk van contracttype, klantsegment, boete-structuur en de breedte van je klantportefeuille. De getallen illustreren orde van grootte, geen specifieke uitkomsten.
4. Drie scenario’s: incident, herhaal, contractbreuk
Hetzelfde contract van €1.500 per maand, dezelfde uurkost van €65, dezelfde 8%-boete-structuur — drie verschillende breach-patronen leveren drie radicaal verschillende kosten op.
| Variabele | Incident | Herhaal | Contractbreuk |
|---|---|---|---|
| Aantal breaches / contractperiode | 1 | 3 | 6+ |
| Response-uren per breach | ~6 | ~8 | ~10 |
| Verhoogde churn-kans | ~2 pp | ~18 pp | ~55 pp |
| Component 1 — boete | ~€120 | ~€360 | ~€720 |
| Component 2 — response | ~€390 | ~€1.560 | ~€3.900 |
| Component 3 — relatiekost | ~€960 | ~€8.600 | ~€26.000 |
| Totaal breach-kost | ~€1.500 | ~€10.500 | ~€30.600 |
Werkhypothese op één representatief contract. Werkelijke uitkomsten variëren met contractwaarde, boete-structuur, klantgrootte en breedte van het klantenbestand. De relatiekost-component is per definitie een verwachte waarde — geen gerealiseerd verlies — en kan in praktijksituaties veel hoger of lager uitvallen.
De drie scenario’s tonen wat in elke werkelijke MSP-portefeuille te zien is: één breach is een operationele aanvaring. Drie breaches binnen een contractperiode is een waarschuwingssignaal. Zes of meer breaches betekent dat je het contract waarschijnlijk al verloren hebt — alleen het opzeggings-moment is nog niet vastgesteld.
En dit is voor één contract. Bij een portefeuille van 80 klanten waar gemiddeld 5 contracten per jaar in herhaal- of contractbreuk-categorie vallen, telt de jaarlijkse breach-kost al snel op tot een bedrag in de tientallen duizenden euro’s — vergelijkbaar met of overstijgend wat een operationele automatisering-investering jaarlijks zou kosten.
5. Wat breach-frequentie zegt over je operationele model
Breach-frequentie is geen prestatie-indicator op zichzelf. Het is een symptoom — en het patroon van breaches verraadt wat er onder de motorkap aan de hand is. Drie patronen komen consistent terug bij mkb-MSPs:
Patroon 1
Breaches geconcentreerd op één of twee klanten
Dit is een klant-fit-probleem, geen operationeel probleem. De getroffen klanten hebben doorgaans een infrastructuurprofiel of werkpatroon dat slecht aansluit op de standaard-leveringsmethode van de MSP. De juiste interventie is meestal commercieel — herziening van de SLA-drempels, andere pricing, of in laatste instantie afscheid — niet technisch.
Patroon 2
Breaches geconcentreerd op één incidenttype
Dit is een standaardisatieprobleem. Een specifiek type incident — bijvoorbeeld vol gelopen logvolumes, een specifieke daemon die crasht onder belasting, of een terugkerende monitoringsfalsie — komt vaker voor dan het wordt opgelost. De juiste interventie is procesgericht: een gedocumenteerde runbook of, in volwassener stadia, een geautomatiseerde policy die het incident structureel afhandelt voordat het de SLA-drempel raakt.
Patroon 3
Breaches verspreid over klanten en incidenttypes
Dit is een schaalprobleem. De MSP groeit sneller dan zijn responscapaciteit, en breaches zijn het symptoom van structurele overbelasting in het engineering-team. Hier wijst breach-frequentie doorgaans samen met een hoge of stijgende engineering-uren per klant per maand: hoe meer EKM, hoe minder buffer er is om bij detectie van een incident snel te reageren, hoe groter de kans op een breach. Dit is het patroon waar operationele automatisering structureel verschil maakt — door reactiewerk te onttrekken aan de menselijke responsketen en breach-vatbare events autonoom af te handelen voordat ze de drempel raken.
Het onderscheiden van deze patronen is een operationele exercitie van een paar uur, niet een diepgaand consultancy-traject. Een eenvoudige analyse van de afgelopen twaalf maanden breach-logging, gefilterd op klant en incidenttype, maakt vrijwel altijd helder welk patroon dominant is. Pas daarna is een investeringsbeslissing onderbouwd.
6. Besliskader: wanneer wordt breach-frequentie een investeringssignaal?
Breach-frequentie alleen rechtvaardigt zelden een grote investering. De vraag is wat het frequentie-niveau zegt over de onderliggende toestand van je operatie — en welke interventie daarbij hoort. Vier categorieën, gerangschikt op jaarlijkse breach-frequentie:
Minder dan 1 breach / jaar
Nog niet automatiseren
Een breach-frequentie onder één per jaar is een prima uitgangspositie. De business case voor automatisering moet je hier niet bij breach-vermijding zoeken — die is te dun om de investering te dragen. Kijk in plaats daarvan naar marge en payback: als je portefeuille robuust genoeg is voor weinig breaches, ligt de vraag eerder bij hoeveel engineering-uren per klant je nu verbruikt en of die te verlagen zijn.
→ Geen breach-gedreven investering. Marge-vraag is relevanter.
2 tot 4 breaches / jaar
Eerst proces standaardiseren
Dit is het bereik waar de meeste mkb-MSPs in zitten en waar de neiging het grootst is om automatisering als oplossing te overwegen — vaak voortijdig. Eerst valideren welk patroon (klant-fit, incidenttype, schaal) dominant is. Als het patroon-1 of patroon-2 is, los het procesmatig op. Als het patroon-3 is, ga door naar de volgende categorie.
→ Patroon-analyse eerst. Investering pas onderbouwd na diagnose.
5 tot 10 breaches / jaar
Nu automatiseren
Bij deze frequentie tilt de jaarlijkse breach-kost al snel boven de jaarlijkse kost van een automatiseringstraject — vooral als component 3 (relatiekost) realistisch wordt meegenomen. De business case staat zelfstandig: zelfs zonder marge-overweging is breach-reductie genoeg om de investering te dragen. Start met de incidenttypes waarop de meeste breaches zich concentreren, niet met de technisch interessantste.
→ Investering op breach-reductie verantwoord. Faseer op incidenttype-impact.
Meer dan 10 breaches / jaar
Nu agressief automatiseren
Bij meer dan tien breaches per jaar is breach-vermijding geen optimalisatie meer; het is een retentievraag. De portefeuille bloedt langs een rand die niet zichtbaar is op de boekhouding maar wel op de churn-cijfers van de komende twaalf maanden. Hier is fasering minder belangrijk dan snelheid: parallelle uitrol op meerdere incidenttypes, met breach-frequentie als primaire KPI.
→ Parallelle uitrol. Uitstel-kost overstijgt implementatie-risico.
Eén onderscheid dat het besliskader doorkruist
Als je breach-concentratie zich richt op één of twee contracten die elk meer dan 8 tot 10 procent van je portefeuille-omzet vertegenwoordigen, schuift de besliskader-uitkomst altijd één categorie omhoog. Het verlies van zo’n contract is niet alleen een directe omzet-amputatie — het brengt vaak ook reputatieschade in dezelfde marktnis met zich mee. Bescherming van key accounts rechtvaardigt agressievere investering dan dezelfde breach-frequentie verspreid over een gebalanceerde portefeuille.
7. Veelgestelde vragen
Wat als onze SLA helemaal geen boeteclausule heeft — dan is er toch geen breach-kost?
De boete is van de drie componenten de kleinste én de meest zichtbare. Een ontbrekende boeteclausule schrapt alleen die ene component, niet de andere twee. Response-overhead bestaat onafhankelijk van wat het contract zegt: een breach gebeurt of niet. Relatiekost bestaat ook: een klant die zijn afgesproken uptime niet krijgt, herinnert zich dat bij de volgende contractronde — los van wat hij contractueel kan claimen. MSPs zonder boeteclausules onderschatten hun breach-blootstelling vaak juist meer, omdat er geen periodieke factuur is die de breach-kost zichtbaar maakt op de boekhouding.
Hoe weeg ik een SLA-credit (terugbetaling aan klant) tegen het verlies aan vertrouwen?
Een SLA-credit is een korte-termijn cash-uitstroom met lange-termijn signaalwaarde. De cash zelf is bijna nooit het probleem; de credit is meestal beperkt tot een fractie van de maandfactuur. Wat een credit feitelijk doet, is de breach administratief en zichtbaar maken — voor jou én voor de klant. Klanten die meerdere credits binnen een contractperiode ontvangen, beginnen vrijwel altijd parallel hun heroriëntatie op alternatieve leveranciers, ook als ze daar niet over communiceren. Een credit is daarom geen oplossing van een breach; het is een vertraagde escalatie.
We hebben maar één of twee breaches per jaar. Loont automatisering dan eigenlijk wel?
Niet op basis van breach-kost alleen. Een lage breach-frequentie betekent doorgaans dat je portefeuille robuust is of dat je SLA-drempels mild zijn ingericht. In beide gevallen is de business case voor automatisering elders te vinden — bij marge en payback, niet bij breach-vermijding. De vraag verschuift dan van "wat kost een breach?" naar "hoeveel engineering-uren per klant per maand verbruik ik en is dat te verlagen?". Dat is de marge-vraag, niet de breach-vraag.
Onze breaches zitten geconcentreerd bij één of twee grote klanten. Hoe verandert dat het rekensommetje?
Aanzienlijk. Wanneer breaches geconcentreerd zitten bij een klein aantal grote contracten, stijgt de relatiekost-component disproportioneel. Verlies van één klant die 8 tot 15 procent van je portefeuilleomzet vertegenwoordigt, raakt je boekhouding direct in een omvang die meerdere jaarboetes overstijgt. In die configuratie is breach-preventie geen operationele beslissing meer maar een commerciële: je beschermt geen SLA, je beschermt key accounts. De investering rechtvaardigt zich vrijwel altijd, ongeacht de overige scenario-uitkomsten.
Hoe sluit dit aan op de SLA-discussie die we voeren met onze grote klanten over strengere uptime-eisen?
Klanten die strengere uptime-eisen onderhandelen, zijn doorgaans op de hoogte van de werkelijke kost van downtime aan hun kant. Wat ze meestal niet zien, is jouw kant van die rekening: de response-overhead en relatiekost die elke breach in jouw organisatie genereert. Een MSP die deze drie-componenten-logica kan toelichten in de SLA-onderhandeling, voert het gesprek vanuit een sterkere positie. Strengere uptime-eisen die je niet realistisch kunt leveren, leiden tot meer breaches — en daarmee meer kost aan beide kanten. Het is daarom een onderhandeling over wederzijds risico, niet alleen over de hoogte van de boete.
Telt een breach door overmacht (cloud-provider down, ISP-storing) ook in deze logica?
Operationeel niet — daar kun je niet op sturen. Financieel wel, want de klant ervaart de downtime gewoon, ongeacht waar de oorzaak ligt. De relatiekost-component is daarom ook bij overmacht aanwezig, zij het beperkter omdat klanten doorgaans meer begrip tonen voor externe oorzaken dan voor interne. Wat in beide gevallen de response-overhead verlaagt, is hoe snel je de oorzaak kunt herleiden en communiceren. Een MSP die een externe storing binnen vijftien minuten kan duiden en aan de klant kan terugkoppelen, beperkt de relatiekost aanzienlijk vergeleken met een MSP die twee uur nodig heeft om dezelfde conclusie te trekken.
Hoe UptimePilot dit aanpakt
UptimePilot is opgebouwd op een breach-vermijdings-logica die de drie componenten apart adresseert. De detectie- en actielaag verkort de tijd tussen event en respons tot voorbij het punt waarop een typische SLA-drempel wordt geraakt — daarmee neemt het de eerste twee componenten weg. De policy-gedreven afhandeling zorgt dat herhalende incidenttypes structureel onder de breach-drempel blijven, waar component 3 het zwaarst weegt.
Een gesprek over jouw breach-blootstelling begint met een analyse van de breaches over de afgelopen twaalf maanden — gecategoriseerd naar de drie patronen uit sectie 5. Pas vanuit dat beeld is een investeringsbeslissing onderbouwd.
Volgende stap
Wat is jouw breach-patroon — en wat kost het je werkelijk?
In een demo doorlopen we eerst je breach-historie van de afgelopen twaalf maanden, categoriseren we het dominante patroon, en bepalen we welk deel van je breach-kost autonome afhandeling kan voorkomen. Geen aanname, geen marketing-cijfer.
Plan een demo →