07 Risk Treatment Plan

After completing the information-security risk assessment, the organization knows:

Which risks exist.
How serious those risks are.
Which controls already exist.
What residual risk remains.
Which risks exceed the organization’s acceptance criteria.

The next question is:

What are we going to do about those risks?

This is the purpose of information-security risk treatment.

A Risk Treatment Plan, commonly abbreviated as RTP, converts risk-assessment results into specific actions.

The process can be visualized as:

Risk Assessment
      ↓
Residual Risk
      ↓
Risk Evaluation
      ↓
Treatment Decision
      ↓
Control Selection
      ↓
Risk Treatment Plan
      ↓
Implementation
      ↓
Validation
      ↓
Residual Risk Acceptance

For a GRC professional, the RTP is one of the most important operational ISO/IEC 27001 artifacts because it connects:

Risk
   ↓
Decision
   ↓
Control
   ↓
Owner
   ↓
Action
   ↓
Evidence
   ↓
Residual Risk

It also becomes an important input to the Statement of Applicability.

Learning Objectives

By the end of this lesson, you will be able to:

Explain the purpose of risk treatment.
Understand the relationship between risk assessment and risk treatment.
Identify risks requiring treatment.
Understand the major risk-treatment strategies.
Select appropriate controls.
Understand the role of ISO/IEC 27001 Annex A during treatment.
Identify additional controls beyond Annex A where appropriate.
Build a Risk Treatment Plan.
Assign treatment and control owners.
Establish realistic target dates.
Define treatment milestones.
Estimate target residual risk.
Obtain risk-owner approval.
Track treatment progress.
Validate treatment effectiveness.
Manage delayed or failed treatments.
Maintain evidence supporting treatment completion.
Connect the RTP to the Statement of Applicability.

1. Risk Assessment vs Risk Treatment

Risk assessment determines:

What is the risk?

How serious is it?

What controls already exist?

What residual risk remains?

Risk treatment determines:

What should we do about it?

Which controls are required?

Who will implement them?

When will they be completed?

What risk should remain afterward?

The two activities should be connected.

2. Why Risk Treatment Matters

A risk register without treatment becomes a list of problems.

For example:

Risk:
Privileged account compromise

Residual Risk:
High

If nothing happens afterward, the organization is only documenting exposure.

Risk management requires decisions.

A useful process is:

Identify
   ↓
Assess
   ↓
Evaluate
   ↓
Treat
   ↓
Monitor
   ↓
Reassess

3. When Does a Risk Require Treatment?

Compare residual risk against approved risk-acceptance criteria.

Example:

Residual Risk	Expected Response
Low	May be accepted
Moderate	Owner review
High	Treatment normally required
Critical	Immediate treatment/escalation

The organization’s approved methodology determines the actual thresholds.

4. Other Reasons Treatment May Be Required

Risk rating is not the only consideration.

Treatment may also be necessary because of:

Law.
Regulation.
Contract.
Customer commitment.
Internal policy.
Certification requirement.
Executive decision.

Example:

Residual Risk:
Moderate

Contract Requirement:
MFA mandatory

Decision:
Treatment required

5. Risk Treatment Strategies

Common risk-treatment strategies include:

Mitigate

Avoid

Transfer

Accept

Organizations may use slightly different terminology, but the underlying decisions are similar.

6. Mitigate Risk

Mitigation means reducing likelihood and/or impact through controls.

Example:

Risk:
Privileged account compromise

Treatment:
Mitigate

Possible controls:

Phishing-Resistant MFA

Privileged Access Management

Least Privilege

Access Reviews

Security Monitoring

Mitigation is one of the most common treatment approaches.

7. Reduce Likelihood

Some controls primarily reduce probability.

Example:

Threat:
Credential theft

Controls:
MFA
Conditional Access
Phishing Protection

These make successful compromise less likely.

8. Reduce Impact

Other controls primarily reduce consequences.

Example:

Risk:
Ransomware

