The security operating model

Scope: how security decisions are made across one organisation · Who: the leader who owns the model · Prerequisites: controls, policies and a register · First result: one quarter

1. Why this exists (the failure mode it prevents)#

Most organisations already have the parts. A security function exists, the policy set is written, controls are inventoried, a register is maintained. Missing is the written answer to one question: who decides what, and how do the three disciplines feed each other.

Without that answer, security is run as a team rather than as a model. On paper the security function owns everything: policy, risk, controls, evidence, the audit response. In practice it owns none of the decisions that create the exposure. Those are taken in a roadmap, a contract or a hiring plan, and the business carries a risk it never decided.

The damage surfaces in four places. Roles below the head of security cannot be evidenced, and clause 5.3 is Organizational roles, responsibilities and authorities ¹. Segregation questions have no answer, although control 5.3 names designing, auditing and assuring information security controls as activities that can require separation ². Management review at clause 9.3 is titled Management review ³, and here it runs on the security function's own opinion, with no business input. And in a regulated entity, independence cannot be shown.

Regulation (EU) 2022/2554 has financial entities other than microenterprises assign responsibility for managing and overseeing ICT risk to a control function, with an appropriate level of independence ⁴. Directive (EU) 2022/2555 has Member States ensure three things of the management bodies of essential and important entities. They approve the cybersecurity risk-management measures, oversee implementation, and can be held liable for infringements ⁵.

An operating model is the answer, and it is one loop rather than three silos. Governance decides what good means here and who answers for it. Risk chooses where the effort goes and how much is enough, handing governance the instrument: criteria, appetite, a register with owners. Compliance later demonstrates that what was decided actually ran, and its evidence returns to governance as the next decision. Protection is ensured through governance, demonstrated through compliance, and both exist to manage risk.

2. Definitions (only the ones that cause disputes)#

Seven terms decide whether the model holds. Requirement text is paraphrased; only titles are quoted.

Term	Working definition	Source
Function	A unit of work the model has to contain: govern, assess risk, run controls, assure. Not a department; one team can hold several.	Method, against clause 5.3 1
Role	The named duties and authorities a function is carried out through. Control 5.2 asks that each area of responsibility is defined, documented and communicated, and authorisation levels documented.	Annex A / ISO/IEC 27002:2022 control 5.2 Information security roles and responsibilities 6
Decision right	Which decisions a role takes alone, takes jointly, recommends, or escalates. Anything absent is escalated by default.	Method, against clause 5.3 as above
The three lines	Financial entities other than microenterprises assign ICT risk management and oversight to a control function with an appropriate level of independence. The same article segregates ICT risk management, control and internal audit functions.	Regulation (EU) 2022/2554 Art. 6(4) 4
Risk owner and control owner	Two accountabilities that often get merged. Control 5.2 asks the organisation to define responsibility for risk management activities, and in particular for accepting residual risks, naming risk owners as the example.	Annex A / ISO/IEC 27002:2022 control 5.2 6
Oversight	A Category of its own in CSF 2.0: results of organisation-wide cybersecurity risk management activities and performance inform, improve and adjust the risk management strategy.	NIST CSWP 29 Appendix A GV.OV 7
Interested party	A party whose requirements the organisation has to satisfy, one row per requirement. Clause 4.2 is Understanding the needs and expectations of interested parties.	ISO/IEC 27001:2022 clause 4.2 8

3. The method — numbered steps, each with input, activity, output and owner#

Nine steps. The first three fix what the model contains and who decides. The next three connect it and give it a calendar. The last three staff, measure and change it.

3.1 Name the functions, then map them to the three disciplines#

Start from work rather than boxes on a chart. Six functions cover the ground; a small organisation can hold several in one role.

ISO 31000:2018 gives the reason at clause 5.3, Integration. Risk is managed in every part of the structure, and everyone has a responsibility for managing it. Determining risk management accountability and oversight roles is integral to governance ⁹.

Function	What it produces	Discipline it serves
Govern	Policy, objectives, decision rights, the mandate to enforce	Governance
Assess risk	Criteria, appetite, a register with owners, treatment plans	Risk
Design and run controls	Controls that operate, each with an owner and a result	Protection, in operation
Assure	Test results, audit findings, independent review reports	Compliance
Respond	Incident handling, and the business trade-off when one is needed	Operations, on governance's terms
Report	The pack that closes the loop back into decisions	All three, one view

