Inside the Security Operations Center

Most of the day is the queue. SOC operations are dominated by triage, meaning reading alerts, checking context, closing the ones that are not real, and escalating the ones that are. In most environments this is the large majority of the time spent. The larger the SOC, the smaller that share tends to be, because scale is what buys you people whose job is not the queue.

The rest of the day divides into roughly four other activities:

• Investigation: working the alerts that survived triage, which is a much smaller number and a much longer time per item.
• Response and coordination: containment actions, talking to IT, chasing an asset owner to find out whether a piece of software is sanctioned.
• Maintenance: tuning noisy rules, fixing broken log sources, and dealing with the collector that stopped reporting on Friday and nobody noticed until Monday.
• Everything else: shift handovers, reporting, on-call, tabletops, onboarding a new log source, answering "is this email a phish" from an employee.

The thing that surprises people outside the function is how much of the day is spent on things that are not attacks. A large share of a SOC's queue is authorized activity that looked unauthorized, misconfigured tooling, and internal questions, and the genuine intrusions are rare, and the rarity is precisely what makes the volume dangerous, because a queue that is almost never real trains the person working it to expect that it is never real.

There are four common models, and organizations frequently mix them.

• Round-the-clock shifts: analysts work rotating shifts covering all 168 hours of the week. Common patterns include twelve-hour shifts on a three-on, three-off or four-on, four-off rotation, and eight-hour shifts across three daily handovers.
• Follow-the-sun: teams in two or three time zones each work local business hours and hand the queue to the next region. This avoids night shifts entirely but requires either multiple offices or a distributed workforce.
• Business hours plus on-call: the SOC is staffed during working hours, and outside those hours an on-call analyst is paged for high-severity alerts only. This is the most common model in mid-market organizations, and it accepts — explicitly or otherwise — that low and medium severity alerts wait until morning.
• Outsourced or hybrid coverage: an external provider covers nights and weekends while the internal team covers business hours. This is the most common way an organization gets to genuine round-the-clock coverage without hiring for night shifts.

Whichever model is chosen, the load-bearing part is the handover, not the schedule, and coverage that exists on the roster but loses the state of every open case at each shift boundary is coverage in name only — the rota is full and the continuity is gone.

All three deliver monitoring and detection. What differs is who does the work, how far they take it, and who is allowed to act.

The historical distinction is that an MSSP monitors and tells you, while an MDR investigates and acts. That distinction has blurred as MSSPs added investigation and MDRs added breadth, so the category label on the contract is now a weak predictor of what you actually get. The reliable way to tell them apart isn't the acronym, it is the two questions that follow in this section: what arrives in your inbox, and what the provider is permitted to do without asking you first. The provider's own side of this arrangement, and how the economics of running one look from the inside, is covered on the MSSP and MDR page.

The arithmetic is the honest answer here, and it is arithmetic most vendor pages assert around rather than show.

A week contains 168 hours. A full-time analyst is contracted for roughly 40 hours, and after holiday, sick leave, training, and mandatory time off, the effective coverage a single analyst delivers over a year is closer to 33 or 34 hours a week. Divide 168 by that and you get roughly five people to keep exactly one seat occupied at all times, with no redundancy of any kind.

That number is the floor, and it is not a realistic operating model, for three reasons:

• One person on shift is a single point of failure: an analyst working an incident can't also work the queue, so a real overnight shift generally needs two.
• Tier 1 alone cannot close everything: somebody with escalation authority has to be reachable, which is either a second on-shift role or a paid on-call rotation.
• Somebody has to maintain the detections: detection engineering, log source health, and tuning are not shift work, and if a SOC staffs only the queue then the queue gets steadily noisier.

Work that through and a genuinely self-sufficient round-the-clock SOC lands in the low double digits of headcount before you count the manager. This is why the great majority of organizations that need round-the-clock coverage buy some part of it rather than building all of it, and it is also why "we will just add an on-call rotation" is the most common way an internal team ends up burning out its most senior people. The enterprise security operations page covers how the same arithmetic plays out at multi-region scale.