Controls:
Immutable Backups
Disaster Recovery
Segmentation

An attack may still occur, but its impact can be reduced.

9. Defense in Depth

High-risk scenarios may require multiple controls.

Example:

Privileged Access Risk
      │
      ├── MFA
      ├── PAM
      ├── Least Privilege
      ├── Access Reviews
      └── Monitoring

Risk treatment should consider control combinations rather than automatically relying on one safeguard.

10. Avoid Risk

Risk avoidance removes the activity creating the risk.

Example:

Risk:
Unsupported legacy application exposed to the internet

Treatment:
Avoid

Action:
Decommission application

Another example:

Risk:
Highly sensitive data processed by unapproved SaaS

Treatment:
Avoid

Action:
Stop using the SaaS platform

11. When Avoidance Makes Sense

Avoidance may be appropriate when:

Exposure is unacceptable.
Controls are ineffective.
Treatment cost exceeds business value.
The activity is unnecessary.
Legal requirements prevent the activity.

Avoidance can sometimes be the strongest treatment.

12. Transfer Risk

Risk transfer shifts part of the financial or operational consequence to another party.

Examples:

Cyber Insurance

Contractual Indemnity

Outsourced Service

Managed Security Provider

However:

Risk transfer rarely transfers all accountability.

The organization may still retain regulatory, customer, operational, or reputational exposure.

13. Transfer Example

Risk:

Financial loss following cyber incident

Treatment:

Cyber Insurance

Transferred:

Part of financial impact

Still retained:

Customer impact

Reputation

Regulatory obligations

Operational disruption

14. Accept Risk

Risk acceptance means the organization knowingly retains the residual risk.

Acceptance may be appropriate when:

Residual risk is within appetite.
Treatment is disproportionate.
Compensating controls sufficiently reduce exposure.
Business requirements justify temporary acceptance.

Acceptance must be authorized.

15. Risk Acceptance Example

Risk:
Legacy system lacks modern MFA

Residual Risk:
High

Business Requirement:
System replacement scheduled in 6 months

Compensating Controls:
Restricted network access
PAM
Monitoring

Decision:
Temporary Acceptance

Approval should follow the defined risk authority matrix.

16. Acceptance Should Be Time Bound

Avoid:

Accepted forever

Better:

Acceptance Date:
01 September 2026

Expiration:
01 March 2027

Review:
Monthly

This prevents accepted risks from disappearing into the register.

17. Selecting the Treatment Strategy

Ask:

Can we reduce the risk?

Can we stop the risky activity?

Can some consequence be transferred?

Is the remaining risk acceptable?

Sometimes more than one approach is used.

Example:

Mitigate
+
Transfer
+
Accept remaining residual risk

18. Treatment Decision Matrix

A practical matrix may look like:

Risk Level	Typical Strategy
Low	Accept / Monitor
Moderate	Mitigate or Accept
High	Mitigate / Avoid / Transfer
Critical	Immediate Mitigation or Avoidance

This provides guidance rather than replacing management judgment.

19. Selecting Security Controls

Once mitigation is selected, determine which controls reduce the risk.

Control selection should consider:

Risk scenario.
Threat.
Vulnerability.
Business context.
Existing controls.
Legal requirements.
Customer requirements.
Cost.
Feasibility.
Expected effectiveness.

20. Risk-to-Control Mapping

Example:

Risk:
Unauthorized privileged access

      ↓

Risk Drivers:
Weak authentication
Excessive privileges
Poor monitoring

      ↓

Controls:
MFA
PAM
Least Privilege
Access Reviews
Logging

Controls should directly address the drivers of the risk.

21. Annex A and Risk Treatment

ISO/IEC 27001 Annex A provides a reference set of information-security controls.

During treatment, organizations should consider relevant Annex A controls.

However:

Annex A is not simply a checklist that must be implemented in full.

Control applicability should reflect organizational needs and risk.

22. Annex A Control Themes

The ISO/IEC 27001:2022 Annex A reference controls are grouped into four themes:

Organizational Controls

People Controls

Physical Controls

Technological Controls

These provide a useful reference during control selection.

23. Organizational Controls

Examples include areas such as:

Policies.
Roles.
Threat intelligence.
Asset management.
Supplier security.
Incident management.
Business continuity.
Compliance.

These often involve governance processes.

24. People Controls

Examples include:

Screening.
Employment responsibilities.
Awareness and training.
Disciplinary processes.
Remote-working security.
Event reporting.

Human risk should be considered during treatment.

25. Physical Controls

Examples include:

Physical boundaries.
Entry controls.
Equipment protection.
Secure areas.
Clear desk.
Environmental protection.

These may be important depending on ISMS scope.

26. Technological Controls

Examples include:

Identity management.
Authentication.
Access control.
Malware protection.
Backup.
Logging.
Network security.
Cryptography.
Secure development.

These often address technical risk scenarios.

27. Controls Beyond Annex A

Organizations may use additional controls.

Examples:

Cloud Security Controls

CIS Benchmarks

NIST Controls

PCI DSS Requirements

Industry Controls

Internal Engineering Standards

If a risk requires a control not represented by Annex A, the organization can still implement it.

28. Example Control Selection

Risk:

Public cloud storage may expose customer information.

Possible treatment:

Cloud Configuration Baseline

Infrastructure as Code

Policy as Code

CSPM

Encryption

Access Logging

Some controls may be more detailed than Annex A reference controls.

29. Existing vs New Controls

The treatment process should distinguish:

Existing Control

from:

New / Improved Control

Example:

Control	Current State	Treatment
MFA	Partial	Expand
PAM	Missing	Implement
Logging	Existing	Improve
Access Review	Existing	Automate

This makes the treatment plan actionable.

30. Risk Treatment Plan

The RTP should document how identified risks will be handled.

A practical RTP may contain:

Field
Risk ID
Risk Description
Residual Risk
Treatment Strategy
Selected Control
Treatment Action
Treatment Owner
Control Owner
Target Date
Target Residual Risk
Status
Evidence
Risk Owner Approval

31. Example RTP Record

Risk ID:
RISK-001

Risk:
Privileged account compromise

Current Residual Risk:
High

Treatment:
Mitigate

Action:
Deploy phishing-resistant MFA for privileged users

Treatment Owner:
IAM Director

Target:
31 December 2026

Target Residual Risk:
Moderate

Status:
In Progress

32. Treatment Owner

The treatment owner is responsible for delivering the remediation action.

Example:

Treatment:
Implement PAM

Treatment Owner:
IAM Engineering Manager

The treatment owner may differ from the risk owner.

33. Risk Owner vs Treatment Owner

Risk Owner
      ↓
Accountable for risk

Treatment Owner
      ↓
Accountable for remediation activity

Example:

Risk Owner:
CISO

Treatment Owner:
IAM Director

This distinction is important.

34. Control Owner vs Treatment Owner

The treatment owner may implement a control.

Once implemented, another role may own ongoing operation.

Example:

Treatment Project:
Deploy CSPM

Treatment Owner:
Cloud Security Architect

Ongoing Control Owner:
Cloud Security Manager

Governance should capture the transition.

35. Treatment Actions

Actions should be specific.

Weak:

Improve IAM.

Strong:

Deploy phishing-resistant MFA to 100% of privileged production accounts.

Specific actions are easier to track and validate.

36. SMART Treatment Actions

Treatment actions should ideally be:

Specific

Measurable

Achievable

Relevant

Time Bound

Example:

Enable phishing-resistant MFA for all 220 privileged accounts by 31 December 2026.

37. Treatment Milestones

Large treatments may need milestones.

Example:

PAM Implementation

September
→ Vendor selected

October
→ Platform deployed

November
→ Tier-0 accounts onboarded

December
→ All privileged accounts onboarded

Milestones improve visibility.

38. Treatment Dependencies

