Use this when policy reviews come due on their cadence, when an audit is approaching and the approval records are stale, or when a big change (new product, acquisition, reorganisation, new law) makes the whole set suspect. You get, in a new folder ./policy-review-cycle-refresh/: a table of every policy with its owner, approver and review status (review-register.md), one short note per policy showing each proposed edit as old text and new text with the reason (in changes/), and a plan for telling staff what changed (communication-plan.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Each policy's approver decides; the agent proposes.
Inputs to gather
Read the policy set with each document's version, owner, approver and last approval record. Then collect what happened since each last approval: the incident log, internal and external audit findings, the exception or waiver register, the risk register changes, new or retired systems and vendors, organisation changes, and customer contract changes. Ask the reader, in one message: who approves which policies, whether the company has written document control rules (versioning, who may approve editorial changes), and whether any law or framework scope changed.
Step 1: build the review register
In the review table (review-register.md), write one row per policy: id, title, current version, owner role, approver role, last approval, review due, the evidence window considered (last approval to this review), the version staff last acknowledged, and status (due, overdue, not due, proposed for withdrawal). Flag documents with no approval record at all; for an auditor those are drafts, whatever their file name says. Flag owners who have left or changed role; the first fix is a new owner, not new text. Do the same for approvers: where the approver role is vacant or no longer senior enough, propose an interim approver to be named and minuted, or the cycle stalls. Flag policies staff acknowledged at an older version than the one now in force. Propose withdrawal, with the last version archived and the approver's sign-off, for a policy whose subject no longer exists, instead of carrying it as a permanent "no change" row.
Step 2: collect the triggers per policy
For each policy, list what since its last approval touches it, with a source:
- Incidents and near misses where the policy was silent, wrong or ignored.
- Audit findings that cite it or the practice it governs.
- Exceptions granted against it. Three or more similar exceptions mean the policy is wrong, not the people asking.
- New systems, vendors, locations or services the policy does not cover, and retired ones it still names.
- Changes in law, contracts or framework scope. Run a framework lookup when a framework's expectation for the policy may have changed, rather than assuming.
A policy with no triggers can still be reviewed: read it against current practice in 15 minutes and record "reviewed, no change" with the reviewer and the review date. That record is the evidence the review happened.
Step 3: propose changes and classify them
Write a change note per policy (changes/<policy-id>.md) with each proposed edit as old text, new text and the trigger behind it. Classify each edit:
- Editorial: wording, formatting, renamed teams or tools, broken references. Usually approved by the owner and versioned as a minor change (2.0 to 2.1) if the document control rules allow it.
- Substantive: changes what someone must do, how often, or who decides. Goes to the policy's approver and versioned as a major change (2.1 to 3.0).
- Contested: the owner and another stakeholder disagree, or the change raises cost. Goes to the approver as a decision with options.
Keep edits small and traceable. A policy rewritten end to end in a review cycle loses its history and forces a full re-read by everyone.
Step 4: prepare version history and approvals
For each policy, draft the version history entry (version, summary of change in one line, trigger, approver role) and an approval block for the approver to complete. Superseded versions are archived, not deleted; ask where the company keeps them and for how long. Stagger the next cycle: propose a calendar that spreads reviews across the year by owner, so the next review is not a single week of rubber stamps before the audit.
Step 5: plan communication
In the communication plan (communication-plan.md), list per substantive change: who is affected, what changes for them in at most three bullets, the channel, and whether a new acknowledgement is needed. Editorial changes need no announcement. Changes affecting behaviour (a new reporting deadline, a new approval step) need one, plus an update to onboarding material, and they feed the awareness or training plan as an input. Keep the plan: it is the record that people were told.
What good looks like
- The best reviewer starts with the exception register and the incident log, because they show where the policies and the work have parted ways.
- The common mistake is the rubber stamp: every policy re-approved on the same day, version numbers bumped, no text changed and no trigger recorded. The tell: an auditor asks what changed in the access policy after the incident in the incident log, and nobody can answer from the record.
- Good output shows, per policy, the triggers considered, the edits made or the reason none were needed, the approver and the communication sent. A reviewer can trace any line of the current text to the version and decision that put it there.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-policy-review-cycle-refresh
Rules
- MUST cite the trigger and its source for every proposed change.
- MUST record "reviewed, no change" with reviewer and review date when a policy needs no edit.
- MUST write outputs only inside
./policy-review-cycle-refresh/ and ask before overwriting.
- NEVER mark a policy approved or change its version in the live document set; the approver does.
- NEVER delete or overwrite a superseded version.
- NEVER put names or personal data in the register; use roles.