People are the control that matters most

I have read a lot of security reports. Most of them are right. A smaller number of them are useful. The gap between those two things is where most cyber risk actually lives.

We have spent a decade professionalising the technical side of this work — better frameworks, better tooling, better evidence. What we have not professionalised at the same pace is the handover: the moment a finding leaves the person who understands it and lands with the person who has to fund, schedule or accept it. That handover is a control. It fails more often than our firewalls do, and almost nobody tests it.

The failure mode nobody logs

A typical example. An assessment identifies weak privileged access management on a business-critical platform. The finding is accurate, well evidenced, mapped neatly to a control framework, and rated high. It goes into a register. Eighteen months later the same finding appears again, now rated high with a note that it is a repeat.

Nothing in that story is a technical failure. The failure is that the finding never became somebody's problem. It had no owner with the authority to act, no cost attached, no decision point, and no articulation of what happens to the business if it stays open. It was information, not a choice. Information gets filed; choices get made.

If a risk has no owner, no cost and no date, you have not reported a risk. You have written a sentence.

What changes when you write for people

The most valuable habit I have picked up across central government and enterprise work is embarrassingly simple: before I write a single finding, I decide who has to do something about it, and I write to them.

• Name the decision, not the deficiency. "Approve £X to close privileged access gaps on Platform Y by Q2" beats "PAM controls are inadequate".
• State the consequence in the language of the business the platform serves — service outage, benefit payments delayed, patient data exposed, contract non-compliance.
• Give the accountable person a genuine set of options, including the option to accept, with what acceptance actually means.
• Cut anything the reader cannot act on. Detail belongs in an annex, not in the way.
• Say what you are not worried about. Credibility comes from proportion, and proportion is what busy people are testing you for.

None of this lowers the technical bar. The analysis underneath has to be rigorous, because the moment a senior stakeholder finds one exaggerated claim, every other claim you make gets discounted. Precision earns you the right to be brief.

Assurance is a relationship, not a deliverable

The engagements where security genuinely improved were never the ones with the best report. They were the ones where the delivery team stopped hiding things from me. That only happens when people believe you are there to help them ship something safely rather than to catalogue their mistakes.

Practically, that means turning up early, explaining what good looks like before anyone is graded against it, and being willing to say "that control is disproportionate here, drop it". Assurance that only ever adds work is assurance people learn to route around.

What I would ask of any security function

• Can a non-specialist executive read your last report and correctly state your top three concerns?
• Does every open high risk have a named owner who knows they own it?
• When did you last withdraw a control requirement because it was not proportionate?
• Do delivery teams bring you problems before they become findings?

If the answer to most of those is no, the constraint on your security posture is not technology or budget. It is communication — and that is a far cheaper thing to fix.

People are not the weakest link. They are the control that decides whether every other control gets funded, implemented and maintained. Treat them that way and the rest of the work gets easier.