06 Risk Treatment Plan

Risk assessment is one of the central components of an ISO/IEC 27001 Information Security Management System.

The standard expects organizations to use a defined, repeatable, and risk-based process to identify and evaluate information-security risks.

This process answers questions such as:

What information or service are we protecting?
        ↓
What could go wrong?
        ↓
Why could it happen?
        ↓
How likely is it?
        ↓
What would the business impact be?
        ↓
What controls already exist?
        ↓
What risk remains?
        ↓
Is that risk acceptable?
        ↓
What treatment is required?

A strong ISO risk assessment should be:

Consistent.
Evidence based.
Business aligned.
Repeatable.
Documented.
Owned.
Suitable for risk treatment and audit.

For a GRC professional, risk assessment is one of the most important practical ISO/IEC 27001 skills because it directly drives the Risk Treatment Plan and ultimately the Statement of Applicability.

Learning Objectives

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

Explain the purpose of ISO/IEC 27001 risk assessment.
Define a risk assessment methodology.
Establish risk criteria.
Define risk acceptance criteria.
Identify relevant assets and business services.
Identify threats and vulnerabilities.
Develop clear risk scenarios.
Assess likelihood and impact.
Calculate inherent risk.
Identify existing controls.
Evaluate control effectiveness.
Calculate residual risk.
Assign risk owners.
Determine whether risk is acceptable.
Select appropriate risk treatment.
Maintain an auditable risk register.
Recognize common ISO risk-assessment mistakes.

1. Why Risk Assessment Matters

ISO/IEC 27001 is not intended to be implemented as a generic control checklist.

Instead, the organization should understand its risks and select appropriate controls.

The logic is:

Business Context
      ↓
Information Security Risk
      ↓
Risk Assessment
      ↓
Risk Treatment
      ↓
Control Selection
      ↓
Statement of Applicability

Without a meaningful risk assessment, the organization cannot confidently justify why particular controls are necessary.

2. Risk Assessment and Clause 6

Within the ISMS, risk assessment supports planning.

It helps determine:

Which risks matter.
Which risks need treatment.
Which controls are needed.
Which risks can be accepted.
Which objectives should be prioritized.

The risk assessment should use defined criteria so similar risks are evaluated consistently.

3. Risk Assessment vs Risk Treatment

These are different activities.

Risk Assessment

Determines:

What is the risk?
How serious is it?
Who owns it?

Risk Treatment

Determines:

What should we do about it?
Which controls should be used?
What residual risk will remain?

Risk assessment comes first.

4. Information Security Risk

An information-security risk is generally linked to the possibility that an event could negatively affect:

Confidentiality

Integrity

Availability

and ultimately impact business objectives.

For example:

A threat actor may compromise privileged credentials and gain unauthorized access to production systems, resulting in customer data exposure and service disruption.

This is more useful than writing:

Risk:
MFA

or:

Risk:
Phishing

5. Risk Methodology

The organization should define how risk will be assessed.

A practical methodology should explain:

Risk-identification approach.
Likelihood scale.
Impact scale.
Risk calculation.
Risk-rating thresholds.
Risk acceptance criteria.
Risk ownership.
Review frequency.

This creates consistency.

6. Risk Assessment Methodology Document

A practical document may include:

Purpose

Scope

Risk Definitions

Likelihood Criteria

Impact Criteria

Risk Matrix

Risk Acceptance Thresholds

Risk Ownership

Treatment Options

Review Frequency

Approval

This becomes a core ISMS artifact.

7. Consistency Matters

Suppose two teams assess the same type of risk.

Team A:

High

Team B:

Low

If both are using different definitions of likelihood and impact, the risk register becomes unreliable.

The methodology should reduce this subjectivity.

8. Risk Criteria

Risk criteria define how risks will be evaluated.

Typical criteria include:

Likelihood

Impact

Risk Score

Risk Rating

Acceptance Threshold

The criteria should fit the organization’s context.

9. Example 5 × 5 Methodology

Use:

Risk Score = Likelihood × Impact

Both values range from:

1 to 5

Maximum score:

10. Likelihood Scale

Example:

Score	Rating	Description
1	Rare	Unlikely under normal circumstances
2	Unlikely	Could occur but not expected
3	Possible	Could reasonably occur
4	Likely	Expected to occur
5	Almost Certain	Expected frequently or imminently

Likelihood should not be chosen only by intuition.

11. Likelihood Factors

Consider:

Threat activity.
Historical incidents.
Attack exposure.
Existing vulnerabilities.
Ease of exploitation.
Frequency of activity.
Industry trends.
Environmental conditions.

Example:

Internet-Facing System
      +
Known Exploitable Vulnerability
      +
Active Exploitation
      =
Higher Likelihood

12. Impact Scale

Example:

Score	Rating	Description
1	Insignificant	Minimal business impact
2	Minor	Limited operational impact
3	Moderate	Material business disruption
4	Major	Significant customer, financial, or regulatory impact
5	Severe	Enterprise-level consequence

13. Impact Dimensions

Consider multiple dimensions:

Financial

Operational

Customer

Regulatory

Legal

Reputational

Safety

Use the most relevant business impact.

14. Confidentiality Impact

Example:

Customer Personal Data Exposed
      ↓
Privacy Notification
      ↓
Customer Impact
      ↓
Regulatory Exposure

Confidentiality impact may therefore be Major or Severe.

15. Integrity Impact

Example:

Financial Records Altered
      ↓
Incorrect Reporting
      ↓
Business Decisions Affected

Integrity loss can be highly significant even if no data is disclosed.

16. Availability Impact

Example:

Critical SaaS Platform Unavailable
      ↓
Customers Cannot Operate
      ↓
SLA Breach
      ↓
Revenue Impact

Availability should be assessed using business context.

17. Risk Rating Thresholds

Example:

Score	Rating
1–4	Low
5–9	Moderate
10–16	High
17–25	Critical

These thresholds should be approved as part of the methodology.

18. Risk Acceptance Criteria

The organization should define what level of residual risk may be accepted and by whom.

Example:

Low
→ Normally acceptable

Moderate
→ Risk Owner Approval

High
→ Treatment required or senior approval

Critical
→ Treatment required / executive escalation

This connects methodology to governance.

19. Risk Acceptance Is Not Automatic

A risk score below a threshold does not necessarily mean the risk must be accepted.

Other factors may include:

Legal obligations.
Contractual requirements.
Customer commitments.
Mandatory policies.

Example:

Residual Risk:
Moderate

Requirement:
MFA contractually mandatory

Result:
Cannot simply accept non-compliance

20. Step 1 — Define Assessment Scope

Before identifying risks, define what is being assessed.

Possible scope:

Customer SaaS Platform

AWS Production Environment

Supporting IAM

Engineering Processes

Third-Party Dependencies

The risk assessment scope should align with the ISMS scope.

21. Assessment Boundaries

Document:

Systems.
Services.
Locations.
Business processes.
Data.
Third parties.
Interfaces.

This helps avoid missing relevant risks.

22. Step 2 — Identify Business Services

Start with business value.

Example:

Business Service:
Enterprise SaaS Platform

Business Owner:
Chief Product Officer

Criticality:
Critical

Then identify what supports it.

23. Business Service Dependency Model

Business Service
      ↓
Applications
      ↓
Cloud Infrastructure
      ↓
Identity
      ↓
Data
      ↓
People
      ↓
Third Parties

This creates a better risk picture than assessing isolated devices.

24. Step 3 — Identify Assets

Assets may include:

Information

Applications

Infrastructure

People

Processes

Cloud Services

Third Parties

Physical Facilities

The organization should use an asset approach that matches its risk methodology.

25. Information Assets

Examples:

Customer data.
Source code.
Financial records.
Employee information.
Credentials.
Business plans.

Information assets often have direct business value.

26. Technology Assets

Examples:

Cloud Accounts

Databases

SaaS Platforms

Endpoints

Networks

Identity Systems

These enable business services.

27. People and Process Assets

Examples:

Security operations team.
Payroll process.
Change-management process.
Customer-support workflow.

Risk is not limited to hardware and software.

28. Asset Ownership

Where practical, identify ownership.

Example:

Asset	Owner
Customer Database	Product
AWS Production	Cloud Engineering
Entra ID	IAM
Source Repository	Engineering

