What Is a Security Operations Center (SOC)? Roles and Models

A security operations center is the team, technology, and defined processes an organization uses to investigate security signals continuously and coordinate response. That definition is settled. What is not settled is how the work should be organized: whether a tiered structure develops practitioners or traps them, whether the staffing behind a 24/7 claim survives a bad week, and whether a build-versus-buy decision made three years ago still holds.

Those questions matter more than the org chart, and the staffing one is sharpest. A SOC can report round-the-clock coverage while running below the headcount that coverage requires. The shortfall is hard to see from a board deck. Overnight is where it shows up as operational risk.

TL;DR:

• The tiered practitioner model can create structural weaknesses. Investigation context erodes at each handoff, and junior investigators can stagnate in repetitive triage.
• A round-the-clock SOC can run below a sustainable staffing floor. Shift math requires more people than many teams can carry, which leaves overnight coverage particularly exposed.
• SOC telemetry often still concentrates on endpoints while attackers work through identity and cloud paths. That is a coverage-architecture problem rather than a tooling-budget problem.
• Operating model choice depends on what an organization can staff, where its organizational context lives, and where contractual liability needs to sit.

What a Modern SOC Covers

Modern SOC coverage runs wider than the monitoring function the name implies. A typical operational cycle moves through continuous monitoring, detection engineering, investigation and triage, incident response, threat intelligence integration, and a feedback loop that pushes what each stage learns back into the next round of detections. Identity and cloud telemetry now sit alongside endpoint data as first-class inputs, not supplementary feeds.

Scope is worth stating plainly, because it drifts. The SOC owns what is happening now and what the organization is failing to see: monitoring, investigation, verdicts, and coordinated response. Vulnerability management, patching, policy, and compliance reporting usually sit with adjacent teams and feed the SOC with context rather than with work. Where that boundary sits determines what the SOC can fairly be held to, and teams that leave it undefined tend to absorb work they were never staffed for.

Threat intelligence is the input most often treated as a subscription instead of a function. Feeds earn their cost only when someone maps them to the organization's actual exposure, converts the relevant pieces into detections, and retires the ones that never fire. Left unattended, intelligence becomes one more queue.

Detection Engineering as a Core SOC Function

Detection engineering deserves to be planned, tracked, and measured like any other engineering function. It is distinct from SIEM administration and from threat hunting, each of which has its own outputs. Detection engineering and hunting run as a loop: hunting surfaces coverage gaps and behaviors that existing rules miss, and detection engineers convert those findings into rules and analytics. Teams that leave detection engineering as everyone's shared responsibility usually learn about their gaps from an external assessment rather than from their own coverage review.

Endpoint-Weighted Telemetry Leaves Coverage Gaps

SOC telemetry often concentrates on endpoint alerts even though intrusions frequently begin through identity and cloud paths. Endpoint-first security tooling on its own rarely gives complete visibility into identity activity or cloud control-plane behavior, so response workflows end up weighted toward the signals that are easiest to collect. Additional tooling spend rarely closes that gap, because the constraint is coverage architecture rather than product count. This is why identity threat detection and response, cloud telemetry, and SaaS audit logs have become core SOC inputs instead of adjacent programs.

SOC Roles and the Tier Debate

Start with the familiar org chart, which is where the pressure is easiest to see. It puts triage investigators at the front validating alerts and escalating, with incident responders behind them running deep-dive investigation and containment. Threat hunters and senior investigators handle specialized work, a SOC manager sits above the whole function, and increasingly a dedicated detection engineer works alongside the investigators. Each of those roles produces something different: triage produces routing decisions, investigation produces verdicts, response produces containment, and detection engineering produces the rules the other three depend on. Most published staffing models still describe some version of this shape. It is under pressure, and the pressure is structural, not cultural.

Where the Tiered Model Breaks Down

The case against tiers rests on two mechanisms that better process can reduce but rarely eliminate.

