Use this on a register that already exists; for a first register, build one instead. You get two files in a new folder, ./risk-register-hygiene-review/: a spreadsheet you can open in Excel with one line per problem found in the register and a proposed fix for each (findings.csv), and a one-page summary with the counts, the five problems that matter most and the questions for each owner (summary.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The register itself is never edited: owners decide each fix.
Inputs to gather
Read the register (spreadsheet, export from a compliance platform, or document), the risk method, the treatment plan, the acceptance records, the incident log, audit and penetration test findings, the asset or service inventory and the supplier list. Ask the reader: when was the register last reviewed as a whole, which teams or systems changed since, and is there a date by which it must be clean.
Step 1: check structure and ownership
For each entry, add a line to the findings spreadsheet (findings.csv) when:
- The owner is a team, a tool or a departed person, not a role that can approve money or change a process.
- One owner holds more than about a third of all risks; nobody can review that many.
- Core fields are blank: scenario, inherent score, residual score, treatment decision, review date.
- The entry is a topic ("ransomware", "GDPR") rather than a scenario with a cause and a consequence.
Step 2: check freshness
Flag entries whose last review is older than the cadence the method states (often 12 months for the whole register, quarterly for top-band risks). Flag treatment actions past their due date with no status change, acceptances past their expiry or with no expiry at all, and clusters of live acceptances on one asset or supplier whose combined exposure no single signer approved. Flag risks tied to systems or suppliers that no longer appear in the inventory or supplier list; those may be closed, or the inventory may be wrong. Propose a disposition for each: closed with a reason and date (the row kept, not deleted), re-linked to the surviving asset, or the inventory corrected.
Step 3: check scoring
Compare scores against the method's anchors. Common faults, each a finding:
- Residual score equal to or higher than inherent with no explanation, or lower with no control named.
- Residual lowered by a control that has no evidence of running.
- Clusters: more than half the risks on one score, which means anchors are not being used.
- A risk scored with a scale the method no longer uses. Record the method version in force at review time so mixed-era scores get a rescoring plan.
- Impact rated below what a recent incident on the same scenario actually cost.
Pick the ten highest-impact entries and rescore them against the anchors in a separate column; show the difference, never overwrite the owner's score.
Step 4: check completeness against the company's own history
Every incident, near miss and audit or test finding should map to at least one risk. List each one that does not, with a draft scenario. Do the same for single points of failure visible in the supplier list and architecture (a sole hosting provider, one engineer holding the backup keys). This is where registers drift most: the business changes, the register does not. Check the other direction too: a completed treatment that added or dropped a control should show in the applicability statement.
Step 5: find duplicates and merges
Group entries that share asset, threat and consequence. Propose a merge where they also share an owner; propose keeping both and cross-referencing where the owners differ for good reason. Record which id survives.
Step 6: summarise for the owners
In the one-page summary (summary.md), give counts by finding type, the five findings that would worry an auditor or a board most (including whether top risks, overdue treatments and expired acceptances reached the last management review), and a list of questions grouped by owner so the clean-up is a short series of decisions. Estimate the effort: most registers of 30 to 60 risks clean up in two to four owner sessions of an hour.
What good looks like
- The first thing a good reviewer checks is the link between the incident log and the register. A company that had an incident and has no matching risk has a register nobody uses.
- The common mistake is cosmetic tidying: fixing typos and formats, leaving every score and owner as they were. The tell: the summary has many findings and none of them changes a decision.
- Every finding has evidence (the field, the date, the incident id) and a proposed fix the owner can approve or reject in one line.
- Rescored values sit next to the original, with the anchor that drove the change. Owners can argue with a reason; they cannot argue with an overwrite.
- The review ends with fewer, sharper risks and an owner per risk who knows what changed.
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-risk-register-hygiene-review
Rules
- MUST cite the field, record or document behind every finding.
- MUST keep proposed rescoring in a separate column next to the owner's score.
- MUST write outputs only inside
./risk-register-hygiene-review/ and ask before overwriting an existing file.
- NEVER edit, merge or close entries in the register itself, in a file or in a compliance platform.
- NEVER close or accept a risk on an owner's behalf.
- NEVER copy personal names from the register into the findings; use roles.