Ownership supports risk accountability.

29. Asset Criticality

Classify importance.

Example:

Critical

High

Moderate

Low

Criticality may influence impact scoring.

30. Step 4 — Identify Threats

A threat is something capable of causing harm.

Examples include:

External Attacker

Malicious Insider

Human Error

Ransomware

Supply-Chain Attack

Technology Failure

Cloud Outage

Natural Disaster

Risk assessments should focus on credible threats.

31. Threat Sources

Threats may be:

Malicious

Cybercriminal.
Insider.
Nation-state actor.
Competitor.

Accidental

Human error.
Misconfiguration.
Accidental deletion.

Environmental / Technical

Power failure.
Hardware failure.
Cloud outage.
Fire.

32. Threat Intelligence

Useful information may come from:

Internal incidents.
Security monitoring.
Industry reports.
Threat intelligence.
Vulnerability intelligence.
External advisories.

Threat information can improve likelihood assessment.

33. Step 5 — Identify Vulnerabilities

A vulnerability is a weakness or condition that can increase the likelihood or impact of a risk scenario.

Examples:

No MFA

Weak Access Review

Public Cloud Exposure

Unsupported Software

Poor Backup Testing

Unsecured API

Manual Vendor Process

A vulnerability is not the same as a risk.

34. Vulnerability vs Risk

Vulnerability:

Privileged accounts do not use MFA.

Risk:

A threat actor may compromise privileged credentials because strong authentication is not enforced, resulting in unauthorized production access and customer-data exposure.

The risk describes the business consequence.

35. Step 6 — Develop Risk Scenarios

Use a structured format:

There is a risk that [threat/event] may exploit [vulnerability/condition], resulting in [business impact].

Example:

There is a risk that an external attacker may exploit an internet-facing critical vulnerability, resulting in unauthorized access to production systems and disruption of customer services.

36. Weak Risk Statement

Cloud risk.

Too vague.

37. Better Risk Statement

There is a risk that cloud storage may be accidentally configured for public access, resulting in unauthorized disclosure of confidential customer information.

This supports clearer scoring and treatment.

38. Risk Categories

A risk taxonomy may help organize the register.

Examples:

Identity

Data Protection

Cloud

Application Security

Third Party

Resilience

Physical Security

Governance

Compliance

Taxonomy supports reporting.

39. Step 7 — Assess Inherent Likelihood

Inherent risk is assessed before considering existing controls.

Example:

Risk:

Privileged account compromise

Assume:

Likelihood = 4
Impact = 5

Then:

Inherent Risk = 20 — Critical

40. Why Inherent Risk Matters

Inherent risk shows the natural exposure associated with an activity.

This is useful for:

Prioritizing controls.
Understanding business risk.
Comparing activities.
Assessing control importance.

41. Step 8 — Identify Existing Controls

Next identify safeguards already in place.

Example:

Risk:
Privileged account compromise

Controls:

MFA

PAM

Least Privilege

Access Reviews

Security Monitoring

Do not assume controls are effective merely because they exist.

42. Control Sources

Controls may come from:

Annex A.
Internal policy.
NIST.
CIS.
Cloud controls.
Regulatory requirements.

In ISO risk assessment, what matters is whether they meaningfully address the risk.

43. Control Effectiveness

Use defined ratings.

Example:

Rating	Meaning
Effective	Consistently reduces risk
Partially Effective	Weaknesses remain
Ineffective	Little meaningful reduction
Not Tested	Effectiveness unknown

Evidence should support the conclusion.

44. Control Effectiveness Evidence

Possible evidence:

Control Test

Audit Report

Configuration Review

Metric

Incident History

Monitoring Report

Avoid purely subjective scoring where possible.

45. Control Design vs Operation

Example:

Control:
Quarterly access review

Design may be appropriate.

But if reviews are frequently missed:

Operating Effectiveness:
Weak

Residual risk should reflect actual effectiveness.

46. Step 9 — Determine Residual Likelihood

After evaluating controls, reassess likelihood.

Example:

Inherent Likelihood:
4

Controls:
MFA + PAM + Monitoring

Residual Likelihood:
2

Controls reduce probability.

47. Step 10 — Determine Residual Impact