Document dependencies that could delay implementation.

Example:

Treatment:
Deploy MFA

Dependencies:
Legacy application upgrade
Identity migration
Vendor support

This allows earlier escalation.

39. Target Date

Treatment deadlines should consider:

Risk severity.
Implementation complexity.
Business constraints.
Regulatory deadlines.
Customer commitments.

Critical risks generally require more urgent action.

40. Example SLA Model

An organization might define:

Risk	Target Treatment
Critical	30 days
High	90 days
Moderate	180 days
Low	As appropriate

These values are organizational decisions, not universal ISO requirements.

41. Target Residual Risk

Before implementing treatment, estimate the expected risk after successful completion.

Example:

Current Residual:
15 High

Treatment:
Deploy PAM + phishing-resistant MFA

Target Residual:
8 Moderate

This helps determine whether the proposed treatment is sufficient.

42. Treatment Sufficiency

Suppose:

Current Risk:
20 Critical

Treatment:
Security awareness training only

Target Risk:
18 Critical

The treatment is probably insufficient.

Additional controls should be considered.

43. Cost vs Risk Reduction

Risk treatment should be proportionate.

Example:

Risk Exposure:
Moderate

Treatment Cost:
₹10 crore

Leadership may evaluate alternatives.

The cheapest option is not automatically correct, nor is the most expensive.

44. Cost-Benefit Considerations

Consider:

Implementation Cost

Operational Cost

Risk Reduction

Regulatory Need

Customer Need

Business Benefit

Risk decisions should support business objectives.

45. Treatment Approval

Risk owners should review proposed treatment.

Approval indicates agreement with:

Strategy.
Controls.
Ownership.
Timeline.
Target residual risk.

This creates accountability.

46. Treatment Approval Record

Example:

Risk:
RISK-008

Treatment:
Mitigate

Action:
Deploy centralized security logging

Owner:
SOC Director

Target:
Q1 2027

Approved By:
Risk Owner

Approval Date:
15 September 2026

47. Implementation Tracking

Possible statuses:

Not Started

Planned

In Progress

Blocked

Implemented

Validation Pending

Closed

Avoid marking treatment closed immediately after deployment.

48. Treatment Dashboard

Example:

Status	Count
Not Started	4
In Progress	12
Blocked	3
Validation Pending	5
Closed	18

This gives GRC operational visibility.

49. Overdue Treatment

Track:

Target Date
vs
Current Date

If overdue:

Treatment
      ↓
Overdue
      ↓
Escalation
      ↓
Risk Reassessment

Risk may have increased during the delay.

50. Treatment Escalation

Example:

Moderate Risk
→ 30 days overdue
→ Treatment Owner

High Risk
→ Overdue
→ CISO

Critical Risk
→ Overdue
→ Executive Risk Committee

Escalation should align with governance.

51. Blocked Treatment

A treatment may be blocked by:

Budget.
Technology.
Vendor.
Staffing.
Business priorities.

Example:

Treatment:
Replace legacy authentication

Blocked By:
Vendor does not support modern MFA

This should trigger a risk decision rather than remain indefinitely “blocked.”

52. Options for Blocked Treatments

Consider:

Compensating Controls

Alternative Treatment

Risk Acceptance

Risk Transfer

Risk Avoidance

Escalation

GRC should ensure a decision occurs.

53. Treatment Evidence

Completion should be supported by evidence.

Examples:

Configuration Screenshot

System Report

Implementation Ticket

Access Report

Policy Approval

Audit Result

Control Test

Evidence should demonstrate implementation.

54. Implementation vs Effectiveness

These are different.

Implemented
≠
Effective

Example:

MFA enabled

does not automatically mean:

All privileged accounts protected

Validation is required.

55. Treatment Validation

Ask:

Was the action completed?

Is the control operating?

Is coverage complete?

Are exceptions documented?

Does evidence support implementation?

Did the risk actually decrease?

Only then should residual risk be reassessed.

56. Recalculate Residual Risk

