What a Security Operations Center (SOC) does

A Security Operations Center, or SOC, is the team and technology that continuously watch an organization's environment, detect threats, and coordinate the response. It is the nervous system of a defense. Logs and signals from endpoints, network, identity, cloud, and applications flow into one place, get correlated, and turn into action. Without it, an attacker who slips past prevention can operate for weeks before anyone notices. The job of a SOC is to shorten that window to minutes.

For a regulated company in finance, healthcare, critical infrastructure, or SaaS, a SOC is no longer optional. Prevention fails. Phishing lands, a credential leaks, a vendor gets breached, and something reaches the inside of your network. What separates a contained incident from a reportable disaster is whether someone is watching and acts before damage spreads. NIS2 and DORA both assume you have this capability, because both set hard clocks for detecting and reporting incidents. A SOC is how you meet those clocks.

This guide covers what a SOC does, its roles, its technology stack, the metrics that matter, the arithmetic of 24/7 staffing, and the economics of build versus buy. We deliver monitoring and response through threat detection and response and managed detection and response.

What a SOC actually does

A SOC is not a room with screens. It is a set of repeatable functions that together form a continuous defense. Each function feeds the next, and a gap in any one breaks the chain. The point is not to collect data, but to turn data into decisions fast enough to matter.

• Monitoring and collection: pulling logs and telemetry from endpoints, network devices, identity providers, cloud platforms, and applications into a central platform.
• Detection: correlating events and recognizing behavior that matches known attacker techniques, aligned to a framework like MITRE ATT&CK.²
• Triage: separating real threats from the flood of benign alerts, deciding what to escalate and what to close.
• Response: containing an incident, isolating affected systems, and coordinating remediation with the incident response plan.
• Threat hunting: proactively searching for attackers who evaded detection, rather than waiting for an alert.
• Continuous improvement: tuning detections, retiring noisy rules, and writing new ones after every incident and every missed signal.

The last function is the one most teams neglect, yet it decides whether a SOC improves over time or slowly drowns. A SOC that does not feed its findings back into better detection is just an expensive alarm nobody trusts.

The roles and tiers inside a SOC

A mature SOC is structured in tiers because different threats demand different skills, and you do not want your most senior people closing false positives all day. Work flows up the tiers as complexity rises. A clean alert that is nothing is resolved at Tier 1; a confirmed intrusion with lateral movement reaches Tier 3 and the incident lead. The model puts the right brain on the right problem.

Small organizations rarely fill every box. One analyst may cover Tier 1 and Tier 2, and detection engineering may be part-time. That is fine, as long as you are honest about the gap. The role most often missing entirely is the detection engineer, which is why so many SOCs slowly fill with noise. The role missing under pressure is the incident lead, which is why responses turn into chaos.

The technology stack a SOC runs on

A SOC runs on a stack of tools, but no single tool detects an attack on its own. Each covers a different layer, and the value comes from how they connect. We break the differences down in SIEM, EDR, and XDR; the short version is below.

• SIEM (Security Information and Event Management) collects and correlates logs from across the organization, and retains them. It is where broad correlation and provability for a regulator live.
• EDR (Endpoint Detection and Response) watches laptops, servers, and workstations, flags suspicious behavior, and enables response on the device, such as isolating an infected host.
• XDR (Extended Detection and Response) ties signals from endpoints, network, email, and cloud into one picture to speed detection and reduce tool sprawl.
• SOAR (Security Orchestration, Automation, and Response) automates repetitive response steps, such as enriching an alert or quarantining a user, so analysts spend their time on judgment rather than clicking.

The trap is buying the stack and assuming the job is done. A SIEM with no tuned detections and a SOAR with no playbooks is a cost center, not a capability. Technology generates signals; people and process turn them into outcomes. A SOC that buys tools but not the engineering around them gets a large bill and false confidence.

The metrics that actually matter

You cannot manage a SOC on gut feel. A handful of metrics tell you whether it is getting faster and sharper or slower and noisier, and they map directly to how long an attacker had inside your environment. A regulator or an insurer will ask about them.

These metrics move together. Cutting MTTD by lowering detection thresholds drives the false-positive rate up, which exhausts analysts and pushes MTTD back up as they miss things. The goal is not to optimize one number. It is to drive dwell time down while keeping the false-positive rate low enough that analysts trust the queue.

The 24/7 staffing problem

This is where most in-house SOC plans break. Attacks do not wait for business hours. A ransomware operator often detonates at 3am on a Sunday precisely because the team is asleep. Continuous monitoring is the whole point of a SOC, and that collides with how many people it takes to keep a seat staffed every hour.

