How To Build A Security Operations Centre Operating Model

Too many organisations try to buy their way to a security operations centre. As one NCSC security architect put it, they chase the fanciest software “with laser dragons and security badgers” and hope it solves everything.

A SOC is a capability, not a room full of screens or a stack of licences. It exists to detect and respond to the threats your organisation actually faces, across the assets that matter most to the business.

That’s why the operating model has to come first. You can’t sensibly decide what to outsource, automate or buy until you know what capabilities you need.

In this article, we’ll explore what a SOC operating model is, how to design one around your threat profile, and where people, governance and technology fit in.

What Is A SOC Operating Model?

A SOC operating model describes the security operations capability your enterprise needs. It covers the threats you’re defending against, what you’re monitoring, which functions you need, who delivers them and how the whole thing is governed.

There’s no universal template. The UK’s National Cyber Security Centre (NCSC) deliberately avoids prescribing a single SOC design and instead calls the target operating model the foundation everything else is built on. Services like threat intelligence, threat hunting and incident response follow from it.

MITRE reaches the same conclusion from a different direction. Its 11 Strategies of a World-Class Cybersecurity Operations Center notes that thousands of SOCs exist worldwide, no two organised exactly alike, and that what works for one organisation may fail in another.

Where the two frameworks differ is emphasis. The NCSC organises its thinking around proportionality: build what your threat profile justifies. MITRE leans harder on organisational structure, offering a spectrum of models from “security as an additional duty” in small businesses to centralised, federated and national SOCs.

Both agree on one thing. The design has to start with your organisation, not someone else’s blueprint.

The NCSC is also honest about timescales. A target operating model is exactly that, a target, and it may take years to implement it fully. The guidance says it should be pragmatic and achievable, but built with growth in mind.

Start With The Threat

Your SOC’s capabilities should be proportionate to the threat you face. That makes defining your threat profile the first job in the design process, according to the NCSC.

The guidance gives a simple example. A small retailer and a large retail bank face very different threats, and only organisations with an extremely high threat profile need a SOC capable of catching the most sophisticated attackers. The NCSC suggests using STIX’s scale of threat actor sophistication to make an honest assessment, and says it’s fine to start with lower capability and grow.

Next comes scope. Few SOCs can monitor an entire estate at the same depth, so the NCSC recommends identifying your most critical assets and the business context they sit in. That means:

• Building a baseline of normal activity, including user and data flows
• Threat modelling the most sensitive parts of your systems
• Assessing the impact of compromise, because even small systems can cause outsized damage

The NCSC’s threat modelling process ends with identifying the log sources you need, which then shape your detection use cases. It also stresses that the model should be revisited as systems and threats change.

MITRE frames this as “know what you are protecting and why”. Its guidance asks SOCs to build awareness across the business mission, the legal and regulatory environment, the technical and data estate, normal user and service behaviour, and the threat itself.

Cloud adoption complicates scope without changing the principle. The NCSC argues that lift-and-shift migrations don’t reduce the need for a SOC, but services built cloud-native and secure by design may not need a “full-” one. Cloud provider monitoring and operations teams can cover some of the ground instead. The gap between cloud security and the SOC is exactly where scope decisions get messy.

Map The Capabilities Your SOC Actually Needs

Once you know the threat and the scope, you can decide which functions the SOC needs. The NCSC suggests organising the model into four pillars:

• Informing the SOC: threat intelligence that directs what the SOC looks for. In smaller SOCs this might just be a third-party feed.
• Developing capability: turning intelligence, requirements and analyst ideas into working detections, plus the engineering that keeps them running.
• Detect and respond: handling anything abnormal, suspicious or malicious, including incident response and incident management.
• Supporting the SOC: functions like system onboarding and stakeholder relationships.

Each pillar feeds the next. The NCSC warns that silos between them stop a SOC from maturing.

Core SOC Functions

Within those pillars, the NCSC lists the most common core functions. Threat intelligence provides information on current threats. Threat hunting proactively looks for attackers who’ve slipped past existing controls. Content development (often called detection engineering) turns intelligence into detection rules.

