Building a SOC team starts with a small group of all-rounders, and only later moves to specialist roles and tiers. That is the approach set out in the Joint SOC Best Practice, the handbook written jointly by the security operations centres of the Dutch central government.
I read the latest version as someone who helps staff SOC teams. The chapter on people is the most useful part, and it applies well beyond government.
What is the Joint SOC Best Practice?
The Joint SOC (J-SOC) is a partnership of SOCs within Dutch central government. Version 3.1 of its Best Practice is dated 23 December 2025 and marked TLP:CLEAR, so it can be shared freely. Contributors include the SOCs of the Dutch Tax and Customs Administration, DICTU, Rijkswaterstaat, SSC-ICT, the Ministry of Justice and Security, DUO and the Ministry of Defence.
It follows the SOC Capability Maturity Model (SOC-CMM) and its five domains: business, people, process, technology and services. The document says it is also meant as inspiration for organisations outside the partnership, and as a reference for managing an outsourced SOC.
Foundations before the SOC
The most striking line comes early: building a SOC can never be the first step in a security strategy. A SOC needs foundations. You need to know which assets sit on your network and who owns them, you need an information security policy and an ISMS, and log management, incident management and asset management processes have to be running already.
That fits with the findings of the Dutch cyber security assessment for 2026, which shows many organisations still lack the basics. Put a SOC on top of that and what you mostly get is alerts that nobody can interpret.
Which roles does a SOC need?
The Best Practice bases its roles on the NIST NICE framework, which includes security analyst, incident responder, forensic analyst, threat intelligence analyst, vulnerability analyst and security architect. It adds roles you meet in practice: SOC manager, SOC lead, coordinator, shift lead, detection engineer, automation engineer and threat hunter.
One useful distinction is that a role and a job title are different things. A senior analyst can hold the analyst and vulnerability analyst roles, or be analyst and team lead at once. In a small team that is exactly the point. The document recommends starting with broad roles such as "analyst" and "engineer" and splitting them only as the SOC grows, while making sure there is at least one senior per area of focus.
Tiers: when they help and when they don't
Many SOCs work in tiers. In the Best Practice model, tier 0 handles as much as possible automatically, a junior analyst in tier 1 triages alerts using playbooks, a mid-level analyst in tier 2 takes on analysis and response, and a senior in tier 3 handles genuine incidents. Detection engineering and automation engineering sit underneath all of it, and "shift left" keeps moving work down to the lower tiers.
The document is candid about the downsides. Tiering gives a clear division of tasks and makes day-to-day staffing easier. It also narrows people's work, makes progression harder and makes you a less attractive employer. On top of that, the stated aim is for tier 1 to be largely automated over time.
I would give that last point a lot of weight. Staff a new SOC with a row of junior tier 1 analysts today and you are building a layer you will want to automate within a few years.
How big should a SOC team be?
The document gives no fixed headcount, but it does offer a guide to structure. According to the Best Practice, one manager's span of control is between 5 and 15 people, depending on how autonomous the team is and how mature the SOC has become. For a new SOC, the advice is to start with a small number of staff. The Dutch National Cyber Security Centre makes the same case in its factsheet on starting a SOC small, warning that a SOC that grows too fast collects more data than it can process.
Attracting and keeping talent
The people chapter opens with a plain statement: attracting talent is hard because of the ongoing shortage. The Best Practice therefore works on two fronts at once. Recruit experienced seniors, and develop new talent yourself through internships, traineeships and partnerships with universities.
To keep people, the document points to room for training and certification, autonomy, and a pay structure that lets people progress on the technical track rather than only into management. Pay should be in line with other SOCs in the same sector or region. It describes staff turnover of up to 10 per cent a year as healthy, because it brings in fresh knowledge. And the training budget should come on top of the organisation's central training budget.
One detail that makes hiring easier: according to the document, Dutch central government bodies may no longer set formal degree requirements, only a required level of work and thinking.
Where interim fits in a SOC
My advice is to use interim specialists for the build phase and keep the core of the team on permanent contracts. A SOC runs on knowledge of your own environment, and you don't want to rebuild that every year. The start-up phase is exactly where you need people who have done it before: a SOC lead to set up the structure, a detection engineer to connect log sources and build the first use cases. They can bring your permanent staff along with them, so the knowledge stays when the contractor leaves.
For growing your own talent, a traineeship is the obvious route. That is what MVPrentice, our programme for young cyber security talent, is for.
Looking for experienced people to build your SOC? Have a look at our expertise in SOC operations and threat intelligence, or bring in an interim professional through MVPeople. Call or email me via our contact page and we can work out which role to fill first.
