Selecting the Right SOC Model for Your Organization

Selecting the Right SOC Model for Your Organization

Published 24 February 2020 – ID G00464962 – 22 min read

An SOC provides centralized security event monitoring and threat detection and response capabilities, and may support other security operations’ functions and business unit requirements. This research helps security and risk management leaders identify the best SOC model for their organization.


Key Findings

  • Security operations centers (SOCs) will fail in their mission without a clear target operating model, and if their deliverables are not tightly coupled to business use cases, risks and outcomes.
  • A hybrid SOC working with external providers is a credible option that is increasingly being adopted by many organizations, specifically midsize enterprises.
  • Organizations are increasingly interested in multifunction SOCs, extending SOC duties to incident response, threat intelligence and threat hunting, while adding OT/ICS/IoT in scope.
  • Building, implementing, running and sustaining a fully staffed 24/7 SOC is cost-prohibitive for most organizations.


Security and risk management leaders responsible for security operations should:
  • Develop an SOC target operating model, taking into account current risks and threats, as well as the business objectives, focusing on specific threat detection and response use cases.
  • Use managed detection and response (MDR) or other security services to offset the cost of 24/7 SOC operations and to fill coverage and skills gaps, tactically or as a long-term strategy.
  • Expand the SOC’s capabilities beyond just SIEM solutions to provide greater visibility into the IT, OT and IoT environment where appropriate, but do not expect a full SOC/NOC integration.
  • Likewise, plan for SOC functions beyond reactive incident monitoring and into threat detection and response, and even proactive threat hunting.

Strategic Planning Assumption

By 2024, 25% of all organizations will have an SOC function, up from 10% today. This will range from small part-time virtual SOCs to fully staffed full-time SOCs, to outsourcing of SOC services to an external provider, or a combination of these.


Security operations centers (SOCs) have historically been adopted by only very large organizations requiring centralized and consolidated security operations focused on security event monitoring, and threat detection and response, usually delivered 24/7.
This has changed, and SOCs are becoming more ubiquitous as organizations large and small shift security efforts from prevention only to a blend of prevention and detection.


Gartner defines an SOC as a construct with the following characteristics:
  • A mission, usually focused on threat detection and response.
  • A facility, dedicated to the SOC, either physical or virtual.
  • A team, often operating in around-the-clock shifts to provide 24/7 coverage.
  • A set of processes and workflows that support the SOC’s functions.
  • A tool or set of tools to help predict, prevent, detect, assess and respond to security threats and incidents.
However, the SOC does not always have to be a physical facility with hundreds of analysts working around the clock. Gartner has seen less mature, as well as resource-constrained organizations employ staff members to perform security operational functions on an ad hoc basis and remotely (that is, where there is a virtual SOC function being delivered). While SOC is the ubiquitous term, other terms such as cybersecurity operations center, cyber defense center and cyber fusion center are often used.
Gartner observes a renewed interest from incoming inquiries in merging both the NOC and SOC functions for economies of scale. Although a fully fused NOC/SOC approach is not a viable alternative at scale, the common set of functions between NOC and SOC needs to be identified, and a decision has to be made on where this function will live. At the very least, always improving coordination between the NOC and SOC needs to be encouraged.
An organization cannot buy an outsourced SOC. Outsourced services still feed into an organization’s own security operations regardless of how informal that may be. A hybrid SOC usually connotes an SOC where one or more of the core functions are performed using outsourced security services. It is the most common form of SOC across all organizations, as most organizations will leverage some types of security services (for example, reverse malware engineering is a common function).


SOCs’ main mission is focused on the following functions, with threat detection and response being the most common across SOCs. The SOC needs to be clearly aligned to its target operating model, as defined in “Create an SOC Operating Model to Drive Success.” If a set of functions is not delivered out of the SOC, this could indicate that these functions are performed by another internal structure, an external service provider or are not aligned to the organization’s security use cases:
  • Security event monitoring, detection, investigation and alert triaging
  • Security incident response management, including malware analysis and forensic analysis
  • Threat intelligence management (ingestion, production, curation and dissemination)
  • Risk-based vulnerability management (notably, the prioritization of patching)
  • Threat hunting
  • Security device management and maintenance (for the SOC technology stack)
  • Development of data and metrics for compliance reporting/management
Figure 1 describes the main functions of an SOC across all SOC models.

Figure 1. Modern SOC Components

