It Can Be Managed

The gap between what the risk register records and what the attacker exploits is not a failure of people — it is a failure of design

Jul 17, 2026

The agenda ran to eleven items. Security was seventh. By the time the board reached it, forty minutes had been spent on a supplier contract and a facilities question about the car park. The CISO had twenty minutes. They used eighteen of them.

The security review recommended twelve measures. The board approved three, deferred four, and excluded five as beyond the year’s plan. The meeting ended. Someone went to get coffee. Nine months later, one of the deferred items was the entry point for a ransomware attack that shut the business down for eleven days.

Nobody in that room had been negligent. Nobody had ignored the risk. The decision was made by competent people using the information they had, inside a process designed to balance competing priorities.

The CISO’s brief was forty-two slides. The executive summary was four pages. The risk register mapped each of the twelve recommendations to a likelihood score and a financial impact range. It was thorough. It was also built to satisfy a compliance requirement, not to help a non-technical board member understand which of those twelve things actually mattered most, and why, and what the difference would look like if they got it wrong.

Item seven on the deferred list was a patch management protocol for legacy systems. The brief described it as “medium risk, estimated remediation cost £18,000, recommended timeline Q2.” It sat between a network segmentation proposal and an employee phishing simulation programme. The board chair asked whether it could wait until the budget review. The CISO said it could be managed. The item was deferred.

That sentence — “it can be managed” — actually means: I believe the risk is tolerable in the short term, given everything else on the table. It does not mean: this is safe. The distinction between those two things disappears in the room. It stays disappeared until something goes wrong.

Organisations have been told for twenty years that security is a board-level responsibility. The intention was good. Bring it out of the IT department. Get it in front of decision-makers. Give the CISO a seat at the table. According to DSIT surveys, only 27 to 31 per cent of UK businesses have a board member with specific responsibility for cybersecurity — and this after a decade of sustained regulatory pressure to change it.

What happened instead is that security became a governance exercise. A risk register. A compliance checklist. A set of items to be approved, deferred, or removed, using the same mental framework that the board uses to evaluate a marketing spend or a property lease. The question is always: what does this cost, what does it protect, and can it wait?

The catastrophic failure of that framework is that cybersecurity risk does not behave like the risks that framework was built for. A lease that is deferred costs rent. A security measure that is deferred creates a window. The attacker does not wait for the budget cycle.

The deferred patch was not a theoretical vulnerability. It was a known gap, documented, scored, and filed. It sat in a folder. The attacker found a different route to it than the folder.

The decision that enabled the attack was made in a Monday morning meeting that ended with someone going to get coffee.

Eleven days offline. Not a dramatic number until you translate it. Supply chain halted. Customer orders unmet. Staff unable to work. The IR firm billing £2,400 a day. The ransom demand. The legal fees. The forensic audit. The regulatory notification. The reputational cost that does not appear in any spreadsheet.

The CISO did not lose their job. The board did not face personal liability. The organisation recovered, at significant cost, and updated the risk register. The patch management protocol was implemented in full. It had cost £18,000 on the original recommendation. The recovery cost many times that.

The people in the meeting were not careless. They were doing exactly what the system asked them to do. The system asked them to balance risks against budgets in a room built for a different kind of risk. That is not a character failure. That is a design failure.

What the brief was actually built for

A forty-two slide deck translated into a four-page summary with a risk register does not help a non-technical director make a well-informed decision about which deferred item will cost them thirty-eight times the remediation price. It helps the CISO demonstrate that they have fulfilled their duty of care. Those are not the same thing. The board member who approved the deferral did not understand the difference between “medium risk” and “a known gap in a legacy system with active exploit code circulating in the wild.” The brief did not help them understand it.

The governance structure was built to add something to security oversight — documentation, audit trail, the appearance of rigour. What it does not reliably add is security, because security requires that decisions reflect the actual threat environment rather than the budgetary one. A compliance framework and a threat actor are operating on entirely different timelines. The register records what was known. The attacker acts on what was left open.

The risk assessment treated every organisation of similar size and sector as roughly equivalent. It did not adapt to this company’s specific exposure: which of their legacy systems was most likely to be targeted, what the attacker’s likely entry path would be, what the actual blast radius of a successful attack on that specific infrastructure would look like. A one-size-fits-all risk score applied to a specific organisation on a specific day in a specific sector is not risk management. It is risk documentation.

The problem is not that boards are incompetent or that CISOs are failing. The problem is that the governance architecture built to manage cybersecurity risk was designed for a world where risk is relatively static and consequences are proportionate. Cybersecurity risk is neither. The architecture needs to change, not the people trying to work inside it.

My opinion

The more we rely on digital services, the more we place ourselves in the hands of organisations whose governance structures were not built to protect us. CISOs are operating in conditions no single role should carry. My position is that security risk belongs at the top of every board agenda, treated as a living state rather than an annual exercise — because the threat changes every day. Every new service deployed without security built in from day one creates exposure that did not exist the day before. Secure by design is not a technical principle — it is a condition of doing business.

The questions the risk register doesn’t raise

Have you ever been in a meeting where a security recommendation was deferred for cost or time reasons? Not because anyone thought it was unimportant — but because the table was full and the budget was finite and it seemed manageable for now?
If you have sat in a room like that one: what would it have taken for the conversation to go differently? What would the CISO have needed to say, or show, or do, to change the outcome?
Should the people who make security deferral decisions face personal accountability when those decisions lead to a breach? And if the answer is yes — what would that accountability look like in practice, and who would apply it?
The gap between the risk register and the real threat environment is not a secret. The people who write the registers know it. The question is whether the governance structures we have built are capable of closing it — or whether they were designed for something else entirely.

The dynamics in that boardroom — the compressed agenda, the deferred risk, the gap between documented exposure and lived consequence — run through The Shadow System. The book takes the argument further than a single meeting.

The Next Evolution

Discussion about this post

Ready for more?