What it means
A SOC is an operating capability, not necessarily a room full of screens. It combines people, processes, and technology to notice suspicious activity, investigate it, and coordinate a response. Some organizations staff their own team; others share responsibilities with a provider or an on-call technology group. Define what the function protects, when it is staffed, who owns decisions, and how it reaches other teams. In this context SOC means security operations center, not the separate System and Organization Controls reporting terminology.
The idea at a glance / Detection
A SOC needs people, scope and authority.
Keep the analyst, incident lead and operations owner visible beside a still-open handoff.
Fictional Chronos Hub’s written operating model covers identity and staffing-app records from 08:00 to 18:00 UTC. Nyx reviews alerts; Vera Vance decides incident handling and approves disruptive actions; Kael Cho operates the application within that approval. At 08:10 Nyx has saved H110 for Vera about AL110. Receipt and action are not confirmed. This is a selected operating-model snapshot, not a tested staffing promise.
READ THE PICTURE
Operating model
Nyx has saved a case for Vera. Vera’s acknowledgement and any instruction to Kael remain open; the tool does not supply their authority.
Keep in mindDefined roles and a saved handoff do not prove that someone is available, has read the case or can complete the work. Coverage outside the written window, endpoints, staffing resilience and response exercises remain unverified. A SIEM is one tool in this capability. Here SOC means security operations center, not System and Organization Controls reporting.
Read the complete example
- Operating model. Nyx has saved a case for Vera. Vera’s acknowledgement and any instruction to Kael remain open; the tool does not supply their authority. The selected Chronos Hub scope is identity plus staffing-app records during 08:00–18:00 UTC. Nyx can inspect evidence and save H110, but cannot approve disruptive containment. Vera Vance is the assigned incident lead and approval owner. Kael Cho can operate the application only within a valid approved instruction. H110 is addressed to Vera, but saving it has not produced an acknowledgement. These are fictional assigned responsibilities, not a claim of live coverage or a completed exercise. Incident communication, legal obligations and backup staffing need their own arrangements.
Defined roles and a saved handoff do not prove that someone is available, has read the case or can complete the work. Coverage outside the written window, endpoints, staffing resilience and response exercises remain unverified. A SIEM is one tool in this capability. Here SOC means security operations center, not System and Organization Controls reporting.
Diagram references: NCSC: a proportionate SOC operating model · NCSC: SOC roles, context and recorded handoffs
AN ILLUSTRATIVE SCENARIO
Defined roles, an unacknowledged handoff
Meridian’s written model assigns Nyx to review identity/staffing-app alerts, Sloane to decide incident handling and approve disruptive work, and Vera to operate the app within that approval. Nyx saves H110 at 08:10. Sloane’s receipt and any instruction to Vera remain open. The 08:00–18:00 UTC scope and named roles describe this fictional arrangement; they do not prove actual staffing or completed response capability.
Put it to work
- Write a service scope that names important systems, hours of coverage, expected outputs, and exclusions. Match the scope to staffing and available telemetry.
- Agree responsibilities with IT, business owners, and external partners. Define incident declaration, containment authority, escalation routes, and a usable case handoff.
- Practice realistic incidents and review results. Measure whether cases reach useful decisions, not only how many alerts analysts close or how quickly they click acknowledge.
How to check your work
Run a tabletop during the intended coverage window. Someone should receive the case, understand the evidence, reach the required decision-maker, and record what happened. Update the operating model when the exercise exposes a gap.
Connect the ideas
- SIEM
A capability that collects, parses, stores, and searches security telemetry and often fires alerts.
- MDR
A service that combines tooling with people who triage and investigate on a customer’s behalf.
- Incident
An event or set of events that actually or potentially causes a security loss requiring coordinated handling.
- Triage
A short, time-boxed judgment of severity, uncertainty, and next action when an alert arrives.