When is a policy not a policy?
Answer: when it has undocumented exceptions.
Sometimes it’s appropriate to make an exception to a policy; policy authors can’t always anticipate all possible relevant future situations.
However, when an exception is necessary, it’s important to recognize that making an exception means that the policy has changed. There are a few different ways to address this:
- a documented list of exceptions, which the policy links to
- an update to the policy to change…
- …the wording, if the exception was needed because the policy wasn’t clear
- …the meaning, if the exception was needed because circumstances have changed
In either case, the change itself–whether to add an exception or update the policy text–should be documented with:
- a precise and complete description of the exception/change
- who requested it, and why
- who granted it, and why
(If these details are sensitive, access to them can be restricted.)
Making such updates explicit and visible simplifies future uses of, and changes to, the policy. More importantly, however, it requires the people involved to be explicit about the nature of, and motivation for, the change.
Notes:
- Explicit documentation may entail some difficult conversations, if the initially presented reason for the exception is “X wants to be able to do something that the policy prohibits”. The more difficult the conversation, the more important it is to have it.
- If a policy gets too complex to be easily understood, it may be time to look into either simplifying it, or automating enforcement.