ISO 27001 policy approval evidence: version and decision
An approval is only useful if you can identify what was approved.
If you look after a policy library, you may have a current document, an approval message and an acknowledgement list. The problem begins when those three records refer to different versions, or nobody can show when the approved rules took effect.
The information security management standard published by the International Organization for Standardization and the International Electrotechnical Commission is commonly called ISO 27001. Relevant references include clauses 5.2, 7.3 and 7.5, with Annex A reference A.5.1 for policy arrangements. This guide paraphrases the practical task without reproducing licensed standard text.
For useful policy approval evidence, connect the exact version, authorised decision, effective date, communication and review. You do not need a long procedure to begin. You need a short trail that survives the person who organised it moving to another role.
What matters this week, and what can wait
This week, select one policy that directs important work, such as access management. Find the current approved version, its decision record and where staff obtain it. Confirm that the owner and approver agree which version is in force.
If they disagree, investigate before asking everyone to acknowledge another copy. Preserve what actually happened rather than backdating a cleaner-looking history.
A new template design, rewriting every introductory paragraph and migrating the whole library can safely wait. A contradictory rule or missing decision affecting current security operations cannot. Your useful output today is one complete policy record with a named owner and an explainable status.
Separate the stages of a policy's life
A policy describes the required direction and responsibilities. A procedure or operating instruction explains how a particular task is carried out. Mixing both can make small technical changes unnecessarily disruptive to governance.
Whatever document structure you choose, keep the following stages distinct:
| Stage | Question it answers | Useful record |
|---|---|---|
| Drafting | What is being proposed, and by whom? | Draft version, owner and change rationale |
| Review | Has the proposal been checked for suitability? | Reviewer comments, responses and unresolved issues |
| Approval | Did an authorised person accept this version? | Decision linked to an exact document version |
| Release and effective date | Which version is available and when do the rules apply? | Controlled release location and effective date |
| Communication | Who was told, by what method and when? | Audience, message or briefing record |
| Acknowledgement | Who recorded receipt or acceptance of the stated version? | Person or group reference, version and date |
| Effectiveness and review | Are the rules understood, workable and current? | Checks, feedback, review outcome and next action |
Approval is not communication. Communication is not acknowledgement. Acknowledgement alone is not proof that someone understood a requirement or followed it in practice.
That distinction matters when you report progress. “All staff acknowledged the policy” and “the access-removal process operates as intended” are different claims requiring different evidence.
Keep a minimal version and decision record
Download the blank policy review log, open the fictional example, or use the workbook. No registration is required. These are internal operating aids, not official standard forms.
For each approved or reviewed version, record:
- A stable policy reference and title.
- The owner and intended audience.
- Version identifier and controlled content location.
- Change summary and reason for the change.
- Reviewer and review outcome, including unresolved concerns.
- Approver, authority basis, decision and decision date.
- Release date and effective date.
- Communication and acknowledgement references.
- Related risks, controls and operational actions.
- Next review date and material-change triggers.
Make sure the version identifier refers to an immutable snapshot or otherwise controlled record of the approved content. A message saying “approved” alongside a document that can be freely overwritten is weak evidence of what the decision covered.
The method need not be elaborate. A controlled document repository plus a clear approval record may be sufficient for the task. The important point is that an authorised reviewer can reconstruct the sequence and retrieve the right content.
A fictional policy change from draft to use
The following example is invented teaching material. It represents no real organisation, policy decision or employee.
A fictional team changes its access policy to require an owner and expiry decision for temporary supplier access. The practitioner prepares version 1.2 and explains the change. The service owner reviews whether the support process can operate under the proposed rule.
An authorised approver accepts that exact version, with an effective date after a short implementation period. The operations owner updates the access procedure, identifies temporary accounts requiring review and prepares the relevant service owners for the change.
The practitioner records which audience received version 1.2 and any acknowledgements. A later operating check samples whether temporary supplier accounts have the expected ownership and expiry decisions.
| Evidence | What it supports | What it does not establish alone |
|---|---|---|
| Approved version 1.2 and decision | Authorised acceptance of the specific rule | That anyone received the new version |
| Release and communication record | Availability and communication to the intended audience | That recipients understood the change |
| Acknowledgement record | A recorded response associated with that version | That the rule operates on every account |
| Sample operating review | Whether selected access records follow the changed process | Complete coverage outside the reviewed sample |
If an operating check finds missing expiry decisions, keep the finding and assign corrective action. Do not amend the acknowledgement evidence to make it appear that the implementation succeeded.
Choose an approver who has the right authority
The document owner coordinates maintenance. The reviewer checks suitability. The approver makes the authorised decision. Those roles may overlap in a small team, but the overlap should be intentional and visible.
Record the authority basis through the organisation's governance arrangements. An approval by an available colleague is not necessarily the required management decision.
Give reviewers a change summary and focused questions. Ask whether the requirements are workable, consistent with obligations and supported by the processes that will implement them. A review that only corrects spelling may miss a significant operational contradiction.
If the change raises contractual or legal questions, obtain qualified advice. Software cannot make legal determinations about the adequacy of a policy or the enforceability of a particular requirement.
Handle dates without rewriting history
The approval date is when the decision was made. The release date is when the controlled version was made available. The effective date is when the organisation intends the new requirements to apply. The next review date is when suitability is reconsidered.
They may be the same, but they are not interchangeable.
If a document was used before formal approval, record the sequence and decide what corrective action is needed. Do not manufacture a retrospective signature or change the date to fit the intended process.
Keep superseded versions retrievable for authorised people who need to establish what applied at an earlier time. Mark them clearly to prevent accidental use. Set retention according to justified need and applicable obligations rather than keeping every personal acknowledgement indefinitely.
Record reviews even when nothing changes
A review can conclude that a policy remains suitable. Record who reviewed it, which version they examined, the basis of the conclusion and when it will be reconsidered.
Choose review intervals that fit the policy, risks and applicable requirements. This article does not prescribe one universal annual interval. Bring forward a review after a material service change, incident, new obligation or evidence that the rule is not working.
Avoid giving every policy the same date solely to simplify a dashboard. Staggering operational work may be sensible, but urgent changes must not wait for a convenient calendar slot.
Where a control owner reports that the policy cannot be implemented as written, resolve the disagreement. Either the operating process needs improvement or the policy needs a justified change through the same review and approval trail.
Connect the policy to controls and evidence
The controls management guide explains how to organise the measures that put a policy into practice. The evidence collection guide helps keep the original record, scope and review context clear.
For a changed rule, identify the control owners affected and whether procedures, training, system settings or supplier arrangements must change. Keep a reference from the decision to those actions. A published document with no implementation owner can remain only a statement of intent.
GRCompliance Core documents policies generated from templates, controls and linked evidence. The public product homepage also describes approval workflows and version control. These public descriptions do not establish that every workflow is identical in every edition.
Evaluate one fictional policy using the capabilities available in your chosen edition. Check how the approved version, decision and evidence can be retained; use a supporting controlled record where necessary. No specific approval button, legal validation, automatic acknowledgement import or guaranteed audit outcome is assumed here.
Try the live demo with fictional content only, or inspect the free open-source Core. A template helps with structure. It cannot decide which rules your organisation should approve.
Frequently asked questions
What should a policy approval record identify?
Identify the exact content version, authorised approver, decision, date and any conditions. Connect it to the controlled document and distinguish release, effective and review dates.
Does acknowledgement prove that staff understand a policy?
No. It records a response associated with the policy version. Briefings, feedback, knowledge checks and operating evidence may be needed to assess understanding and actual behaviour.
Should a review be recorded when the text stays unchanged?
Yes. Keep the version reviewed, reviewer, date, conclusion and next review or trigger. An unchanged document without a review record does not show that its suitability was considered.
Does policy software guarantee conformity or certification?
No. It can organise versions, decisions and records. People remain responsible for authority, content, communication and implementation, and software cannot make legal determinations or guarantee certification.
Sources
Reviewed 7 November 2026. Standard references are paraphrased; the log and examples are editorial operating suggestions.
- International Organization for Standardization: information security management standard; clause references 5.2, 7.3 and 7.5; Annex A reference A.5.1.
- Information security controls guidance overview.
- GRCompliance public product homepage: policy lifecycle, approval and version-control descriptions; edition behaviour requires checking.
- GRCompliance Core documentation: verified policy, control and evidence capabilities.
Try the live demo
Open the public demo to see the product. Use fictional data only.