2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
What is SOC as a service? How an outsourced security operations center works, what you get, and how to choose one
SOC as a service (SOCaaS) is a subscription model in which a specialised provider runs a security operations center for you: analysts, detection platform, response process and 24/7 security monitoring, fed by your own log and endpoint data. This guide explains what a SOC does hour by hour, what changes when you buy it as a service, how it compares with building your own or running a hybrid, and the questions that separate a real SOC from an alert-forwarding desk.
SOC as a service, defined
A security operations center (SOC) is the function that watches an organisation's systems for signs of attack, decides which signals matter, and acts on the ones that do. SOC as a service delivers that function by subscription from an external provider instead of from an internal team. The provider supplies the people (tier 1 to tier 3 analysts, detection engineers, incident responders), the platform (SIEM, EDR or XDR, case management, threat intelligence), and the process (triage rules, escalation paths, response playbooks, reporting). You supply the telemetry: logs from identity providers, endpoints, cloud accounts, SaaS applications, network devices and business systems. The term is also written security operations center as a service or SOCaaS, and the core deliverable is 24/7 security monitoring with people behind it.
The reason the model exists is arithmetic. Continuous coverage needs at least eight to ten analysts to staff three shifts with leave and attrition, plus engineers to keep detections current, plus a platform licence that scales with log volume. Few US mid-market organisations can hire and retain that, and the ones that can often find the team spends its time on tuning rather than on investigation. A service provider spreads the fixed cost across many clients and sees attack patterns across all of them, which is what makes detection improve month over month.
SOCaaS sits next to two related terms. A managed security services provider (MSSP) is the company; SOC as a service is often one of its offerings, alongside firewall or vulnerability management. Managed detection and response (MDR) is narrower and more active: it typically operates endpoint or extended detection tooling and takes containment actions on your behalf, where a SOC service may stop at investigation and escalation unless response authority is contracted. Our MSSP versus MDR versus SOC comparison, linked below, sets the three side by side; this page stays on the SOC itself.
What a security operations center actually does
Six functions, whether the SOC is yours or a provider's. A service that cannot describe how it performs each one is monitoring, not operating.
Monitoring and tier 1 triage
Analysts watch alert queues around the clock, discard false positives, enrich the rest with asset and user context and decide within minutes whether an alert becomes an investigation. Volume is the enemy here; a mature SOC measures how many alerts a tier 1 analyst can close with confidence per hour.
Tier 2 investigation
Escalated alerts become cases. Analysts reconstruct the timeline across sources (identity, endpoint, email, cloud), determine scope and root cause, and decide whether it is an incident. This is where business context matters most: what is normal for your finance team at 02:00 is not normal for anyone else.
Detection engineering
Writing, testing and tuning the rules and analytics that create alerts in the first place, mapped to MITRE ATT&CK techniques and to the log sources you actually have. Without this function the SOC runs on vendor default rules, which attackers have already read.
Threat intelligence
Turning external indicators and reports on active campaigns into detections and hunts relevant to your sector and stack. In a good SOC, intelligence also flows the other way: what offensive testers find in environments like yours becomes a detection hypothesis.
Incident response and containment
When a case is confirmed, the SOC isolates endpoints, disables accounts, blocks indicators and coordinates with your IT team and leadership according to a pre-agreed playbook and authority matrix. How far the provider may act without your approval is a contract term, not an assumption.
Reporting and compliance evidence
Monthly and quarterly reports on alert volumes, cases, incidents, detection coverage and tuning changes, written so they map to the controls you report under (SOC 2, PCI DSS, HIPAA, NIS2, DORA). The report is also where you check that the service is doing what the contract says.
What you get with SOC as a service: people, platform, process and data
Every SOCaaS proposal is a bundle of these four components. Knowing which component each line item belongs to makes two very different quotes comparable.
People: who watches, who investigates, who decides
Named roles and coverage: analysts on shift 24/7 or follow-the-sun, detection engineers, incident responders, a service manager who knows your environment. Ask whether the analysts who triage your alerts are dedicated to a small set of clients or work a shared queue, and who is awake and reachable at 03:00 on a Sunday.
Platform: SIEM, endpoint telemetry and case management
The provider either runs its own multi-tenant platform or operates one in your tenancy. Platforms commonly used include Microsoft Sentinel, Splunk, Elastic, Google SecOps and QRadar; the choice matters less than who owns the licence, where the data lives and what happens to it when the contract ends. A separate guide on managed SIEM covers the platform layer in depth.
Process: playbooks, escalation and authority
Documented triage criteria, severity definitions, escalation matrix with your named contacts, response playbooks per scenario (ransomware, business email compromise, credential theft, insider misuse) and the authority matrix stating which actions the SOC may take unilaterally. Process is what you are actually buying; the platform is how it is delivered.
Data: your telemetry and what happens to it
Which log sources are in scope, in what order they are onboarded, how long they are retained, in which jurisdiction they are stored and how you get them back. US clients with HIPAA or state privacy obligations and EU clients under GDPR should settle data residency and processor terms before the first connector is deployed.
In-house SOC, SOC as a service or hybrid: the three operating models
Three operating models. The right one depends less on company size than on whether you already have people who can own detection and response, and on how much business context the function needs.
| Aspect | In-house SOC | SOC as a service | Hybrid (co-managed) |
|---|---|---|---|
| Who staffs it | Your analysts and engineers | Provider's analysts and engineers | Provider covers 24/7 monitoring; your team owns escalations and business context |
| Coverage hours | As many as you can staff, often business hours plus on-call | 24/7 by contract | 24/7 by the provider, daytime depth by your team |
| Time to operational | Twelve to twenty-four months to hire, build and tune | Weeks to onboard log sources and playbooks | Weeks, provided your platform and roles already exist |
| Platform ownership | Yours, including licence and tuning burden | Provider's, or operated in your tenancy | Usually yours, operated jointly |
| Detection content | Written by your team for your environment | Provider library plus client-specific tuning | Provider library plus your team's environment-specific rules |
| Business context | Highest | Depends on onboarding quality and dedicated analysts | High, if roles are clearly divided |
| Cost logic | Fixed headcount and licences regardless of alert volume | Subscription scaled by users, endpoints or data volume | Subscription plus a smaller internal team |
| Exit risk | None, but key-person dependency | Data portability and detection content ownership must be contracted | Lower, since the platform and knowledge stay partly in-house |
| Best for | Large enterprises with regulatory or sovereignty reasons to keep it inside | Mid-market and enterprise teams without 24/7 capacity | Organisations with a security team that wants to keep ownership but not shifts |
What to look for in a SOC as a service provider
Eight questions, in the order a CISO should ask them. The answers reveal whether 24/7 security monitoring means people investigating or software forwarding.
1. Coverage model
Is monitoring performed by analysts 24/7, follow-the-sun across regions, or by automation with on-call humans? Ask what happens to a high-severity alert at 03:00: who sees it, within how long, and what they may do. Terms such as 24/7 should be defined in the contract in terms of human response, not platform uptime.
2. Log sources and telemetry supported
Identity (Entra ID, Okta, Active Directory), endpoints, cloud control planes (AWS CloudTrail, Azure Activity, Google Cloud audit logs), SaaS applications, email, network and, where relevant, OT. Ask for the supported connector list and how unsupported sources are handled. A SOC that cannot see your identity provider is blind to most modern intrusions.
3. Detection engineering and tuning cadence
How many detections are in the library, how they map to MITRE ATT&CK, how often new ones are added, and how client-specific tuning is tracked and reported. Ask who validates that detections fire: a provider that tests its own rules with purple-team exercises is operating, not just subscribing to a feed.
4. Metrics: MTTD and MTTR as concepts, not marketing
Mean time to detect and mean time to respond only mean something when the start and end points are defined. Ask how each is measured, from which timestamp, and whether figures quoted are averages across all clients or will be reported for yours. The useful questions are about the distribution and the outliers, not the average.
5. Escalation and response authority
Does the provider notify, recommend, or act? Which actions (isolating a host, disabling an account, blocking a domain) are pre-authorised, which need approval, and how is approval obtained outside office hours? The authority matrix should be a schedule to the contract.
6. Threat intelligence and offensive feedback
Where does the provider's intelligence come from, and does it include first-hand knowledge of how attackers actually move through environments like yours? Providers with an offensive security practice can turn penetration test and red team findings into detection hypotheses; ask for an example.
7. Data residency, retention and processor terms
Where logs are stored and processed, for how long, under what encryption, and under which legal terms (business associate agreement for HIPAA, data processing agreement for GDPR). US organisations with EU subsidiaries, and EU organisations with US customers, should confirm both regimes are covered.
8. Onboarding, reporting and exit
A written onboarding plan with milestones, a report format you can file as compliance evidence, and exit terms that return your logs, detection content and documentation in a usable format. Our MSSP contract checklist, linked below, covers the clauses in detail.
Onboarding a SOC service: the steps in order
Onboarding decides whether the service works. A provider who skips the baseline and tuning period will deliver volume, not detection.
- Kick-off: asset inventory, crown-jewel systems, named contacts on both sides, authority matrix and escalation paths agreed in writing
- Log source prioritisation: identity and endpoint first, then cloud control planes and email, then network and business applications
- Connector deployment and data validation: confirm each source arrives complete, parsed and time-synchronised
- Baseline and tuning period, typically several weeks, in which normal behaviour is learned and noisy detections are adjusted with your sign-off
- Playbooks per scenario, tested in a tabletop walk-through with your IT, legal and communications leads
- Detection validation: a controlled set of attacker techniques executed against the environment to confirm alerts fire and reach the right people
- Go-live with a hypercare window, then the first monthly service review against the agreed metrics and report format
Compliance hooks: what frameworks expect from 24/7 security monitoring
US frameworks rarely say 'SOC', but most require the function. SOC 2 common criteria CC7.2 requires monitoring system components for anomalies indicative of malicious acts, CC7.3 requires evaluating security events to determine whether they are incidents, and CC7.4 requires a response programme. PCI DSS v4.0.1 Requirement 10 requires audit logs to be reviewed at least daily (10.4.1), using automated mechanisms (10.4.1.1), and 10.7 requires that failures of critical security control systems are detected and addressed promptly; Requirement 11.5 covers intrusion detection and 12.10.5 requires the incident response plan to include alerts from security monitoring systems. HIPAA's Security Rule requires information system activity review at 45 CFR 164.308(a)(1)(ii)(D), security incident procedures at 164.308(a)(6) and audit controls at 164.312(b). NIST CSF 2.0 places all of this under the Detect function (DE.CM continuous monitoring, DE.AE adverse event analysis), and NIST SP 800-61 Rev. 3 (2025) aligns incident response to the same profile.
Regulators add clocks. The SEC's 2023 rules require public companies to disclose a material cybersecurity incident on Form 8-K within four business days of determining materiality, which is impossible without a function that detects and scopes incidents in time. NYDFS 23 NYCRR 500 requires monitoring of user activity (500.14), 72-hour notification of certain cybersecurity events (500.17), and, for larger Class A companies, endpoint detection and response plus centralised logging and alerting. The GLBA Safeguards Rule (16 CFR 314.4(c)(8)) requires monitoring and logging of authorised user activity, and CMMC 2.0 Level 2 inherits the audit and accountability and incident response families of NIST SP 800-171 Rev. 3. In the EU, NIS2 Article 21(2)(b) requires incident handling and Article 23 sets 24-hour early warning and 72-hour notification deadlines; DORA Article 10 requires mechanisms to promptly detect anomalous activity and Article 17 an ICT-related incident management process; ISO 27001:2022 controls A.8.15 and A.8.16 cover logging and monitoring. A SOC service report should let you trace each of these to evidence.
Where SOC as a service goes wrong
The failure patterns are consistent. Onboarding stalls because nobody on the client side owns log source access, so the SOC goes live watching a third of the environment. Business context never reaches the analysts, so legitimate finance activity is escalated and an unusual service account is not. The authority matrix is left vague, so at 03:00 the provider notifies and waits while the attacker does not. Log volume pricing discourages onboarding the verbose sources that matter most, such as identity and cloud audit logs. And exit is never planned, so after three years the detection content and the historical data belong, in practice, to the provider. Each of these is a contract and onboarding decision, which is why the questions above are asked before signature rather than after the first incident.
How HackersHub runs SOC as a service
Our managed security practice provides 24/7 monitoring, SIEM and EDR management, detection engineering and incident response support for enterprise clients in the EU and the US, delivered remotely from Amsterdam with on-site work where an engagement needs it. What shapes the service is our offensive background: the same team that performs penetration tests and red team engagements informs which techniques we build detections for, and we validate those detections against real attacker behaviour rather than vendor defaults. Reporting is written to map to the frameworks you answer to, from SOC 2 and PCI DSS to NIS2 and DORA, so the monthly report doubles as compliance evidence. Scope, coverage model, authority matrix and log sources are agreed per organisation; there is no catalogue tier, because the variables above move the service more than any tier could capture.
Frequently asked questions
Related guides and services
- Managed security services by HackersHub
- MSSP vs MDR vs SOC as a service: the differences that matter
- SOC as a service cost drivers: what moves the price
- Managed SIEM: the platform layer behind the SOC
- MDR vs EDR vs XDR: tools versus service
- What is an MSSP? Meaning and how to choose one
- MSSP contract checklist: the clauses to get right
- Managed detection and response by HackersHub
Considering SOC as a service?
We scope coverage, log sources, authority and reporting per organisation, with detections informed by the attacks our offensive team runs every week. Talk to our managed security team about your environment.