Skip to main content

Risk as a First-Class Citizen: Methodology, Asset Valuation, Threat Modeling, and Treatment Options

"Risk comes from not knowing what you're doing."

  • Warren Buffett

Introduction: The Engine Room of the ISMS​

If Chapter 2 established the foundation of the ISMS - who you are, what you're protecting, and who holds the accountability - then Chapter 3 is where the ISMS develops its reasoning capacity. Risk management is not a step in the ISO 27001 process. It is the process. Every control selected, every policy written, every investment justified, every exception approved should trace back to a risk decision.

Organizations that understand this build ISMSs that get progressively stronger. Organizations that don't build risk registers that are completed once, filed, and never consulted again.

This chapter dissects the ISO 27001 risk management process from first principles: the methodology choices, asset identification and valuation, threat and vulnerability analysis, risk evaluation, treatment options, and the Statement of Applicability that ties it all together.

Part 1 - The Regulatory and Conceptual Framework​

1.1 What ISO 27001 Actually Requires​

Clauses 6.1.2 and 6.1.3 of ISO 27001:2022 establish the core requirements for risk assessment and risk treatment.

Clause 6.1.2 (Information security risk assessment) requires that the organization:

  • Establishes and applies an information security risk assessment process
  • Defines and maintains information security risk criteria, including risk acceptance criteria
  • Ensures that repeated risk assessments produce consistent, valid, and comparable results
  • Identifies risks associated with the loss of confidentiality, integrity, and availability of information assets
  • Analyzes the risk - assessing the realistic likelihood of occurrence and the potential consequences
  • Evaluates the risk against the risk criteria established
  • Retains documented information about the risk assessment process

Clause 6.1.3 (Information security risk treatment) requires that the organization:

  • Selects appropriate risk treatment options, with reference to the risk assessment results
  • Determines all controls necessary to implement the chosen treatment options
  • Compares the controls determined with those in Annex A and verifies no necessary controls have been omitted
  • Produces a Statement of Applicability
  • Formulates a risk treatment plan
  • Obtains risk owner approval of the risk treatment plan and acceptance of residual risks

What the standard does not prescribe is the specific methodology to be used. The organization has genuine latitude in methodology - but must apply its chosen methodology consistently and must produce results that are reproducible.

1.2 ISO 27005: The Supporting Standard​

ISO 27005 - Information security risk management - is the companion standard that provides detailed guidance on the risk management process. The 2022 revision presents two primary risk assessment approaches:

The asset-based approach starts with information assets, identifies the threats and vulnerabilities relevant to each asset, and derives risks from the combination of asset value, threat likelihood, and vulnerability severity.

The event-based approach starts with risk scenarios - specific events or incident types - and assesses the likelihood and impact of those events occurring.

In practice, most mature ISMSs use a hybrid approach.

Part 2 - Building the Risk Methodology​

2.1 The Methodology Document​

A complete risk methodology document covers:

Risk criteria. The scales and thresholds used to evaluate risk. What does a likelihood score of 3 mean? What does an impact score of 4 mean?

Risk appetite statement. The organization's overall tolerance for information security risk, expressed in terms that are actionable.

Assessment scope and frequency. Which assets, processes, or scenarios will be assessed, at what schedule, and triggered by what events?

Roles and responsibilities in the risk process. Who conducts assessments? Who owns risks? Who approves treatment plans?

Documentation requirements. What records will the risk process produce?

2.2 Choosing a Scoring Approach​

Qualitative scoring uses defined categories - typically high/medium/low, or numerical scales where numbers represent categories.

Advantages: Accessible to non-technical stakeholders, quick to apply, sufficient for most operational risk decisions.

Disadvantages: Aggregation is not mathematically meaningful; different analysts may apply the same scale differently.

Quantitative scoring attempts to express risk in financial terms - annualized loss expectancy (ALE) = annual rate of occurrence (ARO) × single loss expectancy (SLE).

Advantages: Produces financially meaningful outputs; enables direct cost-benefit analysis of controls.

Disadvantages: Requires data that is rarely available with sufficient confidence.

