Your policy says one thing. Your company does another.

Open your information security policy and read the section on access reviews, then check when the last review happened. For a lot of companies those two facts disagree, and nobody has noticed because nobody reads the policy except the auditor.

A policy you don't follow is more dangerous than no policy at all. It turns an ordinary operational gap into a documented failure, and it tells the auditor exactly where to look.

I've written and rewritten ISO 27001 policy sets for fintech and healthcare companies, and the most common audit finding I've seen is a control described one way and performed another.

How documents drift

Policies are usually written in a burst, before a first audit, by someone who won't be operating them. They describe the company as it was that month, or as someone hoped it would be.

Then the company changes. You move from one cloud provider to two. You replace the ticketing tool. The person who approved access leaves and the approval quietly moves to whoever is around. The policy still names the old tool and the old approver.

Nobody updates it because the annual review is treated as a date to change. The most common control in many companies is the annual policy review where someone updates the version number on page one.

How auditors catch it

Auditors test what you said you would do. ISO 27001 clause 5.2 requires the policy, clause 7.5 requires documented information to be controlled and kept current, and Annex A control 5.1 says policies should be reviewed at planned intervals and when significant changes occur. That last part is the one everyone skips.

In SOC 2, the criteria ask whether the entity deploys control activities through policies that establish what is expected, and whether those policies are put into action. If your policy promises a 90 day review cycle and your evidence shows 140 days, the auditor doesn't need to argue with you about best practice. You set the standard and missed it.

Acknowledgement theatre

Then there is the employee side. New joiners are asked to accept twelve policies in a single onboarding flow, and most click through in under three minutes.

You've clicked "I have read and understood" on a policy you didn't open, somewhere between setting up your laptop and finding out where the bathroom is. So has everyone on your team.

The click proves almost nothing. An acknowledgement only means something if the policy is short enough to read and if people are asked to acknowledge again when it materially changes, which is a feature request that shows up on the issue trackers of open source compliance tools for exactly this reason.

Keeping documents honest

Write shorter policies. Each one should be readable in five minutes and point to the procedures and tools that implement it.

Tie each policy statement to the control it describes and the evidence that proves it. If a statement has no evidence behind it, either start collecting evidence or delete the statement.

Review on change, not only on schedule. A new system, a new vendor or a new process should trigger a check of every policy that mentions the thing it replaced.

This is the problem Steppe was designed around: keeping the document and the evidence side by side, so the gap shows up months before an auditor finds it.

A policy you don't follow is a written confession, and auditors read confessions closely.