Risk Registers and Treatment Plans

Risk Registers: Structure and Purpose

A risk register is a living document that tracks everything that could go wrong — and what you're doing about it. Without a register, risks live in Slack threads, email inboxes, and individual memories. When someone leaves the company, their knowledge of a critical risk leaves with them. The register makes risk visible, owned, and trackable.

What goes in a risk register

Each entry in a risk register captures the full lifecycle of a risk:

risk_id: RISK-001
title: Unencrypted database backups stored in public S3 bucket
description: >
  Database backups are written to an S3 bucket that has a public-read ACL.
  If discovered, this would expose all customer PII.
category: Data Exposure
likelihood: High
impact: Critical
risk_score: 16  # likelihood (4) x impact (4)
status: Open
owner: jane.doe@company.com
treatment: Mitigate
mitigation_plan: >
  1. Enable Block Public Access on the bucket (completed)
  2. Enable default encryption with AES-256 (in progress)
  3. Implement pre-signed URL access for restore operations (planned)
residual_risk: Low
due_date: 2026-10-15
review_date: 2026-11-15

The essential fields:

• Risk ID: Unique identifier for tracking
• Title and description: What is the risk and why does it matter
• Category: Data exposure, availability, compliance, operational, etc.
• Likelihood: How likely is this risk to materialize? (1-5 or Low/Medium/High)
• Impact: How bad would it be if it did? (1-5 or Low/Medium/High)
• Risk score: Likelihood x Impact — used for prioritization
• Owner: The person accountable for the treatment plan
• Treatment: What you're doing about it (mitigate, transfer, accept, avoid)
• Residual risk: The risk remaining after treatment
• Review date: When this risk will be re-evaluated

Risk scoring

Risk scoring prioritizes limited resources. A simple matrix:

Scores map to priority:

• 12-16: Critical — treat immediately
• 8-11: High — treat within 30 days
• 4-7: Medium — treat within 90 days
• 1-3: Low — accept and monitor

The register as a communication tool

The risk register serves multiple audiences:

• Security team: Tracks treatment progress and identifies risks that need escalation
• Engineering teams: Understands what risks exist in their systems and what's being done
• Leadership: Sees the overall risk posture and where resources are allocated
• Auditors: Verifies that risks are identified, owned, and treated

A register that isn't shared is a register that doesn't exist. Regular risk reviews (monthly or quarterly) keep it current and visible.

Risk Treatment Options and Decision Framework

Once a risk is identified and scored, you must decide what to do about it. There are four treatment options, and the right choice depends on the risk's nature, the cost of treatment, and the organization's risk appetite.

The four treatment options

1. Mitigate — Reduce the likelihood or impact of the risk

Mitigation is the most common treatment. It involves implementing controls that reduce the risk to an acceptable level:

Risk: Unpatched web server vulnerable to CVE-2024-1234
Mitigation: Apply security patch, implement WAF rule to block exploitation
Residual risk: Low (patch applied, WAF provides defense in depth)

Mitigation is appropriate when:

• The cost of treatment is less than the potential impact
• You have the capability to implement the control
• The risk cannot be fully eliminated, only reduced

2. Transfer — Shift the risk to a third party

Transfer moves the financial burden of the risk to someone else:

Risk: Data breach exposing customer PII
Transfer: Purchase cyber insurance policy with $5M coverage
Residual risk: Low (financial impact transferred to insurer)

Transfer is appropriate when:

• The risk is financial in nature
• Insurance or contractual terms can shift the burden
• The cost of treatment exceeds the cost of transfer

Common transfer mechanisms:

• Cyber insurance policies
• Contractual indemnification clauses
• Outsourcing to a managed security provider

3. Accept — Acknowledge the risk and take no action

Acceptance is a deliberate decision, not an absence of action:

Risk: Legacy system with known vulnerabilities that cannot be patched
Acceptance rationale: System is isolated in a private subnet, no internet access,
  scheduled for decommission in 6 months. Cost of mitigation exceeds
  residual risk given the isolation controls.
Compensating controls: Network isolation, monitoring, access restrictions
Review date: 2027-03-01 (before decommission deadline)

Acceptance is appropriate when:

• The cost of treatment exceeds the potential impact
• The risk is low likelihood and low impact
• Compensating controls reduce the risk to an acceptable level
• The risk is temporary and will be eliminated by a planned change

Critical requirement: Accepted risks must have:

• A named owner who accepts the risk
• Documented rationale for the decision
• A review date — accepted risks must be re-evaluated
• Compensating controls where possible

4. Avoid — Eliminate the risk by not engaging in the activity

Avoidance is the most definitive treatment — you stop doing the thing that creates the risk:

Risk: Storing customer data in a country with weak privacy laws
Avoidance: Do not store data in that country; use a region with strong privacy laws
Residual risk: None (activity is not performed)

Avoidance is appropriate when:

• The risk is unacceptable regardless of treatment
• The activity creating the risk is not essential
• The cost of alternative approaches is acceptable

The decision framework

Choosing a treatment option follows a logical progression:

1. Can we avoid the risk? If the activity isn't essential, stop doing it.
2. Can we transfer the risk? If insurance or contracts can shift the burden, transfer it.
3. Can we mitigate the risk? If controls can reduce it to an acceptable level, implement them.
4. Can we accept the risk? If the residual risk is within appetite and the cost of treatment is too high, accept it with documentation.

Residual risk and risk appetite

After treatment, the remaining risk is the residual risk. This must be compared against the organization's risk appetite — the level of risk the organization is willing to accept:

Inherent risk: 16 (High likelihood, Critical impact)
After mitigation: 4 (Low likelihood, Low impact)
Risk appetite threshold: 6
Decision: Residual risk (4) is within appetite (6) — treatment is sufficient

If residual risk exceeds risk appetite, additional treatment is required. The risk register should document this analysis.