Security is an operational problem, not a tooling problem

Security programmes tend to fail in a predictable order. A tool gets purchased. A policy gets written. A dashboard turns green. Then an incident happens, and it turns out the organisation never actually decided who's allowed to do what once the system is under pressure.

Tools aren't the enemy here. Treating them as the strategy is.

Access control, movement management, and a few compliance-heavy environments taught me the same lesson wearing different uniforms: security is a property of how work actually gets done. If the path around a control is easier than the control itself, people will take it. Not because they're reckless, but because they're trying to finish the job in front of them.

Discipline has to be designed in

You can't bolt discipline onto a system that was built for convenience. The secure path has to be the operable path, full stop. That means fewer exceptions, clearer ownership, and software that assumes people are busy, interrupted, and working with less context than they'd like.

Checklists help, until they become theatre. Scanners help, until they produce more noise than signal. The organisations that get this right treat security the way they treat uptime: as a constraint the product is built around from the start, not a department that shows up after the architecture is already frozen.

Build this instead of buying another tool

Build records that tell the truth. Build workflows that don't require heroics to get through. Build systems where privilege is temporary, visible, and genuinely expensive to abuse. Then pick tools that enforce those decisions, rather than tools that pretend the decisions have already been made.

If your security story starts with a vendor logo, you're already arguing about the wrong layer of the problem.

← All writing