SOC as a service is an arrangement where an outside provider runs security monitoring for you: it collects logs and alerts, triages them, and escalates or acts on real incidents. You still own decisions, access to your systems and the response work inside your company. The contract decides how much the provider can actually do.
What is a security operations center?
A security operations center (SOC) is a team and a set of processes for detecting, investigating and responding to security events. Its inputs are logs and alerts from endpoints, identity systems, networks and cloud services. Its output is decisions: this is noise, this is real, contain it.
NIST SP 800-92 treats log management as the base for all of it, covering how to build log infrastructure and run log processes across an enterprise. NIST SP 800-61 Revision 3 relates incident response to the Cybersecurity Framework 2.0, covering preparing for incidents, reducing how many occur and improving how efficiently you respond.
A service model sells some of those activities, usually the monitoring and first-line triage, to a provider.
What do you actually get?
Offers vary a great deal. Look for what is written in the scope:
- Monitoring hours. Around the clock, or business hours only.
- Data sources. Which logs and tools they ingest. A provider cannot watch what it cannot see.
- Detection content. Who writes and tunes detections, and how often.
- Triage. Whether alerts arrive pre-investigated, with context, or as raw notifications.
- Response. Advice only, or actions such as disabling an account or isolating a device, and under what approval.
- Reporting. Metrics, incident reports and evidence for audits.
A constructed example: a 150 person firm buys a service and assumes it covers everything. The provider monitors laptop agents and email. Nobody connected the cloud accounts or the identity provider. When a stolen cloud key is used, there is nothing to alert on. The provider did what the contract said. The scope had a hole.
What stays with you?
- Knowing your assets and who owns them.
- Granting the provider the access to see and act.
- Deciding how to respond to business-impacting incidents, such as taking a service offline.
- Fixing the root cause: patching, configuration, access changes.
- Legal and regulatory notifications.
The provider detects and advises. The organization decides and repairs.
What should you ask before buying?
- Which of our systems and log sources will you ingest on day one, and which later?
- What is the time target from alert to analyst review, and how is it measured?
- What can you do on our behalf without asking, and what needs approval?
- Who writes detections, and how do you tune them to our environment?
- What does an escalation look like, and who do you call at 3 a.m.?
- Where is our data stored, how long, and who at your company can access it?
- How do you separate our data from other customers?
- What reports and evidence do you provide for audits?
- What happens at the end of the contract: can we export our logs and detection rules?
- Can you name which activities you subcontract?
Run a pilot with a short list of real scenarios, such as a stolen password used from a new country, and see how the provider responds.
How do you measure whether it works?
Agree on a few numbers before signing. Useful ones: the share of your critical log sources actually connected, the median time from alert to analyst review, how many escalations turned out to be real, and how many incidents you found yourself that the provider missed. The last one is the most revealing. Review them monthly with the provider, and write the right to adjust scope or leave into the contract if the numbers do not improve.
How to check or apply this
- Inventory your log sources and mark the critical ones.
- Decide the response authority you are willing to give an outside party.
- Write requirements as scenarios, not feature lists.
- Ask the ten questions above and compare answers in writing.
- Run a 30 day pilot with a tabletop exercise.
- Review monthly: alert volume, time to respond and missed detections.
Quick check
Does SOC as a service replace an internal security team?
No. It covers monitoring and first-line response. Someone inside still has to own risk decisions, access and fixes.
Is it the same as managed detection and response?
The terms overlap and vendors use them differently. Compare the written scope: data sources, hours, actions and reporting.
Sources
- NIST SP 800-92, Guide to Computer Security Log Management
- NIST SP 800-61 Rev. 3, Incident Response Recommendations
Last reviewed: 18 October 2026.
