Een SOC-team opbouwen begint met een kleine ploeg die breed inzetbaar is, en pas later met gespecialiseerde rollen en tiers. Dat is de lijn van de Joint SOC Best Practice, het handboek dat de SOC's van de Rijksoverheid samen hebben geschreven.
Ik las de nieuwste versie met de bril van iemand die SOC-teams helpt bemensen. Het hoofdstuk over mensen is het nuttigst, ook voor organisaties buiten de overheid.
Wat is de Joint SOC Best Practice?
Het Joint SOC (J-SOC) is een samenwerkingsverband van SOC's binnen de Rijksoverheid. Versie 3.1 van hun Best Practice is van 23 december 2025 en gemarkeerd als TLP:CLEAR, dus vrij te delen. Aan het document werkten onder meer SOC's van de Belastingdienst, DICTU, Rijkswaterstaat, SSC-ICT, Justitie en Veiligheid, DUO en Defensie mee.
Het volgt het SOC Capability Maturity Model (SOC-CMM), met vijf domeinen: business, people, process, technology en services. Het document zegt zelf dat het ook bedoeld is als inspiratie voor organisaties die geen lid zijn, en als houvast om regie te voeren op een uitbesteed SOC.
Eerst het fundament, dan het SOC
De opvallendste zin staat vooraan: het bouwen van een SOC kan nooit de eerste stap zijn in een securitystrategie. Een SOC heeft een fundament nodig. Je moet weten welke assets er in je netwerk staan en wie de eigenaar is, er moet informatiebeveiligingsbeleid en een ISMS liggen, en processen voor logmanagement, incidentmanagement en assetmanagement moeten al draaien.
Dat sluit aan op wat het Cybersecuritybeeld Nederland 2026 laat zien: veel organisaties hebben de basis nog niet op orde. Wie dan een SOC neerzet, koopt vooral alerts die niemand kan duiden.
Welke rollen heeft een SOC?
De Best Practice baseert de rollen op het NIST NICE-framework. Je ziet daarin onder andere security analyst, incident responder, forensisch analist, threat intelligence analyst, vulnerability analyst en security architect. Daarbovenop noemt het document rollen die je in de praktijk tegenkomt: SOC manager, SOC lead, coördinator, shift lead, detection engineer, automation engineer en threat hunter.
Een nuttig onderscheid: een rol is iets anders dan een functie. Eén senior analist kan zowel analist als vulnerability analist zijn, of analist en teamlead tegelijk. Voor een klein team is dat precies de bedoeling. Het document adviseert om te beginnen met algemene rollen als "analist" en "engineer", en die pas te splitsen als het SOC groeit. Wel met minimaal één senior per aandachtsgebied.
Tiers: wanneer wel en wanneer niet?
Veel SOC's werken met tiers. In het model van de Best Practice handelt tier 0 zoveel mogelijk automatisch af, doet een junior analist in tier 1 de triage met playbooks, pakt een medior analist in tier 2 de analyse en respons op, en neemt een senior in tier 3 de echte incidenten. Detection engineering en automation engineering lopen eronder door, en werk schuift via "shift left" steeds verder naar de lagere tiers.
Het document is eerlijk over de nadelen. Tiering geeft een duidelijke taakverdeling en maakt de dagelijkse bezetting makkelijker. Maar medewerkers worden beperkter in hun werk, doorgroeien gaat minder makkelijk en je wordt als werkgever minder interessant. Het uitgangspunt is bovendien dat tier 1 op termijn grotendeels geautomatiseerd wordt.
Dat laatste zou ik zwaar laten wegen. Bouw je nu een SOC met een rij junior analisten in tier 1, dan bouw je een laag die je over een paar jaar wilt automatiseren.
Hoe groot moet een SOC-team zijn?
Een vast getal geeft het document niet, wel een richtlijn voor de structuur. De span of control van één manager ligt volgens de Best Practice tussen 5 en 15 mensen, afhankelijk van hoe zelfstandig het team werkt en hoe volwassen het SOC is. Voor een nieuw SOC is het advies om met een klein aantal medewerkers te beginnen. Dat volgt ook het NCSC in zijn factsheet SOC inrichten: begin klein, dat waarschuwt dat een te snel groeiend SOC meer informatie verzamelt dan het kan verwerken.
Talent aantrekken en vasthouden
Het hoofdstuk over mensen begint met een nuchtere vaststelling: talent aantrekken is lastig door de aanhoudende schaarste. De Best Practice zet daarom in op twee sporen tegelijk. Werf ervaren seniors, en leid daarnaast zelf nieuw talent op via stages, traineeships en samenwerking met hogescholen en universiteiten.
Voor het behouden van mensen noemt het document onder meer ruimte voor training en certificering, autonomie, en een beloningsbeleid waarin je ook in de techniek kunt doorgroeien, dus niet alleen via een managementrol. De beloning moet vergelijkbaar zijn met die van andere SOC's in dezelfde sector of regio. Een verloop tot 10 procent per jaar noemt het document gezond, omdat het nieuwe kennis binnenbrengt. En het budget voor training hoort bovenop het centrale opleidingsbudget te komen.
Nog een detail dat werving makkelijker maakt: volgens het document mogen Rijksorganisaties geen diploma-eisen meer stellen, alleen werk- en denkniveau.
Waar past interim in een SOC?
Mijn advies: gebruik interim voor de bouwfase en houd de kern van het team in vaste dienst. Een SOC draait op kennis van je eigen omgeving, en die wil je niet elk jaar opnieuw opbouwen. Juist in de opstart heb je mensen nodig die het al eens gedaan hebben: een SOC lead die de structuur neerzet, een detection engineer die logbronnen aansluit en de eerste use cases bouwt. Zij kunnen je vaste mensen meenemen, zodat de kennis blijft als de interim weer vertrekt.
Voor het opleiden van eigen talent is een traineeship een logische route. Daarvoor hebben we MVPrentice, ons programma voor jong cybersecuritytalent.
Zoek je ervaren mensen voor de opbouw van je SOC? Bekijk onze expertise in SOC operations en threat intelligence, of plaats een interim professional via MVPeople. Bel of mail me via de contactpagina, dan kijken we welke rol je als eerste invult.
