SOC as a Service vs In-House SOC: Which Model Actually Makes Sense?

Somewhere between your first serious security incident, your first enterprise customer's security review, and the compliance deadline that puts monitoring in writing, the same question arrives: who is watching our environment at three in the morning?

It is a fair question, because detection remains slow. IBM's 2025 Cost of a Data Breach Report found that organizations identified and contained a breach in a mean of 241 days, and that figure is the good news: the report calls it the lowest in nine years. A security operations function exists to pull that number down, which is why how you staff one matters more than what you pay for it.

There are three honest answers. Build a security operations center and staff it yourself, contract one, or split the work between your team and a provider. All three work. All three fail in predictable ways when they are chosen for the wrong reason, and a reason that misleads often is a comparison of headline costs rather than a comparison of what each model leaves you responsible for.

This guide walks through what an in-house SOC really requires, what a SOC as a service provider does and does not take off your plate, where each model breaks down, and the signals that point to one over another. It is the conversation we have with clients before any of them gets a budget line.

Key takeaways

• Settle coverage and ownership before price. Work out what each model leaves you accountable for, then compare what the models cost to run over three years with the same line items on both sides.
• Round-the-clock coverage is an arithmetic problem before it is a budget problem. A week has 168 hours and one analyst covers 40 of them, so continuous cover starts at four to five people and grows from there. The shortfall shows up at night and on holidays.
• Outsourcing moves the work, not the obligation. Frameworks put monitoring duties on your organization; a provider performs them, and you still answer for them.
• A hybrid SOC is a designed split, not a half-measure. Keeping context and containment authority in-house while a provider carries the queue and the night shift is where the decision often lands once the responsibilities are written down.
• Scope is the whole contract. "24/7 SOC" can mean a human investigating at 3am or an automated alert emailed to you, and the difference only surfaces during an incident.

What a security operations center is

A security operations center is the function that watches your environment continuously and does something when it sees a problem. It is a team, a set of processes, and a stack of tooling, not a room with screens.

Two points of vocabulary before the detail, because both cause real confusion. In-house does not mean on-premises: an internal SOC can run on a cloud SIEM, buy threat intelligence, and keep specialists on retainer, and what makes it internal is that your organization owns the operating function and directs the daily work, not where the servers sit. And a SOC is not a SOC 2: the acronym collides, so to be explicit, this article is about the Security Operations Center, while SOC 1, SOC 2, and SOC 3 are attestation reports from a CPA firm. A SOC watches your environment; a SOC 2 report describes your controls to customers.

What a SOC does

Whatever its size, a SOC runs the same five activities:

• Collect. Pull telemetry from endpoints, network, cloud, identity, and applications into one place.
• Detect. Surface suspicious activity in that telemetry using tuned rules, analytics, and threat intelligence.
• Triage. Separate the detections that are noise from the ones that deserve an investigation, fast enough that the queue does not build up behind them.
• Investigate. Establish what actually happened, how far it went, and whether it is an incident.
• Contain and support recovery. Cut off the attacker, then hand a documented picture to the teams who restore the systems. A SOC drives containment; recovery and the business calls around it stay with the organization.

Reporting wraps around all five, because leadership and auditors both need to see what happened and how quickly.

What a SOC runs on

The activities above need a stack behind them, and the pieces are fairly standard whoever operates them:

• A SIEM, which centralizes logs from endpoints, network, servers, cloud services, and identity providers, and correlates events that look harmless in isolation.
• Endpoint detection and response, which shows what actually executed on a machine and usually offers the quickest way to isolate it.
• Automation and orchestration, often a SOAR, which handles enrichment and the repetitive steps of a playbook so analysts spend their time on judgment.
• Threat intelligence, which tells the team which attacker behavior to expect and gives an alert the context that decides its priority.
• Case management, so investigations, decisions, and timings are recorded rather than living in a chat thread.
• Log retention, sized to the investigations you might have to run and the retention windows your frameworks impose, which is a compliance decision as much as a storage one.

The stack is not the SOC. Owning these tools without the people and processes above produces alerts, not security operations, and that gap is an expensive misunderstanding to carry into this decision.

