The accountability arrived before the authority

Why has liability moved faster than authority?

Two changes happened in the same decade and only one of them completed. The first was accountability: a handful of enforcement actions and prosecutions established that when an organisation misleads people about a breach, the answer to who is responsible can be an individual with a name and a job title. The number of such cases remains small. Their effect on the profession has been enormous, and the 22-point jump in a single year is what that effect looks like measured.

The second change was supposed to be authority, and it stalled. Roughly 64% of security chiefs still sit inside the technology function, reporting to the person whose objectives include delivering projects on time. That arrangement asks one executive to slow another executive's programme while depending on them for budget, headcount and an annual review. Most of the time it produces exactly what you would expect, which is a security function that raises concerns and does not stop anything.

The consequence is a role carrying personal exposure for outcomes it cannot determine. That is an unstable arrangement in any profession, and the people in it have started behaving accordingly: negotiating indemnities before accepting the job, insisting that risk acceptances are signed by whoever benefits from taking them, and keeping records in a form that survives a subsequent disagreement about what was known and when.

None of that is cynicism, and treating it as such misses what it produces. An organisation where the person who wants the deadline signs for the risk of meeting it is better governed than one where a security team objects informally and gets overruled in a corridor. The paperwork is not defensive posturing. It is the only mechanism that puts a decision in front of the person entitled to take it.

What the job turns out to consist of

Job descriptions for this role describe strategy, architecture and threat. The calendar of somebody doing it describes something else entirely: contract clauses, supplier questionnaires, audit evidence, exception requests, and a standing argument about whether a project can proceed. Very little of the week is spent on anything a technical candidate would recognise as security work, which is the single largest surprise reported by people moving into it from engineering.

A substantial share of the load is answering other organisations' questions. Every significant customer now sends a security questionnaire, each different, most asking for the same assurances in incompatible formats, and none of them read carefully by the recipient. The industry has produced standard frameworks precisely to end this, and the frameworks have been added to the questionnaires rather than replacing them. The cost is real and falls hardest on smaller suppliers, who answer proportionally more of them with proportionally fewer people.

Underneath the paperwork is a genuine function that nothing else in the organisation performs: translation between people who understand what a system does and people who decide what the company will risk. Engineering knows the failure modes and cannot price them. The board can price things and cannot see them. Somebody has to carry meaning across that gap in both directions, and the reason the role has survived every prediction of its obsolescence is that the gap has not closed.

Which suggests a hiring test rarely applied. The useful question for a candidate is not how they would architect something. It is to describe a time they persuaded somebody with more authority to accept a delay, and what it cost them. People who cannot answer have generally not done the job, whatever their title said.

The exception that quietly became the policy

Every organisation has a policy and every organisation breaks it, which is neither scandalous nor avoidable. Systems predate rules, acquisitions arrive with their own arrangements, and a business occasionally needs to do something the standard forbids in order to make money. The exception process exists for this, and it is the most neglected mechanism in the entire field.

Neglected because it is dull, and consequential because it is where the real security posture is decided. A policy describes what an organisation intends. The exception register describes what it actually does. In most places that register is a spreadsheet, incomplete, with entries that have no expiry, no compensating measure, and an owner who left two years ago. Those entries are not deviations from the security programme; collectively they are the security programme.

A functioning version has four properties and none of them require software. Every exception expires, with a date, and the default on expiry is that it stops rather than renews. Every exception names a person senior enough to be uncomfortable signing it. Every exception states what is being done instead, even if that is nothing, because writing "nothing" is itself informative. And the whole register is reviewed by somebody outside the function that requested them.

The same neglect shows up in the one rehearsal that matters. An incident is a governance event before it is a technical one: counsel arrives, an insurer must be notified, a regulator's clock starts running in every jurisdiction where customers live, and somebody has to speak publicly within hours while the forensic picture is still incomplete. Organisations that have practised this discover the awkward questions in a conference room — who authorises paying an extortionist, who signs the customer letter, whether the chief executive or the general counsel fronts the announcement — and organisations that have not discover them at two in the morning with a journalist already holding the story.

A rehearsal worth the afternoon has a specific shape. No slides, a scenario nobody in the room helped write, the communications and legal people present rather than represented, and one deliberate complication introduced halfway through: the backups are encrypted too, or the person with the authority is on a flight. What it produces is not a plan. It is a list of decisions nobody had realised were unassigned, which is the same output as the exception register arrived at from a different direction.

Get that working and a surprising amount of the rest becomes easier. Board reporting acquires content that is genuinely about the future. Prioritisation stops being an argument about severity scores and becomes a queue ordered by what the organisation has already admitted it is uncomfortable with. And the person carrying the personal exposure discussed above has, for the first time, a record showing which decisions were theirs and which were somebody else's.