Security Operating Model and Organisation Design

Most security functions were never designed: they grew one hire, one tool and one audit finding at a time, and the result is unclear ownership, duplicated effort and gaps that nobody is accountable for. A security operating model is the deliberate answer. It sets out what the security function is for, how it is structured, who decides what, which services it provides to the rest of the organisation, how it is funded and how its performance is judged. This guide compares centralised, federated and hybrid models, explains when the Business Information Security Officer (BISO) role helps and when it adds a layer, weighs the main CISO reporting lines, and gives a phased approach for redesigning the function without losing control during the change. It is written for CISOs, heads of security and the COOs, CIOs and HR partners who work with them on organisation design.

Key takeaways

Design decision rights before boxes. The org chart is the last step; first agree who sets policy, who accepts risk, who builds and runs controls, and who gives independent assurance.
No model is best in general. Centralised suits smaller or tightly regulated organisations, federated suits diverse business units with their own technology, and most large organisations end up hybrid: central standards and platforms, embedded delivery.
BISOs are translators, not mini-CISOs. They work when they carry a clear mandate, a dotted line to the business and a solid line to the CISO; they fail when they become a second, unfunded security team.
Reporting lines matter less than access and independence. Regulators and governance codes ask for clear ownership, regular two-way dialogue with the board and the ability to escalate; the UK Cyber Governance Code of Practice asks for formal reporting at least quarterly.
Identity ownership is where models break first. Human access usually has an owner; service accounts, API keys and AI agents often do not, so assign non-human identity ownership explicitly in the model.

What a security operating model defines

An operating model is the bridge between strategy and day-to-day work. It is wider than an org chart and narrower than a strategy. A useful test: a new joiner, an auditor or a business unit leader should be able to read it and know where to go for a decision, a service or an escalation. NIST CSF 2.0 places this work in the Govern function: GV.RR-01 (leadership is accountable for cybersecurity risk), GV.RR-02 (roles, responsibilities and authorities are established, communicated, understood and enforced), GV.RR-03 (adequate resources are allocated) and GV.RR-04 (cybersecurity is included in human resources practices).

Component	The question it answers	Typical artefact
Mandate	What is security accountable for, and what is explicitly outside its remit (for example physical security, fraud, privacy, business continuity)?	Security charter approved by the executive committee or board
Structure	Centralised, federated or hybrid; which teams exist; where they sit	Organisation design document and org chart
Decision rights	Who sets policy, approves exceptions, accepts risk and signs off architecture	RACI or decision rights matrix; delegation of authority
Service catalogue	What the function provides, to whom, at what service level	Catalogue with intake routes and service levels
Sourcing	What is done in house, by a managed service provider or by the business	Sourcing map, contracts with security schedules
Funding	Central budget, chargeback or business-funded embedded roles	Budget model and allocation keys
Interfaces	How security works with IT, engineering, risk, legal, privacy, procurement, HR and internal audit	Interface agreements, joint processes
Performance	How the function shows it is working	Metrics pack, risk reporting, maturity assessment

For the budget side of the model, see the Security Budget and Investment Planning Guide.

Centralised, federated and hybrid models

The structural choice is about where security people sit and who directs their work day to day. It is separate from the question of who sets standards, which almost always stays central.

Model	How it works	Strengths	Weaknesses	Fits best
Centralised	All security staff report into the CISO; business units consume services	Consistent standards, clear accountability, efficient tooling, easier career paths	Distance from business context; can become a bottleneck; seen as a cost centre that says no	Small and mid-sized organisations; single-product companies; heavily regulated firms with one regulator
Federated (decentralised)	Business units or regions employ their own security teams; a small central team sets policy	Close to the business, faster local decisions, funded by those who benefit	Inconsistent controls, duplicated tools, weak visibility for the group CISO, uneven skills	Conglomerates and holding groups with autonomous subsidiaries and separate technology stacks
Hybrid (hub and spoke)	Central hub owns strategy, policy, shared platforms (SOC, IAM, vulnerability management) and assurance; spokes embed in business units	Shared platforms at scale with local context; clearer path for BISOs	Matrix reporting tension; needs strong decision rights to avoid disputes	Large enterprises with several business lines on partly shared infrastructure
Product-aligned	Security engineers embed in product or platform teams; central team provides paved roads and guardrails	Security built into delivery; scales with engineering	Hard to keep independent challenge; risk of embedded staff going native	Software and digital-first organisations