Example:

Before:

Likelihood:
4

Impact:
5

Residual:
20 Critical

After treatment:

Likelihood:
2

Impact:
5

Residual:
10 High

Risk has decreased but remains High.

Additional treatment or formal acceptance may still be required.

57. Multiple Treatment Cycles

Risk management may require several cycles.

Risk
 ↓
Treatment 1
 ↓
Residual High
 ↓
Treatment 2
 ↓
Residual Moderate
 ↓
Accept

This is normal.

58. Risk Closure

A risk does not necessarily disappear when treatment is completed.

Usually:

Treatment Completed
      ↓
Residual Risk Evaluated
      ↓
Residual Risk Accepted
      ↓
Risk Monitored

The risk may remain in the register.

59. Risk Retirement

A risk may be retired if the source of risk no longer exists.

Example:

Risk:
Legacy application compromise

Treatment:
Application decommissioned

Result:
Risk retired

Keep historical evidence where appropriate.

60. Risk Treatment and the SoA

The RTP directly supports the Statement of Applicability.

Example:

Risk:
Unauthorized privileged access

      ↓

Treatment:
Strong authentication + PAM

      ↓

Selected Controls

      ↓

Statement of Applicability

The SoA records control applicability and implementation status.

61. Risk-to-Control Traceability

A mature program should demonstrate:

Risk ID
      ↓
Treatment Decision
      ↓
Selected Control
      ↓
Control Owner
      ↓
Implementation Evidence
      ↓
SoA Entry

This provides strong audit traceability.

62. One Risk to Multiple Controls

Example:

RISK-001
Credential Compromise
      │
      ├── MFA
      ├── PAM
      ├── Access Reviews
      ├── Logging
      └── Security Awareness

One risk can require multiple controls.

63. One Control to Multiple Risks

Example:

MFA
 │
 ├── Credential Theft Risk
 ├── Privileged Access Risk
 ├── Remote Access Risk
 └── SaaS Account Risk

Control mapping should support many-to-many relationships.

64. Control Mapping Register

A practical register may contain:

Risk ID	Control	Source	Owner	Status
R-001	MFA	Annex A/Internal	IAM	Implemented
R-001	PAM	Internal	IAM	In Progress
R-003	Backup	Annex A	IT	Implemented

This later simplifies SoA development.

65. Risk Treatment Plan Example

Risk	Residual	Treatment	Action	Owner	Target
R-001 Privileged Access	High	Mitigate	Deploy PAM	IAM	Dec
R-002 Ransomware	High	Mitigate	Improve recovery	IT	Jan
R-003 Vendor Breach	High	Mitigate	Improve TPRM	GRC	Feb
R-004 Legacy System	Moderate	Accept	Monitor	Business	Review Q1

This becomes a working governance artifact.

66. Scenario — Privileged Access

Risk:

Threat actors may compromise privileged credentials and obtain unauthorized production access.

Current controls:

Standard MFA

Access Reviews

Logging

Residual:

High

Treatment:

Deploy phishing-resistant MFA

Implement PAM

Improve privileged session monitoring

Target:

Moderate

67. Scenario — Ransomware

Risk:

Ransomware may disrupt critical business services.

Treatment actions:

Immutable Backup

Recovery Testing

EDR Coverage

Network Segmentation

Privileged Access Hardening

The RTP should assign each action to an owner.

68. Scenario — Vendor Risk

Risk:

A critical SaaS supplier may suffer a security breach affecting customer information.

Treatment:

Security Assessment

Contract Security Clauses

Continuous Monitoring

Data Minimization

Annual Reassessment

Some residual third-party risk will remain.

69. Scenario — Cloud Misconfiguration

Risk:

Production cloud resources may be insecurely configured, exposing customer information.

Treatment:

Infrastructure as Code

Policy as Code

CSPM

Configuration Baselines

Cloud Logging

The treatment should target the underlying configuration weakness.

70. Scenario — Legacy System

Risk:

A legacy application may be compromised because it cannot support modern security controls.

Possible treatment:

Network Isolation

Restricted Access

PAM

Enhanced Monitoring

Replacement Project

Temporary compensating controls reduce exposure while long-term avoidance removes the risk source.

71. Treatment Exceptions

Sometimes implementation cannot reach 100%.

Example:

MFA Coverage:
98%

Exception:
2 legacy service accounts

Exceptions should be:

Documented.
Risk assessed.
Approved.
Time bound.
Monitored.

72. Compensating Controls

A compensating control provides alternative risk reduction when the preferred control cannot be implemented.

Example:

Required:

MFA

Unavailable:

Legacy Application

Compensating controls:

Network Isolation

PAM

Restricted Source IP

Enhanced Monitoring

Compensating controls should be evaluated for effectiveness.

73. Treatment Change Management

Treatment plans may need modification.

Example:

Original Treatment:
Deploy Vendor A PAM

Problem:
Product does not meet requirements

Revised Treatment:
Deploy Vendor B

Changes should be documented and approved.

74. Treatment Risk

Implementation itself may introduce risk.

Example:

Major IAM Migration
      ↓
Potential Authentication Outage

Treatment projects may therefore require their own change and risk management.

75. Monitoring Treatment Progress

Useful metrics include:

Open Treatments

Overdue Treatments

Critical Treatments

Average Treatment Age

Treatments Completed

Target Risk Reduction Achieved

These provide better insight than simply counting risks.

76. Treatment KPI Example

KPI:
Percentage of High/Critical risk treatments completed within agreed target date.

Target:
95%

77. Treatment KRI Example

KRI:
Number of overdue Critical risk treatments.

Tolerance:
0

This supports escalation.

78. Management Reporting

Executives may need:

Critical Risks

High Risks

Overdue Treatments

Blocked Treatments

Resource Constraints

Risk Acceptance Requests

Keep reporting decision focused.

79. Risk Treatment Review Meeting

A practical agenda:

1. Critical risk treatments

2. Overdue actions

3. Blocked treatments

4. New treatment decisions

5. Residual risk changes

6. Risk acceptance requests

7. Resource escalations

80. Risk Owner Review

Risk owners should periodically confirm:

Risk remains correctly rated.
Treatment remains appropriate.
Progress is acceptable.
Target risk remains realistic.
Additional actions are not required.

This keeps ownership active.

81. Treatment Documentation

Maintain records such as:

Risk Treatment Plan

Treatment Decision Register

Control Mapping

Implementation Evidence

Risk Acceptance

Treatment Approvals

Validation Results

These become valuable certification evidence.

82. Auditor Expectations

An auditor may ask:

How were treatment decisions made?
Why was this control selected?
Who owns the treatment?
What is the implementation status?
Can you show evidence?
Has residual risk been reassessed?
Did the risk owner approve the plan?
How does this treatment appear in the SoA?

The organization should demonstrate traceability.

83. Example Auditor Walkthrough

Auditor selects:

RISK-014

Then follows:

Risk Register
      ↓
Treatment Decision
      ↓
Risk Treatment Plan
      ↓
Selected Controls
      ↓
Implementation Evidence
      ↓
Residual Risk
      ↓
SoA

These records should tell a consistent story.

84. Common Risk Treatment Mistakes

Mistake 1 — No Formal Treatment Plan

Actions exist only in emails or tickets.

Mistake 2 — Vague Actions

Example:

Improve security.

Mistake 3 — No Owner

No one is accountable for delivery.

Mistake 4 — No Deadline

Treatment remains open indefinitely.

Mistake 5 — No Target Residual Risk

There is no defined outcome.

Mistake 6 — Controls Selected Without Risk Linkage

Controls become checklist driven.

Mistake 7 — Implementation Equals Closure

Effectiveness is never validated.

Mistake 8 — Overdue Treatments Not Escalated

High risk persists silently.

Mistake 9 — Acceptance Used to Avoid Remediation