The shift arithmetic is unforgiving. A single analyst seat covered around the clock, every day of the year, is not one person. Once you account for three shifts, weekends, holidays, leave, training, and sickness, covering one continuous seat takes several full-time analysts, not one. In our experience the figure is commonly cited at around five to six people per always-on seat, though the real number depends on your shift pattern, local labor rules, and how much you rely on an on-call rotation versus a staffed night shift. The point is simple: 24/7 coverage is a team, not a hire.

Add recruiting and retaining scarce talent, tooling licenses, training, and management overhead, and the true cost of an in-house SOC is far higher than the salary line suggests. This is the biggest reason regulated companies that genuinely need the capability still do not build their own.

Build, buy, or hybrid: the honest economics

There are three ways to get SOC capability, and the right answer depends on your size, risk, and how much control you need. The decision is rarely about whether you need the capability. For a regulated firm you almost certainly do. It is about who runs it.

1. 01
   Build in-house

   You hire the team, buy the stack, and run it yourself. You get full control and deep context on your environment. You also take on the recruiting, the 24/7 shift math, the retention problem, and a large standing cost. This makes sense for large organizations with the scale to keep specialists busy and the budget to keep them.
2. 02
   Buy as a service (MDR)

   You outsource detection and response to a provider through managed detection and response. You get 24/7 coverage, a trained team, and a tuned platform without building any of it. The trade-off is less direct control and a dependency on the provider's quality. For most mid-sized regulated firms this is the fastest path to the outcome.
3. 03
   Run a hybrid

   You keep a small internal team for daytime work, environment knowledge, and decision-making, and use an external partner for out-of-hours coverage and surge capacity. This is the most common real-world pattern, because it puts your context where it is most valuable and buys the expensive 24/7 hours where they are hardest to staff.

Be wary of false economy in either direction. An understaffed in-house SOC that cannot cover nights pays for control it cannot exercise, and a cheap MDR contract that just forwards raw alerts pays for a service that does not respond. The right question is which model lets you hit a low dwell time at a cost you can sustain for years.

The SOC and compliance

For regulated companies, detection and response is not just good hygiene. It is a legal requirement with a clock attached. NIS2 requires in-scope entities to report a significant incident, with an early warning to the relevant authority within 24 hours of becoming aware of it, followed by a fuller notification within 72 hours. You cannot meet a 24-hour warning window if you do not know you have been breached. That knowledge is exactly what a SOC produces.

DORA, the EU's Digital Operational Resilience Act for the financial sector, sets a similar structure: financial entities must classify and report major ICT-related incidents to their competent authority on defined timelines. We compare the two regimes in NIS2 vs DORA. Both share one hard truth: a reporting obligation is unworkable without a detection capability behind it. A SOC, whether built or bought through MDR, is how regulated firms turn a legal deadline into something they can meet.

Common failures that quietly kill a SOC

Most SOCs do not fail loudly. They degrade. The tooling stays green, the dashboards keep scrolling, and the capability hollows out until an attacker walks straight through it. These failures are predictable, and therefore preventable.

• Alert fatigue: analysts face thousands of low-quality alerts, stop trusting the queue, and the one real alert gets closed with the noise. This is the most common way a SOC misses a breach.
• No tuning: detections are deployed once and never refined. Noise climbs, the false-positive rate stays high, and the platform slowly becomes background hum.
• No threat hunting: the team only reacts to alerts and never proactively looks for what the alerts missed. Sophisticated attackers are built to avoid the alerts.
• No feedback loop: incidents are closed without writing a new detection, so the same attack technique works twice.
• Coverage gaps: critical log sources, cloud accounts, or identity systems are never onboarded, so the SOC is blind to whole parts of the environment.

Every one of these is a process failure, not a tooling failure. Buying a bigger SIEM does not fix alert fatigue. The fix is detection engineering, disciplined tuning, real hunting, and a feedback loop after each incident.

A SOC that is never tuned is not a defense. It is an alarm everyone has learned to ignore.

How Raptoric helps

Building and retaining a 24/7 SOC is out of reach for most regulated companies. We give you the capability without the build cost. Through threat detection and response and managed detection and response, we provide round-the-clock monitoring, tuned detection, real triage, and coordinated response, mapped to your NIS2 and DORA reporting obligations. As an independent, vendor-neutral firm, we tune detection to your environment, not to a product we are paid to sell. Book a scoping call and we will assess your coverage and the gaps.