The first is context loss. Each transfer forces the next investigator to reconstruct part of the investigation, because tickets and notes preserve selected facts, not every assumption, discarded lead, or piece of organizational context that shaped the work so far. Escalations and shift changes therefore introduce repeated interpretation and delay, and tier model handoffs compound that cost while the attacker keeps moving.

The second is career development. Confining junior investigators to triage limits their exposure to the deeper investigation and response work that turns a queue processor into an investigator. Analyst forecasts for 2026 add pressure from a different direction, describing AI-driven SOC systems that enhance alert triage and investigation workflows while unsettling established staffing and upskilling assumptions.

What Replaces Tiers, and What Does Not Get Solved

Organizing work around skills rather than tiers addresses both mechanisms at once. Tierless teams give investigators responsibility for an incident through disposition while making senior expertise available when a case demands it. Specialization moves toward functions such as detection engineering, threat hunting, incident response, and threat intelligence instead of rank-based boundaries, and assignment follows the problem and the capabilities it requires.

The economic argument for keeping tiers is one operators make directly: where alert volume is high, they would rather not put a ten-year incident responder on duplicate alerts. The counter-argument is that the split is a workaround for the cost of investigation, not a property of the work itself. Either way, enterprises that already split routine triage out to vendors are not one decision away from a tierless model, because those contracts would have to be unwound first.

The harder problem is one neither model answers. As automated systems take over more of the routine work junior practitioners used to learn from, organizations still need a deliberate way to build analytical capability. That leaves teams testing alternatives, from structured investigative exercises to planned rotation through detection engineering and incident response.

Who Runs the Work: Build, Share, or Buy

Provider labels matter less than the operational terms of an engagement. What actually separates in-house, co-managed, MSSP, MDR, and SOC-as-a-Service is who owns the investigation and who is allowed to act.

Comparing the Operating Models

An in-house SOC keeps operations and organizational context in-house, at the cost of heavy capital investment and an ongoing retention problem. A co-managed or hybrid arrangement splits that work, keeping context-heavy investigation internal while a provider takes routine triage or after-hours coverage. Managed security service provider (MSSP) engagements center on monitoring and notification, and many MSSPs also sell MDR as one service inside a broader portfolio. Managed detection and response means the provider owns investigation of agreed-upon alerts and may take containment or other response actions according to the customer agreement. SOC-as-a-Service is the fully managed version, built around MDR and often supplemented by managed SIEM, managed security tooling, and detection engineering.

‍

The build side of that decision has a floor set by arithmetic. A week contains 168 hours and a 40-hour FTE covers 40 of them, so a single continuously staffed seat needs roughly 4.2 people before PTO, training, or turnover. Even a modest round-the-clock operation therefore needs multiple investigators plus management, specialist support, and backfill before coverage becomes reliable. One managed security provider puts the practical floor at six to eight people, and Daylight's cost breakdowns put the annual investment for a fully staffed in-house 24/7 SOC in the low millions. Both figures come from vendors selling the buy-side alternative, so weigh them accordingly, though the shift math underneath does not depend on either.

The buy side is splitting three ways. Traditional MDR providers investigate alerts and take response actions within an agreed scope, but the operating model is human-heavy, so escalation volumes tend to run higher and more work comes back to the customer's team. Customer-operated AI SOC tools automate triage and investigation, though the team still runs them and still owns the outcome. A third group runs the investigation on the provider's own agentic platform, with response actions bounded by the authority written into the customer agreement. Daylight Security is a Managed Agentic Security Services (MASS) company, meaning it delivers managed agentic security services for security operations. Its platform assembles telemetry, organizational knowledge, and evidence from prior investigations into an auditable evidence chain instead of judging an alert in isolation, and it applies that investigation context model across MDR, threat hunting, and its Agentic Security Data Lake. Complex or ambiguous cases route to security experts, who also build the customer context the system runs on.

How to Choose