The practical recommendation for most organizations: use a well-defined qualitative approach as the primary methodology, supplemented by quantitative estimation for the highest-priority risks where investment decisions must be justified to financial stakeholders.

2.3 The Risk Matrix​

Symmetrical matrices obscure risk prioritization. A standard 5×5 matrix with risk = likelihood × impact treats high-likelihood/low-impact risks and low-likelihood/high-impact risks as equivalent. Better matrix designs weight catastrophic impact disproportionately.

Too many risk levels create false precision. A matrix with five risk levels is more useful than one with seven.

The matrix must be paired with defined treatment thresholds.

Part 3 - Asset Identification and Valuation​

3.1 What Counts as an Information Asset​

Information assets proper - customer personal data, financial records, intellectual property, proprietary business processes, strategic plans, employee data, authentication credentials, cryptographic keys, configuration data, audit logs.

Technology assets - servers, endpoints, mobile devices, network infrastructure, cloud environments, databases, applications, APIs.

People assets - personnel whose knowledge, access, or skills represent assets.

Physical assets - data centers, server rooms, office facilities, physical media.

Service assets - cloud services, managed services, utilities, telecommunications, third-party processing services.

The common mistake: conflating the asset with the container. A server is not an information asset - it is a container that holds or processes information assets.

3.2 The Asset Inventory: Building and Maintaining It​

Building a complete asset inventory is harder than it sounds:

Shadow IT. In most organizations, a significant portion of the technology estate has been deployed without the knowledge of IT or security.

Information fragmentation. The same data may exist in multiple places simultaneously.

Dynamic environments. Cloud-native and DevOps environments can create and destroy infrastructure at a rate that makes traditional asset management obsolete.

Third-party assets. Assets held by third parties are part of the organization's information risk.

Practical approaches include automated network discovery tools, cloud asset management tools, data discovery and classification tools, and staff surveys to surface shadow IT.

3.3 Asset Valuation: The Foundation of Proportionate Risk Management​

Asset value is assessed across three dimensions:

Confidentiality value: What is the consequence if this information is disclosed to unauthorized parties?

Integrity value: What is the consequence if this information is modified in an unauthorized or undetected manner? Integrity value is often underestimated.

Availability value: What is the consequence if this information or system is unavailable when needed?

Real-world example: A professional services firm conducted an asset valuation exercise and identified that its client contract database was its highest-value information asset - high confidentiality value, moderate integrity value, and high availability value. This valuation drove the investment of stronger access controls, encrypted backups with tested recovery procedures, and integration into the business continuity plan - none of which had been applied before the valuation exercise made the case.

Part 4 - Threat and Vulnerability Analysis​

4.1 Understanding Threats​

A threat is a potential event or action that could exploit a vulnerability to cause harm to an information asset.

By origin:

  • Human threats - deliberate (external attackers, insider threats) or accidental (employee error)
  • Environmental threats - natural events and physical events
  • Technical threats - software vulnerabilities, hardware failures, malware

By actor:

  • External attackers - criminal organizations (financially motivated), nation-state actors (espionage, sabotage), hacktivists, opportunistic attackers
  • Insiders - employees, contractors, and privileged users who misuse their access
  • Third parties - suppliers, partners, and other entities with authorized access

By technique: The MITRE ATT&CK framework provides the most comprehensive and practically useful taxonomy of threat techniques available.

4.2 Threat Intelligence as a Risk Input​

Sources of threat intelligence relevant to ISO 27001 risk assessment include:

Sector-specific intelligence: Information Sharing and Analysis Centers (ISACs) in financial services, healthcare, energy, and other sectors.

Government sources: CISA (US), NCSC (UK), ENISA (EU), and equivalent national agencies publish advisories, alerts, and annual cyber threat assessment reports.

Vendor threat intelligence: The Verizon DBIR, CrowdStrike's annual threat report, Mandiant's M-Trends provide valuable data on incident patterns, attacker behaviors, and sector-specific threats.

Incident history: The organization's own incident history is the most relevant threat intelligence it has.

Annex A 5.7 (Threat intelligence) of the 2022 version explicitly requires organizations to collect and analyze information about threats.

4.3 Vulnerability Analysis​