Risk acceptance should be a governance decision.

Mistake 10 — RTP and SoA Do Not Match

This creates audit traceability problems.

85. Weak Treatment Record

Risk:
Cloud Security

Action:
Improve controls

Owner:
IT

Target:
Soon

This is difficult to govern.

86. Strong Treatment Record

Risk ID:
RISK-021

Risk:
Public cloud storage may expose confidential customer data through configuration error.

Residual Risk:
15 — High

Treatment:
Mitigate

Action:
Implement preventive policy-as-code controls for all production storage deployments.

Owner:
Cloud Security Manager

Target:
31 January 2027

Target Residual:
8 — Moderate

Evidence:
CI/CD policy enforcement report

Risk Owner:
CTO

This is actionable and auditable.

87. Practical Activity — Build the RTP

Create:

01 ISO Risk Treatment Plan

Recommended columns:

Field
Risk ID
Risk Statement
Current Residual Risk
Treatment Strategy
Control
Treatment Action
Treatment Owner
Control Owner
Target Date
Target Residual Risk
Status
Evidence
Risk Owner
Approval

88. Practical Activity — Treatment Decision Matrix

Create:

02 Risk Treatment Decision Matrix

Include:

Risk Level

Acceptance Threshold

Expected Treatment

Approval Authority

Escalation Requirement

89. Practical Activity — Treatment Action Tracker

Create:

03 Treatment Action Tracker

Use:

Action	Risk	Owner	Target	Status	Blocker

This provides day-to-day tracking.

90. Practical Activity — Control Mapping Register

Create:

04 Risk-to-Control Mapping Register

Recommended fields:

Risk ID

Treatment

Control ID

Control Description

Control Source

Control Owner

Implementation Status

Evidence

This becomes extremely useful when building the SoA.

91. Practical Activity — Residual Risk Approval

Create:

05 Residual Risk Approval Record

Include:

Risk ID.
Treatment completed.
Current residual risk.
Remaining exposure.
Risk owner.
Acceptance authority.
Approval date.
Review date.

92. Practical Activity — Treatment Validation

For five treatment actions, verify:

Implemented?

Evidence Available?

Control Operating?

Coverage Complete?

Exceptions?

Target Risk Achieved?

Document the results.

93. Risk Treatment Checklist

Before closing a treatment, verify:

Risk requiring treatment identified.
Treatment strategy selected.
Controls selected.
Annex A considered.
Additional controls considered where necessary.
Treatment owner assigned.
Control owner identified.
Action clearly defined.
Target date established.
Target residual risk established.
Risk owner approved treatment.
Implementation tracked.
Evidence collected.
Control effectiveness validated.
Residual risk reassessed.
Remaining risk formally accepted where necessary.
SoA updated.

94. GRC Analyst Responsibilities

A GRC professional may:

Identify risks requiring treatment.
Facilitate treatment decisions.
Map risks to controls.
Coordinate with control owners.
Maintain the RTP.
Track target dates.
Monitor overdue actions.
Escalate blocked treatments.
Collect implementation evidence.
Coordinate treatment validation.
Reassess residual risk.
Obtain risk-owner approval.
Maintain acceptance records.
Connect treatment results to the SoA.

GRC coordinates the process while risk and control owners remain accountable for their respective responsibilities.

95. Risk Treatment Governance Model

A practical model is:

Risk Owner
      ↓
Approves Treatment

GRC
      ↓
Coordinates & Tracks

Treatment Owner
      ↓
Implements Action

Control Owner
      ↓
Operates Control

Assurance
      ↓
Validates Effectiveness

Risk Owner
      ↓
Accepts Residual Risk

96. Risk Treatment Lifecycle

The complete lifecycle can be visualized as:

Risk Identified
      ↓
Risk Assessed
      ↓
Residual Risk Evaluated
      ↓
Treatment Selected
      ↓
Controls Mapped
      ↓
Action Assigned
      ↓
Implementation
      ↓
