Ten years ago, telling someone your organisation had a Security Operations Centre meant something specific. It implied a dedicated team of analysts watching screens around the clock, looking for threats across the whole IT environment, with the people, processes and technology to detect, contain and respond to incidents at any hour.
Today, the term has been stretched until it almost snaps. One provider markets a “SOC” that runs 24/7 with multiple roles, threat hunting and incident response. Another markets a “SOC” that watches endpoint alerts during office hours and forwards anything suspicious by email. Both call themselves the same thing.
For anyone responsible for cyber resilience, whether they are a CISO at a mid-market organisation, an IT manager preparing for NIS2, or a board member weighing up risk, this matters. Choosing the wrong type of SOC means paying for capability you do not get, or worse, assuming you are protected when you are not.
This guide answers the questions buyers actually ask, in the order they tend to ask them. It explains what a Security Operations Centre really is, how it relates to the increasingly common term Managed Detection and Response, why the definition has eroded, the main types of SOC you will encounter in the market today and how to select the one that fits your risk, sector and budget.
A short note on positioning before we begin: Guardian360 does not operate a SOC. We provide continuous attack-surface insight and vulnerability management that strengthens whatever SOC an organisation chooses to work with. Throughout this article we use five of our partners, namely NFIR, SLTN, Intermax, Beterbeschermd and Trustteam, as honest examples of how different SOC models look in practice. The aim is not to recommend one over another, but to help you recognise which model best fits your situation.
What is a Security Operations Centre, really?
A Security Operations Centre is, at its core, the function within or outside an organisation that is responsible for the continuous monitoring, detection, analysis and response to cyber threats. It is a combination of three things: people, processes and technology. Take any one away and you do not have a SOC.
The technology side typically includes a Security Information and Event Management (SIEM) platform that aggregates logs from across the IT environment, Endpoint Detection and Response (EDR) or Extended Detection and Response (XDR) tooling, network detection capability and a case management system. Increasingly, modern SOCs add Security Orchestration, Automation and Response (SOAR) tooling, threat intelligence feeds and User and Entity Behaviour Analytics (UEBA).
The process side covers detection use cases, playbooks, escalation paths, incident response procedures, reporting cadences and continuous improvement. A SOC without documented playbooks is, in practical terms, a group of people with dashboards.
The people side is where many “SOCs” quietly fall short. A genuine SOC has analysts at multiple tiers, typically L1 triage, L2 investigation, L3 threat hunting and incident response. It also has engineers who tune detections, a SOC manager and ideally a CISO-level link into the customer organisation. It runs continuously, because attackers do not work nine to five.
If a provider is offering you what they call a SOC, the simplest test is to ask: who is watching at three o’clock on a Sunday morning, what are they actually doing, and what authority do they have to act?
What is the difference between a SOC and Managed Detection and Response?
The terms “SOC” and “MDR” are used so interchangeably in the market that it is worth unpicking them.
A SOC is the operational function: the people, processes and technology that monitor, detect, analyse and respond. The phrase describes a capability, not a particular commercial offering. An organisation can run its own SOC, hire a provider’s SOC or run a hybrid model.
Managed Detection and Response is the commercial wrapper most commonly used to package SOC capability for the mid-market. In an MDR service the provider takes responsibility for the monitoring tooling, often EDR or XDR, applies its own analysts and playbooks against your environment and reports findings and actions back to the customer. In practice, almost every outsourced SOC service offered to mid-market organisations today is sold under the MDR label or a close variant.
What this means for buyers is straightforward. The label “MDR” tells you something about the commercial model, but not about the depth of analysts, the hours of coverage, the scope of detection or the response authority included. A 24/7 specialist MDR with full incident response can be very different from a 5×8 endpoint-only MDR; both are sold under the same three letters. The questions later in this article are designed to surface the difference.
Why has the term “SOC” become diluted?
Three forces have pulled the definition apart.
The first is marketing inflation. As cyber threats moved up the agenda, “SOC” became a label that helped sell services. Endpoint monitoring with a 5×8 follow-up service got rebranded as a SOC. Vulnerability management dashboards got rebranded as SOC components. Where a label sells, the label spreads.
The second is the diversity of providers entering the space. The companies offering SOC-like services today come from very different starting points. Some are pure-play cybersecurity firms that built their SOC around incident response. Others are managed hosting providers that added a Cyber Defence Centre to protect their own platform and then offered it to customers. Others are broad IT integrators where security is one expertise area among many. Others are regional managed service providers who recognised their SME clients needed something more than antivirus and a firewall. Each of these models has merit, but they are not the same product.
The third is the absence of a single, enforceable standard. There are good frameworks, including MITRE ATT&CK, the SANS SOC functions model and NIST CSF, but no certification that a buyer can demand and trust as a like-for-like comparator. ISO 27001 and SOC 2 say something about how an organisation handles information security, but they do not certify a SOC’s operational depth.
The result is a market where the same word covers very different services at very different prices. The buyer has to do the unpicking.
What are the main types of SOC in the Dutch market today?
Looking across the providers we work with, four broad models cover most of what you will encounter. Each has clear strengths, clear trade-offs and a clear ideal customer.
Type 1: The pure-play cybersecurity specialist SOC
This is the model closest to the original definition. The provider’s entire business is cybersecurity. The SOC is the heart of the operation, surrounded by adjacent capabilities like penetration testing, incident response, digital forensics and security awareness training. Analysts are deep specialists, and the firm typically holds accreditations specific to security work rather than to IT services in general.
NFIR is a clear example of this archetype. They run a 24/7/365 Managed Detection and Response service from their own SOC, alongside a Computer Emergency Response Team that handles incident response, a CCV-certified penetration testing practice and a digital forensics arm. Their staff have formal vetting through the Chief of Police and the firm holds ISO and BSI accreditations focused on the security domain. The proposition is straightforward: when something serious happens, the same firm that monitors your environment can also investigate, contain and report on the incident, including the forensic detail that may be needed for insurers, regulators or law enforcement.
The strength of this model is depth. The trade-off is that it expects a customer with a relatively mature IT environment. The SOC will detect and respond, but it does not run your wider IT.
Best fit: organisations that already have a competent IT function, want a specialist security partner and value strong incident response and forensic capability. This is typically a fit for larger mid-market and enterprise organisations, government, education and any sector with elevated incident risk.
Type 2: The SOC embedded in a broad IT integrator
In this model, security and the SOC sit alongside other IT services (workplace, cloud, networking, applications, data, hosting) in a single portfolio. The strength of the model is integration: the partner that monitors your security also understands your wider IT landscape, because they probably built parts of it. Many of these integrators also operate hosting and private cloud capabilities themselves, which means they can host, integrate and monitor under one roof.
SLTN is a good example. They describe themselves as a partner for “Future-proof IT” and offer expertise across business and IT professional services, digital workplace, datacentre, cloud, hosting, networking, AI services, data services, application services and cybersecurity. Crucially, SLTN runs its own datacentre and private cloud capability, so a customer can place security, workplace and hosted infrastructure with the same partner. Their cybersecurity proposition is consultative: survival guides, advice tailored to the organisation, working through the full picture of how to protect systems while enabling staff to do their jobs.
What also stands out about SLTN is the breadth of sectors they serve. Where some partners in this article are tightly focused on one or two domains (Intermax in healthcare, for instance), SLTN’s customer base spans healthcare, retail, local and central government, finance, industry, logistics and professional services. For mid-market organisations whose IT and security needs sit in a less obvious sector, or for groups operating across multiple sectors, that breadth means SLTN is rarely unfamiliar with the regulatory context, the sector-specific applications or the operational rhythm of the customer’s business.
This sector breadth is a different kind of strength from sector depth. A specialist with a single vertical focus offers deep understanding of one set of compliance frameworks and operational nuances. A multi-sector integrator like SLTN, by contrast, brings the ability to recognise patterns across sectors and apply lessons from one to another, which is particularly useful for organisations whose IT environment spans more than one operating context. Both kinds of strength have value, and the right answer depends on whether you need depth in one sector or familiarity across several.
Trustteam is a second example with a different shape. Headquartered in the Benelux and with offices in the Netherlands, Belgium, France and Luxembourg, Trustteam organises its security practice (“Next Gen Security”) explicitly around the NIST Cybersecurity Framework: Identify and Protect, Detect and Respond, Recover. Within the Detect and Respond pillar they offer Managed Detection and Response, Network Detection and Response and Endpoint Detection and Response as named, packaged products, alongside continuous monitoring, analysis and mitigation, response planning, awareness, and infrastructure security. The integrator sits over private cloud, public cloud (Azure) and on-site infrastructure, with a structured framework approach that suits buyers who want to map their controls to a recognised model. For organisations with a Benelux footprint, the cross-border nature of the firm is a meaningful practical advantage.
The strength of this model is coherence. You are not bolting security onto an unfamiliar IT environment; the same partner can align identity, workplace, cloud, hosting and security as one programme. The trade-off is that the SOC may not run as deep as a specialist’s, and the breadth means the organisation as a whole splits its attention across many practice areas.
Best fit: organisations that want one partner to take responsibility for IT and security together, particularly when the IT environment itself is being modernised. Common in mid-market organisations going through a workplace, cloud or networking transformation, and Benelux organisations who value cross-border presence.
Type 3: The SOC integrated with a managed hosting or cloud platform
Here, the SOC is part of a managed hosting or cloud-sourcing service, and that hosting capability is the centre of gravity of the firm. The provider’s primary business is running customer infrastructure, often within their own data centres or as a managed cloud, with security monitoring woven directly into the platform they operate. The difference from Type 2 is one of focus and depth: hosting is the firm’s identity rather than one of many practices, and the security capability is built around the hosted environment.
Intermax is a strong example. They are a Rotterdam-based cloud-sourcing company with a large portfolio of certifications including ISO 27001, ISO 20000, ISO 9001, NEN 7510, ISAE 3402 type II and SOC 2. They are a Microsoft Cloud Service Provider, VMware Service Provider and Fortinet Managed Security Service Provider, and they run a Cyber Defence Centre that uses modern detection tooling, including Elastic Security with AI-driven attack discovery. Their depth in healthcare deserves a paragraph of its own.
For organisations in healthcare, Intermax is in many respects an exceptional fit. The combination of NEN 7510 (the Dutch information security standard for healthcare), ISO 27001 and SOC 2, with an existing customer base that includes hospitals, mental health institutions and other zorginstellingen, means Intermax already understands the regulatory burden and the day-to-day reality of hosting EPDs and other clinical applications. Their managed HiX offering is one example of this depth. For a Dutch healthcare organisation, choosing between a hosting partner that has occasionally worked with clinical systems and one whose business is built around them is rarely a difficult choice. Intermax is firmly in the second group, which is why it is a particularly strong SOC partner for any organisation in the Dutch zorg.
The strength of this model is that security is “baked in”. The hosting platform and the SOC share the same engineering team, the same telemetry and the same compliance evidence. The trade-off is that you are buying into a hosting model as well as a SOC; if you want to run your IT independently and only contract for monitoring, this is not the right shape.
Best fit: regulated sectors such as healthcare, finance and government, and organisations that want to outsource their hosting and security to one highly certified provider. Particularly strong for Dutch healthcare given the depth of NEN 7510 evidence and clinical application experience.
Type 4: The MSP-grade SOC, including SOC services for other MSPs
The fourth model has grown rapidly in the last few years. Regional managed service providers, who already deliver day-to-day IT for SME and mid-market customers, have built or partnered into SOC services that are accessible to organisations that could never justify an enterprise contract. A meaningful sub-trend is now visible: a number of these firms are deliberately positioning their SOC capability as a service that other MSPs can use, rather than only their own clients.
Beterbeschermd is a clear example. The firm originated within Noord-Holland-based MSP BEEREPOOT, where it serves the existing MSP client base, but it is deliberately positioned as a separate brand and operation that can offer its SOC capability to other MSPs and their end customers. The team combines SOC operators with a Cybersecurity Officer role that handles risk analysis, audits, awareness training, NIS2 and ISO 27001 guidance and compliance support. For an MSP that does not have the scale to build its own SOC, partnering with a peer MSP that has already built one is often more workable, both commercially and culturally, than partnering with a large enterprise specialist.
The strength of this model is accessibility and cultural fit. Smaller organisations get monitoring, awareness training and compliance guidance in a single relationship at a price that scales to their size, and MSPs without a SOC of their own can offer one to their customers without the multi-million-euro investment. The trade-off is that the depth of forensic and threat-hunting capability may not match a pure specialist’s, and the geographic footprint of the partner matters in a way it does not for a national specialist.
Best fit: SMEs and lower mid-market organisations whose IT runs through an MSP relationship, and MSPs themselves who want to offer SOC capability to their clients without building it from scratch.
So which type of SOC do you need?
The honest answer is that it depends on five factors, in roughly this order.
Risk profile. What is the realistic worst case? An organisation handling patient data, payment data or critical infrastructure has a different worst case from a B2B services firm. The higher your worst case, the more depth of detection and response capability you need.
Regulatory pressure. NIS2, the AVG/GDPR, sector-specific rules such as NEN 7510 or DigiD, and contractual obligations from customers all push the bar upwards. Some of the SOC types above carry compliance evidence that is difficult to build any other way.
Internal IT maturity. A specialist SOC assumes you can act on its findings. If your internal IT function is small or stretched, an integrated model (either with an IT integrator or an MSP) will be more workable than a specialist relationship that hands you a stream of alerts you cannot resource.
Existing IT relationships. If you already trust an MSP or integrator with your IT, putting your SOC in the same relationship reduces friction. If you have a strong internal IT function and want a specialist counterpart, a pure-play SOC will give you the most depth.
Budget. A 24/7 specialist SOC is not the same price as a 5×8 monitoring add-on. Be clear about what you are willing to spend, and be honest with providers when you ask for proposals.
What questions should you ask a SOC provider?
A short, useful checklist when you are evaluating providers, whether they sit in any of the four models above or somewhere else entirely.
Hours. Is monitoring 24/7/365, 5×8 with on-call, or something else? Who is awake at three on Sunday morning, and what are they authorised to do without your involvement?
Scope. What exactly is being monitored? Endpoints only? Endpoints, identity and email? Cloud workloads? Operational technology? On-premise servers and network? The further the scope, the more meaningful the SOC.
Detection. What tooling sits behind the service? SIEM and EDR are baseline; ask about XDR, NDR, identity threat detection, cloud posture monitoring and threat intelligence feeds. Ask how detection rules are tuned and how often they are reviewed.
People. How many analysts, at which tiers, and where are they based? Is the night shift in-house or outsourced? What is the rotation, and how is fatigue managed? Who is your named senior contact?
Response. When an incident happens, what does the SOC actually do? Alert you and stop? Contain a host? Reach into your environment and act? What authority does the SOC have, and how is that authorisation tested?
Incident response retainer. Is there a guaranteed response window for serious incidents? Is forensic capability part of the deal, or contracted separately? Can the SOC produce reports that are usable for insurers, regulators and, if it comes to it, law enforcement?
Compliance. What standards does the SOC itself comply with? Can the provider produce evidence that helps your own audits, including for ISO 27001, NEN 7510, NIS2 readiness, SOC 2 or ISAE 3402?
Reporting and transparency. What do you receive each week, each month, each quarter? Can you see the underlying detections and actions, or only summaries? Is there a portal? Are tabletop exercises and threat-hunting findings included?
Fit and exit. How does the SOC integrate with your existing tools, such as your ticketing system, identity provider and cloud accounts? If you ever want to move, how portable is your detection content and history?
What are the most common pitfalls when selecting a SOC?
A handful of mistakes repeat across the market.
The first is buying on price alone. A “SOC” that costs a quarter of the going rate is almost certainly doing a quarter of the work. The work it is not doing tends to be the part you most need when something goes wrong.
The second is mistaking tooling for a service. A SIEM is not a SOC. EDR is not a SOC. A dashboard with alerts is not a SOC. Without the analysts and the playbooks, the tooling produces noise.
The third is not testing the response. Many organisations sign a SOC contract and never run a tabletop exercise to see what actually happens when an incident is raised. The first time you stress-test the relationship should not be the day a real incident happens.
The fourth is overlapping responsibilities and unclear escalation. If the SOC, the MSP, the in-house IT team and the cloud provider all believe someone else is monitoring a particular system, no one is. Map ownership before you sign.
The fifth is signing a long contract without an exit plan. Ask, on day one, what happens to your detection content, your historical alerts and your case data if you ever want to leave.
A short framework for selecting your SOC
Pulling the above together, a practical sequence for choosing a SOC looks like this.
Start by defining what you are protecting and from whom. Map your most critical assets, your worst-case scenarios and the regulatory regimes that apply. Be specific.
Decide what you want to keep in-house and what you want to outsource. The two extremes (full in-house SOC versus fully outsourced) are rarely the right answer for mid-market organisations. A hybrid, where the SOC handles continuous detection and your team retains policy, risk and the strategic relationship, is usually most workable.
Set a realistic budget. Industry benchmarks for outsourced SOC services in the Dutch market sit in a wide range depending on scope and hours. Do not expect enterprise-grade 24/7 monitoring at SME prices, and do not pay enterprise prices for SME-grade coverage.
Shortlist by SOC type, not by name. Decide whether you need a specialist, an integrator, a hosting-led platform or an MSP-led service, and then look for the strongest provider in that category.
Ask the questions above, in writing, and compare the answers. If two providers offer the “same” service at very different prices, the answers to those questions will usually explain why.
Finally, take references. Ask current customers what happened during their last real incident, not their last successful detection. The gap between the two answers is informative.
Where Guardian360 fits in
We do not run a SOC. We have deliberately stayed out of that market because we believe a healthy SOC ecosystem benefits the customer more than a single dominant provider would. What we do is sit one step earlier in the chain.
A SOC is most effective when the environment it monitors is well understood and the basic exposures have already been closed. Guardian360 provides continuous insight into your attack surface and vulnerabilities, so that the SOC, whichever model you choose, spends its time on real threats rather than chasing noise from misconfigurations and unpatched systems.
If you are weighing up a SOC decision and would like an objective conversation about which of the four models above fits your organisation, we are happy to have it. We can also introduce you to the relevant partner (NFIR, SLTN, Intermax, Beterbeschermd, Trustteam or others in our network), depending on what you actually need.
The right SOC is the one that matches your risk, your IT maturity, your sector and your budget. It is not necessarily the largest, the cheapest or the one that answered your enquiry first. With the framework above, the choice should at least be a fully informed one.