Constraints that are already fixed usually settle the model before preference gets a vote. Staffing sets the outer bound; where organizational context lives, what evidence has to stay internal, and who is allowed to act at three in the morning narrow it from there. The same constraints are worth re-running on a schedule, because headcount loss, a cloud migration, or a contract renewal can move the answer without anyone revisiting it.

• Teams without existing round-the-clock coverage, or without the headcount to hold the six-to-eight-person floor described earlier, will struggle to run a viable in-house 24/7 SOC regardless of budget intent. A hybrid arrangement, with a provider covering nights and weekends while the internal team owns daytime investigation, is the common middle path.
• Regulated organizations should identify which compliance requirements and supporting evidence must stay internal before choosing. In-house and co-managed models generally give more direct control over audit evidence, and reputational risk stays with the organization even when a failure traces to a third party.
• Teams that depend on deep organizational context gain a structural advantage from keeping investigation internal. Evaluation should test whether a provider can capture knowledge such as which service-account behavior is expected or which team is piloting a new VPN, and whether that knowledge stays current.
• Teams whose real problem is escalation volume at three in the morning need containment authority written into the contract, and a provider that can explain how its system reached a conclusion well enough to survive a compliance audit.
• Teams running custom detections should settle how a provider handles those rules before signing.

None of these choices moves governance. Outsourcing transfers who does the work and who carries contractual liability for poor performance, while the board and security leadership still govern cyber risk in every model.

What Makes a SOC Design Hold Up

The durable test for any of these designs is whether it can sustain coverage, preserve organizational context, authorize response, and assign accountability without pushing unresolved work back onto the internal team. A SOC that passes those four is defensible at whatever size it happens to be. One that fails any of them tends to fail overnight, where the consequences are hardest to see and slowest to surface.

Frequently Asked Questions About Security Operations Centers

Is Entry-Level Triage Still a Viable Entry Point Into Security Operations?

Entry-level triage is no longer sufficient as a training ground on its own. Automation is taking over a growing share of the routine queue work junior investigators once learned from, which erodes the default development mechanism without replacing it. Structured investigative exercises and deliberate exposure to real cases can transmit the analytical habits the queue used to teach.

Which SOC Metrics Are Worth Reporting Upward?

Report fewer metrics and prioritize quality over speed. Treat any speed statistic with skepticism unless the calculation method and starting point are transparent, because measuring from investigator review rather than from alert fire produces a very different number. Volume metrics are worse: a SOC measured on closure volume has a structural incentive to close alerts without full investigation, which is why closure counts are a vanity metric. Alert backlog is a core health metric, and age and investigative status make it more useful than raw queue size alone.

How Many People Does Round-the-Clock SOC Coverage Take?

More than a single shift roster suggests. One continuously staffed seat requires roughly 4.2 full-time equivalents before PTO, training, or turnover, and a working SOC needs more than one seat plus management and specialist support. Vendor estimates of the practical minimum for genuine 24/7 coverage land at six to eight people. A coverage claim is worth testing against the roster rather than against the intent behind it.

How Much of the SOC Can AI Actually Run Today?

Some classes of work automate cleanly and others do not. Enrichment, evidence assembly, and triage of alerts carrying a clear malicious indicator tend to automate well, because the system has concrete evidence to reason over. Weak anomalies, protocol violations, and behavior with no precedent in the environment are where verdicts get unreliable, so confidence should track the strength and completeness of the available signal. That variability is why governance and formal assessment need to keep pace with adoption instead of trailing it.

Does Outsourcing the SOC Mean Losing Detection Engineering?

Outsourcing should preserve the detection engineering program, and a provider that asks an organization to give it up is exposing a gap. Someone still has to turn raw security data into reliable signals, attach the context investigators need, and maintain those detections as the environment changes. That work matters whether an internal investigator or a provider's system acts on the output, which is why buyers should confirm in writing that custom rules receive the same investigative depth as the provider's own detections.