Risk Treatment Plans That Work (And Why Yours Probably Doesn't)

TL;DR

Your risk treatment plan is not a risk register. It’s the bridge between “we found problems” and “auditors believe they’re fixed.” A treatment plan needs four things a spreadsheet usually misses: specific control mapping, named owners (not teams), verifiable deadlines, and evidence links.

The Problem With Most Treatment Plans

You run a risk assessment. You get a register full of risks with CVSS-like scores and descriptions like “Unencrypted data at rest” or “No MFA on admin panel.” You dump them into a spreadsheet, assign an owner, set a due date, and call it a treatment plan.

Three months later, the auditor asks: “How do you know this risk is treated?”

The owner says: “We upgraded the database.” The auditor says: “Does that encryption use AES-256 or TDE or column-level or something else? Show me the config.” The owner opens the spreadsheet. The due date was “Q3.” It is now Q4.

The treatment plan failed because it never specified what “treated” actually means.

What a Treatment Plan Actually Is

ISO 27001:2022 Clause 6.1.3 requires documented information about risk treatment. The standard doesn’t prescribe a format, but every audit I’ve seen treats the treatment plan as the single most important document after the SoA.

A treatment plan answers four questions for each risk:

Question	Spreadsheet usually gives	Treatment plan should give
What are we doing about it?	“Implement encryption”	“Enable TDE on all PostgreSQL 15+ instances using AES-256, documented in runbook-042”
Who owns it?	“DevOps team”	“Jane Doe (DBA lead) — confirmed individually”
When is it done?	“Q3 2026”	“2026-08-15 (completed)” or “2026-09-01 (in progress, 60%)”
How do we verify it?	N/A	“runbook-042 §3 shows `pg_hba.conf` and `postgresql.conf` settings; screenshot in evidence-2026-0814”

Four columns. That’s it. If any risk in your register doesn’t have all four, the treatment plan is incomplete.

Treatment Options: More Than “Fix It”

ISO 27001 defines four risk treatment options. Most teams only use two. Here’s when each matters:

1. Modify (Mitigate)

The obvious one. Apply a control that reduces likelihood or impact.

Risk: Unauthenticated API endpoint exposes user data
Treatment: Add API key validation to /api/v1/users
Control mapped: A.8.9 (Configuration management) + A.8.5 (Secure authentication)
Owner: Backend lead
Evidence: API gateway config + test results

2. Avoid

Stop doing the thing that creates the risk. Sometimes the best treatment is walking away.

Risk: Legacy payment processor charges 2.9% + $0.30 per transaction, creates PCI scope
Treatment: Migrate to Stripe (PCI SAQ-A, simpler scope)
Control mapped: A.5.19 (Supplier relationships) + A.8.16 (Monitoring)
Owner: Payments lead

Avoid doesn’t always mean “shut down.” It means “the risk lives in the old process, not the new one.”

Insurance, SLAs, sub-processors — risk sharing moves some of the impact elsewhere.

Risk: S3 bucket leak exposes 2M records
Treatment: Cyber insurance policy #2026-0847 (covers up to $2M per incident)
Control mapped: A.5.27 (Cybersecurity insurance)
Owner: CTO
Evidence: Policy document, premium schedule

4. Accept

This is the most abused option. “Accept” means you consciously decided the cost of treating exceeds the impact. But it’s not valid unless you’ve checked.

Risk: Internal tool uses self-signed TLS
Treatment: Accept — tool is accessed only via VPN, used by 3 team members
Control mapped: A.8.24 (Use of cryptography) — partial
Owner: Infrastructure lead
Review date: 2026-12-01 (revisit when used by >10 people or exposed externally)

The acceptance trap: Teams mark risks as “accepted” and never look at them again. A treatment plan with accepted risks needs a review date — when will you re-check that acceptance is still valid?

The Evidence Problem

This is where most treatment plans die. You’ve mapped controls, named owners, set deadlines. Now what proves it?

✓ Control implemented: TDE enabled on production PostgreSQL
✗ Evidence linked: runbook-042 exists in Confluence
✗ Verification date: never
✗ Auditor-ready: config screenshot from 2026-08-14 buried in a Slack thread

A treatment plan is only as good as its evidence trail. For each risk, link:

Implementation evidence — config files, screenshots, runbooks, PR links
Verification record — who checked it and when
Remaining risk score — after treatment, what’s left?

A Real Example: IDOR in User Profile API

Here’s a treatment plan for an actual bug bounty finding, generalized:

risk_id: R-2026-0147
title: IDOR in /api/v2/users/{id} allows listing any user's profile
risk_score: 7.2 (High)
treatment_option: modify

treatment_plan:
  control_mapping:
    - A.8.3 (Information access restriction)
    - A.8.24 (Data leakage prevention)
  
  implementation:
    description: "Add session-bound user ID check in middleware; return 403 for mismatch"
    owner: "@jdoe"  # individual, not team
    deadline: "2026-08-15"
    status: completed
    
  evidence:
    - "PR #1847: middleware/user_id_check.go"
    - "Test results: POST /api/v2/users/123 with session for user 456 → 403"
    - "Load test: 0 false negatives across 10K random user pairs"
    
  remaining_risk:
    score: 3.1 (Low)
    residual: "Bulk export endpoint /api/v2/users/export still accepts arbitrary IDs"
    next_action: "Add pagination token + session validation — target 2026-09-15"

Three things make this auditor-ready:

The control mapping connects the treatment to ISO 27001. The auditor can trace “IDOR fixed” → A.8.3 → “implemented.”
The evidence is linked, not described. You know where to find the proof.
The remaining risk is called out. Nothing is treated to zero. Good treatment plans show what’s still exposed.

When Treatment Plans Break

I’ve seen treatment plans fail for the same four reasons, over and over:

1. Owners are teams, not people

“DevOps owns this.” Which DevOps person? When they leave, does the treatment die with them?

2. Deadlines are quarters, not dates

“Q3” means nothing to an auditor. “2026-07-31” means “it’s late.” If you need quarters, add a specific day: “2026-07-31.”

3. Evidence is a folder name

“evidence/risk-147/” — inside it, three files with no dates and no context. An auditor opens it and has no idea what any file represents.

4. Accepted risks are never revisited

“Accept” is not “ignore.” Every accepted risk needs a review trigger: “re-evaluate when user count > 100” or “re-evaluate on 2026-12-01.”

The Minimal Viable Treatment Plan

If you’re starting from zero, build this first:

Spreadsheet columns:
1. Risk ID
2. Risk description (one line)
3. Treatment option (modify/avoid/share/accept)
4. Control(s) from Annex A
5. Owner (individual name)
6. Deadline (YYYY-MM-DD)
7. Status (not-started/in-progress/completed)
8. Evidence location (URL or path)
9. Remaining risk score (after treatment)
10. Review date (for accepted risks)

Ten columns. That’s it. Everything else is polish.

Conclusion

A risk treatment plan isn’t a status report. It’s a contract between the risk register and the auditor. It says: “For each risk, we chose an option, mapped it to a control, named an owner, set a deadline, and linked proof.”

The best treatment plans don’t look perfect. They show remaining risk honestly, link real evidence, and get revisited. The worst ones look clean in the spreadsheet and fall apart the first time someone opens them.

Build yours like an auditor will read it — because they will.