Modern SOC Components
Depending on the functions and capabilities provided, a fully functional SOC running 24/7 requires at least eight to 12 full-time employees (see “How to Plan, Design, Operate and Evolve a SOC”). This does not include capacity for management, staff turnover, personal time off or other special activities like malware reverse engineering, forensics and threat analysis that may need to be performed by the SOC staff.
Ideally, an SOC should be located in a dedicated, physical environment (such as an isolated room) with heightened levels of physical access required. Due to the sensitive nature of incident investigations, as well as the potential for tampering with potential evidence and hiding malicious tracks, physical access to the facility needs to be restricted to authorized personnel only. The SOC’s infrastructure (network, systems, applications) should be isolated or segmented from the production network to prevent internal breaches affecting the operations of the SOC. Furthermore, the technology infrastructure used for monitoring and investigations within the SOC should be isolated and separated from the internet. Finally, the SOC will often have its own independent internet connectivity so that it can continue to operate and perform investigations even if the corporate network is, for example, under a distributed denial of service (DDoS) attack. Based on Gartner client inquiries, however, this is not always the case. Although some organizations build/manage SOCs with high levels of physical protection and isolation, as described above, most organizations opt for a traditional office environment and simple isolation measures.

SOC Models

Five main models of SOC have emerged, which can be mapped along the maturity of the SOC processes and workflows in an organization, as described in Figure 2.

Figure 2. Five Models of SOC

Five Models of SOC
These models are further described in Table 1 and the sections below.

Table 1: Five Primary Operational SOC Models for Typical Organizations

Enlarge Table
SOC Model
Typical Maturity of SOC Workflows
Main Attribute
When to Select
Virtual SOC
Very low
No dedicated facility
  • No dedicated facility available
  • Part-time and geographically distributed team members
  • Activated when an incident is discovered
Multifunction SOC
Low to medium
Simple SOC with IoT/OT/ICS and some 24/7 NOC
  • Dedicated facility with a dedicated team performing, not just security, but some other critical 24/7 IT operations from the same facility to reduce costs
  • Availability of some formalized processes and workflows
Hybrid SOC
Low to very high
Mixes internal resources and outsourced security services
Any SOC model can be qualified as hybrid when it uses outsourced security services
  • Dedicated and semidedicated staff, either internally or outsourced
  • Security operations can be performed by the organization’s internal staff 24/7, 8-5 on weekdays, or 8-5 every day with some responsibilities offloaded to an external provider
  • Primary model when fully delegated to an MSSP or an MDR
Dedicated SOC
Medium to high
Self-contained, in-house, dedicated 24/7 threat detection and response
  • Dedicated facility
  • Dedicated team
  • Fully in-house, 24/7 operations
  • Incident response, TH and TI functions and teams in place
Command SOC
High to very high
Manages and coordinates other SOCs and activities
  • Need to coordinate other SOCs
  • Coordinate response across all SOCs for major incidents
  • Provide threat intelligence, situational awareness and additional expertise
  • Rarely directly involved in day-to-day operations
Source: Gartner (February 2020)

Virtual SOC
A virtual SOC (vSOC) does not reside in a dedicated facility, nor does it have a common war room.
Instead, it is composed of team members who may have other duties and functions. Since there may not be dedicated tools for the SOC, like a SIEM, team members rely on available IT, and sometimes security technologies, and become active when a security incident occurs. In addition to a lack of SOC tools and SOC expertise, the lack of formalized processes and workflows for both the detection as well as the response phase is a typical attribute of a vSOC. Things are done reactively, ad hoc, using the available people and tools, usually on a best effort and nondeterministic way.
A vSOC is typically suited to smaller enterprises that experience only infrequent incidents and/or do not have resources for a more encompassing SOC. Sometimes an organization can only afford an IT person or a handful of people who can, on a part-time basis, review alerts generated by the firewall or an antivirus, or periodically review critical logs in support of a threat detection and response function.