Write one line per function saying which role holds it today. Where two land in one role and one assures the other, mark the conflict now rather than at the audit.

• Input: the organisation chart; the control inventory; the register; the assurance plan.
• Activity: name the holder of each function; mark conflicts; note the functions nobody holds.
• Output: function map, one page, an owning role against every function.
• Owner: the head of the security function drafts; top management confirms.

3.2 Write the decision rights before writing anything else#

A model is a list of decisions with owners. Prose about collaboration is not one. Control 5.2 asks that information security roles and responsibilities are defined and allocated to the organisation's needs, with authorisation levels documented ⁶. ISO 31000:2018 says the same at clause 5.4.3, where top management assigns and communicates risk authorities at all levels and identifies the risk owners ¹⁰.

Decision	Proposes	Decides	Consulted	Informed	Evidence of the decision
Risk criteria and appetite	Security function	Top management	Business owners, finance	Risk owners	Approved criteria, dated
The policy set and its topics	Security function	Top management	Legal, business owners	All personnel	Approval record per policy
Security objectives for the period	Security function	Top management	Business owners	The organisation	Objectives register
Control selection and applicability	Security function	Risk owner	Control owners	Audit	Statement of Applicability
Residual risk acceptance	Security function	Risk owner, within criteria	Security function	Top management	Dated acceptance in the register
Exception to a policy or standard	Requesting role	The named approver	Security function	Risk owner	Exception record with an expiry
The assurance plan for the year	Assurance function	Top management	Security function	Business owners	Approved audit programme
Business trade-off during an incident	Response lead	The accountable business role	Security function, legal	Top management	Decision in the incident record

Two rules keep the table honest. One role decides per row, and a decision absent from the table is escalated rather than assumed.

• Input: the function map; the delegation of authority; the risk criteria; the exception process.
• Activity: list the recurring decisions; assign one deciding role each; agree who is consulted and informed; name each proving record.
• Output: decision-rights table, approved and dated.
• Owner: the security function drafts; top management approves.

3.3 Draw the three lines for security, and show the independence#

The three lines are a shape, not a headcount. First line: the roles that operate controls, and the risk owners who accept residual risk. Second: the security and risk functions that set criteria, challenge the first line and report. Third: audit, which tests both.

Regulated sectors make the shape explicit. Financial entities ensure appropriate segregation and independence of ICT risk management, control and internal audit functions. The shape follows the three lines of defence model, or an internal model ⁴. Their framework is audited regularly by auditors with sufficient knowledge and appropriate independence ¹¹. Critical findings then run through a formal follow-up process for timely verification and remediation ¹².

Outside those sectors the same discipline is a control. Control 5.35 asks that the approach to managing information security and its implementation is reviewed independently at planned intervals, or on significant change ¹³. The reviewer sits outside the line of authority of the area under review. Control 5.36 puts the first-line half on managers, who regularly review compliance with the policy set and report to the independent reviewer ¹⁴.

• Input: the function map; the assurance plan; the reporting lines; the sector's independence rules.
• Activity: place every function in a line; mark roles sitting in two lines; record the compensation for each overlap.
• Output: three-lines map, one page, overlaps and compensations named.
• Owner: the security function drafts; the assurance function confirms its line.

3.4 Wire the interfaces, so the loop is visible#

This is where the model stops being a chart. Three doors, each with an artefact and a counterpart each side.

Risk enters through the criteria and the register. Criteria and appetite are set once and used everywhere. The method is in Risk appetite and criteria decisions can use, the register in The risk register other people trust. Clause 6.1.2 is Information security risk assessment, clause 6.1.3 Information security risk treatment ¹⁵.

Governance enters through policy and objectives. Control 5.1 asks that the information security policy and topic-specific policies are defined, approved by management, published, communicated, acknowledged and reviewed ¹⁶. Clause 6.2 is Information security objectives and planning to achieve them ¹⁷. CSF 2.0 states the outcome at GV.PO-01, where policy is established from context, strategy and priorities, then communicated and enforced ¹⁸.

