Appearance
Policy Lifecycle
A policy is not a document you write once. It is a governed record with a life, and most policy failures are lifecycle failures rather than drafting failures.
The lifecycle
The three failure modes
Policy estates fail in three predictable ways. The lifecycle is designed against each.
1. The policy nobody approved
A document circulating as "the policy" that was never formally approved. Guard: publication requires the governed approval chain. A policy in Draft or Under Revision is visibly not in force.
2. The policy that quietly aged
A policy published in 2021, never reviewed, still cited as current. Guard: review and expiry dates, the Expiry Monitor, and automatic transition to Expired.
3. The policy that changed without anyone noticing
A published policy edited in place.
Semantic Doctrine: Published != Compliant
A published policy is the output of internal governance. It establishes that the organization has authored, reviewed, and authorized an internal requirement.
- Publication does not equal compliance: Having a published policy does not certify regulatory compliance with supervisory rules.
- Publication does not equal control effectiveness: Control effectiveness is determined by objective evidence, technical indicators, and testing, not by the policy's publication status.
- Publication does not equal operationalization: A published policy must be operationalized against owners, controls, and assets to have operational effect.
A published policy must enter revision before re-approval
A policy in Published cannot be resubmitted for approval directly. It has to enter revision first.
This prevents a published policy being quietly re-approved without a version change — which would leave two different documents having been "the published policy" with no record of the difference.
The Expiry Monitor
Where to find it: Policy Governance, then Expiry Monitor (/governance/expiry).
The monitor shows the policy estate against its dates:
| View | Shows |
|---|---|
| Due for review | Review date approaching |
| Overdue for review | Review date passed, still published |
| Approaching expiry | Expiry date approaching |
| Expired | Past expiry |
Overdue review is the leading indicator; expiry is the lagging one
A policy overdue for review is still in force and still being relied on. By the time it expires, the organisation has usually been operating against an unreviewed document for months.
Work the overdue-review list, not the expired list.
Review dates and expiry dates project into the GRC Calendar as governance obligations.
Recording a review
A review records that someone with authority looked at the policy, concluded whether it remains fit, and set the next review date.
A review can conclude:
| Conclusion | Next step |
|---|---|
| Remains fit for purpose | Set the next review date; the policy stays published |
| Requires amendment | Move to revision; the current version stays in force until the new one is published |
| No longer required | Archive |
Requires policy.review.
A review is not an approval
Recording a review confirms the policy was examined. It does not republish it. If the review concludes the policy needs changing, the changed version goes through the full approval chain.
What happens when a policy expires
An expired policy is no longer in force. That has consequences worth being explicit about:
- Obligations whose only policy coverage was that policy become uncovered in gap analysis
- Attestation campaigns against it become meaningless
- Controls that cite it as their authority have no current authority
None of these are automatic compliance failures, but all three are the kind of thing an auditor finds and asks about.
Setting review cadence
| Policy type | Typical cadence |
|---|---|
| Board-level policy | Annual |
| Operational standard | Annual or biennial |
| Procedure | On material change, with a periodic backstop |
| Policy responding to a specific regulation | Aligned to the regulation's own review cycle |
Whatever cadence you choose, set the expiry date beyond the review date with enough margin for the review and approval to complete. A policy whose review date and expiry date are the same day will expire during its own approval process.
Permissions
| Action | Permission |
|---|---|
| View the register and expiry monitor | policy.read |
| Create and update policies | policy.write |
| Record a review and set the next review date | policy.review |
Example
Policy: Information Security Policy v3.0.
| Date | Value |
|---|---|
| Effective | 1 April |
| Review | 1 March the following year |
| Expiry | 30 April the following year |
The two-month gap between review and expiry is deliberate: it allows the review, any revision and the full approval chain to complete before the current version lapses.
What happened:
| Date | Event |
|---|---|
| 15 Jan | Expiry Monitor shows the policy as approaching review; calendar event and Workbench task raised |
| 1 Mar | Review recorded. Conclusion: requires amendment to reflect a new regulatory obligation |
| 3 Mar | Policy enters revision; v3.0 remains in force |
| 22 Mar | v3.1 submitted for approval |
| 8 Apr | v3.1 approved and published; v3.0 superseded |
| 30 Apr | v3.0 would have expired; it had already been superseded |
The margin did its job. Without it, the review conclusion on 1 March would have left five weeks to revise, approve and publish — and the organisation would probably have been operating on an expired policy through May.
Troubleshooting
"A policy expired despite being reviewed." A review does not extend the expiry date on its own. Set the next review and expiry dates as part of recording the review.
"An expired policy still appears in gap analysis coverage." It should not, and it does not count as coverage. Check whether a different policy is also mapped.
"I cannot revise a published policy." Move it into revision first. That is the required step.