Multifunction SOC
The defining attribute of a multifunction SOC is to bring IoT/OT/ICS in scope for the SOC, and/or to deliver on other critical 24/7 IT operations from the same facility to reduce costs.
This model is usually adopted by less mature organizations that need to deliver multiple use cases from the same facility, and that may not have dedicated expertise in IT, security and OT. These use cases are usually simple enough, both from the NOC as well as SOC standpoint, to be delivered by common tools and common people. However, factors such as politics, budget and process maturity levels can lead to staff members doing multiple things, but none of them well. NOCs adhere to the Information Technology Infrastructure Library (ITIL) definitions of incident and incident management, which is generally not the right approach to take in terms of security incidents. The ITIL’s focus is on events that cause a disruption of service, with the goal of restoring the service as quickly and efficiently as possible. Security and risk management leaders must never be distracted by this convergence or else it may affect the mission of the SOC and its ability to help securely deliver and enable business outcomes.
Organizations engaged in this model always start by mapping available telemetry, tools, and expertise, and defining common use cases, processes and workflows for the multifunction SOC (see “Align NetOps and SecOps Tool Objectives With Shared Use Cases”). These can include not only IT and security devices and users, but also IoT/OT/ICS.

Hybrid SOC
The defining attribute for a hybrid SOC is to mix both internal resources with outsourced ones, while leveraging external security services for the delivery of some or most of the SOC functions.
One or more dedicated people are responsible for ongoing SOC operations, involving semidedicated team members and third parties, as required. If an organization cannot operate 24/7, the resulting gap can be covered by a number of providers, resulting in a hybrid SOC model. These providers might include an MSSP (see “Magic Quadrant for Managed Security Services, Worldwide”), a managed detection and response (MDR) service provider (see “Market Guide for Managed Detection and Response Services”), a co-managed SIEM service provider, or sometimes a special security consulting provider or system integrator (SI) for such services as specialized incident response/forensics. Only large enterprises are able to afford and commit to dedicated, 24/7 internal SOCs. However, many organizations desire some form of internal security operations capability (although limited), even if they are using an external provider for a majority of their security monitoring needs.
The hybrid SOC model can reduce the cost of 24/7 operations. Therefore, it is well suited not only for small to midsize enterprises, and especially for those working extensively with third parties, but also to larger organizations and mature SOCs that can selectively outsource some security services.
Furthermore, it allows the organization to maintain stable security operations while internal capabilities are developed over time. During this time, any resource gaps can be filled, and existing security resources can shift their focus to other activities, such as deeper investigations of incidents. As such, this model is also adopted by organizations that have a desire to build insourced competencies but (1) need an immediate solution to their problem, (2) have limited expertise to be autonomous right away, and (3) want to leverage the security service provider for knowledge transfer and continuous expertise gathering.
Driving adoption of this model are a shortage and gap in the availability of skills and expertise, general budget constraints, and the considerable cost of 24/7 security operations. As an example, Gartner has seen increased interest in and adoption of co-managed SIEM services (see “How and When to Use Co-managed Security Information and Event Management”).

Dedicated SOC
The defining attribute of a dedicated SOC is to have a 24/7 centralized threat detection and response function, with a dedicated facility, IT, and security infrastructure and team, and robust processes and workflows. It is self-contained, possessing all of the resources required for continuous day-to-day security operations.
A fully centralized SOC is suited for large enterprises with multiple business units and geographically dispersed locations, sensitive environments, and high-risk, high-security requirements, as well as service providers that provide MSSs. Specifically, large enterprises choose to build, implement and run their own SOCs when:
  • Laws, regulations or governance issues prevent the outsourcing option.
  • There are concerns about specific/targeted threats.
  • Specialized expertise and knowledge about the business cannot be outsourced.
  • The organization’s technology stack is not supported by third-party security services.
Recently, Gartner is seeing large enterprises with a complex and distinct set of use cases and/or very widespread security mandates fusing traditional security operations with more contemporary functions. Examples of these extended use cases include, but are not limited to, threat intelligence, cyber incident response and OT/Internet of Things (IoT) security. There are, however, both advantages and disadvantages to doing this. For example, fusing incident response as part of the SOC will allow tighter integration between detection and response, and is an essential factor needed for security operational success (see “Prepare for the Inevitable With an Effective Security Incident Response Plan”). On the other end of the spectrum, it can create separation of duties conflicts and/or pull the security event monitoring resources away from the incident response tasks, thus affecting the effectiveness of the monitoring during an actual incident (see “How to Plan, Design, Operate and Evolve a SOC”).
Dedicated SOCs usually keep most functions in house and minimize security services. However, even large dedicated SOCs can outsource some very specific functions, such as reverse malware engineering. Strictly speaking, most dedicated SOCs are also very advanced hybrid SOCs.

