Policies, standards and procedures
These three words are often used loosely, but separating them makes documents easier to write and maintain.
- A policy states what the organization expects and why, in broad terms. Example: company devices must be protected against unauthorized access.
- A standard sets a specific, measurable requirement that supports a policy. Example: devices must lock after a set period of inactivity.
- A procedure describes the steps to carry out a task. Example: how to enroll a new laptop so it meets the standard.
Policies change rarely and are approved at a senior level. Procedures change more often and are usually owned by the team that performs them. Keeping them in separate documents means you can update a procedure without reopening a policy debate.
Decide which policies you need
Start from the organization’s actual risks and obligations rather than from a long template list. Common IT policies include:
- Acceptable use of company systems, devices and internet access
- Passwords and authentication
- Data handling and classification
- Remote work and personal devices
- Software installation and approved tools
- Incident reporting
- Backup and retention
- Access to systems, including how it is granted and removed
A small organization might combine several of these into one short document. A larger one may keep them separate so each can have its own owner. What matters is that each topic is covered somewhere and that staff can find it.
Writing a policy people will read
Staff are more likely to follow a policy they can finish reading in a few minutes. A few habits help:
Use plain language. Write “do not share your password” rather than “credentials shall not be disclosed to third parties”. Define any term a non-specialist might not know.
Explain the reason. One sentence about why a rule exists tends to improve compliance, because people can apply the spirit of the rule in situations the text did not anticipate.
Be specific about who and what. State whether the policy applies to employees, contractors, volunteers or all of them, and which systems and devices it covers.
Keep it short. A policy of one to three pages is usually easier to maintain than a long one. Move detailed steps into procedures.
Avoid rules you cannot enforce or support. A policy that bans something everyone does in practice teaches staff to ignore the rest of the document.
A simple structure
Many effective policies use the same skeleton:
- Purpose: what the policy is for
- Scope: who and what it covers
- Policy statements: the actual rules, as a short numbered list
- Responsibilities: who does what
- Exceptions: how to ask for one and who approves it
- Consequences: a general statement of how violations are handled, in line with HR guidance
- Owner, approval date and next review date
Acceptable use as an example
An acceptable-use policy usually says that company systems are for business purposes, with perhaps limited personal use; that staff must not try to bypass security controls; that accounts are personal and not to be shared; and that certain activities are prohibited. It often notes whether activity may be monitored. Because monitoring and employee rights vary by location, this is a section worth having reviewed by someone with legal or HR expertise before publishing.
Approval and ownership
Every policy should have a named owner who is responsible for keeping it accurate, and an approver with enough authority to make it binding, often a senior manager or a governance committee. The approval step matters: a policy written by the IT team alone may not carry weight with the rest of the organization. This approval chain is part of wider IT governance, which sets who decides what.
A reasonable approval flow looks like this:
- The owner drafts the policy.
- Affected teams review it and comment, so that practical problems come up early.
- HR or legal advisers check anything touching employment or legal duties.
- The approver signs off, and the date and version are recorded.
- The policy is published somewhere staff can easily find it.
Procedures that back the policy
A policy without procedures leaves people guessing how to comply. Good procedures are short, ordered and written for the person doing the task. Numbered steps, expected results and a note on what to do if something goes wrong usually work well. Screenshots can help but go stale when software changes, so use them selectively.
Procedures are best stored where people already look for help, such as a knowledge base, so that they are easy to search and update. The same care that goes into writing clear documentation applies here: one task per procedure, a named owner, and a last-reviewed date.
Rolling the policy out
Publishing a document is not the same as informing people. Announce new or changed policies, summarize what is different, and ask staff to acknowledge them, for example through a simple sign-off. Policy content is also a natural subject for security awareness sessions, where examples make the rules easier to remember. If a policy changes how people do their jobs, give them time and support to adjust.
Keeping policies current
Policies drift out of date as tools, laws and working habits change. Build maintenance into the process:
- Set a review date on every policy; annually is a common choice, though some topics warrant more frequent checks.
- Review after significant events, such as a security incident, a major system change or a change in regulations.
- Keep a version history so you can see what changed and why.
- Retire policies that no longer apply instead of letting them linger.
- Track exceptions. If the same exception keeps being requested, the policy may need to change.
Where a rule requires changes to systems, it helps to connect it to your change management process so that exceptions and updates are approved and recorded consistently.
Common mistakes
- Copying a template word for word without adapting it to the organization
- Writing for auditors rather than for staff
- Mixing policy statements and step-by-step instructions in one long document
- Leaving owner and review dates blank
- Creating more policies than anyone can realistically follow
- Forgetting contractors and temporary workers
A practical starting point
If you are starting from nothing, pick the two or three topics that matter most, often acceptable use, passwords and data handling, and write short, clear versions of each. Get them approved, publish them, and set review dates. Add more as needs arise. A small set of policies that people understand and follow is generally more valuable than a large library that nobody reads.