Choosing between them

Count the technology estates, not the business units: if every unit runs on the same identity provider, cloud tenancy and SOC, a federated model mostly duplicates cost. Separate estates argue for embedded capability.
Follow the regulatory perimeter: if a subsidiary has its own licence or supervisor (a bank in a group, a regulated utility), it usually needs a named accountable security lead locally, even inside a centralised model.
Check the shared platforms first: identity, logging and detection, vulnerability management and secrets management give the largest economies of scale when central. Keep them central unless there is a strong reason not to.
Size changes the answer: under roughly a few dozen security staff, a federated model rarely has enough people in any one unit to be resilient. Large groups that acquire often run federated for acquired companies and converge later; see the Cyber Due Diligence in Mergers and Acquisitions Guide.

The BISO and other embedded roles

The Business Information Security Officer is a senior security leader aligned to a business unit, region or major function. The role is not defined by any standard, so organisations must write the mandate themselves.

What a BISO does: translates business plans into security requirements and security risk into business language; owns the unit's risk register entries; brings security into product and investment decisions early; represents the unit at the security leadership forum; and tracks remediation commitments.
What a BISO should not do: run a parallel security operations team, buy tools outside the central architecture, or approve their own exceptions.
Reporting: the common and most stable pattern is a solid line to the CISO (for standards, career and independence) and a dotted line to the business unit leader (for priorities and context). The reverse makes the BISO a business employee with a security title, which weakens challenge.
Funding: business-funded BISOs win sponsorship but can be cut first in a downturn; centrally funded ones are more independent. Write the funding source into the charter.
Related roles: security champions in engineering teams extend reach without headcount (see the Security Champions Programme Guide); security architects or engineers can be embedded in product teams; deputy CISOs cover the CISO's operational load.

When not to create BISOs: if the business units are small, share one technology estate and already meet the CISO regularly, a BISO layer adds cost and slows decisions. A relationship manager role inside GRC may be enough.

CISO reporting lines

There is no regulatory requirement in the sources checked for this guide that the CISO report to any particular executive. What governance codes and rules do ask for is clear ownership, adequate expertise and a working relationship with the board. The US SEC requires listed companies to describe in Form 10-K the board's oversight of cybersecurity risk and management's role in assessing and managing material cybersecurity risk, including the relevant expertise of those managers (Regulation S-K Item 106). The UK Cyber Governance Code of Practice, published 8 April 2025, asks boards to establish a cyber governance structure with clearly defined roles, including cyber ownership at executive and non-executive level, to require formal reporting at least quarterly, and to maintain regular two-way dialogue with senior executives including the CISO or equivalent. Recital 137 of the NIS2 Directive says management bodies should approve cybersecurity risk-management measures and oversee their implementation.

CISO reports to	Advantages	Risks	Mitigations
CIO or CTO	Close to technology delivery; easy to influence architecture and operations	Conflict when security findings criticise the CIO's own estate; security budget competes with IT projects	Direct access to the audit or risk committee; separate security budget line
CEO	Visible mandate; security treated as a business risk	CEO bandwidth; CISO may lose operational leverage over IT	Strong interface agreement with the CIO; joint objectives
COO	Links security with operational resilience and continuity	Less technical sponsorship	Architecture authority via a design review board
CRO or General Counsel	Independence; risk and legal framing; often used where security acts as a second line	Distance from engineering; security seen as compliance	Operational security engineering stays in IT with a dotted line to the CISO
CFO	Budget discipline; fraud alignment	Risk of cost-only view of security	Risk-based investment cases; board committee access

Whatever the line, write down three things: the CISO's right of direct access to the board or its risk or audit committee, who can overrule a security decision (and how that is recorded), and how disclosure and incident escalation decisions are made so they never rest on one person. For board reporting, see the Board Cyber Risk Reporting Guide; for the personal exposure of the role, the CISO Personal Liability Guide.