Command SOC
The defining attribute of a command SOC is to support and manage several SOCs, and not be involved in day-to-day operations.
Very large and/or distributed organizations that have regional offices with a certain operating independence, service providers offering MSSs and those providing shared services (for example, government agencies) may have more than one SOC under their purview. Where these SOCs are required to run autonomously, they will function as centralized or distributed SOCs. In some instances, the SOCs will work together, but must be managed hierarchically. In those cases, one SOC should be designated as the command SOC. The command SOC coordinates security intelligence gathering, produces threat intelligence, curates and fuses these for consumption by all other SOCs, in addition to providing additional expertise and skills such as forensic investigations and/or threat analysis. Sometimes, this is how a computer emergency response team (CERT) functions in smaller countries where they are serving as an aggregation and coordination point more than delivering day-to-day security operations.

Benefits and Uses

Improved Threat Management
Many organizations already routinely implement and/or employ a variety of security technologies and services designed to prevent and detect threats, as well as harden and protect assets. When these solutions are managed in silos, organizations lose the opportunity to centrally consolidate, normalize, correlate and monitor these threats in real time, and will at best waste valuable time and resources, and at worst miss obvious threats that an SOC could have easily detected. Such a value is realized via the SOC as a delivery vehicle for a central point of reconciliation and management of these threats.
Reduction in MTTD and MTTR Incidents
Integrated security event monitoring gives the security operations team better visibility and enables it to correlate patterns and surface suspicious activities. Effective detection and escalation of incidents and close coordination between the individual teams within a defined workflow and process allow an organization to detect and respond faster, improving both mean time to detect (MTTD) and mean time to remediate (MTTR).
Centralization and Consolidation of Security Functions
Consolidating security functions in an SOC can provide cost efficiencies, enable cost sharing and leverage economies of scale while maximizing the available expertise, skills and resources. For larger organizations with a distributed geographical environment, especially those with local governance requirements, centralizing some security operations functions can help provide a centralized view, as well as a set of core security services, to all entities, while respecting local regulations.
Regulatory Compliance
An SOC is often the operational model of choice for large and some midsize enterprises to meet regulatory requirements mandating security event monitoring, vulnerability management and incident response functions. Furthermore, an SOC can improve compliance auditing and reporting across the organization, but an SOC would typically not be built for compliance-only use cases.

Adoption Rate

Gartner indicates SOC spending tends to be a significant percent of an organization’s total security budget (see “SOC Development Roadmap”) — 57% spend over 20% of security’s total budget on the SOC. However, clients seem to be split between insourcing or outsourcing their SOC (see “Setting Up a Security Operations Center (SOC)”). In addition, an increased spending in SOC is sustained by:
  • Maturing of information security programs
  • Centralization of incident detection, threat detection and response capabilities, as well as consolidation of security operations functions expanded throughout the entire organization
  • Current and future legislation and regulatory frameworks that mandate security event monitoring and detection and response capabilities (see “A Technical Solution Landscape to Support Selected GDPR Requirements”)
  • An increase in risks/threats via breaches and incidents
  • Growth of technology usage due to digitalization of business (see “Hype Cycle for Threat-Facing Technologies, 2019”)
  • Increased adoption of external service support for security event monitoring and device management
In 2019, Gartner saw a 39% increase of inquiries from clients requesting assistance on both building and maturing their security operations through the lens of an SOC. These clients have security operations functions that are either conducted by internal staff, supported by an external provider offering MSSs to offload some of the SOC functions from the organization internally, or provided in the form of regionally or vertically aligned shared services.