Engineering maintains the tooling and onboards log sources. Incident response investigates events and decides whether to escalate. Incident management takes over confirmed incidents, coordinating everything from communications to containment.

Some organisations add more. Vulnerability management needs very different skills and tools. Insider threat monitoring needs its own segregated tooling, the NCSC says, because SOC staff could themselves become subjects of an investigation.

Capability Is Cumulative

This is the bit organisations often miss. The NCSC describes SOC capability as cumulative: if you expect sophisticated adversaries, you need every capability beneath that level too. Threat hunting without mature use-case development is building on sand.

MITRE agrees. It recommends expanding into hunting, purple teaming, deception and forensics only once incident response is mature.

Finding the Right People

The NCSC calls finding the right people potentially one of the biggest constraints on any operating model. It’s also where the “target” nature of the model becomes obvious, because hiring and training take time.

The guidance warns against pigeonholing analysts into isolated tasks. That leads to triage fatigue, poor job satisfaction and, ultimately, poor security. Instead, it recommends rotating analysts across threat intelligence, content development and incident handling so they understand the full detection lifecycle.

MITRE is blunt about the market. There aren’t enough cybersecurity professionals, so SOCs must grow talent internally and plan for turnover by formally capturing institutional knowledge.

Coverage Is An Operating Model Decision

Hours of operation are a design choice, not a default. The NCSC notes that a 24/7 SOC needs significantly more staff than a 9-5 operation with on-call cover, and that a 9-5 SOC still beats having no SOC at all.

It also raises a question many organisations skip. A 24/7 SOC loses much of its value if the IT teams it needs during an incident only work office hours. Options include routing high-priority out-of-hours alerts to an existing 24/7 IT team for initial triage, or paging on-call analysts automatically.

Governance Gives The SOC Its Authority

A SOC without authority is just an alert factory. MITRE recommends a SOC charter, signed by executives, that sets out the SOC’s function, scope and authority to procure resources and enact change. It notes the SOC most commonly sits under the CIO or CISO, though other placements are possible.

The NCSC adds that governance must keep the SOC operating legally and within policy, and stop its powers being misused. Its example will be familiar to many SOC leaders: someone asking what a particular employee was doing all day. Whether that’s the SOC’s job depends on your requirements, but answering it diverts resources from detecting threats.

The NCSC suggests documented operating principles covering lawful operation, limits on searching sensitive data, and data retention. It also recommends treating the SOC itself as a high-value target, with segregated services, separation of duties and auditing of SOC staff actions.

Metrics belong in governance too. MITRE splits SOC metrics into three groups: those for internal SOC use, those showing value to stakeholders, and wider security insights that fall outside the SOC’s mission. It warns that choosing the wrong measures can waste time or actively encourage harmful practices.

Continuous improvement closes the loop. The NCSC points to three pressures that never stop: a changing organisation, a changing threat landscape, and detections that decay without maintenance.

Where Technology And Outsourcing Fit

The NCSC recommends mapping each function’s inputs, processes, outputs and dependencies, using a model like SIPOC, before establishing technology requirements and choosing tools. 

Only then does the conversation about SIEM, XDR or SOC automation make sense. It’s the same logic behind building SIEM use cases around business goals rather than features. MITRE’s guidance similarly treats tools as something that should support analyst workflow, not define it.

Outsourcing follows the same rule. The NCSC observes that most SOCs outsource something, even if it’s only detection signatures.

In-house functions bring better business context. Outsourcing can make sense for functions that are rarely used or that the SOC lacks resources to deliver.

The trade-off is context. The NCSC’s own blog notes that external SOC analysts may lack knowledge of your architecture and may respond more slowly than an internal team.

That’s precisely why the operating model comes first. Which capabilities stay internal, which go to a provider and which are shared is a separate decision, and one we unpack in our guide to SOC sourcing: build, buy or blend.

The organisations that get security operations right aren’t the ones with the most tools. They’re the ones that know exactly what their SOC is for.