Technical vulnerabilities: Unpatched software, misconfigured systems, insecure default settings, weak cryptography, insufficient input validation, insecure APIs.

Process vulnerabilities: Inadequate access review processes, change management processes that don't include security review, backup processes that are not tested.

Human vulnerabilities: Insufficient security awareness, susceptibility to social engineering, tendency to share credentials.

Physical vulnerabilities: Inadequate access controls to server rooms, insufficient protection against environmental events.

Organizational vulnerabilities: Unclear security responsibilities, inadequate security budget, poor security culture.

4.4 The Vulnerability-Threat Pairing​

Worked example: A mid-sized financial services firm is assessing the risk to its customer transaction database.

Threat: External attacker - financially motivated criminal organization - using SQL injection to extract customer financial data.

Vulnerability: Customer-facing web application with insufficiently validated input parameters. Penetration test six months ago identified the vulnerability; remediation has been deferred pending a planned application rewrite.

Asset: Customer transaction database - high confidentiality value (financial data, regulatory obligations), high integrity value (financial accuracy), high availability value (transaction processing).

Risk: Unauthorized access to and exfiltration of customer financial data through exploitation of a known SQL injection vulnerability in the customer-facing web application.

Part 5 - Risk Evaluation and Prioritization​

5.1 Likelihood Assessment​

Likelihood is the estimated probability that a specific threat will exploit a specific vulnerability to affect a specific asset within a defined timeframe. Assessing likelihood requires combining:

Threat capability and motivation: Is the threat actor sophisticated enough to exploit this vulnerability?

Vulnerability exposure: Is the vulnerability publicly known? Is it exposed to the internet?

Existing controls: What controls already exist that reduce the likelihood of exploitation?

Historical data: How frequently have similar organizations experienced this type of incident?

5.2 Impact Assessment​

Financial impact: Direct costs (incident response, forensics, legal fees, notification costs, fines, litigation) and indirect costs (business interruption, revenue loss, remediation investment).

Regulatory and legal impact: For organizations subject to GDPR, the potential fine structure (up to €20M or 4% of global annual turnover) must be factored into impact assessment for risks involving personal data.

Reputational impact: The consequences for customer trust, market position, and brand value.

Operational impact: The consequences for business operations - systems unavailable, processes unable to function.

Safety impact: For organizations in sectors where information system failure can create physical safety consequences.

5.3 The Risk Register​

A well-designed risk register is:

Specific. "Business email compromise through phishing of finance team members with wire transfer authority, exploiting insufficient multi-party approval for outbound payments over $50,000" is a risk register entry. "Phishing risk" is not.

Current. The risk register reflects the current state of the risk environment.

Owned. Every risk has a named owner who is accountable for the treatment plan.

Connected. The risk register connects to the treatment plan, the Annex A controls, the incident register, and the internal audit program.

Part 6 - Risk Treatment​

6.1 The Four Treatment Options​

Risk modification (mitigation): Implementing controls that reduce the likelihood or impact of the risk.

Risk avoidance: Eliminating the risk by eliminating the activity that gives rise to it.

Risk sharing (transfer): Transferring some or all of the financial consequence of a risk to a third party - typically through insurance.

Risk acceptance: Accepting the risk - deciding that the level of residual risk is tolerable. Risk acceptance must be:

  • Explicit - documented as a deliberate decision, not a default arising from inaction
  • Authorized - accepted by the appropriate risk owner at the appropriate organizational level
  • Consistent with risk appetite
  • Monitored - tracked and reviewed

The risk acceptance trap: Many organizations have risk registers full of risks that are neither accepted nor treated - they have been identified, scored, assigned to owners, and then left in a state of permanent deferred treatment.

6.2 Control Selection: Using Annex A Correctly​

The correct sequence:

First: Identify the controls needed to address the risk. This is a risk-driven decision.

Second: Map those controls to Annex A.

Third: Confirm that the Annex A check hasn't identified controls that should be relevant but were missed.

The incorrect sequence - starting with Annex A and working backward - inverts the logic of risk-based security.

6.3 The Statement of Applicability​

