Waarom je SOC vastloopt en wat XDR verandert (en niet)

Een SOC loopt zelden vast door te weinig tools. Het loopt vast op de tijd die het kost om verspreide signalen tot één verhaal te maken. XDR verkort die tijd, maar lost niet alles op.

Securityteams investeren al jaren in SIEM, SOAR en nu XDR om detectie en response te verbeteren. Toch blijven veel SOC's overbelast. Het aantal alerts blijft stijgen, onderzoeken duren te lang en de directie begrijpt nog steeds niet goed wat er tijdens een incident is gebeurd. Uit onderzoek van Devo onder 200 SOC-managers en -directeuren (2025) blijkt dat 83% van de analisten overweldigd raakt door het aantal alerts, false positives en gebrek aan context. En 85% is veel tijd kwijt aan het verzamelen en koppelen van bewijs voordat een alert een bruikbare case wordt. Dat vertraagt de respons op echte dreigingen.

XDR verbetert hoe data wordt gekoppeld en onderzocht, maar lost niet vanzelf op hoe een SOC werkt. Voor organisaties die risico moeten verkleinen en moeten laten zien dat ze in control zijn, zit het echte probleem in het gat tussen wat je kunt en wat je aantoonbaar bereikt.

Een gewone ochtend in de SOC

Het is 09:00 uur. De dashboards staan vol alerts, van endpoint, cloud, identiteit en netwerk. Elke melding voegt een stukje informatie toe, maar geen enkele vertelt het hele verhaal. Uitzoeken hoe ze samenhangen: daar begint het werk.

Een analist start een onderzoek. Vijf tabbladen open, dan tien. De activiteit op een endpoint ziet er verdacht uit, maar is niet doorslaggevend. Er is een afwijkende login van dezelfde gebruiker, maar of die ermee te maken heeft, is onduidelijk. De cloudlogs tonen activiteit, maar zonder context weet je niet waar die in de volgorde past. Een tweede analist schuift aan, dan een derde. Om twaalf uur probeert het team nog steeds dezelfde vraag te beantwoorden: wat is er nou eigenlijk gebeurd?

Waarom je in de juiste tools investeerde en toch hier uitkomt

De meeste organisaties deden precies wat ze moesten doen. Ze kochten een SIEM om data te centraliseren en aan compliance-eisen te voldoen. Ze voegden SOAR toe om repetitief werk te automatiseren. En recent kwam XDR erbij om detectie over omgevingen heen te verbeteren. Elke beslissing was op dat moment logisch, en elke laag voegde iets toe.

Maar in de SOC zelf veranderde het dagelijkse werk vaak nauwelijks. Analisten moesten nog steeds tussen systemen schakelen om te snappen wat er speelde. Incidenten kostten nog steeds uren om te reconstrueren. En als de directie vragen stelde, waren de antwoorden ingewikkelder dan nodig.

Het probleem was nooit te weinig data. Het was het gat tussen data hebben en die data gebruiken voor een heldere beslissing. In dat gat verdwijnt het vertrouwen, bij analisten en bij de directie.

Waar gaat de tijd echt naartoe?

De meeste incidenten zijn niet lastig te detecteren omdat ze onzichtbaar zijn. Ze zijn lastig omdat de informatie versnipperd is. Een endpoint-alert vertelt zelden het hele verhaal. Een afwijkende login ook niet, en een verdachte netwerkverbinding evenmin. Het echte signaal verschijnt pas als je die gebeurtenissen aan elkaar koppelt en in de goede volgorde zet.

Zonder die koppeling moeten analisten het verhaal zelf bouwen. Eerst het ene systeem, dan het volgende, steeds met de vraag of gebeurtenissen bij elkaar horen of toeval zijn. Dat is zorgvuldig en belangrijk werk, maar het is traag. En in die vertraging groeit het risico. Niet bij de eerste detectie, maar in de tijd die nodig is om te begrijpen wat die detectie betekent.

Voor de directie geeft dat een ander soort druk. Duurt het uren om uit te leggen wat er is gebeurd, dan weet niemand of de situatie ooit onder controle was. Het vertrouwen in de SOC brokkelt af. Niet omdat het team tekortschiet, maar omdat niemand de uitkomst helder kan uitleggen.

Wat verandert XDR in de praktijk?

XDR is precies voor dit probleem bedacht. In plaats van alerts als losse signalen te behandelen, koppelt het activiteit van endpoint, identiteit, netwerk en cloud in één overzicht. Het doel is niet meer data verzamelen, maar de data die je al hebt bruikbaar maken tijdens een onderzoek.