Which roles a SOC needs

The work divides into a fairly standard set of roles, whether a team fills each one separately or collapses several into one person:

• Tier 1 monitors the queue and handles routine triage.
• Tier 2 takes escalations and runs real investigations.
• Tier 3 covers threat hunting, forensics, and the incidents that do not fit a playbook.
• Detection engineers write and tune the rules so the queue stays survivable.
• A data-source owner watches the health of the feeds, because log sources fail quietly.
• A SOC manager owns process, escalation, and reporting. Larger programs add security architects and people who assemble evidence for auditors.

Tiers are the common shape rather than the only one: some teams drop them in favor of small mixed pods that own a detection end to end. Either way the work above still has to be assigned, and small teams simply collapse it into fewer people.

That is the line worth drawing. A SOC needs investigation depth, detection engineering, incident coordination, reporting, and cover for absences. When one or two people carry most of it, the organization has an internal security team rather than a SOC that survives a bad week.

How a SOC is judged

Two numbers travel with security operations everywhere, and they are worth knowing before you read anyone's service description. Mean time to detect measures how long an intrusion goes unnoticed. Mean time to respond measures how long it takes to act once it is noticed. The 241 days in the opening covers both stages together, which is why the figure is so large: IBM measures the time to identify and contain a breach, not detection alone. Compressing either half moves it.

Around them sits the machinery that actually moves them: playbooks that set out what happens for each incident type, who is told, and when it escalates, and a tuning loop that reviews what fired, what turned out to be noise, and what was missed. A mature operation runs that loop on a schedule and can show you the trend. An immature one measures nothing and calls a quiet month a good one.

When you evaluate the models later in this article, these are the terms the comparison rests on: who is accountable for those two numbers, and who can prove what they were.

Why coverage decides the model

Attacks do not keep business hours, and the stretch between an alert firing and a person reading it is time an intruder gets for free. Closing that gap is what continuous coverage buys, and it is the part of a SOC that tooling alone cannot finish: automation can triage and even contain some things overnight, but somebody has to be reachable when it declines to.

Coverage is also what splits the cost of a SOC in two, and the halves behave differently. Tooling scales with your environment: log volume and retention drive the platform bill whether the queue is watched for eight hours a day or twenty-four. Staffing scales with hours, and that is where the multiple lives. A team that settles for business-hours monitoring still buys most of the stack, it simply needs fewer people sitting behind it. So the first question is not build or buy. It is how much of the clock you genuinely need covered, because that answer moves the cost and the model more than any other input.

What an in-house SOC gives you

With the function itself defined, take the options in turn, starting with building your own. It is not only a cost center, and the reasons to choose it are real.

• Context that cannot be bought. Analysts who live in your environment know which alert is a genuine anomaly and which is Tuesday. That knowledge accumulates and it does not transfer with a contract.
• Direct control. Detections, priorities, and playbooks change when you decide they change, without renegotiating scope with a supplier.
• Immediate authority to act. The people who see the incident already hold the access to contain it, so there is no pause between detection and response.
• You decide where the data sits. The platform is under your contracts, so residency, retention, and who may read the telemetry are your decisions rather than a supplier's defaults. That holds whether the SIEM runs in your data center or in your own cloud tenant.
• A capability you own. If security operations sit close to your product or your regulatory identity, the expertise compounds internally instead of accruing to a vendor.

What running an in-house SOC demands

The honest version of the build option has five moving parts: coverage, queue quality, people, tooling, and the time before any of it works. Only the last one does not appear in a budget, which is why it is the one most plans understate.

The staffing arithmetic

Start with the number that decides everything else. A week contains 168 hours. An analyst working a standard 40-hour week covers 40 of them. Covering every hour with a single person on duty therefore takes at least 4.2 full-time analysts before anyone takes a holiday, attends training, calls in sick, or leaves.

That 4.2 is a floor, not a plan. Our own pricing work puts the practical figure at roughly five people to keep a single analyst seat staffed around the clock once shifts, weekends, and leave are counted, and that is still one seat: one person watching, with nobody beside them.