Evidence Collected
      ↓
Effectiveness Validated
      ↓
Risk Reassessed
      ↓
Residual Risk Accepted
      ↓
Ongoing Monitoring

97. Risk Treatment Maturity

Level 1 — Ad Hoc

Actions tracked through email.

Level 2 — Documented

Formal RTP
Owners
Deadlines

Level 3 — Managed

Escalation
Validation
Residual Risk

Level 4 — Integrated

Risk
Controls
SoA
Audit
Evidence

Level 5 — Continuous

Automated Monitoring
Dynamic Risk Updates
Continuous Control Validation

98. Treatment Traceability

A mature ISMS should demonstrate:

Business Context
      ↓
Risk
      ↓
Risk Assessment
      ↓
Treatment Decision
      ↓
Security Control
      ↓
Implementation
      ↓
Evidence
      ↓
Residual Risk
      ↓
Statement of Applicability

This traceability is central to a defensible ISO program.

99. Risk Treatment Mindset

When reviewing a treatment plan, ask:

Why does this risk require treatment?

Why was this strategy selected?

Which control reduces the risk?

Who will implement it?

Who will operate it afterward?

When will it be completed?

What evidence will prove implementation?

How much risk should remain?

Who accepts that residual risk?

Has the SoA been updated?

If these questions can be answered clearly, the RTP is likely well governed.

Key Takeaways

Risk treatment converts risk-assessment results into concrete actions.
Risks should be evaluated against approved risk-acceptance criteria.
Common treatment strategies are mitigation, avoidance, transfer, and acceptance.
Treatment may be required even for lower-rated risks when legal, contractual, or policy requirements apply.
Controls should be selected because they address specific risk scenarios.
Annex A should be considered during treatment, but organizations may use additional controls where necessary.
Risk owners, treatment owners, and control owners perform different roles.
Treatment actions should be specific, measurable, owned, and time bound.
Target residual risk helps determine whether planned treatment is sufficient.
Treatment implementation should be supported by evidence.
Implementation does not automatically prove effectiveness.
Residual risk should be reassessed after treatment.
Remaining risk should be formally accepted where required.
Overdue and blocked treatments should be escalated.
Risk-to-control mapping provides critical traceability.
The Risk Treatment Plan directly supports development and maintenance of the Statement of Applicability.

Knowledge Check

Before continuing, make sure you can answer:

What is the purpose of a Risk Treatment Plan?
How does risk treatment differ from risk assessment?
When does a risk normally require treatment?
What are the four common treatment strategies?
What is risk mitigation?
What is risk avoidance?
What does risk transfer actually transfer?
When might risk acceptance be appropriate?
Why should acceptance often be time bound?
How should controls be selected?
What role does Annex A play in risk treatment?
Can an organization implement controls outside Annex A?
What is the difference between a risk owner and treatment owner?
What is the difference between a treatment owner and control owner?
What is target residual risk?
Why should treatment effectiveness be validated?
What should happen when treatment is overdue?
What are compensating controls?
How does the RTP connect to the Statement of Applicability?
What role does GRC play in risk treatment?

What’s Next?

➡️ Next: 08 — Statement of Applicability (SoA)

In the next lesson, you will build one of the most important ISO/IEC 27001 governance and certification artifacts: the Statement of Applicability.

You will learn how to:

Review Risk Treatment Decisions
        ↓
Review Annex A Controls
        ↓
Determine Control Applicability
        ↓
Document Inclusion Justification
        ↓
Document Exclusion Justification
        ↓
Map Controls to Risks
        ↓
Identify Control Owners
        ↓
Record Implementation Status
        ↓
Link Control Evidence
        ↓
Approve the SoA
        ↓
Maintain It Through ISMS Changes

You will also build a practical SoA Control Register, Risk-to-Control Mapping Matrix, Control Applicability Decision Record, Control Ownership Matrix, and SoA Review Checklist that can be used for ISO implementation, internal audit, and certification readiness.