What a good risk treatment plan includes

A risk treatment plan states which risk you are addressing, the response chosen, the specific actions, who owns them, the deadline, the cost, the expected rating afterwards, and who approves the remaining risk. If a reader cannot tell what will change by when, it is a wish list, not a plan.

The fields

1. Risk reference. The register ID and the scenario sentence.
2. Current rating. With the date it was assessed.
3. Response. Reduce, avoid, share or accept, with a reason.
4. Actions. Small, verifiable tasks, each with an owner and a date.
5. Resources. Budget, people and tools needed.
6. Target rating. The residual risk you expect once actions are done.
7. Success evidence. How you will prove the action worked.
8. Approver. The person who accepts the remaining risk.
9. Status and review date.

NIST IR 8286B describes recording risk priorities, response information and projected costs in the register so leaders keep an enterprise view and can confirm or adjust strategy. Those are the same ideas applied at plan level.

A short example

• Risk: R-12, an attacker uses a leaked deployment token to push code to production.
• Current rating: High, assessed in September.
• Response: Reduce.
• Actions: Move deployment to short lived credentials (platform lead, six weeks). Restrict who can trigger production deploys (engineering manager, three weeks). Alert on deploys outside the release window (security engineer, four weeks).
• Target rating: Medium.
• Evidence: Configuration export, a test of a revoked token, and a sample alert.
• Approver: Head of engineering.

Checks before you approve a plan

• Does each action reduce likelihood or impact? Training slides rarely change the rating of a technical risk.
• Is the target rating realistic? Controls usually reduce risk, not remove it.
• Are dates credible? Compare to team capacity, not to the audit calendar.
• Is evidence defined now? Choosing it later invites weak proof.
• Do actions depend on another team? Name that team and get agreement.

Why plans stall

The usual causes are an owner without budget, actions too large to start, and no one checking progress. Break big actions into steps of a few weeks. Review open plans on a fixed rhythm and escalate any that slip twice.

Plans and audits

Frameworks that expect a managed risk process commonly look for a documented assessment, defined treatment decisions and evidence they were carried out. Check the exact wording of the framework you follow rather than assuming. A clear plan with dated evidence tends to serve all of them.

Quick check

Sources

• NIST IR 8286B
• NIST SP 800-30 Rev. 1

Last reviewed: 19 October 2026.