Three lines and where security sits

The Institute of Internal Auditors' Three Lines Model (2020, updated 2024 and since superseded by a newer IIA Statement of Position) separates management roles that own and manage risk, roles that provide expertise, monitoring and challenge, and internal audit, which gives independent assurance. Security functions often sit awkwardly across the first two.

First line activities: running the SOC, operating IAM and PAM platforms, patching, configuring cloud controls, secure engineering. These are management activities even when the security team performs them.
Second line activities: setting policy and standards, risk assessment, control testing, exception review, reporting risk posture to the risk committee.
Third line: internal audit reviews both. See the Internal Audit for Cybersecurity Guide.
The design choice: large and regulated organisations often split a technology risk or cyber risk oversight team (second line, under the CRO) from the CISO's operational function. Smaller organisations combine them but should at least separate control testing from control operation so no team marks its own homework.

Capabilities, services and sourcing

Map the capabilities the function must provide before deciding team boundaries. The NICE Framework (NIST SP 800-181 Rev. 1, with components currently at version 2.2.0) gives a common vocabulary of work roles, competency areas and Task, Knowledge and Skill statements, which helps when writing job descriptions (SP 800-53 PS-9 Position Descriptions) and skills plans (PM-13 Security and Privacy Workforce).

Capability	Usually central	Often embedded or federated	Common sourcing
Strategy, policy and standards	Yes	Local procedures	In house
Governance, risk and compliance	Framework, risk register, regulatory interface	Business unit risk owners, BISOs	In house with audit support
Security architecture	Reference architectures, design authority	Solution-level reviews	In house
Identity and access management	Identity platforms, PAM, NHI and secrets standards	Application access owners	In house, platform vendors
Security operations and incident response	SOC, threat intelligence, IR lead	Local responders, crisis teams	Often MDR or co-managed SOC
Vulnerability and exposure management	Scanning platform, prioritisation rules	Remediation by asset owners	In house or managed
Application and product security	Tooling, paved roads, testing standards	Embedded engineers, champions	Mixed; testing often outsourced
Cloud and platform security	Guardrails, landing zones, posture management	Platform teams	In house
Third-party risk	Method, tiering, register	Relationship owners	Questionnaire services
Awareness and human risk	Programme, phishing simulation	Local delivery	Platform vendors

Outsourcing a capability does not outsource accountability: name an internal service owner for every managed service. See the Co-Managed SOC and SOC-as-a-Service Guide.

Decision rights and the RACI

A short decision rights matrix prevents most operating model disputes. Keep it to the ten or so decisions that cause friction.

Decision	Accountable	Responsible	Consulted	Informed
Approve security policy	Executive committee or board risk committee	CISO	Legal, risk, BISOs	All staff
Accept a risk above appetite	Business owner at the delegated level	Risk owner	CISO, CRO	Risk committee
Grant a policy exception	CISO or delegate	Requesting owner	BISO, architecture	Internal audit
Select a security platform	CISO	Security architecture	CIO, procurement, BISOs	Business units
Declare a major incident	Incident commander per plan	SOC and IR lead	Legal, communications	Executive committee
Decide external disclosure	CEO or disclosure committee	General Counsel	CISO, communications	Board
Own a non-human identity	Business or platform owner of the workload	Engineering team	IAM team	Security operations

Where identity fits: IAM can sit in security, in IT or split between them, and each works if the decision rights are clear. The recurring gap is non-human identities: service accounts, API keys, OAuth integrations and AI agents created by engineering teams with no named owner. Put NHI ownership in the matrix and in the onboarding process for every new system. See the NHI Ownership Guide and the Identity Security Programme Guide.

Redesigning the function: a phased approach

