The failures are rarely exotic. Almost none of them look like the thing the security industry sells you protection against.

If you are about to take a security leadership role, this is the argument I would want handed to me on day one.

The first thing: loss of trust

Not the incident. The incident is survivable. A badly handled one is not.

Everyone gets hit eventually. It is not a question of if, only of when and how, and I have been saying that publicly for years without seeing much to change my mind. What separates the companies still here from the ones nobody mentions any more is almost never the sophistication of the attack. It is what happened in the following seventy-two hours.

The ones that acknowledged it, asked for help, explained the mechanics and said plainly what they were changing came through it. Some came through stronger, because a company that handles a bad day well has demonstrated something no marketing can buy. The ones that denied it, minimised it, or went quiet while everyone else assembled the story without them did not.

This matters more than most security work because trust is the only asset you cannot rebuild on your own schedule. You can replace infrastructure in a weekend. You cannot replace a customer’s belief that you will tell them the truth when something goes wrong.

Which leads to an uncomfortable implication for how you spend your first year: the work of earning trust has to be done before the bad day, not after it. An incident response plan written in advance, an ownership map that says who does what, a disclosure standard agreed while nobody is panicking, a named human that partners can escalate to. None of these prevent anything. All of them determine whether the next seventy-two hours are survivable.

The second thing: the unknown unknown

The event nobody was looking for, in a place nobody thought to look.

Every control you can name is a defence against something somebody already imagined. Frameworks are catalogues of imagined failures. Audits check for known classes of mistake. Scanners look for signatures of things that have happened before. All of it is useful, and all of it is backward-looking by construction.

The failures that actually end companies are almost never on the list. They come through the supplier nobody mapped, the integration nobody owned, the process that existed only in one person’s head, the piece of software that was fine until the day it was not.

So the most useful description of this job is not “prevent attacks.” It is turning unknown unknowns into known unknowns: taking the space of things that could hurt us and steadily converting it into things we have at least named, sized and made a decision about. A named risk you have consciously accepted is not a failure. An unnamed risk that lands is.

That reframing changes what you spend money on. Threat modelling is for this. Tabletop exercises are for this. A properly scoped bug bounty is for this — run well, a bounty is not a vulnerability pipeline, it is an external research team telling you about parts of your estate you had forgotten you owned. Monitoring built from threat models rather than from whatever your tooling emits by default is for this. And a risk register that someone actually maintains, with a strategy built from it rather than alongside it, is for this.

Everything on that list is an instrument for finding out what you did not know you did not know.

The one place I say no

I used to believe security should be able to block. I do not any more, and unlearning it was the single most useful thing that happened to my career.

It does not work. You get routed around. And a security function that is routed around is worse than no security function at all, because it produces the appearance of coverage while the actual decisions happen somewhere you are not.

My job is to find risk, size it, and put it in front of the person who owns the outcome with enough information to make a real decision. If they accept it, that is a legitimate answer — and I write it down, name the owner, put a date on it and come back to it. Risk acceptance is a decision, not a defeat, and treating it as a defeat is how you teach people to stop telling you things.

There are two exceptions.

Anything that cannot be undone. Money movement, key rotation and signing, recovery and MFA changes, production and deploy access, irreversible deletion. Get one of these wrong and there is no remediation, only disclosure. There I want a named human making the call, and there I will say no.

Commitments the company has already made. A contract, a regulatory obligation, an attestation given to a customer. Those are not my opinion and I will enforce them as facts.

Everywhere else, my job is to make the decision informed, not to make it for you.

Prevent what cannot be undone. Prove it continuously. Keep shrinking the unknown.

That is the job. What it looks like as a plan is the next post, A head of security’s first year.

I have talked about most of this on stage over the years; recordings are at https://cvh.sh

Add PDFs, documents, or other text to reference in this project.

Content

two-things-kill-a-company.md

md