What an operating model is — and is not
An operating model is not an organisation chart. The chart is one output of the model, and usually the last one to be drawn. The model starts from the services the security function provides to the rest of the business and works outward: the capabilities those services rely on, who should deliver each one, how much demand they face, and what people, technology and money that requires.
When organisations skip straight to the chart, they end up arguing about reporting lines while nobody can say which team owns vulnerability management for the cloud estate.
The seven components
A complete cybersecurity target operating model covers seven components, best grouped into three bands.
What the function does
- Service catalogue — the services offered, each with a consumer, an outcome, a service owner and service levels.
- Capability model — the capabilities the services depend on. A capability is not a service; one capability (say, threat intelligence) can support several services.
How it is delivered
- Sourcing — for each service, a scored decision between in-house, co-sourced and outsourced delivery.
- Organisation — the structure, roles and interfaces that deliver the in-house work and manage the providers.
- Sizing — the number of people needed, driven by demand figures rather than by benchmarks alone.
What it runs on
- Skills and technology — the competencies, tools and platforms each service needs.
- Funding and transition — the cost model, the funding route and a staged plan to move from today's state to the target.
Five principles that keep the model honest
- Structure follows services. Design the services first; the organisation exists to deliver them.
- Size follows demand. Volumes — alerts, assessments, access requests, projects — drive headcount. Peer ratios are a sanity check, not a method.
- A capability is not a service. Mixing the two produces catalogues that no consumer recognises.
- One accountable owner per service, whoever delivers it. Outsourcing moves the work, not the accountability.
- Every position and every cost traces to a service. If a role cannot be traced, question it.
How to run the design
Work through four phases. Mandate: confirm the strategy input, the function's role in the wider ecosystem, where it sits in the organisation and the design principles. Baseline: inventory current activities, people, skills and demand, and assess the health of each component. Design: build the service catalogue and capability model, score the sourcing options, size the teams and cost the result. Transition: plan the moves in stages, with dependencies, risks and the governance that will oversee them.
A one-page service card for every service — purpose, consumers, owner, sourcing, service levels, demand and cost — is the single most useful artefact. It is what managers keep using long after the design project ends.
Signs your current model needs redesign
- Two teams believe they own the same service, or no team believes it owns it.
- Headcount requests are argued on peer ratios with no demand data.
- Managed service contracts exist without a named internal owner.
- The security budget cannot be broken down by service.