There is a particular kind of organisational document that is written once, approved by a committee, stored somewhere sensible, and never opened again by anyone who has to comply with it. Security policies are unusually prone to this.
The failure is rarely dramatic. The policy simply drifts out of alignment with what people do, and nobody notices until something forces a comparison.
Why policies drift
They were written for the wrong reader. Many policies are drafted with an auditor in mind rather than an employee. The result is a document that satisfies a review and instructs nobody.
They describe an idealised organisation. Controls assume tooling that was never bought, roles that do not exist, or approval steps that would stop the business functioning. People work around them, sensibly, and the workaround becomes the real process.
They are too long to be read. A forty-page policy will not be read by someone whose actual job is something else. It will be skimmed, signed and forgotten.
They have no owner in practice. A policy with no named person responsible for keeping it current will not be kept current.
What works better
Write the behaviour, not the theory. Rather than a general statement about data classification, state what someone should actually do when they need to send a client file externally. Specific instruction beats accurate abstraction.
Separate the layers. A short policy setting direction and accountability. Standards specifying requirements. Procedures giving step-by-step instructions. Most organisations collapse all three into one document and it serves none of the three purposes well.
Test it on the person who has to comply. Before approval, give it to someone in the relevant role and ask them to tell you what they would do differently tomorrow. If they cannot answer, it is not finished. This single step catches more problems than any review committee.
Make the compliant path the easy path. If the approved method for sharing a large file is slower than the unapproved one, the unapproved one will win. Policy and tooling decisions have to be made together.
Set a real review cycle, with a named owner. Not “annually” as an aspiration, but a date in a calendar belonging to a person, with a trigger for review whenever the systems or obligations change.
Evidence is part of the design
A control you cannot evidence is a control you cannot rely on when someone asks. Build the evidence into the process rather than reconstructing it later: approvals recorded where they are given, exceptions logged when they are granted, training completion captured automatically.
The organisations that handle audits calmly are usually not the ones with the most controls. They are the ones whose ordinary working process happens to produce a record.
A short test
Pick any policy your organisation has approved in the last two years. Ask three people it applies to what it requires them to do. If you get three different answers, the document is not doing its job, whatever the review committee concluded.
That is fixable, and it is usually fixed by writing less, more specifically, for the person who actually has to act.