SOC Models: In-House, Out-Sourced, or Hybrid SOC?

There’s no single perfect, one-size-fits-all SOC model. Leaders are still unsure whether to bring the SOC in-house, get it outsourced, or do a mix of these two approaches (the so-called hybrid SOC). How do you choose? Investing now in the right model (with adaptability and portability as key considerations) might not be glamorous, but it will set you up for success in the future. Let’s run through the many factors that play a role, and share best practices from your peers from our roundtable held at Gartner Security & Risk Management Summit 2023.

In-House, Outsourced, Hybrid – What’s the Difference?

In-house: The SOC is run in-house. This option requires in-house headcount and talent, set-up investment and technical investment. However the SOC has the organisational context, autonomy, and the mandate to make changes.

Outsourced: The SOC is run by a third party, external to the organisation. Often used to provide a level of service (such as 24/7 coverage, or a higher capability level) that in-house talent can’t support, it usually requires the least organisational effort to set up, and is a great solution for smaller organisations who wish to benefit from specialist expertise. Importantly, this model does not outsource the risk — an old misconception that is thankfully fading.

Hybrid: A mix of in-house and outsourced. Seen often during a transition period between the two models, but increasingly as a permanent state, because requirements are too specialised or too intensive for a fully in-house model (e.g. forensics, incident response, 24/7) but security is seen as too important to outsourced fully. Another common hybrid approach outsources L1 tasks and admin maintenance, alongside in-housing deeper analytical investigations. 

Just Eat’s Approach

At Gartner Security & Risk Management Summit 2023, Splunk hosted a roundtable discussion featuring the story of Neal Potter and Richard Fawcett from Just Eat, who decided to in-house their SOC after deciding the capability of their outsourced solution was too low, and the risk was too high. The MSSP did not adapt to their technology and technical architecture changes, and the MSSP constantly asked one question more than any other: “what does this mean?” This lack of adaptation and organisational context was reducing security capacity and creating intolerable risk for Just Eat.

After some careful investigation on the cost (meaning financial cost, but also the “human tax” of time, skills resource required and effort), balanced against the huge reduction in risk, Neal and Richard decided to in-house their SOC. Of course, they used Splunk because of all its amazing functionality, but that’s not really the point of this discussion. Interestingly, it was also cheaper than their previous outsourced solution.

Neal’s priority was prioritisation. This “makes people happy,” avoids burnout and helps with their talent needs: “give folks the right tools and it becomes a nice place to work — it gives them freedom.” To build this vision, Richard had few guiding engineering principles, and top-of-mind was ‘simplicity’ paraphrased as “my mum should be able to do it.” Rest assured if this sounds like a gendered diminutive, it wasn’t; Richard genuinely tested the systems out on his mother, and took her out to dinner as a thank you. And now his mum can investigate insider threats and fraud. Everyone wins.

Of our attendees, there was an even split between those who have the SOC in-house, outsourced or hybrid — a third of each — which made for a great mix of perspectives and conversations, summarised below.

The In-Housers

Internal SOC teams have the most organisational context and, due to their mandate to make changes, they reduce remediation time. Many attendees remarked that updating an MSSP and ensuring they are in the loop was more or less the same work as doing it all in-house, and that time investment would be better spent on their own employees. My view is that mandate matters: does your organisational risk posture allow the MSSP to do remediations? And if not, can your team handle all the tickets that the MSSP creates?

On the flip side, talent constraints are a big issue when in-housing the SOC. It’s hard to hire, retain and avoid burnout, and outsourcing can help to provide capabilities beyond your talent’s reach, like a 24/7 SOC. One attendee challenged this, saying when they really looked into it, they didn’t need 24/7 capability, and instead they just do on-call. Another said it wasn’t worth the hassle of dealing with an external party, so even without the headcount for a 24/7 service, they shifted the SOC in-house and found it better for morale, risk management and security outcomes. In short: your context is important and greatly affects your ultimate decision.

The Outsourcers 

Attendees said that MSSPs often have a sales pitch that "they do everything," but in this organisation’s reality they were just opening tickets for the organisation to close (again, because they lacked the context and permissions to take action) — ultimately adding to in-house workload. One even described their provider as a “TSSP” — a ticketing security service provider. 

But is this the fault of the MSSP or that of the organisation? Even with an outsourced SOC, you need internal security leadership and responsibility to form a true partnership. One attendee found that this ownership and recalibrating the MSSP relationship (sharing context and opening communication) unlocked the MSSP’s fantastic know-how and vastly improved outcomes. Another advised having an expert for MSSP contracts, who can get up-front definitions of SLAs, and actively manage RFPs, to unlock this potential faster by defining clear expectations and interlocks.

I also believe that tolerance for MSSP-originated errors is much lower than for in-house errors, with many seeing MSSPs as an “added risk,” forgetting to balance against the risk from having the same function provided by in-house staff.

The Hybrids

Hybrids cover many approaches, but one of the most common models is neatly summarised as “no single person can learn everything” — to this end, many have outsourced various support services to complement their in-house SOC. As “the reality of the SOC is that you need more than just security people,” outsourcing alone was not an option for some attendees either; security engineers and project managers had to be in-house. 

Other models include (but are not limited to) where organisations outsource specialist functions, bring in consultants for high-level strategy, leverage MSSPs to cover lower-skilled tasks and tiers, or use third parties to architect and set up the tooling that is run in-house. 

In our discussion, the hybrids started solely in-house or outsourced, then brought in the other complementary part, rather than developing both in parallel. Starting the SOC in-house, one attendee went hybrid to provide 24/7 coverage and deep detection engineering knowledge. Another started outsourced, and began in-housing when their talent constraints eased.

Making Your Choice and Communicating it Well

I’ve seen all types of models work very well and very poorly. It’s not the case that choosing one approach guarantees an amazing SOC, but there are some common success factors. My advice is, whichever model you have:

• Be clear on responsibilities and mandate from the start between your organisational teams, and any third parties involved.
• Define a lead in your organisation who owns the SOC and manages any third parties.
• Prioritise which capabilities are truly necessary, and define critical services.
• Consider portability and staff training needs from the start, so that you are never starting from scratch if you change models (or MSSP).
• Define protection levels and SLAs that can be benchmarked. It’s vital to ensure that the metrics for the service drive the correct behaviours, and can help to allocate budget (in-house) or define payments (outsourcing).

Whatever your decision, think about how you communicate that choice upwards. Boards and CxOs understand money, loss and reputation — so speak in those terms, and centre around risk to get your message across. Participants variously used storytelling of particular scenarios, impact on customer satisfaction, and turnaround times of incidents to explain the reputational risk and communicate their choices.

Conclusion

I repeat what I said at the start: there’s no single perfect, one-size-fits-all SOC model. You have to consider talent constraints, costs, time, risk, distribution of responsibilities, and many other factors. A common “tipping point” seems to be when risk becomes unacceptable, in many forms, including a lack of coverage, poor capability levels, or personnel issues - or just around contract renewal times.

But don’t wait until a tipping point to make a change; open the dialogue now on what’s not working and what is (un)acceptable risk.