Preview · selected sections of Cybersecurity Operating Model v1.0
1. Purpose and scope
A cybersecurity operating model answers five questions in order, and it is only credible if it answers them in that order:
-
What is the function for, and where does it sit in the organisation and its wider ecosystem?
-
What services does it deliver, to whom, and which capabilities stand behind each one?
-
How is each service delivered — performed in-house, shared with a partner, or bought?
-
What organisation, sized to what demand and holding what skills, runs it?
-
What does it cost, what enables it, and how does the organisation get there from where it is today?
Most operating models fail on the second and fourth of these. They begin by drawing boxes — an organisation chart negotiated between existing managers — and then look for work to put in the boxes. And they size those boxes by ratio: a headcount per thousand employees, or a percentage of IT, copied from a survey whose population looks nothing like the client. This method removes both failure modes: structure follows services, so no unit exists without defined work; and size follows demand, so every position can be explained from the work it performs.
1.1 Scope
The method covers the full arc from mandate to an approved, costed transition plan. It deliberately uses, rather than repeats, the work of its two companion guides:
-
Upstream — strategy. The vision, themes, goals and initiatives come from the cybersecurity strategy. Where an initiative creates a standing capability or service, that is a demand the operating model must absorb. The operating model does not set security direction; it organises the function to deliver it.
-
Downstream — governance. The service catalogue, organisational units and roles produced here are what the governance model builds its decision rights, RACI, interactions, procedures and performance measures on. The operating model names who does the work; the governance model defines how that work is directed, controlled and held to account.
Nor does the method cover job evaluation, grading or recruitment. It produces role profiles, grade bands and a list of positions; Human Resources evaluates, grades and recruits against them under its own policies.
1.2 Who does what
| Role | Responsibility in this method |
|---|---|
| Operating model owner typically the CISO |
Owns the mandate, the design principles and the target model. Approves the service catalogue, the structure and the sourcing decisions. Presents the headcount and funding request. |
| Design lead the consultant or internal lead |
Runs the baseline, facilitates the design workshops, performs the sizing and costing, and maintains the artefacts and their cross-references. |
| Service owners | Define their services, supply demand figures and effort estimates, and validate the service levels they will be held to. |
| Human Resources | Supplies workforce data, organisation design rules, grade structure, salary cost assumptions and localisation obligations. Validates role profiles and the position transition map. |
| Finance | Validates the cost assumptions and the capital / operating expenditure split. Confirms the funding envelope. |
| Procurement / vendor management | Advises on the provider market, existing contract terms and notice periods. Uses the sourcing decisions as procurement scopes. |
| Technology and architecture | Owns the tools and shared IT services the security function depends on. Validates the technology requirements. |
| Business stakeholders | Consume security services. Supply demand data and confirm service-level expectations. |
| Governing body | Approves the mandate, the reporting line, the headcount and the funding envelope. Receives transition progress. |
3. The method at a glance
The work runs in five phases. Each phase produces artefacts the next phase uses; nothing later in the sequence can be completed honestly without what comes before it.
The phases are not strictly serial in practice — demand data is usually collected while the service catalogue is being drafted, and the structure options often surface sourcing questions — but the dependencies are real. Units cannot be drawn before services exist. Positions cannot be sized before demand is measured. Costs cannot be stated before the sourcing mix is decided. A team that draws the organisation chart first and then writes service descriptions to fit it has produced a reorganisation, not an operating model.
3.1 The operating model framework
The method designs seven components, arranged in three bands. The strategic mandate sets what the function is for. The operating model proper — four components — describes how it works. The enabling ecosystem — two components — sets the conditions it works within. Every component is designed; none is assumed.
Each component carries a design question. The question is the brief for that component, and the component is complete when the question has an evidenced answer in the artefacts.
| # | Component | Sub-components | Band | The design question it answers |
|---|---|---|---|---|
| 1 | Mandate and positioning | Role in the ecosystem · Position in the organisation · Vision statement · Strategic objectives | Strategic mandate | What is the function for, who does it serve, and where must it sit to do that with the authority it needs? |
| 2 | Services and capabilities | Service catalogue · Delivery model · Capability model | Operating model | What does the function deliver, what must it be able to do, and who performs each service? |
| 3 | People and organisation | Organisational structure · Organisational sizing · People skills | Operating model | How is the work grouped, how many people does it take, and what must they be able to do? |
| 4 | Technology | Technology requirements · Supporting technology platforms | Operating model | What must the tools do for each service, and on what platforms do they run? |
| 5 | Governance | Governance model · Policies and standards · Performance metrics | Operating model | How is the function directed, controlled and measured? (Designed in detail by the Cybersecurity Governance Model guide.) |
| 6 | Legislative and regulatory environment | — | Enabling ecosystem | Which obligations does the function exist to satisfy, and which constrain how it may be organised and sourced? |
| 7 | Funding | — | Enabling ecosystem | What does the model cost to run and to reach, and how is that cost carried and allocated? |
3.2 Working formats
Every artefact in this method can be produced with Word and PowerPoint. As a rule of thumb, anything with rows that will be cross-referenced is a Word table; anything that will be presented or needs to be seen as a whole is a PowerPoint slide. Where sizing and costing become large, a simple spreadsheet is a convenience, not a requirement.
| Kind of artefact | Suggested format | Tips |
|---|---|---|
| Registers (services, roles, drivers, constraints) | Word table, one row per item | Give each row a simple sequence number so other tables can refer to it. |
| Matrices (service × capability, person × skill) | Word table, ticks or levels in cells | Put the longer list down the side; landscape pages help. |
| Structures and diagrams | PowerPoint slide | Use the figures in this guide as the starting layout. |
| Sizing and cost workings | Word table — or a spreadsheet if large | Show every assumption in its own column so it can be challenged. |
| Decisions and options | PowerPoint slide for the workshop; Word paragraph for the record | Record the option chosen and the reason beside the options rejected. |
| Final document | Word | Section order in section 10; workshop slides go in the appendix. |
That is the preview. The full publication continues with 12 more sections — every phase summary, checklist, figure, quality check and appendix — available under licence.
Buy the full method