Short answer: Write a usable security policy with a clear purpose, limited scope, direct requirements, real role names, defined terms, practical exceptions, and links to the procedures employees actually follow. Plain language makes a requirement easier to follow; it does not make the requirement less serious.
Write for the person who acts
State who must do what, under which condition, and where to get help. “Users should protect accounts” is vague. “Employees must report suspected credential compromise to the service desk immediately” gives a reader an action.
Keep policy separate from procedure
The policy should contain the durable rule and responsibility. Put changing tool steps in a controlled procedure or runbook. This keeps the policy readable and reduces the number of places that must change after a system update.
Define terms and exceptions
Explain terms that a non-specialist could interpret differently. State how exceptions are requested, approved, recorded, and reviewed. Do not hide important conditions in footnotes or rely on an acronym without defining it.
Use real roles and examples
Name the role that owns the decision and link to the workflow that implements it. A short example can clarify the expected behaviour, but label it as an example so employees do not mistake it for a complete list of permitted situations.
Test the draft with readers
Ask an employee who did not write the policy to explain the required action and where they would record it. Note questions, ambiguous phrases, and steps that cannot be followed with the tools or access people actually have. Fix the policy or procedure based on what the test reveals.
Check accuracy before approval
Compare the draft with current systems, roles, controls, and evidence. Do not turn a desired future state into a claim that the control is already implemented. Approval should record the owner, reviewer, date, and open follow-up work.
Write requirements teams can actually follow
Test each material requirement with a simple pattern:
- Name the actor or role.
- State the action.
- State when or under what condition it applies.
- Identify the approved system, channel, or procedure.
- Explain what evidence or record remains.
- State how an exception is requested.
For example, “Access reviews must be performed regularly” is difficult to operate. “The application owner reviews privileged access every quarter in the approved access-review system and records removals, retained access, and approved exceptions” gives the team a testable requirement. Validate the wording against the real workflow before approval.
For the exception decision and expiry process, see how to manage policy exceptions without weakening governance. For the relationship between a policy requirement and its control and evidence, see how to build policy traceability from framework to control to evidence.
Practical example
Instead of saying “users must maintain secure accounts,” an access policy can say employees must use the approved password manager, never share credentials, and report suspected compromise to the service desk immediately. Each requirement tells the reader what action to take.
FAQ
What makes a policy easy to follow?
Use direct requirements, real role names, clear scope, defined terms, practical exceptions, and links to the procedure or help channel.
Does plain language weaken a security policy?
No. Clear wording makes the approved requirement easier to apply and review.