Controls may also reduce impact.

Example:

Ransomware Impact:
5

Strong Recovery Controls:
Reduce outage severity

Residual Impact:
4

Not every control reduces both likelihood and impact.

48. Residual Risk

Calculate:

Residual Risk =
Residual Likelihood × Residual Impact

Example:

Likelihood = 2
Impact = 5

Residual Risk = 10 — High

The risk remains significant.

49. Inherent vs Residual Risk

Inherent Risk
      ↓
Existing Controls
      ↓
Control Effectiveness
      ↓
Residual Risk

Example:

Inherent:
20 Critical

Residual:
10 High

The controls reduce exposure but do not eliminate the risk.

50. Risk Evaluation

Now compare residual risk with acceptance criteria.

Example:

Residual Rating:
High

Risk Appetite:
High requires treatment

Decision:
Additional treatment required

This is risk evaluation.

51. Step 11 — Assign Risk Owner

Each material risk should have an accountable owner.

Example:

Risk:
Production availability

Risk Owner:
CTO

The owner should have enough authority to influence treatment.

52. Risk Owner Responsibilities

May include:

Review assessment.
Agree treatment.
Monitor residual risk.
Request acceptance.
Escalate significant issues.

GRC facilitates the process.

53. Step 12 — Determine Treatment

Common treatment options:

Mitigate

Avoid

Transfer

Accept

54. Mitigate

Implement or improve controls.

Example:

Risk:
Credential compromise

Treatment:
Deploy phishing-resistant MFA

55. Avoid

Stop the activity creating the risk.

Example:

Risk:
Unsupported internet-facing legacy application

Treatment:
Decommission service

56. Transfer

Shift some risk consequences through:

Insurance.
Contract.
Outsourcing.

Transfer does not normally remove all accountability.

57. Accept

Management formally accepts residual exposure.

Risk acceptance should be:

Authorized.
Documented.
Time-bound where appropriate.
Periodically reviewed.

58. Risk Treatment Decision Record

Example:

Risk ID:
RISK-005

Residual Risk:
High

Decision:
Mitigate

Action:
Deploy phishing-resistant MFA

Owner:
IAM Director

Target:
31 December 2026

This later feeds into the treatment plan.

59. Risk Register

A practical ISO risk register may include:

Field
Risk ID
Risk Category
Business Service
Asset
Risk Statement
Threat
Vulnerability
Inherent Likelihood
Inherent Impact
Inherent Score
Existing Controls
Control Effectiveness
Residual Likelihood
Residual Impact
Residual Score
Risk Owner
Treatment
Treatment Action
Due Date
Status

60. Example Risk Record

Risk ID:
RISK-001

Risk:
Threat actors may compromise privileged accounts due to phishing-susceptible authentication, resulting in unauthorized production access.

Inherent:
20 — Critical

Controls:
MFA
PAM
Monitoring

Control Effectiveness:
Partially Effective

Residual:
12 — High

Owner:
CISO

Treatment:
Mitigate

Action:
Deploy phishing-resistant MFA

61. Risk Evidence

The assessment should be supported by evidence where relevant.

Possible sources:

Architecture diagrams.
Asset inventory.
Vulnerability scans.
Audit reports.
Incident data.
Control testing.
Policies.
Security metrics.
Vendor assessments.

This improves defensibility.

62. Risk Assessment Workshop

A practical assessment may involve:

GRC

Business Owner

Security

Engineering

IT

Risk Owner

GRC facilitates discussion.

63. Risk Workshop Agenda

Example:

1. Confirm scope.

2. Review business service.

3. Identify critical assets.

4. Identify threats.

5. Identify vulnerabilities.

6. Develop risk scenarios.

7. Score likelihood and impact.

8. Review controls.

9. Score residual risk.

10. Agree owner and treatment.

64. Managing Scoring Disagreement

Different stakeholders may disagree.

Example:

Security:
Likelihood = 5

Business:
Likelihood = 2

Use evidence.

Ask:

Has this happened before?
What exposure exists?
Are attackers actively exploiting this?
What safeguards exist?
How reliable are the controls?

Document rationale.

65. Avoiding Risk Inflation

A common mistake is rating everything:

Critical

If every risk is critical, prioritization becomes impossible.