Diagnose (weeks 1 to 4): inventory every person doing security work, including those outside the security team; list services, tools and budgets; interview business leaders on what they need; collect the decisions that caused friction in the past year.
Agree principles (weeks 4 to 6): with the executive sponsor, agree design principles such as "one owner per control", "shared platforms stay central", "no team assures its own controls" and "every service has an intake route".
Design options (weeks 6 to 10): draft two or three structures, test each against five or six real scenarios (a major incident, a new product launch, an acquisition, an audit finding, a regulator request) and pick the one that resolves them with the fewest hand-offs.
Write decision rights and the service catalogue (weeks 8 to 12): before announcing structure, agree the RACI, exception process and intake routes with the CIO, CRO and business heads.
Pilot (one quarter): run the new model in one business unit or one service line first. Measure handover delays, open exceptions and stakeholder feedback.
Transition in waves: move teams in waves with HR, keep incident response and on-call rotas unchanged until each wave is stable, and publish an interim contact map so nobody loses an escalation path.
Roll back if needed: keep the previous escalation paths and on-call arrangements documented until the new model has handled at least one significant incident; if the pilot shows unresolved ownership gaps, pause the next wave rather than forcing it.
Review annually: revisit the model after major changes such as an acquisition, a new regulator or a large cloud migration.

Measuring whether the model works

Ownership coverage: percentage of critical systems, controls and non-human identities with a named, current owner.
Exception health: number of open policy exceptions, share past expiry, and median age.
Time to decision: median time from a security review request to a decision, by business unit.
Remediation commitment: share of high-risk findings fixed within the agreed service level, by owning team.
Duplication: number of overlapping security tools or contracts across units, a good signal in federated models.
Stakeholder confidence: a short annual survey of business leaders on whether security is reachable, timely and useful.

Report these alongside risk metrics, not instead of them. See the Identity Security Metrics Guide for identity-specific measures.

Framework mapping

Framework	Reference	Relevance to the operating model
NIST CSF 2.0	GV.RR-01 to GV.RR-04	Leadership accountability, roles and authorities, resources, HR practices
NIST CSF 2.0	GV.OC-02, GV.RM-01, GV.PO-01, GV.OV-01	Stakeholder expectations, risk objectives, policy, review of strategy outcomes
NIST SP 800-53 Rev. 5	PM-1, PM-2, PM-29	Programme plan, senior information security officer role, risk management leadership roles
NIST SP 800-53 Rev. 5	PM-13, PS-9	Security workforce, position descriptions
ISO/IEC 27001:2022	Clause 5.3; Annex A 5.2, 5.3, 5.4	Roles, responsibilities and authorities; segregation of duties; management responsibilities
NIST SP 800-181 Rev. 1	NICE Framework components	Work roles and competencies for job design
UK Cyber Governance Code of Practice	Principle E, Assurance and oversight	Governance structure, quarterly reporting, dialogue with the CISO

Common failure patterns

Reorganising the boxes, not the decisions: a new structure announced without a decision rights matrix recreates the old disputes under new names.
BISOs without authority: BISOs who cannot influence budgets or block launches become meeting attendees, and business units route around them.
Security marking its own homework: the team that runs a control also reports it as effective to the risk committee, with no independent testing.
Federated by accident: acquired companies and shadow IT teams keep their own tools and staff indefinitely because nobody owned convergence.
Escalation resting on one person: when one security leader can decide alone how an incident is handled and disclosed, governance fails. In the Uber breach 2016, attackers were paid USD 100,000 through the bug bounty programme under non-disclosure agreements and the breach was disclosed a year later; the former CSO was convicted in 2022 of obstructing FTC proceedings and misprision of a felony.
Unowned machine identities: engineering teams create service accounts and keys under a model that only assigns ownership for human access.

Practitioner checklist

Write a one-page security charter stating mandate, out-of-scope areas and the CISO's right of board access.
Inventory everyone doing security work, inside and outside the security team.
Choose centralised, federated or hybrid against technology estates and regulatory perimeters, not org politics.
Keep identity, detection, vulnerability and secrets platforms central unless there is a documented reason.
Give BISOs a written mandate, a solid line to the CISO and a defined funding source.
Publish a decision rights matrix covering policy, risk acceptance, exceptions, incidents, disclosure and NHI ownership.
Separate control operation from control testing, even in a small team.
Pilot the new model in one unit and keep old escalation paths until it has handled a real incident.
Report ownership coverage, exception health and time to decision every quarter.

Security Operating Model and Organisation Design Guide