The Statement of Applicability (SoA) lists every control in Annex A - all 93 controls in the 2022 version - and for each control:

  • Indicates whether the control is applicable
  • Provides justification for inclusion or exclusion
  • Notes the implementation status of each included control

Common SoA failures:

  • Generic justifications that don't link to specific risks ("best practice" is not a justification)
  • Exclusions without justification ("N/A" is not a justification)
  • Inclusions where the control is listed as implemented but audit evidence shows it is not
  • SoA not updated when risks change

6.4 The Risk Treatment Plan​

The risk treatment plan documents for each risk being actively treated:

  • The risk being addressed
  • The treatment option selected
  • The specific controls to be implemented or enhanced
  • The responsible person for implementation
  • The target completion date
  • The expected residual risk after treatment
  • The resources required

Risk treatment plan as a management tool: The plan shows, for each proposed investment: what risk it addresses, what the expected reduction in risk exposure is, and what the residual risk will be if the investment is not made.

Part 7 - Residual Risk and Risk Acceptance​

7.1 Inherent Risk, Control-Adjusted Risk, and Residual Risk​

Inherent risk is the level of risk in the absence of any controls.

Control-adjusted risk is the risk level after existing controls are taken into account.

Residual risk is the risk level that remains after the planned risk treatment is fully implemented.

7.2 Risk Acceptance: The Management Responsibility​

ISO 27001 requires that risk owners explicitly accept residual risks. This is a governance mechanism that ensures:

  • Business leaders understand the risks the organization is carrying
  • The acceptance decision is made by someone with the authority to make it
  • Accepted risks are monitored and reviewed
  • When an incident occurs from an accepted risk, the organization can demonstrate the risk was known and deliberately accepted

Risk acceptance criteria - the thresholds at which risks can be accepted without escalation - should be defined in the risk methodology document and approved by the executive sponsor.

Part 8 - Maintaining the Risk Process Over Time​

8.1 The Living Risk Register​

The risk register should be updated:

At planned intervals - at minimum annually.

Following significant organizational changes - new systems, new processes, restructuring, acquisitions.

Following incidents - every security incident should trigger a risk register review.

Following significant threat intelligence updates - when new attack techniques emerge or a major vulnerability is disclosed.

8.2 Integration with the ISMS Cycle​

The key integration points are:

Risk assessment → SoA: Control applicability determinations should trace to risk assessment outcomes.

Risk assessment → Treatment plan → Controls: The treatment plan drives the control implementation agenda.

Incidents → Risk register: Incidents are data about the accuracy of risk assessments.

Internal audit → Risk register: Audit findings may constitute new vulnerabilities.

Management review → Risk appetite: Management review may result in adjustments to risk appetite.

Part 9 - Common Risk Process Failures​

The compliance-driven risk assessment. The risk assessment is conducted to satisfy the auditor rather than to manage risk. It starts from Annex A rather than from organizational assets and threats.

The consultant-owned risk register. The initial risk assessment is conducted by an external consultant who has never worked in the organization. The risk register is technically correct but not owned by anyone internally.

The missing risk owner. Risks are identified and scored but not assigned to owners.

The static risk register. Updated annually as a management review input but otherwise never touched.

The disconnected SoA. The SoA is completed independently of the risk register.

The unmeasured residual risk. Treatment plans are developed and implemented but residual risks are never formally assessed.

Summary: What Chapter 3 Has Established​

The risk management process is not a component of the ISMS - it is the ISMS's operating logic.

Methodology must be chosen deliberately, documented explicitly, and applied consistently.

Asset identification and valuation is the prerequisite for meaningful risk assessment.

Threat and vulnerability analysis must be grounded in current threat intelligence and specific enough to drive specific treatment decisions.

Risk treatment must be explicit - every risk must be deliberately treated, accepted, avoided, or transferred.

The living risk register - maintained, current, owned, and connected to the full ISMS cycle - is the difference between an ISMS that manages security and an ISMS that documents having once thought about it.

Next: Chapter 4 - Annex A Unmasked: Every Control Domain, Its Attack Surface Relevance, and Its Most Common Implementation Failure

© ISO 27001 Wiki - For CISOs, Security Analysts, and GRC Professionals