Ratings should follow defined criteria.

66. Avoiding Risk Minimization

Business teams may underestimate risk because treatment is expensive.

Example:

"We've never had an incident,
so likelihood is low."

Historical absence does not automatically mean low future probability.

Assessment should remain objective.

67. Quantitative Considerations

ISO does not require one specific quantitative model, but some organizations may incorporate financial analysis.

Example:

Expected Loss

Downtime Cost

Regulatory Penalty Exposure

Incident Response Cost

These may help leadership understand impact.

68. Example Financial Impact

Suppose:

SaaS Revenue:
₹20 lakh per hour

Potential Outage:
8 hours

Direct revenue exposure:

₹1.6 crore

This may help justify an impact rating.

69. Scenario — Cloud Misconfiguration

Risk:

Cloud storage may be accidentally configured for public access, resulting in disclosure of confidential customer information.

Inherent:

Likelihood:
4

Impact:
5

Score:
20 Critical

Controls:

Infrastructure as Code

Cloud Security Posture Management

Encryption

Access Policies

Effectiveness:

Partially Effective

Residual:

Likelihood:
3

Impact:
5

Score:
15 High

Treatment:

Implement preventive policy-as-code deployment gates.

70. Scenario — Ransomware

Risk:

Ransomware may compromise enterprise systems and disrupt critical business services.

Inherent:

5 × 5 = 25 Critical

Controls:

EDR.
MFA.
Segmentation.
Backups.
Security monitoring.

Residual:

3 × 4 = 12 High

Treatment may include stronger recovery testing.

71. Scenario — Third-Party Breach

Risk:

A critical SaaS provider may experience a breach resulting in unauthorized disclosure of customer data.

Consider:

Vendor Security Controls

Data Minimization

Contract Controls

Monitoring

Vendor Assurance

Residual risk depends heavily on the third-party control environment.

72. Scenario — Insider Threat

Risk:

A privileged employee may intentionally misuse authorized access to extract confidential information.

Controls:

Least Privilege

DLP

PAM

Logging

Access Reviews

Segregation of Duties

Likelihood may remain low but impact may remain high.

73. Scenario — Service Outage

Risk:

Failure of a critical cloud region may make customer services unavailable.

Controls:

Multi-AZ Architecture

Backups

Recovery Procedures

Monitoring

Impact depends on RTO and customer commitments.

74. Risk Assessment Frequency

Risk assessments should occur:

At planned intervals.
When significant changes occur.

Common planned frequency:

Annual

but this should fit organizational needs.

75. Event-Driven Risk Assessment

Triggers may include:

New Product

Major Cloud Migration

New Vendor

Acquisition

Security Incident

Critical Vulnerability

Regulatory Change

Do not wait for annual review if risk materially changes.

76. Risk Review Frequency

Risk-specific reviews may also vary.

Example:

Residual Risk	Review Frequency
Critical	Monthly
High	Quarterly
Moderate	Semiannual
Low	Annual

This supports continuous risk management.

77. Risk Aging

Track how long high risks remain open.

Example:

Risk:
Critical privileged access gap

Age:
220 days

This may require escalation.

78. Risk Movement

Track whether risk is:

Increasing

Stable

Decreasing

Example:

Previous:
Critical

Current:
High

Trend:
Improving

This helps management understand progress.

79. Risk Reassessment

After treatment, reassess.

Example:

Initial Residual:
15 High

New Control:
Phishing-resistant MFA

New Residual:
8 Moderate

Risk treatment should demonstrate actual reduction.

80. Treatment Effectiveness

Do not assume control implementation automatically reduces risk.

Validate:

Is the control deployed?
Is coverage complete?
Is it operating?
Has it been tested?
Are exceptions managed?

Then reassess residual risk.

81. Risk Acceptance Record

If accepted:

Risk ID

Residual Rating

Reason

Compensating Controls

Risk Owner

Approver

Acceptance Date

Expiration

Review

This should align with governance.

82. Risk Assessment Evidence Package

A complete ISO risk assessment may include:

Risk Assessment Methodology

Asset / Service Inventory

Risk Register

Risk Workshop Records

Control Evidence

Risk Acceptance Criteria

