How to Build a SOC: Team, Tools, and Budget

Most SOC build plans fail on arithmetic rather than ambition. Three analysts per shift across three shifts reads like nine hires on a slide, but a seat that has to be filled every hour of the year costs several times its headline headcount once PTO, sick days, training, and holidays are priced in. That gap between the slide and the payroll is where SOC builds stall, and it compounds through tooling, hidden operating costs, and the years it takes an operation to mature.

TL;DR:

• A functional mid-market 24/7 SOC costs well over a million dollars a year to run, and the exact number moves with team size, compensation, tooling, log volume, and maturity.
• Coverage math, not org design, sets the headcount floor. Every continuously filled seat needs several people behind it, and the engineering and management roles sit on top of that.
• The costs that break build plans are the recurring ones a business case leaves out: turnover, detection tuning, log onboarding, and the team capacity consumed by tool maintenance before anyone investigates an alert.
• Teams that cannot absorb those requirements have credible hybrid and managed alternatives, though how much work moves off the internal team depends on contract scope and the environment.

Everything downstream, from tooling volume to the maturity timeline, gets priced off the team number, so that is where a build plan starts.

The Team: Coverage Math Comes First

A continuously filled seat has to cover every hour of the year, while each employee's available time shrinks with PTO, sick days, training, and holidays. Divide 168 coverage hours per week by a conventional 40-hour workweek and one continuously filled seat needs 4.2 FTEs before a single absence is accounted for. Plan above that floor to absorb those absences. At prevailing compensation levels, each around-the-clock seat carries the loaded cost of several full-time hires.

The Realistic Headcount Floor

A reliable 24/7 operation needs enough analysts to cover vacations, illness, training, and unexpected absences without stranding one person alone on shift. Two continuously staffed seats require 336 coverage hours per week, or 8.4 coverage FTEs against a conventional 40-hour week before absences, which means the plan needs at least nine people for monitoring alone. Six positions spread across three daily shifts leave that requirement short. Add a detection engineer or two, a security engineer, and a SOC manager, and a functioning operation lands between 12 and 14 FTEs depending on coverage and seniority mix. That is the SOC team structure a build plan has to fund.

Understaffing tends to surface as a specific failure mode: one analyst alone at three in the morning with a suspicious OAuth grant spanning two tenants, no second opinion, and a six a.m. handoff where the incoming analyst reopens the ticket and rebuilds the timeline from raw logs.

Salary benchmarks vary substantially by role, experience, geography, and hiring market, so treat senior analysts, SOC managers, and detection engineers as premium roles in the staffing plan. Budget well above base salary for benefits, payroll costs, tooling, training, recruiting, and management overhead, because those loaded costs can materially increase the staffing budget.

Tiered or Tierless

Tiered staffing is under real pressure. Automated triage and investigation are absorbing much of the routing work that a first tier existed to handle, and Gartner's 2026 outlook treats AI-driven SOC tooling as a destabilizing force on operational norms rather than a marginal efficiency gain.

A build starting in 2026 should organize roles around outcomes instead of escalation levels. Investigation, detection engineering, threat hunting, and incident response leadership are the actual work, and a room of junior analysts grinding through repetitive routing is a structure the tooling is already eroding.

The Tools: Ingestion Economics Drive the Stack

SIEM ingestion becomes the line item that surprises finance, because its pricing uses log volume as the basis and moves independently of headcount. More endpoints, cloud services, identity systems, SaaS applications, and security controls all expand the telemetry flowing into the platform.

That makes a budget built on today's volume unreliable. A company may begin with standard productivity-suite, firewall, and endpoint logging, then watch ingestion climb sharply after adding CASB, DLP, cloud, or identity telemetry. Every new control sends another stream of logs into the SIEM, and the projection has to assume that growth.

EDR pricing scales with endpoint count, product tier, retention, and whether managed detection is included. The rest of the stack carries its own pricing logic:

• SOAR costs range from comparatively lightweight automation subscriptions to enterprise platforms that may require dedicated architects and engineers to maintain a growing set of playbooks across an organization's integrations.
• Threat intelligence platforms commonly price core access separately from brand, vulnerability, SecOps, and other add-on modules.

Those costs also climb steeply as the organization grows. Broken out by organization size, the full technology stack runs $128K to $341K annually for 500 to 1,000 employees on a Microsoft path and $677K to $1.37M for 1,000 to 2,500 employees. A mature Splunk-based stack at 2,500 to 5,000 employees runs $1.6M to $4.1M. A tooling quote that looks affordable in isolation is rarely the binding constraint.

The Budget: What the Spreadsheet Misses

The planning baseline for a functional mid-market 24/7 SOC, under this staffing model and these technology ranges, runs into seven figures a year. The calculation starts with 12 to 14 FTEs, then adds loaded compensation, tooling tied to endpoint and log volume, recruiting, training, and management overhead. Daylight's own build-versus-buy modeling puts the realistic planning range at roughly $1.5M to $2.86M annually once staffing, technology, overhead, and the recurring costs below are included. Estimates vary according to what counts as functional, how many people are included, and whether the model covers mature threat hunting and detection engineering, so the total has to be modeled from your own inputs. Universal benchmarks do not capture that variation.

The business case usually captures those numbers. What it misses:

• Replacing analysts who leave costs recruiting spend, lost institutional knowledge, and months of reduced productivity while the next hire learns the environment.
• Tool integration, tuning, maintenance, and compliance documentation consume team capacity before anyone investigates an alert, so that capacity needs its own line in the plan.
• Bringing dozens of log sources into a SIEM requires engineering, testing, documentation, and ongoing connector maintenance, and a vendor API update can silently break one.
• Budget opacity undermines the analysis itself, since a build-versus-buy comparison is only as honest as the spend visibility behind it.