Everything else you need sits on top of that number. Serious incidents are not investigated well by one person alone, so some shifts need a second pair of hands. Somebody has to write and tune detections. Somebody has to own the health of the log sources, because feeds fail quietly and a SOC watching a dead feed is watching nothing.

This is how a "24/7 SOC" quietly becomes "business hours plus an on-call phone". That is a legitimate model, but it should be a decision, not something you discover during an incident.

Alert volume and tuning load

Staffing solves the hours; it does not solve the volume. An untuned stack produces far more alerts than it produces threats, and the failure mode is well known: analysts spend their shift closing false positives, attention degrades, and the real detection gets acknowledged as routine. Alert fatigue is one of the main reasons a fully staffed SOC still misses things, and it is not fixed by hiring. It is fixed by detection engineering, automation, and ruthless tuning, which is ongoing work that has to be somebody's job rather than something done after the queue is clear.

There is a reporting problem underneath it too. Demonstrating that an internal SOC is worth its budget is genuinely hard: the outcome is an absence of incidents, and metrics that make sense to a security team rarely make sense to a board. Plan how you will show value before you need to defend the line item.

Hiring and retention

Security analysts are hard to hire and harder to keep, and night-shift roles are the hardest of both. Recruitment cycles run long, salaries in this specialty are competitive, and the work at Tier 1 is repetitive enough that good analysts move on unless there is a path into detection engineering or hunting. A build plan without a retention plan is a plan to re-hire every couple of years.

The tooling and how it bills

The components are the ones listed earlier. What matters here is how they bill, and the licensing is only the visible part. Log volume drives cost in most platforms, which means the price rises as you get better at collecting the right data, and storage for the retention windows your frameworks require adds to it. Integration work is continuous rather than one-off.

Time to value

This is the part most plans understate. The tooling can be bought quickly; getting useful detections out of it cannot, and in our experience that gap runs to months rather than weeks. Telemetry has to be onboarded and validated, detections tuned against your actual environment to stop drowning the team in false positives, escalation paths written and rehearsed, and the team trained on your systems. A SOC that is technically live but noisy is not yet protecting anything.

What SOC as a service actually is

That is the build option in full. The alternative is to contract the same function.

SOC as a service, sometimes written SOCaaS or sold as a managed SOC, is a contracted security operations function. A provider runs the monitoring stack, staffs the analyst queue around the clock, triages and investigates alerts from your environment, and escalates to you under an agreed process.

The functions on offer are consistent enough that even government programs describe them the same way. CISA's service catalog describes the Department of Justice's SOCaaS offering as delivering "24x7x365 threat monitoring, detection and incident response, threat intelligence, and cybersecurity investigations" to its customers. That is the shape of the product: eyes on the queue at all hours, investigation capacity behind them, and threat intelligence feeding both.

What usually stays with you matters more than what the provider takes:

• Your environment and its context. Which systems matter, which behavior is normal for your business, and what an outage would cost.
• Access and change. The provider needs telemetry and, for containment, some level of authority. Granting, scoping, and revoking that access is yours.
• The decision to declare an incident and everything downstream of it: legal counsel, customer and regulator notification, recovery, and the business calls.
• Governance of the provider. Reviewing whether the service is actually performing, which is a supplier risk obligation in its own right.

The single most important variable is scope, and it lives in the service level agreement rather than the sales deck. The SLA is where the service becomes specific: which threats are covered, what response time means, when the clock starts and stops, how deep an investigation goes before it escalates, what the provider may do without calling you, and how often you get reporting. Two contracts can both say "24/7 SOC" and mean entirely different things: one puts a human on your alert within minutes at any hour, the other generates an automated notification overnight that a person reads in the morning. Read the SLA for what happens at 3am on a Sunday.

What SOC as a service gives you

The case for contracting the function rests on what a provider already has running before you sign:

• Coverage from day one. The provider already has the shifts staffed. You are buying the answer to the 168-hour problem rather than solving it.
• A team you could not assemble quickly. Providers spread senior investigators, detection engineers, and threat hunters across many customers, so you rent a share of specialists rather than funding each role outright.
• A working stack without a build project. Platform, detections, and case management arrive configured, and tuning starts from a baseline rather than from nothing.
• Speed to a functioning capability. In our experience provider onboarding runs in weeks, while an internal build reaching comparable maturity runs in quarters.
• A simpler cost structure. Spend moves from headcount and per-seat licenses you manage to a contracted fee, which is easier to defend and easier to stop. How predictable it is depends on the meter: a retainer holds steady, while a per-GB price moves with your log volume.
• Elasticity. Adding a cloud environment or a new subsidiary is a scope change rather than a hiring round.
• Evidence for auditors. A good provider produces monitoring records, escalation timelines, and reporting in the form assessors ask for, which is work your team would otherwise assemble by hand.

Where SOC as a service falls short

Every provider page lists the upside. These are the limits worth pricing in before signing.

• They do not know your business. A provider sees your telemetry, not your context. Unusual behavior that is normal for your finance team, or a system whose downtime costs more than a breach, has to be taught deliberately and re-taught as things change.
• Onboarding is a real project with a real gap. Deploying the provider's stack, onboarding log sources, and tuning to your environment takes time, and coverage during that transition is thinner than either side would like.
• Your data leaves your perimeter. Telemetry, and often sensitive detail inside it, moves to the provider's platform. That raises residency, retention, and confidentiality questions, and it makes the provider part of your own supply chain risk.
• Access to your own logs can cost extra. When the platform belongs to the provider, full log access, extended retention, and bulk export are commercial terms rather than givens. Ask before signing, not during an investigation.
• Response often means "notify", not "act". Many contracts authorize the provider to alert and advise but not to isolate a host or disable an account. If containment still waits for your team, your real response time is your team's response time.
• Shared service means limited customization. Efficiency for the provider comes from running many customers on similar detections and playbooks. Deep customization is possible, usually at a price, and sometimes not at all.
• Vendor dependence and exit. Detections, tuning, and history accumulate inside the provider's platform. Leaving means rebuilding that somewhere else, so exit terms and data portability belong in the first contract, not the renewal.

What each model actually costs

Cost is where most of these comparisons start, and it is where most of them mislead, because the models do not present their costs in the same shape. One is a set of internal line items you assemble; the other is a metered fee that includes some of those items and excludes others.

An in-house SOC costs what its parts cost.

• People, usually the largest line. Salaries for the roster above, plus recruitment, onboarding, training, and the cost of re-hiring when someone leaves.
• The stack. SIEM, endpoint and network detection, case management, automation, and threat intelligence. Log volume, not headcount, drives most of it, and volume rises as your detection improves.
• Retention and storage. Keeping the data your frameworks require you to keep, for as long as they require it.
• The line items business cases forget. Management time, facility and shift overhead, tabletop exercises, and the internal effort of proving the function works.

A contracted SOC costs whatever the meter says. Providers usually price on one of four meters: per endpoint, per user, per GB ingested, or a flat co-managed retainer for an agreed scope and coverage window. Which meter you sign changes what a growth event does to your bill: hiring 40 people moves a per-user price and leaves a retainer alone, while onboarding one noisy log source moves a per-GB price and leaves the others alone.

A hybrid arrangement carries both shapes at once: you keep a smaller internal roster and its licenses, and you buy a narrower scope of contracted work, usually on a retainer sized to the coverage window rather than to your headcount. Costed honestly it will not always look cheapest on the spreadsheet; what it buys is coverage without giving up context.

The comparison trap is putting a provider fee next to an internal salary budget. The fee usually excludes licenses you keep paying for, onboarding effort, log volume overages, incident work billed separately, and the internal time spent governing the relationship. Build both columns with the same line items, over three years rather than one, and the answer stops depending on which number was easier to find.

The meters, the current market rates, and the drivers behind them are set out in detail in our guide to SOC as a service pricing.

In-house SOC vs SOC as a service, side by side

The two models differ on more axes than cost, and the ones that decide the outcome are rarely the ones that open the conversation. The table below sets the two out side by side. The co-managed middle ground gets its own chapter further down, because it borrows from both columns, but it appears in the ownership matrix underneath this one, since ownership is where it actually differs.