Risk Treatment Decisions

Approval Records

This supports auditability.

83. Auditor Expectations

An ISO auditor may ask:

What methodology do you use?
How are likelihood and impact defined?
Can you show a recent risk assessment?
How do you identify risks?
Who owns them?
What treatment decisions were made?
How is acceptance authorized?
How do risk results influence the SoA?

You should be able to demonstrate the complete chain.

84. Risk-to-SoA Traceability

Example:

Risk:
Privileged account compromise
      ↓
Treatment:
Implement strong authentication
      ↓
Control:
Identity & authentication control
      ↓
SoA:
Applicable

This is one of the most important ISO relationships.

85. Risk Assessment vs Annex A

Do not start with:

Annex A checklist
      ↓
Select everything

Better:

Risk
      ↓
Treatment
      ↓
Control selection
      ↓
Compare against Annex A
      ↓
Document SoA

Annex A supports treatment, but risk should drive the process.

86. Common Risk Assessment Mistakes

Mistake 1 — Asset List Only

Listing assets is not the same as identifying risk.

Mistake 2 — Generic Risks

Example:

Malware

without explaining the business consequence.

Mistake 3 — No Defined Methodology

Ratings become inconsistent.

Mistake 4 — All Risks Are Critical

Prioritization becomes meaningless.

Mistake 5 — Control Effectiveness Assumed

Controls should be evaluated.

Mistake 6 — No Risk Owners

Risk decisions lack accountability.

Mistake 7 — No Acceptance Criteria

There is no consistent decision threshold.

Mistake 8 — Static Annual Risk Register

Significant changes should trigger reassessment.

Mistake 9 — No Link to Treatment

Assessment becomes documentation rather than management.

Mistake 10 — No Link to SoA

Control selection becomes disconnected from risk.

87. Weak vs Strong Risk Assessment

Weak

Risk:
Phishing

Score:
High

Strong

Risk:
Threat actors may compromise workforce credentials through phishing, resulting in unauthorized access to customer-facing systems.

Inherent:
20 Critical

Controls:
Email Security
MFA
Training

Effectiveness:
Partial

Residual:
12 High

Treatment:
Deploy phishing-resistant MFA

Owner:
CISO

The strong version supports governance and action.

88. Practical Activity — Build Risk Methodology

Create:

01 ISO Risk Assessment Methodology

Include:

Risk definitions.
Likelihood scale.
Impact scale.
Risk matrix.
Acceptance criteria.
Ownership.
Treatment options.
Review frequency.

89. Practical Activity — Build Risk Register

Create:

02 ISO Information Security Risk Register

Recommended fields:

Risk ID

Business Service

Asset

Threat

Vulnerability

Risk Statement

Likelihood

Impact

Inherent Risk

Existing Controls

Control Effectiveness

Residual Likelihood

Residual Impact

Residual Risk

Risk Owner

Treatment

Action

Due Date

Status

90. Practical Activity — Identify Risks

Create at least ten risks across:

Identity

Cloud

Application Security

Data

Third Party

Incident Response

Business Continuity

Physical Security

Governance

Compliance

Write complete risk scenarios.

91. Practical Activity — Build Risk Acceptance Criteria

Create:

03 Risk Acceptance Criteria

Example:

Risk	Treatment Expectation
Low	May accept
Moderate	Owner decision
High	Treat or senior approval
Critical	Executive escalation

Adapt to organizational governance.

92. Practical Activity — Build Treatment Decision Record

Create:

04 Risk Treatment Decision Register

Use:

Risk	Decision	Control/Action	Owner	Due

This will prepare you for the next lesson.

93. Practical Activity — Build Risk Approval Record

Create:

05 Risk Acceptance Record

Include:

Risk.
Residual score.
Business justification.
Compensating controls.
Approver.
Expiration.
Review date.

94. Risk Assessment Checklist

Before completing an assessment, verify:

Assessment scope defined.
Business services identified.
Assets identified.
Threats identified.
Vulnerabilities identified.
Risk statements documented.
Likelihood scored.
Impact scored.
Inherent risk calculated.
Existing controls identified.
Control effectiveness evaluated.
Residual risk calculated.
Risk owner assigned.
Acceptance criteria applied.
Treatment decision documented.
Approval captured.
Review frequency established.

