Writing Information Security Policies People Actually Follow

Most information security policies are written once, to pass an audit, and then never read again. They are long, generic, and full of requirements nobody in the company actually meets. That is worse than having no policy, because a policy you do not follow is documented evidence that you fail your own controls. This is about writing policies that describe what people really do, and that people can actually follow.

The gap between the policy and the practice

The failure mode is familiar. A company buys a policy template or copies one from a friendly peer, fills in the name, and files it. The document says passwords must be rotated every ninety days, that all changes require CAB approval, that a formal risk assessment happens quarterly. None of these things happen. The policy describes a company that does not exist.

An auditor's job is to test whether you do what you say. When your policy claims controls you do not operate, every one of those claims is a finding waiting to happen. The generic template does not protect you. It hands the auditor a checklist of your own gaps.

The deeper problem is cultural. When employees encounter a policy that is obviously disconnected from how work actually happens, they learn that policies are theater. That lesson generalizes. The next policy, even a good one, gets the same treatment. Credibility, once spent, is hard to earn back.

The goal is not an impressive policy. It is a policy that is true and that people follow. A short, accurate, followed policy beats a comprehensive, aspirational, ignored one every time, both for security and for audit.

Write what you do, then improve what you do

The right sequence is counterintuitive to teams who think of policy as a wishlist. Start by documenting what actually happens today. Then, separately and deliberately, decide where practice needs to improve and change the practice, updating the policy to match once the new practice is real.

This does two things. It produces a policy that is immediately true, which means immediately auditable. And it surfaces the real gaps, the places where current practice is genuinely insufficient, so you can prioritize fixing them rather than papering over them with words.

Concretely:

• Interview the people who do the work. How do you actually grant access? What really happens when someone leaves? How do changes actually get deployed?
• Write the policy to describe that reality in clear terms.
• Where the reality is inadequate, note it as a gap and plan the improvement as a project with an owner and a date.
• Update the policy when the improved practice is operating, not before.

A policy that runs slightly ahead of practice, describing a control you are two weeks from fully operating, is a small and defensible gap. A policy that runs a year ahead of practice is fiction. Keep the distance short.

Short, specific, and owned

Length is the enemy of adherence. A thirty-page policy is a policy nobody has read to the end, which means nobody knows what it requires, which means nobody follows it. The discipline is to say what matters and stop.

A few principles produce policies people can actually use:

• One topic, one document. Separate access control from incident response from acceptable use. A monolith is unnavigable.
• Specific over comprehensive. State the actual rule. "Access is granted through a request in our ticketing system and approved by the resource owner" beats a paragraph of principles about least privilege.
• Name the owner. Every policy needs a person accountable for keeping it true. Without an owner, policies rot the moment reality moves.
• Say who it applies to and what they must do. A reader should finish the relevant section knowing exactly what is expected of them.
• Cut the boilerplate. The legal-sounding preamble that appears in every template adds pages and communicates nothing.

The test of a good policy is whether a new engineer could read the relevant section and know what to do. If they finish more confused than they started, the policy has failed at its actual job, which is guiding behavior, not filling a binder.

Make following it the path of least resistance

The most reliable way to get a policy followed is to make the compliant path the easy path. Policies that fight the grain of how people work lose. Policies embedded in tooling win without anyone thinking about them.

If your access policy requires requests through a specific system, make that system fast and make the alternative harder. If your change policy requires review, enforce it in branch protection so the review is automatic rather than a thing to remember. If onboarding must follow certain steps, put those steps in a checklist that is part of the process, not a document someone is supposed to consult.

This is where GRC and product thinking overlap. You are designing for a user, the employee, and the same rules apply. Reduce friction on the desired behavior. Remove the need for willpower and memory. A control that depends on people choosing to comply every time will eventually fail on a busy day. A control built into the workflow holds regardless.

When the compliant path is the natural path, the policy stops being something people follow and becomes simply how things are done. That is the state you want, and it is also the state that produces the cleanest audit evidence, because the evidence is generated automatically by the tools people already use.

Keep them alive

A policy is not finished when it is written. It is finished when it is retired. Between those points it needs to stay true as the company changes, and companies at this stage change fast.

Sustainable maintenance looks like:

• A review cadence, at least annually, where the owner confirms the policy still matches practice
• A trigger for updates when practice changes materially, tied to how you roll out significant process changes
• Version history, so you can show an auditor the policy has been maintained, not written once and abandoned
• A light approval step, so changes are deliberate and someone accountable has signed off

Review does not mean rewrite. Most reviews should confirm the policy still holds and change little. But the act of reviewing, and the record of it, is itself evidence of a living management system, which is precisely what ISO 27001 is asking you to demonstrate. A policy set with recent review dates and a change history tells a very different story than one last touched the week before certification.

Bottom line

Information security policies earn their keep only when people follow them, and people follow policies that are short, specific, true, and embedded in how work already happens. Write what you actually do, fix the practices that need fixing, keep the documents lean and owned, and make the compliant path the easy one. The result is a policy set that guides behavior and survives an audit, because it describes a company that really exists.

If your policies were written to pass an audit and you suspect they no longer match how your team works, a Kellwick readiness review can tell you where the documentation and the practice have drifted apart, before an auditor does.