Who should be accountable for cybersecurity when the CISO role spans strategy, compliance, and incident response?

Why CISO accountability has to be shared, not absorbed

When a CISO owns strategy, compliance, and incident response, the role can look centralised even though the underlying accountability is distributed. The CISO can set direction, define security priorities, and coordinate response, but legal, compliance, IT, and business leaders still own the decisions and controls in their own domains. That distinction matters because cybersecurity failures often arise when one function assumes another function is carrying the risk on its behalf.

For a shared-accountability model to work, executive ownership has to be explicit. Security policy, risk acceptance, regulatory obligations, technical control operation, and business continuity cannot all sit with the CISO in practice, even if they sit under the same programme. The better model is one of coordinated accountability: the CISO orchestrates, escalates, and evidences, while peer leaders own the actions that only they can authorise. That is why shared governance is the right answer for the question of who should be accountable when the role spans multiple disciplines. NIST Cybersecurity Framework 2.0 reinforces the point that governance is an organisational responsibility, not a security-team-only task.

In practice, many security teams discover the accountability gap only after an incident exposes unclear decision rights across legal, IT, and business leadership, rather than through a deliberate governance review.

How shared accountability works across strategy, compliance, and response

The modern CISO role spans three different operating modes, and each one creates a different accountability pattern. Strategy is about setting risk appetite, target state, and investment priorities. Compliance is about proving the organisation meets external obligations and internal policy. Incident response is about making fast decisions under pressure, often with incomplete information. The CISO may coordinate all three, but the CISO does not own all three in isolation.

In practice, shared accountability works best when the organisation separates coordination from authority. The CISO usually coordinates the programme, but the executive team must own risk acceptance, the legal function must own legal interpretation and disclosure decisions, IT must own platform recovery and technical execution, and business leaders must own operational trade-offs when control changes affect service delivery. This structure avoids the common failure mode where security becomes the default owner of every uncomfortable decision.

• Strategy: the CISO proposes security direction, while executive leadership approves priorities and funding.
• Compliance: security assembles evidence and controls, while compliance and legal own regulatory interpretation and sign-off.
• Incident response: the CISO directs the security response, while business and IT leaders own service-impact decisions and recovery choices.

That model is consistent with broader governance frameworks that separate direction, control, and assurance. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it shows that many obligations are implemented across multiple functions, not only within security. Where organisations fail is usually not in declaring accountability, but in failing to define who can accept risk, who can commit the business, and who can stop or continue operations during an event.

That guidance breaks down when the organisation has no formal decision rights, because then “shared” accountability becomes indistinguishable from no accountability at all.

When the CISO role spans too much, the edge cases become governance failures

Tighter centralisation can improve consistency, but it also increases the risk that the CISO becomes a bottleneck for decisions that should be owned elsewhere. The trade-off is speed and coherence versus over-concentration of responsibility. That matters most in matrixed organisations, regulated sectors, and companies with separate product, platform, and corporate risk structures.

One common edge case is compliance-heavy environments where the CISO is asked to attest to controls they do not operate. Another is incident response, where security may lead containment but cannot independently decide on customer notification, regulatory reporting, or business shutdown. A third is strategy, where the CISO may define the target architecture but the engineering and operations leaders still own delivery and maintenance. Industry consensus is clear on one point: the CISO can be accountable for security leadership, but should not be the sole accountability sink for enterprise risk decisions.

Another edge case is where a security function spans both preventive and responsive work. In those organisations, it is tempting to blur responsibility because the same team is visible before, during, and after an incident. That convenience can hide a serious governance weakness: if the CISO is treated as the owner of every control outcome, other executives may disengage from the risks embedded in their own processes.

Risk and Threat Considerations

When accountability is overloaded onto the CISO, the primary risk is governance failure, not just organisational confusion. The issue is a loss of decision ownership across control design, risk acceptance, and incident escalation, which can leave material gaps in both prevention and recovery.

Failure mechanism: Shared work without explicit authority leads to delayed escalation, disputed sign-off, and control gaps that sit between functions. In incident response, that can mean security identifies the issue but cannot compel legal, IT, or business actions quickly enough to contain it.

Impact: The organisation can end up with weak auditability, slower containment, inconsistent risk acceptance, and leadership that cannot prove who approved which security decision when it mattered.

Practitioner Guidance

What to prioritise: Define decision rights before the next incident or audit cycle. The CISO should be the coordinator of security governance, but every major security decision should have a named business, legal, or IT owner who can approve, reject, or fund the action.

What to verify: Check whether your operating model distinguishes between recommending a control, authorising a risk, and executing a technical change. If those are all treated as the CISO’s job, the organisation is already over-assigned and likely to be slow under pressure.

Practitioner takeaway: The healthiest model is not “the CISO owns everything,” but “the CISO makes ownership visible.” When accountability is explicit, security becomes governable; when it is implicit, the first incident turns it into an argument.

Related resources from NHI Mgmt Group

• Who is accountable when log loss affects incident response or compliance evidence?
• Who is accountable when an incident response plan fails?
• How do organisations make AI agent visibility useful for compliance and incident response?
• Who is accountable when a machine identity causes a compliance incident?