Who owns what in each model

The model name settles less than people expect. What settles the question is a written answer to who performs each activity and who is accountable for it. NIST's Cybersecurity Framework 2.0 makes this explicit in its governance function: it asks that "roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced" (GV.RR-02), and it holds that "organizational leadership is responsible and accountable for cybersecurity risk" (GV.RR-01). Outsourcing changes the performer, not the accountability.

Fill this in for your own organization before you shortlist anyone. If a row has two owners, or none, the model is not decided yet.

Where the hybrid SOC fits

Many organizations that ask the build-or-buy question sit at neither pole. They have a security team that knows the environment, and no realistic path to staffing nights. A hybrid SOC, also sold as co-managed operations, is built for exactly that: your people keep context, ownership of critical decisions, and usually daytime triage, while a provider carries the queue overnight, brings the platform and the specialist bench, and escalates into your process.

It fits best where there is real internal capability with specific gaps: hours, surge capacity, or a specialism such as cloud forensics that does not justify a full-time hire.

• Done well, it takes the better half of each column above: external capacity without surrendering context or containment authority.
• Done badly, it produces the failure common to hybrids, which is an activity that looks assigned to both teams and is therefore owned by neither.

The difference is not the contract, it is the matrix above, filled in per activity rather than per model, and rehearsed once against an after-hours incident before you rely on it.

What outsourcing a SOC does not transfer

This is the part vendor material tends to skip and the part auditors do not.

Compliance obligations attach to your organization, not to your supplier. NIST SP 800-171, the standard that sets safeguarding requirements for contractors handling controlled unclassified information, requires organizations to monitor the system to detect attacks, indicators of potential attacks, and unauthorized connections, to identify unauthorized use of the system, and to monitor inbound and outbound communications traffic for unusual or unauthorized activity. That is requirement 03.14.06 in Revision 3; CMMC assessments currently score against Revision 2, which puts the same duty more briefly as monitoring organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. Neither version says anything about who performs the monitoring. Hiring a provider satisfies it only if the provider's actual scope covers what the requirement demands, and you can show that it does.

Three consequences follow.

• You still own the evidence. When an assessor asks how monitoring works, the answer has to include the provider's scope, the escalation path, and records that show it operated. Contract for reporting and log access in a form your assessors accept, before you need it.
• You acquire a new obligation, not fewer. Handing security operations to a supplier makes that supplier part of your risk surface, and brings the relationship inside your vendor risk management program. NIST CSF 2.0 asks that the risks posed by a supplier, their products and services, and other third parties be "understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship" (GV.SC-07). Provider oversight is now a control you have to run.
• Accountability does not move. Notification duties, customer commitments, and the board conversation after an incident stay where they were. A provider can supply the timeline; it cannot supply the accountability.

None of this argues against buying. It argues for buying with the obligations written down first, so the contract is scoped against what you actually have to prove.

Which model makes sense for your organization

Company size is a poor proxy for this decision. Two companies of the same headcount can have completely different exposure, obligations, and existing capability. Judge by the signals instead.

Signals that point to building in-house:

• Security operations is close to your product or your regulatory identity, and running it is a capability you intend to own.
• Your environment is unusual enough that generic detections would produce noise rather than signal.
• Data residency, classification, or contractual terms make sending telemetry to a third-party platform genuinely difficult.
• You already have several experienced analysts and a credible path to funding the rest of the roster for years, not quarters.
• Containment has to be immediate and unilateral, at any hour, by people who already hold the access.

Signals that point to SOC as a service:

• You need continuous coverage sooner than a hiring cycle can deliver it.
• Alert volume already exceeds what the current team can triage, and the backlog is growing.
• A customer, an auditor, or a framework has put monitoring on a deadline.
• Your environment is mostly mainstream cloud and endpoints, where provider detections start out well matched.
• Security headcount is one or two people who are also doing compliance, IT, and everything else.

Signals that point to co-managed:

• You have real internal expertise but no realistic night coverage.
• You want to keep detection strategy and containment authority, and buy capacity underneath them.
• You are building toward an internal SOC and need cover during the years it takes to get there.
• Your obligations require demonstrable oversight of the operation, which is easier when your own people are inside it.