95. GRC Analyst Responsibilities

As a GRC professional, you may:

Maintain the risk methodology.
Facilitate assessment workshops.
Identify risk scenarios.
Guide scoring.
Challenge unsupported assumptions.
Maintain the risk register.
Coordinate control evidence.
Track risk owners.
Document treatment decisions.
Coordinate risk acceptance.
Monitor remediation.
Reassess residual risk.
Prepare risk reporting.
Link risk results to the SoA.

This is one of the core operational responsibilities in an ISO/IEC 27001 program.

96. Risk Assessment Governance

A practical model may be:

GRC
   ↓
Facilitates Assessment

Business Owner
   ↓
Provides Business Context

Security / Technology
   ↓
Provides Technical Evidence

Risk Owner
   ↓
Owns Risk Decision

Leadership
   ↓
Approves Significant Risk

Risk assessment should be collaborative.

97. Risk Assessment Maturity

Level 1 — Ad Hoc

Unstructured
Inconsistent scoring

Level 2 — Defined

Methodology
Risk Register
Ownership

Level 3 — Managed

Treatment Tracking
Periodic Review
Evidence-Based Scoring

Level 4 — Integrated

Risks Linked to Controls
SoA
Audits
Compliance

Level 5 — Continuous

Continuous Monitoring
Dynamic Risk Signals
Automated Reassessment

98. Risk Assessment Mindset

When performing an ISO risk assessment, ask:

What business service are we protecting?

What information matters?

What could happen?

Why could it happen?

How likely is it?

What would the business impact be?

Which controls already reduce risk?

How effective are those controls?

What risk remains?

Is that risk acceptable?

What treatment is required?

Who owns the decision?

If these questions are answered clearly, the assessment is likely meaningful.

Key Takeaways

ISO/IEC 27001 risk assessment should be structured, repeatable, and risk based.
Risk methodology should define likelihood, impact, scoring, acceptance criteria, and ownership.
Business services and information assets provide context for risk identification.
Threats and vulnerabilities should be translated into clear business-oriented risk scenarios.
Inherent risk is assessed before controls.
Control effectiveness should be evaluated rather than assumed.
Residual risk represents exposure remaining after controls.
Residual risk should be evaluated against approved acceptance criteria.
Every material risk should have an owner.
Risk treatment may involve mitigation, avoidance, transfer, or acceptance.
Risk assessments should be reviewed periodically and after significant change.
Risk results should directly influence the Risk Treatment Plan and Statement of Applicability.
GRC professionals facilitate, document, challenge, and govern the risk assessment process.

Knowledge Check

Before continuing, make sure you can answer:

Why is risk assessment central to ISO/IEC 27001?
What should a risk methodology define?
What is risk criteria?
What are risk acceptance criteria?
What is inherent risk?
What is residual risk?
What is the difference between a threat and vulnerability?
What is a good risk statement?
Why should business services be identified?
What factors influence likelihood?
What factors influence impact?
Why should control effectiveness be evaluated?
What is risk evaluation?
What are the four common risk-treatment options?
What is the role of a risk owner?
When should risk reassessment occur?
Why should accepted risk be formally documented?
How does risk assessment connect to the Statement of Applicability?
Why should Annex A not be used as the starting point for risk assessment?
What role does GRC play in ISO risk assessment?

What’s Next?

➡️ Next: 07 — Risk Treatment Plan

In the next lesson, you will move from identifying and evaluating information-security risks into deciding how each unacceptable risk will be treated.

You will learn how to:

Review Residual Risk
      ↓
Determine Treatment Strategy
      ↓
Select Security Controls
      ↓
Assign Control Owners
      ↓
Define Remediation Actions
      ↓
Establish Target Dates
      ↓
Estimate Target Residual Risk
      ↓
Obtain Risk Owner Approval
      ↓
Track Implementation

You will also build the practical artifacts needed for ISO/IEC 27001 implementation, including a Risk Treatment Plan, Risk Treatment Decision Matrix, Treatment Action Tracker, Residual Risk Approval Record, and Control Mapping Register.

These outputs will directly prepare you for the next major ISO artifact: the Statement of Applicability.