Most organisations don't have a tooling problem. Walk into a typical security setup and you'll find dashboards, endpoint agents, a SIEM, perhaps a SOC contract, and alerts arriving faster than anyone can read them. What's often missing is harder to point at: a clear answer to a simple question. Are we actually secure, and who is responsible for making sure we are?

Tools are very good at answering "what is happening on this endpoint right now." They are not designed to answer "is our security program sound, and is it improving?" That second question doesn't have a technical answer. It has an owner, or it doesn't.

More tools rarely close the gap

There's a comforting logic to buying technology. A new threat appears, a new product promises to address it, and the budget line is easy to justify. The trouble is that the evidence doesn't support the assumption that more tooling produces more security.

In a global study of more than 3,400 IT and security professionals conducted by the Ponemon Institute for IBM Security, organisations running more than 50 security tools rated themselves lower at detecting and responding to attacks than those running fewer, 8% lower on the ability to detect a cyberattack and 7% lower on the ability to respond, because the resulting complexity worked against them rather than for them (IBM Security & Ponemon Institute, 2020). The same research found that what actually distinguished more resilient organisations was not the size of the toolset but whether they had an incident-response plan applied consistently across the business. Yet 51% said their plans were inconsistent, informal, or ad hoc, and organisations without a consistently applied plan reported notably more business disruption (IBM Security & Ponemon Institute, 2020).

Tools, in other words, are necessary but not sufficient. Past a certain point, adding more of them without someone to integrate, tune, and make sense of them can quietly make things worse.

The hard problems aren't tooling problems

Look at how breaches actually happen and the same pattern appears. Verizon's 2025 Data Breach Investigations Report, drawn from more than 22,000 security incidents and over 12,000 confirmed breaches, found that the human element was involved in around 60% of breaches, and that the share of breaches involving a third party had doubled from 15% to 30% in a single year (Verizon, 2025).

You cannot buy your way out of a phishing-prone culture, an unclear escalation path, or a supplier whose security you've never assessed. These are problems of judgement, process, accountability, and relationships, the connective tissue between systems and the people who run them. No product owns that tissue. A person, or a clearly accountable function, has to.

The field, and the regulator, have caught up to this

This isn't a contrarian opinion any more; it's becoming the consensus position. When the U.S. National Institute of Standards and Technology released version 2.0 of its widely used Cybersecurity Framework in 2024, the headline change was the addition of a sixth core function, Govern, sitting alongside Identify, Protect, Detect, Respond, and Recover. Its purpose is to elevate cybersecurity governance, risk-management strategy, accountability, and supply-chain risk to a first-class concern rather than something assumed to happen in the background (National Institute of Standards and Technology, 2024).

European regulation is moving the same way. Under the NIS2 Directive, cybersecurity risk management becomes an explicit responsibility of an organisation's management body, which is expected to approve and oversee the measures taken and can be held accountable for failures (European Parliament & Council of the European Union, 2022). Governance is no longer a soft recommendation. It is being written into both frameworks and law as the thing that holds everything else together.

What an owner actually does

An owner is not a person who watches dashboards. The role is to hold the whole program together and answer for it:

• Deciding what matters: translating business priorities and risk appetite into where security effort and budget actually go.

• Maintaining the risk picture: keeping a live view of risks rather than a spreadsheet revisited once a year.

• Connecting the parts: making sure governance, architecture, compliance, and day-to-day operations point in the same direction instead of each optimising in isolation.

• Reporting with honesty: giving the board and leadership a clear, defensible account of where the organisation stands. In practice this is often missing: only 45% of organisations issue a formal report on their cyber resilience to executives or the board (IBM Security & Ponemon Institute, 2020).

• Making sure plans exist and are exercised: which, as the same research suggests, is one of the few things that reliably reduces the damage when something goes wrong (IBM Security & Ponemon Institute, 2020).

The common thread is accountability. Tools generate information; an owner turns it into decisions and stands behind them.

Ownership comes in different shapes

None of this requires a particular line on the org chart. For some organisations the owner is a full-time CISO. For others, especially those that have outgrown ad hoc security but can't yet justify a full internal team, it's a fractional or external arrangement. What matters is not the title but that the responsibility for the program as a whole sits clearly somewhere, with the mandate and the seniority to act on it.

This connective, accountable layer is, as it happens, the work we do at CTRL Disrupt, we manage the program, not the tooling. But the more important point stands regardless of who provides it: a security program is not a collection of products. It's a set of decisions someone is answerable for.

The tools will keep coming, and many of them are genuinely useful. The question worth answering first is who owns the program they're meant to serve. If the honest answer is "no one, exactly," that's the gap worth closing, well before the next tool.

References

European Parliament & Council of the European Union. (2022). Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2 Directive). EUR-Lex. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

IBM Security & Ponemon Institute. (2020). Cyber Resilient Organization Report 2020. IBM Corporation. https://www.ibm.com/security/digital-assets/resilient/cyber-resilient-organization-report/

National Institute of Standards and Technology. (2024). The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29). U.S. Department of Commerce. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

Verizon. (2025). 2025 Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/