These items recur and compound. Recruiting, turnover, training, tool maintenance, and ramp-up time all continue well past launch, and the workload the team inherits can be punishing, because alert queues force a standing decision about what gets investigated, deferred, or ignored.

The Timeline: Months to Stand Up, Years to Mature

A functional in-house SOC takes months to stand up and years to mature. Initial monitoring capability can arrive earlier, but tuned detections, integrated playbooks, reliable handoffs, and a team that has worked incidents together develop through repeated iteration. UK government SOC build guidance is explicit that designing and building a SOC takes many iterations and a fair amount of investment rather than a single deployment.

Tenure works against the maturity clock, and analysts may leave before the operation develops the organizational knowledge that justified building it. Sequencing matters too. Threat hunting is a milestone the operation reaches after launch, and the SOC maturity literature places it downstream of effective incident response and accurate case closure.

When to Build, When to Buy, When to Split

Whether an internal SOC succeeds depends on budget, talent pipeline, regulatory posture, and what security means to the business. The decision usually resolves along five lines:

• If your security operations budget cannot absorb a seven-figure annual commitment, buy. Managed detection and response starts from a lower cost base than a fully staffed internal operation, though the difference depends on contract scope and the customer environment.
• If time to fill security roles is already measured in months, buy. Industry survey data puts a majority of teams understaffed, with hiring for many roles running three to six months.
• If security is a core business differentiator, you have the budget, and you have retained senior talent before, build. Complex legacy tooling and existing incident response depth strengthen the case.
• If regulation mandates internal control or strict data residency, build, or choose a co-managed model with contractual data-sovereignty requirements.
• If you have a capable internal team but cannot staff nights and weekends, split it. Keep investigation, detection engineering, and response judgment in-house and outsource continuous alert investigation and overnight response coverage.

Buyer intent leans toward the split. A Gartner Peer Community poll of IT and security leaders found a hybrid model to be the most common target SOC operating model. If you fully outsource, retain internal security ownership to manage the provider, own policy, and make investment decisions.

Where the Investigation Burden Sits

The buy option covers several different arrangements, and the distinction that matters is where the investigation burden sits: with your team, shared, or fully owned by the provider.

AI SOC tools are software your team runs. They investigate alerts and return findings and recommendations, and the customer remains accountable and owns response staffing. They generally initiate investigations from alerts raised by connected customer tools.

Traditional MDR and AI-native MDR are managed services. The provider may accept defined contractual responsibility for continuous investigation and agreed in-scope response actions, and AI-native MDR can initiate investigations from both connected-tool alerts and custom rules run against logs. Liability, exclusions, investigation depth, escalation patterns, cloud coverage, and response scope vary by provider and agreement, and organizational and CISO accountability remains with the customer regardless of the model. The practical AI SOC vs MDR question is which of those three positions you are buying.

That choice changes the staffing plan. A customer-operated tool may reduce repetitive work, but the internal team still owns 24/7 response, on-call escalation, and coverage for absences. A managed service can move continuous investigation and response coverage outside internal headcount while the customer retains security ownership and investment decisions. Engagement scope determines how much work moves.

Daylight is a MASS company, meaning it offers managed agentic security services for Security Operations. AI-native MDR is the entry point, with threat hunting and an Agentic Security Data Lake running on the same agentic architecture, and MDR coverage extending to phishing and DLP investigation and response.

What the Build Decision Turns On

A SOC build is a multi-year staffing and operating commitment priced in seven figures a year. The parts that decide whether it works are usually the parts a first-pass business case leaves out: coverage math, context that accumulates, and people who stay long enough to hold it.

Whichever path you take, the question underneath stays the same: who investigates, with what context, and who is accountable when a verdict is wrong. That last problem is largely one of context architecture, the organizational capability to build and maintain the context an investigation runs on.

Frequently Asked Questions About Building a SOC

What Should an MDR Contract Specify Before We Sign It?

Define which investigation types the provider owns, what constitutes a completed investigation, which response actions are in scope, when customer judgment is required, and how unresolved work is handed back. Require verdicts to be written back into the tool that raised the alert, and require the agreement to define the provider's service liability and in-scope response obligations. Ask who handles escalations and what their background is, since "24/7 coverage" can mean anything from senior incident responders to junior staff on a night rotation.

How Do We Cover Nights Without Stranding One Analyst Alone?

Pair the night seat with a follow-the-sun partner or provider so a second set of eyes is always awake. Then name a senior on-call escalation path with a defined wake-up threshold, so the night seat never decides alone whether something warrants waking someone. Require a written handoff artifact covering the timeline, actions taken, and open questions, because otherwise the incoming shift rebuilds the case from raw logs.

How Do We Keep SIEM Costs From Eating the Tooling Budget?

Compare commitment pricing with pay-as-you-go rates and filter before ingestion. Route full telemetry to cheap storage and forward only investigation-relevant data to the SIEM. Model continued volume growth in every projection, because a flat-volume budget will be wrong as the environment adds endpoints, cloud services, SaaS applications, and security controls.

If We Hire an MDR, Can We Skip Internal Security Hires Entirely?

No. Retain internal professionals to liaise with the provider, own policy, and decide on security investments even if investigation and response are fully outsourced. The internal role shifts away from staffing a queue and toward governing a provider relationship.

How Long Until an In-House SOC Pays for Itself?

There is no universal payback timeline, and payback is a weak frame for a capability that keeps costing money to maintain. An understaffed build also carries risk that payroll does not capture, because coverage gaps are where dwell time accumulates. Tenure limits payback further, since the team that reaches maturity may not be the team you hired.