Four questions sharpen any of these lists, and they are worth answering in writing before a shortlist exists.

• What must happen after hours, stated as a maximum acceptable delay? Set it per asset and per incident type. "As fast as possible" is not an answer anyone can contract against.
• What capability do you actually have? Count real analysts, engineers, and responders, not job titles held by people who also run IT, compliance, and everything else.
• When does the clock start and stop? An SLA without defined timer boundaries, investigation depth, and response authority is a number, not a commitment.
• What happens when the model changes? Growth, an acquisition, a new cloud platform, or a provider transition should not require starting over. Ask now what comes back to you, and in what format.

Whichever direction the signals point, test the answer against one scenario before committing: a confirmed compromise on a Saturday night. Write down who notices, who investigates, who is allowed to isolate the host, who decides it is an incident, who calls counsel, and who notifies the customer. If any of those has a vague answer, the model is not ready regardless of its name.

What to ask a provider before you sign

If the answer points to a contracted or hybrid model, the shortlist is won and lost on the service description rather than the feature list. These are the questions worth asking every provider, and the answers belong in the contract rather than in an email.

• What happens at 3am on a Sunday? Ask for the staffing model behind the coverage claim: who is on shift, how many customers they carry at once, and what an analyst is authorized to do without waking someone on your side.
• Show us a real investigation. Sample cases, redacted, tell you more than any capability matrix: how deep the analysis goes, what evidence is attached, and what the escalation actually looked like.
• When does the clock start and stop? Response times mean nothing without the timer definition, the severity model behind it, and what counts as the end of the obligation.
• What can you do without asking us? Get the containment actions in writing, split into pre-approved and escalate-first, and check that the split still works for a production system at peak hours.
• Where does our data live, and who touches it? Residency, retention period, access controls on their side, and their own subprocessors, since they now sit inside your supply chain.
• What evidence do we get for audits? Ask to see the actual monthly report and the triage records, and confirm they carry what your assessors ask for rather than what looks good in a business review.
• What comes back to us if we leave? Detections, tuning history, case records, and raw logs, in what format and within what window. Ask this at the first meeting, not at renewal.

Common mistakes in this decision

These are the failures we see from the compliance side of the table, where the consequences surface later than the purchase.

• Buying the service before writing down what you are obliged to monitor. Scope should be derived from your frameworks, contracts, and customer commitments, in that order. Teams that skip this end up with monitoring that is genuinely good and partly irrelevant, and they discover the gap when an assessor asks about a system nobody was watching.
• Assuming the provider's own compliance covers yours. A provider's SOC 2 report describes the provider's controls. It is not evidence that your systems were monitored, and no assessor will accept it as such. You need records about your environment.
• Letting the provider draw the boundary. Vendors scope naturally to what their platform ingests cleanly. Your boundary is set elsewhere: the enclave holding controlled unclassified information, the cardholder data environment, the systems in your SOC 2 description. When those two boundaries differ, the difference is your exposure, not theirs.
• Contracting without an evidence format. Reporting that satisfies a monthly business review is rarely the artifact an auditor wants. Agree what monitoring records look like, how long they are retained, and how you export them, before the first assessment rather than during it.
• Comparing a provider fee with an internal budget. As the cost chapter sets out, the fee leaves several of your line items in place. Put the same items on both sides and compare three-year totals, or the cheaper column is simply the one that was easier to add up.
• Leaving exit and portability to the renewal conversation. Detections, tuning history, and cases accumulate inside the provider's platform. What you can export, in what format, and how long you keep access after termination belongs in the first contract.

Conclusion

The build-versus-buy question has no universal answer, but it does have a reliable method. Establish what continuous coverage genuinely requires, write down who owns each activity in the operation, check the result against the obligations you already carry, and only then compare the models on three-year cost. Run in that order and, in our experience, the answer often lands in the middle: context and authority stay in-house, and the capacity that makes round-the-clock coverage realistic is bought.

What rarely works is the reverse order: picking a model from a price list, then discovering during an incident that nobody owned the decision that mattered.