2.2 Information Security Risk Assessment Framework (Clause 6.1.2 & ISO 27005)
Key Takeaways
- ISO/IEC 27001 Clause 6.1.2 mandates establishing and maintaining information security risk assessment criteria, ensuring repeated assessments produce consistent, valid, and comparable results.
- ISO/IEC 27005 provides guidance on information security risk management, aligning assessment methodologies with ISO 31000 risk management principles.
- Risk criteria must define risk acceptance thresholds, impact evaluation levels, and likelihood scales tailored to organizational context and legal/regulatory requirements.
- Every identified risk must have a designated Risk Owner with explicit operational authority and budget accountability to manage and accept residual risk.
- Asset-based and scenario-based risk identification methodologies allow organizations to evaluate threats against confidentiality, integrity, and availability.
2.2 Information Security Risk Assessment Framework (Clause 6.1.2 & ISO 27005)
Risk management is the central operational engine of an Information Security Management System (ISMS). ISO/IEC 27001:2022 Clause 6.1.2 specifies the mandatory requirements for defining and executing an information security risk assessment process. To operationalize Clause 6.1.2 effectively, Lead Implementers rely on ISO/IEC 27005, the supporting guidance standard that outlines detailed risk assessment and treatment methodologies aligned with ISO 31000 risk management principles.
1. ISO 27001 Clause 6.1.2 Mandatory Requirements
Clause 6.1.2 mandates that an organization establish, document, and apply an information security risk assessment process that:
- Establishes Risk Criteria: Defines risk acceptance criteria and criteria for performing information security risk assessments.
- Ensures Repeatability & Comparability: Guarantees that repeated assessments produce consistent, valid, and comparable results regardless of who performs the assessment over time.
- Identifies Information Security Risks: Identifies risks associated with loss of confidentiality, integrity, and availability (CIA triad) for information within the ISMS scope.
- Identifies Risk Owners: Assigns a specific Risk Owner to every identified risk.
- Analyzes & Evaluates Risks: Assesses potential impacts, realistic likelihoods, and estimates risk levels to prioritize risk treatment against acceptance criteria.
+-----------------------------------------------------------------------------+
| CLAUSE 6.1.2 RISK ASSESSMENT PROCESS |
+-----------------------------------------------------------------------------+
| [1. Establish Criteria] --> [2. Identify Risks & Owners] |
| | |
| [4. Evaluate Risk Levels] <-- [3. Analyze Impact & Likelihood] |
+-----------------------------------------------------------------------------+
2. Establishing Risk Criteria, Appetite & Tolerance
Before assessing individual risks, the organization must establish formal risk criteria approved by top management. Without standardized criteria, risk evaluations become subjective, arbitrary, and non-comparable.
Risk Appetite vs. Risk Tolerance
- Risk Appetite: The broad amount and type of risk an organization is willing to accept in pursuit of its strategic objectives (e.g., 'The company maintains zero appetite for regulatory non-compliance or data breaches involving unencrypted customer PII').
- Risk Tolerance: The acceptable operational variation around specific risk metrics (e.g., 'System outages under 30 minutes for non-critical administrative portals are tolerable during scheduled weekend maintenance windows').
Standardizing Impact & Likelihood Scales
Organizations typically establish 3x3 or 5x5 qualitative rating matrices. Below is a standard 5-point impact and likelihood definition scale used in enterprise ISMS assessments:
| Level | Likelihood Definition | Financial / Operational Impact Definition |
|---|---|---|
| 1 - Very Low | Rare; occurs once every 5+ years; negligible threat capability | Negligible impact (<$10k loss); no regulatory reporting required |
| 2 - Low | Unlikely; expected once every 2–5 years | Minor impact ($10k–$50k loss); minor operational delay (<4 hrs) |
| 3 - Moderate | Possible; expected once per year | Moderate impact ($50k–$250k loss); short-term customer disruption |
| 4 - High | Likely; expected multiple times per year | Major impact ($250k–$1M loss); regulatory notification required |
| 5 - Very High | Almost Certain; ongoing exploitation observed | Critical impact (>$1M loss); severe brand damage, executive liability |
3. Risk Owner Identification & Governance Rules
Clause 6.1.2 c) 1) explicitly requires organizations to identify Risk Owners. A Risk Owner is an individual with the operational authority, organizational stature, and budget to manage a given risk and sign off on residual risk levels.
Critical Governance Rules for Risk Ownership
- Functional Authority: Risk Owners must be business process owners or operational executives (e.g., VP of Engineering for software security risks, VP of HR for employee onboarding risks, Head of Infrastructure for cloud downtime).
- The CISO Pitfall: The Lead Implementer or CISO must NOT be assigned as the Risk Owner for operational business risks. The CISO facilitates the risk management framework; business leaders own the operational risks inherent in their business activities.
4. Asset-Based vs. Process/Scenario-Based Risk Identification
ISO/IEC 27005 outlines two primary approaches to identifying information security risks:
Asset-Based Risk Identification (Traditional ISO 27005 Model)
Identifies primary and supporting assets, mapping threats and vulnerabilities to each asset item.
- Primary Assets: Business processes, core activities, and information types (e.g., Customer Credit Card Data, Intellectual Property R&D, Financial Statements).
- Supporting Assets: Hardware, software, networks, personnel, physical sites, and third-party services that store, process, or transmit primary assets.
Process / Scenario-Based Identification (ISO 27001:2022 Focus)
Focuses on risk scenarios impacting business processes regardless of individual underlying server assets (e.g., 'Ransomware infection compromising cloud ERP system, causing 72-hour fulfillment outage and loss of operational integrity'). This modern approach simplifies risk assessments for cloud-native and serverless environments.
5. Threat & Vulnerability Analysis & Risk Matrix
Risk estimation combines threat capability, vulnerability exposure, and control effectiveness to calculate raw and current risk scores.
Enterprise 5x5 Information Security Risk Matrix
Below is a standard 5x5 risk evaluation matrix establishing overall risk severity levels:
| Likelihood \ Impact | 1 - Negligible | 2 - Minor | 3 - Moderate | 4 - Major | 5 - Critical |
|---|---|---|---|---|---|
| 5 - Almost Certain | Moderate (5) | High (10) | High (15) | Critical (20) | Critical (25) |
| 4 - Likely | Low (4) | Moderate (8) | High (12) | High (16) | Critical (20) |
| 3 - Possible | Low (3) | Moderate (6) | Moderate (9) | High (12) | High (15) |
| 2 - Unlikely | Low (2) | Low (4) | Moderate (6) | Moderate (8) | High (10) |
| 1 - Rare | Low (1) | Low (2) | Low (3) | Low (4) | Moderate (5) |
Severity Action Thresholds
- Critical Risk (20–25): Unacceptable. Immediate emergency risk treatment required; mandatory escalation to Executive Board within 24 hours.
- High Risk (10–16): Unacceptable. Risk Treatment Plan mandatory within 30 days; CISO and Risk Owner monthly tracking.
- Moderate Risk (5–9): Tolerable conditionally. Treatment required if cost-beneficial; Risk Owner review quarterly.
- Low Risk (1–4): Acceptable. Retain risk within existing operational controls; review annually.
6. PECB Lead Implementer Exam Insights & Practical Tips
- Repeatability Requirement: Exam questions often ask why qualitative scales must be formally documented. The answer is to satisfy Clause 6.1.2 b) by ensuring repeatable and comparable risk assessment results across different assessors and timeframes.
- Designating Risk Owners: Look out for distractor options assigning risk ownership to external consultants, internal auditors, or CISO assistants. Only operational managers with budget and decision-making authority can own risk.
- Primary vs. Supporting Assets: Remember that information assets (customer records, code repositories) are primary assets, while physical servers and laptops are supporting assets.
Under ISO/IEC 27001:2022 Clause 6.1.2 c) 1), who is qualified to be designated as a Risk Owner for an identified information security risk?
What is the primary purpose of requiring repeatable and comparable risk assessment results under Clause 6.1.2?
According to ISO/IEC 27005 guidance, how are primary assets distinguished from supporting assets in an asset-based risk assessment?