Daarmee verandert het startpunt van een analist. Die hoeft niet meer tool na tool te openen om een incident in elkaar te puzzelen, maar begint met een tijdlijn die al laat zien hoe gebeurtenissen samenhangen. Dat scheelt veel handwerk, verkort de tijd tussen detectie en beslissing, en maakt het makkelijker om een incident zo uit te leggen dat ook de raad van bestuur het snapt. Hoe XDR zich verhoudt tot MDR, lees je in MDR vs XDR: wat is het verschil en wat heb je nodig?

Waar passen SIEM en SOAR nog?

SIEM en SOAR hebben nog steeds hun plek. Maar geen van beide is gemaakt om snel te bepalen of meerdere signalen bij hetzelfde incident horen.

Een response automatiseren werkt alleen als eerst duidelijk is waarop je reageert.

Wat lost XDR niet op?

Het is verleidelijk om te denken dat betere detectie vanzelf betere resultaten oplevert. In de praktijk is dat zelden zo.

Daarom zien sommige SOC's na de invoering van XDR een meetbare verbetering, en merken andere er weinig van. Het verschil zit niet in het platform. Het zit in hoe het wordt beheerd, onderhouden en wie er eigenaar van is.

Het gat tussen kunnen en aantoonbaar bereiken

De meeste organisaties hebben de onderdelen die ze nodig hebben al in huis. Ze verzamelen data, automatiseren processen en hebben detectieplatformen draaien. Toch komen bij elk incident dezelfde vragen terug:

• Hoe lang duurde het voordat we begrepen wat er was gebeurd?
• Hoe zeker zijn we van die conclusie?
• Kunnen we het helder uitleggen aan de directie?

Zijn die antwoorden wisselend, dan ontbreekt het niet aan capability. Dan zit het probleem in hoe detectie en response daaromheen zijn ingericht. Hier lopen ook de verwachtingen rond XDR vaak stuk. Het platform maakt beter koppelen en onderzoeken mogelijk, maar als de processen eromheen dat niet ondersteunen, blijft de verbetering op papier staan.

Waar stuur je op als het resultaat uitblijft?

Blijft een SOC worstelen na de invoering van XDR, dan is nog een tool erbij zelden de beste stap. Zet eerst een stap terug en bepaal waar de gaten echt zitten. Deze vragen helpen daarbij:

• Begint een onderzoek met een heldere tijdlijn, of met een stapel losse alerts?
• Is de dekking gelijk over endpoint, identiteit, netwerk en cloud?
• Is de ruis in de loop van de tijd afgenomen, of gelijk gebleven?
• Kun je een incident helder samenvatten in één verhaal?

Dit zijn geen technische vragen, maar operationele. Ze bepalen of detectie echt werkt of alleen output produceert. En het zijn precies de vragen die je directie vroeg of laat ook gaat stellen.

En als je geen eigen SOC hebt?

Veel organisaties met een klein IT-team hebben helemaal geen eigen SOC. Dan speelt hetzelfde probleem, alleen groter: niemand legt 's nachts de verbanden tussen meldingen. In dat geval is MDR meestal de eerste stap. Een externe partij bewaakt je omgeving dag en nacht en grijpt in als er iets gebeurt.

Bij ON2IT combineert onze Managed Global SOC (GSOC) monitoren, ingrijpen en begrijpen in één laag, gebouwd op het AUXO™ Zero Trust Platform. Lees meer over MDR Detect™ en MDR Prevent™.

Conclusie

De meeste SOC's lopen niet vast omdat ze te weinig technologie hebben. Ze lopen vast omdat begrip te lang op zich laat wachten, en omdat het daarna moeilijk uit te leggen is aan iedereen buiten de SOC.

XDR helpt dat gat te dichten. Het koppelt incidenten sneller, scheelt handmatig reconstrueren en geeft teams een duidelijker verhaal. Maar het werkt alleen met de juiste dekking, goed afgestelde detectie en ervaren toezicht. De vraag is dus niet of je XDR hebt. De vraag is of analisten elk onderzoek kunnen beginnen met overzicht in plaats van chaos, en of de directie na een incidentbriefing echt weet waar ze aan toe is.

FAQ

Over de auteur

Karin Muller leidt de marketing van ON2IT, waar ze een AI-first marketingteam bouwt waarin security vanaf het begin is ingebouwd. Ze maakt van thought leadership iets waar sales mee verder kan, met Threat Talks en Hack the Boat als vlaggenschepen.