Lack of Improvement in Breach Response Efficiency/Capabilities
With threat management as a major driver for adopting an SOC, most will be judged by how they perform in that function and will be measured by the speed and efficacy of security event monitoring and threat detection and response.
Organizations adopting the SOC model should carefully evaluate how this investment translates to less frequent and severe breaches, and compare it to their own pre-SOC state. Furthermore, security technologies are not silver bullets. SOCs may become overwhelmed by the vast number of alerts generated by an expanding number of security tools. Although this is a common issue, there is no simple solution to avoid this quandary. After all, some organizations genuinely have a lot of malicious activity, which leads to alert overload. Better SIEM tuning to minimize noise, use of advanced analytics for better detection, and use of automation for alert triage and faster response are often used to reduce the alert flood.
Skills, Expertise and Staff Retention
Staff retention for SOC analysts is generally difficult. Even service providers that can offer a career path and progression struggle to keep their SOC analysts for longer than three to four years. As a result of the shift-based and repetitive work, in addition to a rare and sought-after skill set, the SOC analyst role is often seen as a steppingstone role. This trend is further exacerbated by a global shortage in available qualified staff (see “Adapt Your Traditional Staffing Practices for Cybersecurity”).
An understaffed SOC or one staffed with inexperienced analysts will be ineffective and will struggle to achieve its objective of rapid detection and response to threats and incidents, despite all the spend on technology and data collection. It will also increase analyst attrition if left understaffed for longer periods. To avoid starting an SOC project that can never succeed due to resource constraints, seek out alternatives such as MSSs or other forms of hybrid and outsourced security event monitoring, like MDR service providers. Alternatively, start with non-24/7 coverage and expand later when the resources are available.
Regardless of the SOC model implemented, Gartner recommends developing an SOC staff retention strategy from the start, as well as maintaining a continuous hiring capacity, which can help the organization maintain the SOC with the minimum, yet optimum staff required (see “Develop Existing Security Staff to Excel in the Digital Era”).
Return on Investment Demonstration
Security and risk management leaders need to understand that success is not just about achieving the security operations metrics, but also about the concurrently external metrics that align with the business. Important starting points are paying attention to what is your market, what is your message and what media you should use. For example, concerns over detection rates, open tickets per analyst and ticket closure rates are warranted. However, do not lose sight of the fact that the business is mainly concerned about addressing these questions:
  • Can we continue to deliver our products/services?
  • What competitive disruptions or players in our market will cause clients to shift from our products/services?
  • Are we conducting our activities legally?
For more information on aligning security metrics with business objectives, see “Develop Key Risk Indicators and Security Metrics That Influence Business Decision Making.”
To ensure your organization has the most appropriate security metrics, start with the end in mind and first develop tightly defined goals and metrics the SOC needs to deliver against that align to the business outcomes. Also, make sure that a sustainable budget is secured for the first two to three years of the SOC operation. It will often take this amount of time for people, processes and technology to be integrated into your organization and delivering at a reasonable level of proficiency.


Security and risk management leaders involved in incident monitoring, threat detection and response, and/or other adjacent security operations functions (such as threat hunting and threat intelligence) should benefit from efficiencies by formalizing all relevant duties within a security operations center. This SOC will then:
  • Gather and centralize required security personnel. These can be present either physically or virtually, and can belong to the organization’s security, operations, IT or network teams, or belong to a service provider. Likewise, these resources can be assigned on a full-time or part-time basis.
  • Define repeatable and automatable processes and workflows. These will depend on the scope of the SOC and should tend to address not only threat detection but also response. When an outside service provider is involved, it is then particularly important to define the “who is doing what, when” by using a responsible, accountable, consulted, informed RACI matrix to define roles and responsibilities, and expose integrations and communications between the client and the service provider.
  • Appropriately implement tools. Depending on scope, these tools (which can include, for example, CLM, SIEM, SOAR, SIRP or ITSM) should be selected and implemented to not only support current SOC requirements, but also current or planned SOC scope creep beyond security. This includes, for example, supporting the IT operations team and its NOC, or the ICS owners and their IoT ecosystem.
The scope of the SOC can then be defined along the following two dimensions:
  • Breadth of scope. As an example, does the SOC address only a subset of the infrastructure, or a subset of the user population, entire BUs or even the entire organization?
  • Depth of scope. As an example, does the SOC address basic, best-practice cyber-hygiene use cases, or does it address more complex use cases such as advanced persistent threat (APT) or insider threat? Does it include the IoT ecosystem, and does it deliver some NOC services as well?
Based on the scope of the SOC along these two dimensions, available expertise and resources, and strategic appetite for insourcing versus outsourcing, organizations can engage in an SOC initiative using one of the models described in this research note.

Note 1ITIL 4 Incident and Incident Management Definitions

The definition of “incident” was revised in ITIL 2 as “an event which is not part of the standard operation of a service and which causes or may case disruption to or a reduction in the quality of services and customer productivity.” Failure of one disk from a mirror set would fall in this category. ITIL 4 refers to incident management as a practice, describing key activities, inputs, outputs and roles. The primary objective of the incident management ITIL process is to return the IT service to users as quickly as possible.

Leave a Reply