An IT director recently showed me his “security policy binder” with some pride.
When I opened it, I found 47 pages of detailed instructions on how to configure a firewall, how to name files, and how to run a backup.
Those were not policies. They were procedures bundled together.
This confusion is widespread, even (especially) in organizations certified to ISO 27001. And it creates problems: documents that are impossible to maintain, employees who do not know what is expected of them, and auditors who raise nonconformities.
The fundamental distinction
Policy says WHAT. Procedure says HOW.
It is that simple, but it changes everything about how you structure your security documentation.
A policy sets the rules, the expectations, and the boundaries. It reflects the organization’s values and legal obligations. It is addressed to everyone, and it does not change often.
A procedure describes the concrete steps to complete a specific task. It is addressed to the people who perform that task. It changes every time the process or the tool changes.
An example that makes it clear
Take access management.
The policy says:
“All access to the organization’s systems must be granted according to the principle of least privilege and reviewed at least once a year.”
The procedure says:
- Open the identity management system
- Select the account in question
- Check active rights against the access matrix
- Record the review in the shared register
- Notify the manager if a gap is found
Same topic, two completely different levels. The policy survives a tool change. The procedure has to be updated every time the tool changes.
Why the confusion is expensive
When you mix the two, this is what happens in practice:
- Your policies become impossible to approve: management has to validate every technical detail change, which freezes document updates
- Your procedures go stale fast: they are buried in “official” documents that nobody dares to touch
- Your employees are lost: they look for a clear rule and find a technical manual, or the reverse
- Your auditors flag gaps: ISO 27001 requires you to demonstrate that your policies exist AND that your procedures are applied. If the two are fused, nothing is clearly demonstrable
How to structure your documents properly
A healthy structure looks like this.
Level 1: policy
Approved by management, reviewed annually.
- Short: 1 to 3 pages maximum
- Management language, not technical language
- Answers: why, what, for whom, what consequences
Level 2: procedure
Owned by IT or process owners, updated as needed.
- As long as it needs to be
- Operational language, numbered steps
- Answers: how, with what, in what order, who validates
Level 3: work instructions or guides (optional)
- Specific to a tool, a system, or a context
- Screenshots, checklists, forms
Questions to ask yourself for every document
Before you create or classify a document, ask:
- Does this say what is expected, or how to do it?
- Does management need to approve this, or the operational team?
- Does this change if we change tools?
- Do all employees need to read it, or only the people who perform the task?
If it changes as soon as you change tools, it is a procedure. If management has to approve it on every update, you have probably fused the two levels by mistake.
A policy without a procedure is a rule nobody knows how to apply. A procedure without a policy is a recipe with no reason to exist.
Both are necessary. Both play a different role. And both must be maintained separately to stay useful.
In short: if your policy is more than three pages, it probably contains procedures. If your procedure says “the organization commits to,” it has become a policy.
Separate the two. Assign an owner to each level. And make sure your policies are read by management and your procedures by the teams that apply them.
It is a simple discipline, but it is the difference between documentation that does something and documentation that sleeps in a shared folder nobody opens.
Is your binder mixing the two? Let’s talk.