Perspective: The Security Team Cannot Own Every Risk

Ask who owns cyber risk in most organizations and the answer comes quickly: the CISO. It is the wrong answer, and it is wrong in a way that makes the program worse at reducing risk.

The security team owns a great deal. It owns the controls it runs, the quality of the risk information it gives leadership, and the advice it gives when someone wants an exception. It does not own the application with the unpatched component, the supplier relationship, the deadline that squeezed testing, or the budget that decides whether a fix happens this planning cycle or never.

When accountability sits with the function that has the information instead of the person with the authority, three things break. Risks get accepted by people who cannot change the underlying activity. Accountability lands on a team with no control over the outcome. And risk reporting drifts toward either comfort or alarm, because the people reporting are also the people being held responsible.

What the standards say

The NIST Cybersecurity Framework 2.0 is direct. Its Govern function states that organizational leadership is responsible and accountable for cybersecurity risk [1]. It names leadership, not the security function.

NIST IR 8286 makes a related argument from the enterprise side: cyber risk deserves attention comparable to legal and financial risk inside enterprise risk management, and a risk register is a tool for identifying, assessing, communicating and managing it [2]. Consider how other risks are treated. Nobody expects the internal audit team to own the risk of a failed product launch, or the finance control function to own the risk of a bad acquisition. Those risks are owned by the executives who run the activities that create them.

The Institute of Internal Auditors’ Three Lines Model points the same way. Management owns the work and the risk that comes with it. A second line of specialist expertise supports and challenges. An independent third line provides assurance [3]. Security usually sits in the second line when advising the business, and in the first line for the controls it operates itself. Ask it to own business risk as well and it ends up challenging decisions it has effectively taken.

Regulators assume both ownership and oversight exist. For companies subject to the US SEC’s cybersecurity disclosure rules, annual reports must describe how the board oversees cyber risk and what management’s role is in assessing and managing material cyber risks [4]. That is a disclosure requirement, not an ownership rule, but it presupposes that someone can be named.

How ownership drifts to security

Nobody decides to hand security every risk. It happens through process design, and the pattern is easy to spot.

• The exception form with a security signature box. A business unit submits, security approves, and the record shows a senior security person accepted a risk in a system they do not run, fund or answer for.

• The vulnerability backlog. Security tools produce the findings, security tracks them, and fixing depends on teams whose priorities are set elsewhere. The number sits on the security dashboard. The lever sits somewhere else.

• Supplier risk. A business owner contracts the supplier, security assesses it, and when the assessment is poor the launch date wins. The risk register lists security as owner.

• Cloud and product delivery. Teams provision and ship. Security tracks posture and carries the finding.

The common thread is that accountability attaches where the information is, not where the authority is.

A hypothetical case. A business unit wants to launch a customer-facing service on a supplier’s platform. The security assessment finds weak access controls and no commitment to notify of incidents. The launch date is fixed. The acceptance goes to the CISO, who signs with conditions nobody monitors. After an incident, the organization’s first question is what security missed. The better question is who decided the launch date mattered more than the findings, and who was in a position to make that trade-off.

A test for ownership

In the author’s view, three questions settle most ownership arguments.

1. Can this person change or stop the activity that creates the risk?

2. Can they fund the treatment, or decide not to?

3. Would they answer to the board, customers or a regulator for the outcome?

If any answer is no, that person is an adviser to the risk, not its owner. This is a practical rule of thumb, not a standard, but it is hard to argue against once the questions are asked out loud.

What security owns, and what it does not

The objections

“Business leaders don’t understand cyber risk well enough to own it.” Then the job of security is to translate. Ownership does not require technical depth. Executives own financial, legal and operational risks without being specialists in them, and they rely on specialists for the information. If leaders cannot decide with what they are given, the information is poor, and producing decision-grade information is a security deliverable.

“Someone has to be accountable for the whole thing.” Someone is: organizational leadership, as the NIST framework says [1]. The CISO is accountable for the program, meaning its design, its delivery and the honesty of its reporting. That is a large responsibility and it is the right size.

There is an opposite failure worth naming. Security can abdicate, announcing that the business owns the risk while the business has neither the information nor the process to act on it. Moving ownership only works if it comes with decision-grade information, an escalation route that functions, and records showing who decided what.

It also has a cost. Some owners will accept more risk than security would have. In the author’s view that is the arrangement working. Risk accepted visibly by someone with authority to accept it is better than risk absorbed invisibly by someone without.

What to change

1. Name a business executive as owner of each register entry. Allow the security function as owner only where the risk sits in a system security runs.

2. Route risk acceptance by authority. Set thresholds and send acceptances above them up the executive line, not sideways to the security signature box.

3. Put an end date and a review trigger on every exception. An acceptance with no expiry is permanent by default.

4. Report cyber risk by owner and treatment status, not only by severity count. A list of open items per executive changes conversations in a way a heat map does not.

5. Write down what security can refuse, what it must escalate and what it must document. The role needs authority to say no to being the named owner.

A question worth putting to a board: for each of the top ten cyber risks, name the executive who could fund the fix and who would face customers or regulators after an incident. If the answer is the CISO more often than not, the program has been handed risk it has no power to treat.

Related Reading

ARTICLE Cybersecurity Operating Model Design for a Distributed Enterprise

How responsibility for security and risk can be distributed without losing clear accountability.

ARTICLE Why Cybersecurity Programs Keep Growing Without Reducing Business Risk

The investment side of the same problem: activity that is not tied to a risk someone owns.

EXPERT BRIEFING Expert Briefing: From Cyber Activity to Business Risk

A discussion of how to connect security work to risks leadership can decide on.

ARTICLE Why Security Investment Fails to Change Risk

Why spending does not move risk when no one with authority owns the outcome.

PRACTITIONER FIELD NOTE Field Note: What a Good Cyber Risk Workshop Should Produce

How to leave a risk workshop with owners, decisions and dates.

Sources

[1] National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, Govern function. doi.org/10.6028/NIST.CSWP.29

[2] National Institute of Standards and Technology. Integrating Cybersecurity and Enterprise Risk Management (ERM), NIST IR 8286. csrc.nist.gov/pubs/ir/8286/final

[3] The Institute of Internal Auditors. The IIA’s Three Lines Model. theiia.org

[4] U.S. Securities and Exchange Commission. Cybersecurity risk management, strategy, governance and incident disclosure rules. sec.gov