Waarom loopt een MDR-implementatie vaak vast bij MSP's?
Een MDR-dienst loopt vast wanneer een MSP na livegang vijftig tot honderd security-incidenten per dag krijgt zonder vooraf gedefinieerde prioriteiten, mandaten en escalatiepaden. De implementatie faalt niet op techniek, maar op ontbrekende afspraken over wie wat mag afsluiten en welke klant-impact acceptabel is.
Welke beslissingen moeten staan vóór de MDR-knop omgaat?
Voor activatie moeten drie zaken vastliggen: prioritering per incident-type, mandaat van engineers richting klant-infrastructuur, en impact-classificatie per klant. Een fotografiebedrijf accepteert een uur downtime op zijn website; een gemeente die paspoorten uitgeeft niet. Zonder deze classificatie vooraf belandt het MSP-team in paniek-modus zodra de eerste honderd alerts binnenkomen.
-
Waarom ontstaat alert-overload?
Bij go-live van MDR komen vaak vijftig tot honderd secured incidents per dag binnen. Twee engineers zien dan letterlijk de bomen door het bos niet meer en raken verlamd in triage.
-
Wie mag wat afsluiten?
Mandaat-afspraken ontbreken vaak: mag een engineer backend-infrastructuur van een klant offline halen om een incident te stoppen? Zonder schriftelijke bevoegdheid blijft een incident liggen of escaleert de schade.
-
Hoe weeg je klant-impact af?
Een uur downtime bij een fotograaf is laag-impact, dezelfde uur bij een gemeente die paspoorten uitgeeft is hoog-impact en politiek gevoelig. Impact-classificatie hoort per klant vastgelegd, niet per incident bedacht.
Vaak steken partijen de kop in het zand omdat ze die honderd incidents niet meer boven water krijgen.