Compliance enters through testing, monitoring, audit and the record. Control 8.16 has networks, systems and applications monitored for anomalous behaviour, with appropriate action taken ¹⁹. Clause 9.2 requires a planned internal audit programme, with auditors selected so objectivity and impartiality are preserved ²⁰. Clause 7.5 covers the documented information that carries the evidence ²¹.

A fourth door closes the loop. Governance owns the decision on what good means here; risk owns the instrument that says where and how much; compliance owns the demonstration that it ran. What assurance finds becomes the next governance decision. Run as three programmes on three calendars, all three stay busy and no model exists.

• Input: the register and its criteria; the policy set; the objectives register; the assurance plan.
• Activity: name the counterpart each side of each door; agree the artefact and its cadence; record where a finding becomes a decision.
• Output: interface map, one page per door.
• Owner: the security function maintains the map; counterparts confirm their side.

3.5 Put the decisions on a calendar#

A model without dates degrades into whoever asks loudest. The calendar lists the points at which each decision in step 3.2 is actually taken.

Four fixed points carry most of it. Planning, where objectives for the period are set under clause 6.2 as above. Risk review, where entries are re-scored and overdue treatment challenged. Control testing, where managers review compliance with the policy set under control 5.36 ¹⁴. And management review, where clause 9.3.3 is Management review results ²².

ISO 31000:2018 asks the same at clause 5.5. Identify where, when and how each type of decision is made, and by whom, then modify those processes where necessary ²³. The upward view is in Board and management reporting for security; the strategy it serves in Security strategy on one page.

• Input: the decision-rights table; the planning calendar; the audit programme; the review schedule.
• Activity: place every decision on a date; name the forum that takes it; publish it; record attendance.
• Output: operating calendar, twelve months ahead, a forum named per decision.
• Owner: the security function owns the calendar; each forum chair owns the slot.

3.6 Choose a placement, and state the trade-off as a trade-off#

Three shapes recur. Each buys something and costs something structurally, and effort does not remove the cost.

Shape	How it works	What it buys	What it costs
Central	One function holds govern, assess and assure; the business runs controls	Consistent criteria; simple evidence; one voice to the auditor	Distance from decisions; slow answers; controls documented, not operated
Federated	Security roles sit inside business units under a central mandate	Early sight of decisions; local credibility; short decision latency	Divergent practice; capture by local appetite; units hard to compare
Hybrid	Central criteria, policy and assurance; federated advice and risk ownership	Criteria stay stable while decisions stay local	Two reporting lines; interfaces have to be written, not assumed

Record the choice, the cost accepted and the compensating measure in the model document. The federated shape has a role-level design of its own, and that method is in The BISO operating model. This step decides the shape, not the placement of any single role.

• Input: the function map; unit count, headcount and change volume; the instruments.
• Activity: select a shape; write the cost accepted; name the compensating measure; set a date to revisit.
• Output: placement record inside the model document.
• Owner: the security function proposes; top management decides.

3.7 Staff the functions, and say what capacity each one needs#

Every function in step 3.1 needs competence and time. Clause 7.2 is Competence ²⁴. Control 5.2 adds that whoever takes a named security role should hold the knowledge and skills that role needs, with support to stay current ⁶.

Capacity is the half that gets skipped. ISO 31000:2018 makes it a design activity at clause 5.4.4, Allocating resources: people, skills and competence, processes and tools, documented procedures, information systems, training needs ²⁵. CSF 2.0 states the outcome at GV.RR-03, where adequate resources are allocated commensurate with the strategy, roles, responsibilities and policies ²⁶.

Write one capability line and one capacity line per function. Where capacity is short, the honest answer is a smaller model, not the same one at half speed.

• Input: the function map; the skills inventory; the calendar's workload; the instruments.
• Activity: define a capability profile per function; estimate capacity in days; record gaps with dates; re-assess annually.
• Output: function charters, one per function: capability, capacity, interfaces.
• Owner: the security function owns the profiles; the appraising line the records.

3.8 Measure the model, not the activity#

Four measures separate a model from an organisation chart. Each has a source record and a fixed reporting date.

