---
{
  "title": "Security operations centers",
  "summary": "A team and operating model for finding and responding to security problems.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## A security operating function

A security operations center, or SOC, is a team and operating model for monitoring security-relevant activity, investigating signals, and coordinating appropriate response. It may be internal, outsourced, distributed, or organized around several specialist teams. The name matters less than clear responsibilities, dependable evidence, and the ability to act on findings.

A SOC is not simply a room of dashboards or a purchased monitoring platform. Tools help collect and analyze information, but people and processes decide which events matter, who owns an investigation, and which actions are authorized.

## Follow one case through the function

At a fictional academy, an analyst receives an alert about a staff account creating an external forwarding rule. The analyst checks the supporting records, contacts the relevant owner through a trusted channel, and assesses whether the change matches an approved workflow.

If the explanation remains suspicious, the case moves to someone with deeper identity expertise and the authority to coordinate account restrictions. A service owner considers operational effects, while a response lead manages the wider investigation if other accounts are affected.

This sequence shows why [[soc-roles]] and escalation paths matter. A queue can appear busy while important cases stall because nobody owns the next decision. The SOC needs explicit handover expectations and a way to track unresolved actions.

## Build around the services being protected

Start with important business services, likely failure or abuse scenarios, available telemetry, and the team's response capabilities. A detection that requires data the organization does not collect or expertise it cannot access creates a false sense of coverage.

[[siem]] can centralize records and support queries. [[endpoint-detection-response]] provides device-level visibility and response capabilities. [[soar]] can connect repeatable workflow steps. These tools should serve the operating process rather than define it by default.

The SOC also needs working relationships with IT, cloud, identity, application, privacy, and business teams. Security findings often require changes that analysts cannot safely make alone. Preparation includes access arrangements, contact information, evidence retention, and tested response options.

## Measure useful outcomes

Alert counts and closed tickets describe activity, but they do not establish effective security. Review whether important incidents are detected, investigations are well supported, actions reduce harm, and lessons improve the underlying controls. [[soc-metrics]] helps avoid incentives that reward quick closure over sound decisions.

For practice, design a small operating model for the forwarding-rule case. Identify who receives the signal, who investigates, who can restrict the account, who assesses information exposure, and who communicates with staff. Then introduce an unavailable specialist and explain the fallback route. The exercise tests whether the function can keep working under realistic constraints.

## Related concepts

- [[logs-and-telemetry]]
- [[alert-triage]]
- [[incident-response]]