Naming the CISO accountable for everyone's decisions is a liability shield, not governance

A practitioner decision guide published by SC World argues that the standard complaint about the CISO role - responsibility for security outcomes without the authority to control them - is the wrong diagnosis ^[1]. That matters because the usual remedy, more authority for the CISO, leaves the people actually making risk-bearing decisions exactly where they were ^[2].

The guide's central point is uncomfortable and correct. Security outcomes are produced by product owners, infrastructure teams, procurement committees, application developers and line-of-business leaders ^[3] - five distinct populations, none of whom report to the security function in most organisations ^[17]. Naming the CISO as the accountable party for all of it does not assign accountability; according to the guide, it creates a liability shield for everyone else ^[4]. Risk-bearing decisions keep being made by people who carry no formal accountability, while the CISO carries accountability for decisions they did not make and cannot unilaterally reverse ^[5].

The reason this passes unnoticed is a confusion about control functions. The CISO runs the security programme, so the CISO is assumed to own the outcome of security-relevant decisions made by others ^[6]. The guide argues that inference turns operationally dangerous when it starts shaping escalation paths, budget authority and post-incident reviews ^[7]. The question to ask is not how to make the CISO more powerful but who owns each decision, and how the organisation knows ^[8].

Underneath that sits a vocabulary problem. Accountability means being answerable for the result, responsibility means doing the work, and authority means being able to commit resources or block action ^[9]. Collapse them and the failure modes are predictable: accountability without authority is exposure, responsibility without accountability produces drift, and authority without accountability produces unchecked risk-taking ^[10]. The guide notes this is not new theory - NIST SP 800-39 already distributes risk management across the organisation, mission/business-process and information-system tiers and defines a risk executive function ^[11], and the Govern function in NIST Cybersecurity Framework 2.0 establishes cybersecurity roles, responsibilities and authorities while treating oversight as distinct from executing controls ^[12].

The operational test is granularity. A decision-rights model maps each high-consequence security decision to a named role owner, not a team name, not a committee, and not "the business", on the grounds that named owners can be held to SLAs and committees cannot ^[13]. The guide identifies four decision types that recur in breakdowns: implementing a threat-informed control, remediating a known exposure within an agreed SLA, approving a high-risk change to a payment or production system, and formally accepting residual risk on behalf of the organisation ^[18]. In that model the CISO holds process oversight and escalation authority rather than default ownership ^[14]. The blunt version: a CISO who owns every decision owns every failure ^[15].

What to watch is the enforcement edge, which is where these models usually die. Decision rights fail when declining to decide carries no consequence - if a product owner can defer a critical remediation indefinitely without triggering formal escalation, the table on the wall is decorative ^[16]. Two artefacts tell you whether an organisation has actually done this: residual-risk acceptances signed by a named business owner rather than the security team ^[18][13], and post-incident reviews that name the decision owner instead of the control function ^[7][14].