Decision latency: days from a security question raised to a decision recorded against the decision-rights table. Unowned controls: inventory entries with no named owner, as a count and a share. Acceptances on record: accepted risks carrying an owner, a date and an expiry. Findings by line: assessment findings grouped by the line that produced them.

Clause 9.1 is Monitoring, measurement, analysis and evaluation ²⁷. ISO 31000:2018 asks the same of the framework at clause 5.6, Evaluation. Measure its performance periodically against purpose, plans, indicators and expected behaviour, and judge whether it supports the objectives ²⁸. CSF 2.0 closes it at GV.OV-03, where risk management performance is evaluated and reviewed for adjustments needed ²⁹.

• Input: the decision log; the control inventory; the register; the finding register.
• Activity: define each measure once, with its source record; report every period; review the definitions annually.
• Output: measure definitions; periodic measure results.
• Owner: the security function reports; top management reads the results.

3.9 Let the model change, on triggers rather than on mood#

A model that never changes is either finished or ignored, and it is rarely finished. Two mechanisms keep it current.

The first is a maturity conversation, and CSF 2.0 supplies the vocabulary. Tiers characterise the rigour of cybersecurity risk governance and management practices as Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3) and Adaptive (Tier 4). They describe a progression from informal responses to approaches that are agile, risk-informed and continually improving, and complement a risk management methodology rather than replacing it ³⁰. Used as a target grade they are theatre; used as shared language in one meeting they help.

The second is a trigger list, and control 5.35 supplies one. It names the occasions for an independent review beyond the planned interval. Laws and regulations change, or significant incidents occur. The organisation starts or changes a business, takes a new product or service into use, or changes controls significantly ¹³. ISO 31000:2018 asks that the framework is continually monitored and adapted to external and internal change ³¹.

• Input: the operating model document; the trigger list; the finding register; the review reports.
• Activity: test the triggers quarterly; hold one Tier conversation a year; record every change with its reason and date.
• Output: model change record; independent review report covering the model.
• Owner: the security function maintains the record; an independent reviewer covers the model.

4. Deliverables#

Five artefacts, each produced by a step above and named as it will be named in the evidence set. Retention periods are organisational choices.

Deliverable	Produced by	Format	Retention
Operating model on one page	Steps 3.1, 3.6	document, approved and dated	every version, whole cycle
Decision-rights table	Step 3.2	table inside the model document	every version, whole cycle
Three-lines map	Step 3.3	one page, overlaps named	current plus one cycle
Interface map	Step 3.4	one page per interface	current plus one cycle
Operating calendar	Step 3.5	calendar plus a summary page	current period

Function charters from step 3.7 carry the capability profile, the capacity estimate and the interfaces for one function: template pending. Measure definitions from step 3.8 live inside the model document, so changing a measure is changing the model.

5. What the auditor or authority will ask#

The phrasing follows how an assessor opens: a request for a record, then for the decision behind it.

An assessment that stays on the model document is going well. One that moves to the decision log, then asks a business owner what they decided, is where a chart without decision rights fails.

6. Failure modes and how they surface as findings#

Four patterns account for most of the damage. Each is the pattern, the wording it produces, and the smallest change that removes it.

The root cause is the same in all four: authority described in prose rather than written as decisions with owners and records.

7. Mapping the model to the standards#

Provenance for the table. ISO/IEC 27001:2022 clause numbers and titles come from the publisher's contents listing ³². ISO/IEC 27002:2022 controls come from a licensed copy, paraphrased ³³. ISO 31000:2018 clauses likewise ³⁴. CSF Category identifiers come from Appendix A ³⁵.

