In-house SOC or SOC as a service? How to decide without getting the math wrong | Blog

What a SOC needs to work

A Security Operations Center is not a tool, it is an operation. To produce the result expected of it, it needs at least five elements at the same time: continuous coverage, detection engineering, threat intelligence, a response process and someone with the authority to act.

If one is missing, the whole does not deliver. A correlation tool without detection engineering generates alerts nobody trusts. 24x7 coverage without a response process generates incident records, not containment. That is why the comparison between in-house and contracted has to look at the entire operation, not at the license line.

The shift math almost nobody does

Covering 24 hours a day, every day of the year, is arithmetic before it is strategy. A week has 168 hours. One person on a standard schedule covers about 40. Just to keep one position staffed at all times takes a little over four people, and that is before accounting for vacations, training, sick leave and turnover. In practice, the figure the market uses to size a 24x365 position is around five professionals.

Now multiply that by the number of positions a real operation requires: triage analyst, investigation analyst, detection engineer, coordination. The minimum team for an in-house SOC that really works rarely fits in fewer than a dozen people, and each of them is in a scarce market, with high turnover and competitive salaries.

It is this math, not the price of the platform, that usually decides feasibility.

What the as-a-service model delivers

When you contract, you join an operation that already exists. That means three concrete things:

Continuous coverage is already in place, with on-call and escalation defined, without depending on your ability to hire for three shifts.
The detection repertoire has already been built up in other environments, which reduces the time until alerts become reliable.
The cost is sized by consumption, usually by volume of events, assets and integrations, instead of by payroll.

The decisive advantage is rarely price. It is time. A mature in-house SOC takes months to produce quality detection, because that maturity is built incident by incident.

What you lose, and how to compensate

It would be dishonest to treat the contracted model as a choice with no trade-off. You lose proximity and tacit knowledge of the environment: someone from outside does not know, in the first month, that a strange behavior is the routine of a legacy system.

This can be compensated, and the contract should specify how:

Onboarding with a survey of critical assets, known exceptions and what cannot stop under any circumstances.
An explicit authority matrix: who authorizes a containment action that takes a service down, and at what time.
A detection tuning cycle, with false positive reduction measured and reviewed.
One person on the client side as the decision point, even if they hold the role alongside other duties.

Without defined authority, the alert arrives quickly and the decision takes a long time, which cancels out the time gained through monitoring.

SOC, NOC and CSIRT are not the same operation

The confusion is frequent and gets in the way of sizing. The NOC takes care of availability and performance: the service is up and responding. The SOC takes care of threats: someone is trying to get in, escalate privileges or exfiltrate data. The CSIRT is the incident response team, called in when something has already happened.

They share tools and sometimes space, but they answer different questions. Contracting a NOC while thinking you are contracting a SOC is a common mistake, and it only shows up at the first incident.

The hybrid model, which is usually the real answer

In practice, the binary choice is a false one. The most common arrangement in mid-sized organizations is hybrid: continuous coverage and detection engineering come from outside, while decision authority, knowledge of the environment and the relationship with the business areas stay inside.

This design takes advantage of the scale of those who operate 24x365 without outsourcing the decision, which is precisely the part that should not leave the house.

How to compare proposals without fooling yourself

SOC proposals are hard to compare because each provider draws the scope differently. Questions that reveal what is and is not included:

Is response in scope, or only notification? Who carries out containment?
How many log sources are included, and what does it cost to add one?
What is the event retention period, and what happens to the history at the end of the contract?
Where is the data processed, and what happens if it cannot leave the environment?
How are false positives measured and reduced over the course of the contract?
What is the time commitment for triage and escalation, by severity?

The decision criterion

If the organization has the scale to sustain ten or more specialists on a continuous basis, and security is part of the product it sells, an in-house SOC is justified. In other cases, the useful question is not how much it costs to maintain, but how long it would take you to reach the same level of detection, and what the interval until then is worth.

While the operation does not exist, exposure does not wait for planning.

FAQ

What is the difference between an in-house SOC and SOC as a service?

An in-house SOC requires a team in three shifts, a correlation tool, detection engineering and threat intelligence, all maintained internally. As a service, you join an operation that already exists, with continuous coverage in place and an accumulated detection repertoire. The decisive difference is usually not price, but the time until you are actually protected.

How many people are needed for a 24x7 SOC?

It is shift arithmetic: a week has 168 hours and a standard schedule covers about 40, so keeping a single position staffed at all times takes a little over four people, and about five when you account for vacations, training and absences. Multiplying by the positions a real operation requires (triage, investigation, detection engineering and coordination), the minimum team rarely falls below a dozen.

Are a SOC and a NOC the same thing?

No. The NOC takes care of availability and performance, that is, whether the service is up and responding. The SOC takes care of threats: access attempts, privilege escalation, data exfiltration. They may share tools and space, but they answer different questions, and contracting one while thinking you contracted the other only shows up at the first incident.

What do you lose when you outsource the security operation?

You lose proximity and tacit knowledge of the environment, which can be compensated with onboarding of critical assets and known exceptions, an explicit authority matrix, a measured detection tuning cycle and a decision point on the client side. What should not be outsourced is the decision: whoever authorizes a containment action that takes a service down needs to be in-house.

What should you ask when comparing SOC proposals?

Whether response is in scope or only notification, and who carries out containment; how many log sources are included and the cost of adding another; the retention period and what happens to the history at the end of the contract; where the data is processed; how false positives are measured and reduced; and what the time commitment is for triage and escalation by severity.