Stop Asking Who ‘They’ Are: Cybersecurity’s Accountability Problem

Every major cyber incident seems to create the same question: why didn’t they stop it?

It is asked by customers, journalists, regulators, shareholders and sometimes by the organisations that were breached. Yet the identity of “they” is rarely clear. Is it the security team, the CISO, the technology provider, the regulator, the board or the government?

This ambiguity is convenient because it allows responsibility to move precisely when it matters most. When an attack succeeds, everyone can point towards somebody else.

Over time, many organisations have progressively outsourced not only parts of their security operations, but also their sense of responsibility for cyber risk. They buy platforms, engage service providers, appoint a CISO and assume the problem has been handed over. If something goes wrong, the expectation is that one of those parties should have prevented it.

But cybersecurity does not work like that. A vendor can provide the technology, and a security team can identify the threat, but the organisation itself must decide what those defenders are authorised to do.

This is becoming particularly important as businesses introduce AI into their security operations. Boards increasingly expect AI to detect attacks, make decisions and respond at machine speed. At the same time, many have not given either their human security teams or AI systems a meaningful mandate to act.

That contradiction sits at the heart of the accountability problem.

If a security operations centre detects an attack but must seek approval from several people before isolating a system, the response will always be slower than the threat. If an AI system reaches the same conclusion but is prohibited from taking action, it becomes another alerting tool. In both cases, the organisation may later ask why the attack was not stopped, despite having designed a process that prevented anyone from stopping it.

This is not simply a technical issue. It is a leadership decision.

A mandate to act cannot come from a technology provider. It must come from the organisation’s leadership, based on a clear understanding of operational priorities and acceptable risk. Boards cannot demand autonomous defence while avoiding the decisions that make autonomy possible.

Of course, giving security teams or AI permission to act introduces difficult questions. Taking an infected employee laptop offline may be straightforward. Isolating a production system that generates significant revenue is very different. In some circumstances, the disruption caused by containment could exceed the immediate damage caused by the intrusion.

That decision cannot be made intelligently unless the defender understands what the affected asset is, what business function it supports and what would happen if it became unavailable.

Many organisations still lack this basic context. Their asset records are incomplete, outdated or fragmented across business units. Shadow IT remains common, with departments purchasing systems and connecting them to corporate environments without the knowledge of central IT or security teams. Cloud adoption, remote working and sprawling third-party environments have made the picture even more complicated.

As a result, security teams are frequently expected to protect infrastructure that the organisation itself cannot fully identify.

AI can help address this problem. It can support asset discovery, classify systems, identify likely business owners and help maintain the information required for informed response. But AI cannot invent an organisation’s risk appetite or decide, without direction, whether protecting a system is worth interrupting a critical operation.

It needs authority, context and boundaries. Establishing those is the responsibility of the organisation deploying it.

This is where the debate over liability risks becoming unbalanced. As AI assumes a greater role in defensive operations, vendors will understandably be cautious if they can be held responsible for every unintended consequence. If an automated response shuts down a factory for six hours, the organisation may blame the technology provider for the lost production. Yet if the system does nothing and ransomware spreads, the same provider may be criticised for failing to stop it.

Faced with that position, vendors will build technology that takes the safest possible course. That may reduce the risk of a disruptive false positive, but it may also limit the system’s ability to intervene decisively during a real attack.

There must be accountability for how security technology is designed and represented. But the organisation using that technology must remain responsible for deciding what it is allowed to do, what information it receives and how its actions reflect business priorities.

This cannot be contracted away.

The next generation of cyber defence will depend on systems that can respond far faster than people. Attackers are already operating at a speed that makes a purely manual response increasingly unrealistic. An organisation that requires every decision to pass through a lengthy chain of approval will spend its time investigating incidents after the damage has occurred.

Before asking why “they” failed to stop an attack, leaders should ask more difficult questions. Did our defenders have permission to act? Did they know which systems mattered most? Had we agreed what level of disruption was acceptable? Did we give our AI enough context to make an appropriate decision?

Cybersecurity providers have a serious role to play, but they cannot carry responsibility for decisions that belong inside the organisation. Technology can detect, recommend and increasingly act. It cannot compensate for absent ownership.

When the next breach happens, “they” will again be blamed. The organisations best prepared to withstand it will be those whose leaders have already decided who is responsible, what authority they have and what action they are expected to take.