Your security policy describes a company that doesn’t exist

Most security policies start life as a template downloaded from somewhere on the internet. It describes an organization that enforces MFA everywhere, reviews access quarterly, and has a tidy incident response process. Then someone fills in the company name and calls it done.

The problem is that document describes nobody. It’s a wannabe scenario — a future state, maybe an aspirational one, but not what’s actually happening on Monday morning.

The better way: use the template as a structural example, nothing more. Then go topic by topic and describe your own reality. Not what you intend to do. Not what the template assumes you do. What you actually do today.

Where reality falls short, don’t quietly edit the policy to paper over it. Write it down as a gap. “We don’t enforce MFA” doesn’t belong hidden inside a policy pretending otherwise — it belongs in a gap analysis that says we need to add it.

This matters more the smaller and simpler the organization is. If it’s one team, one CTO, one way of doing things, describing reality is straightforward, and the gap analysis actually means something. The exercise gets harder once there are multiple teams, multiple environments, and a control that exists in one place but not another — but the principle doesn’t change: the policy should say what’s true, and the gaps should live where gaps belong.

A policy that describes the future instead of the present isn’t a policy. It’s fiction with a version number.