For many organizations, yes, and for some, no. The determining factor is usually not size, it is how much of the response path requires knowledge of your environment that a provider can't hold.

MDR replaces an in-house SOC well when the environment is reasonably standard, the tooling is mainstream, and the actions that matter most (isolate an endpoint, disable an account, block a domain) are ones a provider can be authorized to take. A great many mid-market organizations sit exactly here, and building an internal equivalent would cost more and detect less.

MDR replaces an in-house SOC poorly in three situations. The first is when containment decisions carry business consequences that only an insider can weigh, such as an operational technology environment where isolating a host stops a production line. The second is when the environment is unusual enough that a provider's detections do not fit, which is common in industrial, healthcare, and heavily custom estates. The third is when the organization needs someone accountable in the room during an incident, which is a governance requirement rather than a technical one.

The most common real-world answer is neither replacement nor rejection. Organizations keep a small internal function that owns context, ownership, and authority, and buy the coverage hours. That is the co-managed model.

A co-managed SOC is a split model where an external provider and an internal team share the security operations function, usually with the provider covering monitoring and first-line triage and the internal team owning escalation, response, and the environment's context.

Containment authority is the part that has to be written down, and the failure to write it down is where co-managed arrangements come apart. There are generally three positions a contract can take:

• Provider-authorized: the provider can take defined containment actions, such as isolating a workstation, without asking. The list of permitted actions is enumerated, and everything outside the list is an escalation.
• Approval-gated: the provider recommends and the customer approves, usually with a named on-call contact and a response window. This is safer and slower, and it fails badly at 3am when the named contact does not answer.
• Customer-only: the provider never acts, only reports. This is common in regulated and operational technology environments and it means your mean time to contain is bounded by your own availability, not the provider's.

Co-managed arrangements tend to fail on three points that contracts leave unwritten: which specific actions the provider may take unilaterally, who the named out-of-hours approver is and what happens when that person doesn't answer inside the agreed window, and who owns the decision when containment would cause a business outage. An arrangement that hasn't settled those three discovers them during its first real incident.

SOC as a Service, usually shortened to SOCaaS, is a subscription model where an external provider supplies the security operations function, including the platform, the analysts, and the processes, as a service rather than as tooling you run.

In practice SOCaaS and MDR overlap heavily and different vendors draw the line differently. The most common distinction is scope: SOCaaS tends to describe a broader function including log management, compliance reporting, and general monitoring, while MDR tends to be centered on threat detection and response specifically. Some providers use SOCaaS to signal that they will operate a SIEM you own, and others use it to signal that everything including the platform is theirs.

Because the label isn't standardized, it carries very little information on its own. What distinguishes one SOCaaS arrangement from another is the same set of things that distinguishes any outsourced arrangement: what telemetry is in scope, what the provider does with an alert before the customer sees it, and what the provider is permitted to do without asking.

Look at what arrives, not at what the contract promises. An MDR that is genuinely investigating produces a different artifact than one that is forwarding, and the difference is visible in the first month of any trial.

Signals that real investigation is happening:

• The volume that reaches you is much smaller than the volume the tools generate: and the provider can tell you what was closed and why.
• Findings arrive with a scope statement: meaning which assets and accounts were checked, not just the one that alerted.
• Findings say what was ruled out: an investigation that considered alternatives and eliminated them reads differently from one that never considered any.
• The recommended action is specific to your environment: naming the actual host, account, and business owner rather than a generic remediation paragraph.
• False positives get tuned rather than repeated: if the same benign alert reaches you weekly for three months, nobody is doing detection engineering on your behalf.

Signals that you're being forwarded to:

• You receive raw alert text with a severity label attached and are asked to advise.
• The provider's questions to you are questions they could have answered from the telemetry they already hold.
• Reporting is measured in alerts handled rather than in investigations closed with verdicts.

The difference shows up fastest under a controlled test, and a benign but alert-worthy action, such as an authorized administrative task that reliably trips a detection, produces a response whose shape and latency are far more informative than a reference call.