grcskills
Menu

Risk treatment plan drafting

Use this skill when a risk register has treatment decisions but no plan anyone can execute, or when someone asks "write the risk treatment plan", "turn the risk register into actions", "what do we do about our high risks", "treatment plan for the auditor", "budget the security roadmap from the risks" or "our treatment plan is just a list of controls". Turns each reduce, avoid or transfer decision into dated actions with an owner, budget, dependency and the record that will prove it was done, states the expected residual score and why, and adds interim measures for risks that stay high while the work runs. Writes a CSV plan and a short notes file.

RiskISO 27001SOC 2General

Use this after the register is scored and owners have chosen a treatment option for each risk above the acceptance threshold. You get two files in a new folder, ./risk-treatment-plan-drafting/: a spreadsheet you can open in Excel with one line per action (who does it, by when, what it costs and what record proves it is done) (treatment-plan.csv), and a short note with the open questions for owners and what does not fit the budget (plan-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Owners approve their own lines; the skill never approves a plan or a budget.

Inputs to gather

Read the risk register, the risk method (scales, acceptance threshold, who approves what), the current control set or applicability statement, open audit findings, the product and engineering roadmap, and any security budget line. Ask the reader in one message: what budget exists this year for security work, which teams have capacity in the next two quarters, and whether any customer or auditor has a date the plan has to meet.

Step 1: select the risks that need a plan

Take every risk above the acceptance threshold and every risk whose owner chose reduce, avoid or transfer. Risks the owner wants to accept go to a separate list for an acceptance memo, each with the approver the risk method requires at its score; flag any acceptance an owner made above their authority. They do not belong in this plan. If a risk has no treatment decision yet, list it in the plan note (plan-notes.md) as a question for its owner rather than inventing one.

Step 2: write actions, not control names

For each risk, write one to four actions as lines of the plan spreadsheet (treatment-plan.csv). An action is a change someone can finish: "enforce hardware keys for the 12 production admin accounts", not "implement access control". Each line carries: risk id, action, owner role, contributors, estimated effort in person-days, cash cost, dependency on other actions, target date, the record that proves completion (a config export, a signed contract, a ticket closed with a test result), the control in the reader's control set that the action strengthens, whether the applicability statement needs an update when it completes, and any open audit finding the action closes. Where the reader wants the control mapped to a framework, run a framework lookup instead of assuming the mapping.

Rules of thumb that keep the plan real:

  • No owner holds more than about a quarter's worth of actions at once; spread or sequence them.
  • Any action over 20 person-days gets split into milestones with their own dates.
  • Transfer (insurance, contract clauses, outsourcing) is an action too, with its own owner and evidence; it rarely moves likelihood and often leaves part of the impact.
  • Avoid means stopping an activity; write down who agreed to stop it.

Step 3: state the expected residual score and why

For each risk, estimate residual likelihood and impact after all its actions are done, and write one line on which part of the scenario each action changes. An action that reduces likelihood should name the step of the scenario it breaks. If the expected residual is still above the threshold, flag it: the owner will need a further action or an acceptance decision. The expected residual moves into the register only when the record proving the action exists, never on the target date or on plan approval.

Step 4: cover the gap while the work runs

For each risk scored in the top band, add an interim measure that applies now: tighter monitoring, a manual check, a temporary restriction. Long plans with nothing in the meantime leave the highest risks untouched for months, and that is what an auditor or an incident finds first.

Step 5: sequence, total and hand over

Order actions by risk reduction per person-day, then by dependency. Put the actions that must land before any customer or audit date first, and flag those that cannot make it. Total effort and cash per quarter and compare them with the capacity and budget the reader gave. If the plan does not fit, show the cut line in plan-notes.md and list what falls below it with the risk that stays open. Add a status column (not started, in progress, done with record, blocked) and a review cadence, typically monthly for top-band risks and quarterly for the rest.

What good looks like

  • Every line can be ticketed today: a named owner role, a date and a definition of done that is a record, not an opinion.
  • The plan fits inside the stated budget and capacity, or says plainly what does not fit and which risk that leaves open.
  • The common mistake is a plan that lists control names with a single year-end date. The tell: you cannot say which action finishes first or who does it, and every residual score drops to low on paper.
  • Residual scores are argued per action. A reviewer can follow why an action changes likelihood or impact, and challenge it.
  • Owners recognise their lines. A plan written without the people doing the work is a wish list.

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-treatment-plan-drafting

Rules

  • MUST give every action an owner role, a target date and the record that proves completion.
  • MUST show the cut line when effort or cost exceeds the capacity and budget the reader stated.
  • MUST write outputs only inside ./risk-treatment-plan-drafting/ and ask before overwriting an existing file.
  • NEVER approve the plan, a budget or a date on an owner's behalf.
  • NEVER lower a residual score without naming the action and the part of the scenario it changes.
  • NEVER put risks the owner wants to accept into the treatment plan; route them to an acceptance decision.