Ownership & decision rights

Who holds each control, and who may switch a running system off.

22documents on this topic
16organizations represented
2issues named
8sourced citations
0sourced statistics

The state of it

One of 6 topics within Security & threat model.

This is where the free material runs out, and it is not an accident. A published framework has to be organisation-agnostic to be adoptable, so it can tell you a control should have an owner and cannot tell you who. That gap is the most valuable thing in this theme.

Two failures recur. The first is delegation as an exit: most chief executives put cyber in the top three business risks and then treat it as a technical matter to be handed to the security function, which is a way of being concerned about something without being accountable for it. The second is quieter - nobody holds the authority to stop a working system. Switching off something that is producing value, on suspicion, costs money and reputation, and in most organizations no single person has been told they may do it without asking.

The consequence shows up as delay at precisely the moment delay is expensive. A containment decision routed through three approvals during an incident is not a control; it is a queue.

The issues, by agreement

How many independent organizations name each issue as a problem. An issue is only as real as the number of separate publishers that identify it, so the count is the ranking. Bars are organizations, not documents. Where the count reads ours, no publisher here states the issue and the analysis is our own.

Where they disagree

No contradictions recorded on this topic yet.

The issues in full

Each issue carries the organizations that name it, the numbers behind it, and the remedies proposed - with the concrete steps under each. Every citation points at a section of a named document, so any count here can be checked.

Issue 011 organization name it2026 evidence

Cyber risk is ranked in the top three and delegated out of the leadership team

The risk is acknowledged at the top and treated as a technical problem for the security function, so the decisions that actually determine exposure - product design, speed targets, what gets built - are taken elsewhere.

The pattern is well described and recent: chief executives recognise the threat as a first-order business risk and still hand it to a CISO or CIO as a specialist matter rather than holding it as a leadership responsibility. It matters because the security function does not control the variables that set the exposure. It does not choose the latency target that gets a guardrail disabled, or the launch date that skips a review. Ownership has to sit where those trades are made.

How to fix it — 1 approach, 3 steps

Hold the risk where the trade-offs are made

Put accountability for AI security exposure with the executives who set launch dates, latency targets and product scope, not only with the function that implements controls.

Done when An executive who is not the CISO is named accountable for AI security exposure, and the approval record for the most recent AI-enabled product contains a security position.

  1. Name the executive accountable for AI security exposure who is not the CISO.0-30 daysCEO
  2. Require a security position in the approval for any new AI-enabled product.30-90 daysChief product officer
  3. Report exposure to the board against business decisions, not control counts.90-180 daysCISO
The evidence — 4 documents
OrganizationDocumentPosition
Boston Consulting GroupConsultancy · August 2026How CEOs should manage escalating cybersecurity risks in the age of AIOur reading Reports that most chief executives place cyber threats among the top three business risks while still treating them as a strictly technical matter to delegate, rather than a responsibility of the whole leadership team.Recognised as a top risk, delegated as a technical issuenames it
AWSHyperscaler · April 2025Navigating the security landscape of generative AIOur reading Argues the opposite of consolidation: train people inside the delivery and data science teams to run their own reviews and to recognise when to escalate, on the reasoning that a single central function becomes the gate every review waits at, and that each hand-off across an organizational boundary costs something. Offers its own internal programme as the worked example, and is explicit that the posture has to be enablement rather than refusal.Spread the function rather than concentrate itproposes a fix
Boston Consulting GroupConsultancy · August 2026How CEOs should manage escalating cybersecurity risks in the age of AIOur reading Proposes building security into the design of new products and services and empowering a cross-functional team to act during incidents, which places the decision where the trade-offs are made.Security inside product designproposes a fix
FS-ISACInstitution · April 2026Preparing the enterprise for AI-enabled vulnerability discoveryOur reading Moves the accountability off the security function and onto the people who own and fund the systems: patch velocity and how current a platform is kept become objectives measured alongside whether the system performs, and remediation speed is reported to governance committees and to the board as operational risk rather than as a security update. Says outright that leaders across business, technology and resilience have to reset what they consider business as usual, which is the part a delegated model never asks of them.Put remediation speed in the objectives of whoever owns the systemproposes a fix

Issue 02Our analysis2026 evidence

Who may switch a working system off

Stopping a system that is producing value, on suspicion and before the facts are in, is expensive and visible. The sources here ask for decommissioning policies and for contingency processes to be verified; none of them establishes who holds standing authority to act.

This is the single question a security kit can answer that a free framework cannot, because the answer is specific to a company. During an incident the cost of the decision is dominated by its latency, and an approval chain converts a control into a queue. The fix is unglamorous: name the person, put it in writing, state the threshold at which they act without asking, and accept in advance that they will sometimes be wrong in the expensive direction. No organization in this index states that the authority is absent. What they supply is the policy that should exist, which is why the consensus count is zero and this is framed as a question to answer rather than a finding.

How to fix it — 1 approach, 3 steps

Name who may stop a system, and their threshold

Write down who may suspend a live AI system without further approval, on what evidence, and at what hour - and rehearse it.

Done when A written statement names who may suspend each live system without seeking approval and the evidence threshold at which they act, and an out-of-hours rehearsal is recorded with the time the decision took.

  1. Name the person who may suspend each live system without seeking approval.0-30 daysCEO
  2. State the threshold of evidence at which they act, in writing.30-90 daysCISO
  3. Rehearse it out of hours and record how long the decision actually took.90-180 daysHead of security operations
The evidence — 4 documents
OrganizationDocumentPosition
Boston Consulting GroupConsultancy · August 2026How CEOs should manage escalating cybersecurity risks in the age of AIOur reading Proposes empowering a cross-functional team to react quickly when incidents occur, which only means anything once someone in it may act without a further approval.A cross-functional team empowered to actproposes a fix
Cloud Security AllianceInstitutionAgentic AI Identity and Access ManagementOur reading Proposes that termination be an available, propagating action, which is the technical half of the same question.Immediate termination as a designed capabilityproposes a fix
Cloud Security AllianceInstitutionAI Model Risk Management FrameworkOur reading Treats the ability to intervene in or shut down a system that has gone off track as a required capability rather than an escalation of last resort.The ability to intervene or shut a system downproposes a fix
NISTInstitutionAI Risk Management Framework PlaybookOur reading Proposes the artefact whose absence this issue is about, and is specific about what it has to cover: policies for taking an AI system out of service that address user and community concerns and reputational risk, business continuity and financial exposure, dependencies both upstream and downstream, retention and other regulatory duties, and the possibility of a later legal, regulatory, security or forensic investigation. Separately asks that contingency processes for mission-critical systems be verified to include deactivating them - verified, not merely documented. It stops short of naming who holds that authority, which is the part still resting on our own reading.Decommissioning as a written policy, not a decision taken under pressureproposes a fix

Who is represented

This dossier is drawn from 18 organizations working on the subject, 5 of which are cited directly in the issues above.

Consultancy — 5

Boston Consulting Group 1 Capgemini 2 EY 1 Heidrick & Struggles 1 Infosys 1

Institution — 7

Cloud Security Alliance 3 NIST 2 FS-ISAC 1 World Economic Forum 2 Association of Corporate Counsel 1 Institute of Directors 1 Marketing AI Institute 1

Academic — 1

Carnegie Mellon SEI 1

Hyperscaler — 4

AWS 1 IBM 4 Google Cloud 1 Microsoft 1

Frontier lab — 1

Anthropic 1