Why many policies are not followed
Policies fail for ordinary reasons. They are long, so nobody reads them. They are vague, so nobody can tell whether they comply. They apply to everyone, so people assume they apply to someone else. They are written to protect the organization on paper rather than to help people do the right thing.
A rule people cannot follow is not an effective control. It can also do harm, because widespread quiet non-compliance makes it hard to tell which rules matter. Good drafting aims for fewer rules, written so that a busy person can understand and apply them.
Policy, standard, guideline
Three terms are used loosely, and keeping them distinct helps. Organizations define them differently, so treat the following as a common usage rather than a universal rule.
- Policy: a short statement of intent and principle, approved at a senior level. It says what the organization requires and why, in general terms. For example, that company data must be protected from unauthorized access.
- Standard: a specific, mandatory requirement that implements a policy. It says what must be done in measurable terms. For example, a defined minimum for how access is approved.
- Guideline: advice and recommended practice. It is not mandatory, and it helps people choose well where flexibility is acceptable.
A related document, the procedure, describes the steps for carrying out a task; these are often recorded as standard operating procedures.
The distinction matters because each has a different level of authority and a different route for change. A policy changes rarely and at a senior level. A standard may change as technology and risk change, through a simpler approval. A guideline can be updated by the owner. If everything is called a policy, the important requirements are lost among the optional ones.
Principles for drafting
Keep it short
Short documents are read. If a policy runs to many pages, it probably contains standards, procedures and background that belong elsewhere. Aim for a policy that fits on a page or two and a standard that covers one topic.
State the purpose
One or two sentences explaining why the rule exists help people apply it sensibly in situations the authors did not foresee. They also make it easier to judge exception requests.
Define the scope
Say who and what the document applies to: which people, which systems, which locations. Say what is excluded. A rule with unclear scope will be applied inconsistently. Scope statements should be specific enough that a reader can answer “does this apply to me?” in a few seconds.
Make requirements testable
A good requirement can be checked. Compare “access should be reviewed regularly” with “access to the shared finance system is reviewed by its owner at least once a year.” The second can be verified and the first cannot. Not every requirement can be so precise, and false precision is a risk, but ask of each statement how someone would know whether it was met.
Use plain language
Prefer short sentences and ordinary words. Use “must” for requirements and “should” for recommendations, and use them consistently. Define unusual terms once.
Name an owner
Each document needs an owner who maintains it, answers questions and decides on updates. It also needs a date and a review point.
Build in a way out
Provide for exceptions. A rule with no route for justified exceptions tends to be bypassed. A fair standards exception process keeps the rule credible.
A simple structure
Many standards work well with a few headings:
- Purpose
- Scope
- Requirements
- Roles and responsibilities
- Exceptions
- Owner, approval and review date
Resist adding sections just to look thorough.
Testing a draft
Before publishing, try the following.
- Ask someone outside the drafting team to read it and explain what it requires. Where they get it wrong, the text is unclear.
- Ask whether a typical user could comply without help, and what it would cost them in time and effort.
- Check for conflicts with other rules. Two standards that cannot both be met cause confusion.
- Ask what the rule is trying to prevent and whether it would actually do so.
- Consult the people who have to comply. Early local input often reveals practical problems that central authors miss.
Keeping the rule set healthy
Policies accumulate. A periodic clean-up retires rules that no longer serve a purpose, merges duplicates and updates what has changed. Exception patterns are a useful signal: if many units need the same exception, the standard may need to be revised. The same applies to areas such as data retention schedules, where requirements change over time and often depend on legal advice.
For security, privacy, health and safety, financial or other regulated topics, the content of a policy should be checked with qualified specialists. This article covers how to write rules clearly, not what any particular rule should contain.
Trade-offs
Central standards bring consistency, easier support and clearer accountability, but they can also limit local flexibility and fit some units poorly. A hybrid approach is common: a few firm central requirements, with guidelines for everything else. Fewer, clearer rules are usually easier to follow, explain and enforce than many detailed ones.