A security operations center, or SOC, is the people, process and tools that watch an organization's systems for attacks, investigate suspicious activity and coordinate the response. It can be a room of analysts, a small on-call rota, or an outside service. What matters is that someone is responsible for noticing and acting.
What does a SOC do all day?
Most of the work is quiet. Alerts arrive from tools that watch accounts, endpoints, cloud activity and networks. An analyst decides whether each alert is real, looks for related activity, and either closes it with a note or escalates it.
NIST SP 800-53 describes the underlying duty in control SI-4: monitor the system to detect attacks and unauthorized connections, analyze detected events and anomalies, and adjust monitoring when risk changes. A SOC is how an organization actually does that.
What are the main jobs inside it?
Monitoring and triage. The first look at an alert. Fast, structured, and often the highest-volume work.
Investigation. A deeper look when something might be real. Which accounts were involved, what else did they touch, when did it start?
Incident handling. NIST control IR-4 lists the phases as preparation, detection and analysis, containment, eradication and recovery. The SOC usually runs the middle three and feeds lessons learned back into the first.
Threat hunting. Control RA-10 asks organizations to search for indicators of compromise and to detect, track and disrupt threats that evade existing controls. Hunting is proactive and starts from a hypothesis, not an alert.
Detection engineering. Writing and tuning the rules that generate alerts. MITRE ATT&CK, a knowledge base of adversary behavior, is commonly used to organize that work.
What tools does it use?
Typical tools collect and search logs, watch endpoints, track identities and manage cases. Names vary by vendor, and the same acronym can mean different things between products. Rather than memorizing acronyms, ask what data the tool sees and what action it can take.
Who needs one?
Any organization with systems it cannot afford to lose has the function, even if nobody calls it a SOC. A ten-person company might have one engineer who gets pages from a cloud alert and a contract with an outside responder. That is a SOC in miniature, and it can be enough if the roles are clear.
Regulated sectors and larger companies tend to need written procedures and defined hours. Check your own regulator or customer contracts for specific requirements, because this post cannot list them.
What are the common ways to run one?
In house. You hire analysts and run the tools. You gain context and control. You pay for staffing across nights, weekends and holidays.
Managed. An outside provider watches your data and escalates. You gain coverage and experience. You depend on how well they understand your systems.
Hybrid. Your team handles business hours and decisions, a provider covers off hours. Many mid-size organizations end up here.
What makes a SOC work or fail?
Three things. First, visibility: if a system does not send logs, nobody can see attacks on it. Second, decisions: analysts need clear authority to act, such as disabling an account. Third, feedback: closed incidents should improve detections so the same noise or miss does not recur.
A frequent failure is alert fatigue. When most alerts are false, analysts stop trusting them. Tuning is not optional maintenance, it is the job.
How does it relate to application security?
A SOC sees runtime events. Application security teams find weaknesses in code and dependencies before release. The two meet when a vulnerability is being exploited. Good handoffs tell the SOC which assets are affected and tell the application team what attackers are actually trying.
What does a day look like for a small team?
In a ten to thirty person company, the SOC may be one engineer and an outside provider. The engineer checks a queue in the morning, reads overnight escalations from the provider, closes the routine ones and asks the business about the odd ones: did you really log in from there? Once a week they tune the noisiest rule. Once a quarter they run a short exercise to check that alerts still arrive. It is modest, and it is real, because the response chain is known and used.
What to do
- Name who is responsible for watching alerts, including nights and weekends.
- List your most important systems and confirm each sends logs somewhere searchable.
- Write down which response actions an on-call person may take without approval.
- Choose in house, managed or hybrid based on coverage hours you need.
- Review closed alerts monthly and tune the noisiest rules.
Quick check
Is a SOC the same as an incident response team?
They overlap. The SOC watches continuously and handles incidents as they begin. An incident response team may be called in for larger events.
Do we need a physical room?
No. Most SOCs work through shared tools and chat. What counts is coverage, process and authority.
Sources
- NIST SP 800-53 Rev. 5, controls SI-4, IR-4, RA-10 (OSCAL catalog)
- NIST SP 800-61 Rev. 3
- MITRE ATT&CK FAQ
Last reviewed: 18 October 2026.