Model element	ISO/IEC 27001:2022	ISO/IEC 27002:2022	ISO 31000:2018	CSF	Evidence sampled
Context, interested parties and scope	4.1, 4.2, 4.3	—	5.4.1 Understanding the organization and its context	GV.OC	Register rows; approved scope
Leadership and mandate	5.1 Leadership and commitment	5.4 Management responsibilities	5.2 Leadership and commitment	GV.RR	Approval record with a date
Functions and decision rights	5.3 Organizational roles, responsibilities and authorities	5.2 Information security roles and responsibilities	5.4.3 Assigning organizational roles, authorities, responsibilities and accountabilities	GV.RR	Decision-rights table, approved
Policy set	5.2 Policy	5.1 Policies for information security	5.4.2 Articulating risk management commitment	GV.PO	Approval and review record per policy
Risk assessment and treatment	6.1.2, 6.1.3	—	5.3 Integration	GV.RM	Register entries with named owners
Objectives per period	6.2 Information security objectives and planning to achieve them	—	5.5 Implementation	GV.RM	Objectives register with results
Competence and capacity	7.2 Competence	5.2 as above	5.4.4 Allocating resources	GV.RR	Charters; competence records
Segregation of duties	5.3 as above	5.3 Segregation of duties	5.4.3 as above	GV.RR	Owner and tester named separately
Control operation and first-line review	9.1 Monitoring, measurement, analysis and evaluation	8.16 Monitoring activities; 5.36 Compliance with policies, rules and standards	5.6 Evaluation	GV.OV	Periodic results; review records
Internal audit and independent review	9.2, 9.2.2 Internal audit programme	5.35 Independent review of information security	5.6 as above	GV.OV	Programme; reviewer independence
Management review and the record	9.3, 9.3.3 Management review results; 7.5 Documented information	—	5.5 as above	GV.OV	Decisions with owners, dates and versions
Improvement of the model	10.2 Nonconformity and corrective action	5.35 as above	5.7 Improvement	GV.OV	Change record with triggers

Two instruments sit outside the table because they bind rather than guide. Directive (EU) 2022/2555 requires members of the management bodies of essential and important entities to follow training. They gain the knowledge to identify risks and assess risk-management practices ³⁶. Under Regulation (EU) 2022/2554 the management body sets clear roles and responsibilities for all ICT-related functions ³⁷.

8. Checklist#

Each item is observable. "Agreed" is not; an approved page with a date is.

• Each of the six functions has a named owning role, and the gaps are listed.
• The decision-rights table names exactly one deciding role per decision.
• Decisions absent from the table are escalated, by a written route.
• The three-lines map shows where one role sits in two lines, with the compensation.
• No role both operates and assures a control, or the exception is recorded.
• Risk criteria and appetite are approved, dated, and used by every register entry.
• Each register entry has an owner entitled to accept it under the decision-rights table.
• The operating calendar carries every decision, with the forum that takes it.
• Management review inputs include risk results and assurance results, not only status.
• Every function charter carries a capability profile and a capacity estimate.
• The model's own review is in the independent review programme, reviewer named.
• The model change record shows what changed, what triggered it and when.

Related#

• The BISO operating model — the federated shape at role level.
• Risk appetite and criteria decisions can use — the instrument risk hands to governance.
• Security strategy on one page — what the model is built to deliver.
• Board and management reporting for security — the upward half of the loop.

References#

Primary sources only. ISO/IEC 27001:2022 clause titles come from the publisher's contents listing; ISO/IEC 27002:2022 controls and ISO 31000:2018 clauses from licensed copies, paraphrased.

1. ISO/IEC. Information security management systems — Requirements. ISO/IEC 27001:2022. Contents and clause titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ³²
2. ISO/IEC. Information security controls. ISO/IEC 27002:2022. Controls 5.1, 5.2, 5.3, 5.4, 5.35, 5.36 and 8.16 read in a licensed copy; catalogue entry at https://www.iso.org/standard/75652.html ³⁸
3. ISO. Risk management — Guidelines. ISO 31000:2018. Clause 5 read in a licensed copy; catalogue entry at https://www.iso.org/standard/65694.html ³⁹
4. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. Section 3.2 and Appendix A read at https://doi.org/10.6028/NIST.CSWP.29 ⁴⁰
5. European Parliament and Council. Directive (EU) 2022/2555 (NIS 2 Directive). OJ L 333, 27.12.2022, p. 80. Article 20 read at https://publications.europa.eu/resource/celex/32022L2555 ⁴¹
6. European Parliament and Council. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. OJ L 333, 27.12.2022, p. 1. Articles 5 and 6 read at https://publications.europa.eu/resource/celex/32022R2554 ⁴²

Cadences, retention periods and thresholds above are organisational choices, not requirements of any standard named here.