Risk assessment is the engine that drives an ISO 27001 information security management system (ISMS). Without it, control selection becomes guesswork — organisations either implement too many controls and waste resources, or too few and leave critical exposures unaddressed. Clause 6.1.2 of ISO 27001:2022 establishes risk assessment as a mandatory process, requiring organisations to identify information security risks, analyse their likelihood and consequences, and evaluate them against defined criteria.
This guide walks through the full risk assessment lifecycle: from choosing a methodology and identifying assets, through to building a risk register, selecting treatment options, and connecting the results to your Statement of Applicability.
What Clause 6.1.2 requires
ISO 27001:2022 Clause 6.1.2 sets out specific requirements for the risk assessment process. Understanding these requirements is essential before selecting a methodology or beginning any assessment work.
The standard requires organisations to:
- Define and document a risk assessment process that produces consistent, valid, and comparable results each time it is applied.
- Establish risk acceptance criteria — the thresholds that determine whether a risk requires treatment or can be accepted as-is.
- Identify risks to the confidentiality, integrity, and availability of information within the scope of the ISMS.
- Analyse risks by assessing the realistic likelihood of each risk occurring and the potential consequences if it does.
- Evaluate risks by comparing the analysed risk levels against the acceptance criteria and prioritising risks for treatment.
Crucially, the standard does not prescribe how organisations should accomplish these steps. It mandates the outcomes — a documented, repeatable process that identifies, analyses, and evaluates risks — but leaves the methodology to the organisation. This flexibility is intentional: a 30-person SaaS company and a multinational financial institution face fundamentally different risk landscapes and need different approaches.
Choosing a risk assessment methodology
The methodology you select shapes every subsequent step. There are three broad approaches, and most organisations adopt one or combine elements from several.
Asset-based risk assessment
This is the most traditional approach and remains the most widely used for ISO 27001. It begins by identifying information assets — databases, servers, applications, documents, personnel — and then systematically evaluates the threats and vulnerabilities that apply to each asset.
Strengths: Comprehensive coverage, directly links risks to tangible assets, aligns naturally with Annex A control categories.
Limitations: Can become unwieldy in complex environments with thousands of assets. Requires a thorough asset inventory before risk identification can begin.
Scenario-based risk assessment
This approach starts with threat scenarios — realistic narratives describing how an incident could unfold. Examples include “a disgruntled employee exfiltrates customer data via USB” or “a ransomware attack encrypts production databases during a holiday weekend.” Each scenario is assessed for likelihood and impact.
Strengths: More intuitive for stakeholders, focuses attention on realistic attack paths, can surface risks that asset-centric methods miss.
Limitations: May not achieve the same breadth of coverage as asset-based methods. Requires experienced practitioners to develop meaningful scenarios.
Hybrid approach
Many organisations combine both methods: they maintain an asset inventory and use it as the foundation for risk identification, but supplement it with scenario analysis for high-value or high-risk areas. This hybrid approach often delivers the best balance of coverage and practical relevance.
Whichever methodology you choose, document it thoroughly. Your certification auditor will examine the methodology documentation and verify that it produces results that are consistent (different assessors reach similar conclusions), valid (the method accurately reflects real-world risk), and comparable (results can be meaningfully compared across assessment cycles).
Step 1: Identify information assets
Before you can assess risks, you need to know what you are protecting. An information asset is anything that holds value to the organisation because of the information it contains, processes, stores, or transmits.
Common asset categories include:
- Data and information — customer records, financial data, intellectual property, employee personal data, configuration files, encryption keys.
- Software — production applications, operating systems, database management systems, SaaS tools, custom scripts.
- Hardware — servers, workstations, mobile devices, network equipment, removable media.
- Services — cloud hosting, DNS providers, payment processors, email platforms, third-party APIs.
- People — employees with privileged access, contractors, key personnel whose knowledge is critical to operations.
- Physical locations — data centres, offices, archive storage.
For each asset, record the asset owner (the individual or team accountable for the asset), the classification level, and its importance to the organisation. This information feeds directly into the risk analysis stage: a risk affecting a critical production database demands different treatment from one affecting an internal wiki page.
Avoid the temptation to catalogue every minor asset. Focus on assets that are material to the confidentiality, integrity, and availability of information within your ISMS scope. A bloated asset inventory creates assessment fatigue and dilutes attention from genuine risks.
Step 2: Identify threats and vulnerabilities
With assets catalogued, the next step is to identify what could go wrong. This involves two related concepts:
- Threats are potential causes of an unwanted incident. They can be deliberate (cyber attacks, insider threats, social engineering), accidental (human error, misconfiguration), or environmental (power failure, natural disaster, hardware failure).
- Vulnerabilities are weaknesses that a threat could exploit. Examples include unpatched software, weak access controls, lack of encryption, insufficient logging, and inadequate staff training.
A risk exists where a threat intersects with a vulnerability. A phishing attack (threat) is only a risk if employees lack security awareness training and email filtering is inadequate (vulnerabilities). Documenting both the threat and the vulnerability for each risk ensures that treatment plans target the right layer of the problem.
Useful sources for identifying threats and vulnerabilities include:
- Threat intelligence feeds and industry reports (e.g., ENISA Threat Landscape, Verizon DBIR).
- Internal incident history and near-miss reports.
- Vulnerability scan results and penetration test findings.
- Results from previous risk assessments.
- Input from asset owners and operational teams who understand day-to-day exposures.
Step 3: Assess likelihood and impact
Each identified risk must be analysed to determine its level. ISO 27001 does not mandate a specific scoring system, but most organisations use a qualitative scale — typically a 3-point or 5-point rating for both likelihood and impact.
Likelihood scale (example — 5-point)
| Rating | Label | Description |
|---|---|---|
| 1 | Rare | Could occur only in exceptional circumstances |
| 2 | Unlikely | Not expected to occur but possible |
| 3 | Possible | Could occur at some point during the assessment period |
| 4 | Likely | Probable occurrence within the assessment period |
| 5 | Almost certain | Expected to occur, possibly multiple times |
Impact scale (example — 5-point)
| Rating | Label | Description |
|---|---|---|
| 1 | Negligible | Minimal operational or financial impact |
| 2 | Minor | Limited impact, manageable within normal operations |
| 3 | Moderate | Significant disruption or financial loss |
| 4 | Major | Severe impact on operations, reputation, or regulatory standing |
| 5 | Critical | Existential threat to the organisation or its customers |
The risk level is typically calculated as likelihood x impact, producing a score between 1 and 25. This score determines where each risk falls on the risk matrix and whether it exceeds the organisation’s risk acceptance threshold.
Be rigorous about consistency. If two assessors evaluate the same risk and reach significantly different scores, the methodology needs clearer criteria or calibration sessions. Document the rationale behind each score — auditors will ask why a particular risk was rated as “likely” rather than “possible,” and you need a defensible answer.
Step 4: Evaluate and prioritise risks
Risk evaluation compares each risk’s calculated level against the risk acceptance criteria defined in your methodology. Risks that exceed the threshold require treatment; risks below the threshold may be accepted, though they should still be documented and monitored.
A common approach is to divide the risk matrix into three zones:
- Low risk (scores 1-6): Generally acceptable. Monitor and review at planned intervals.
- Medium risk (scores 7-14): Require attention. Treatment should be planned and implemented within a defined timeframe.
- High risk (scores 15-25): Require urgent treatment. Escalate to senior management and address as a priority.
Prioritisation ensures that limited resources are directed at the risks that matter most. An organisation with 150 identified risks cannot treat them all simultaneously — the evaluation step creates a ranked list that drives the treatment plan.
Step 5: Build the risk register
The risk register is the central artefact of the risk assessment process. It records every identified risk, its analysis, its evaluation outcome, and its treatment status. Auditors will examine the risk register closely during certification and surveillance audits.
A well-structured risk register includes the following fields:
| Field | Purpose |
|---|---|
| Risk ID | Unique identifier for tracking |
| Asset | The information asset affected |
| Threat | The threat that could exploit the vulnerability |
| Vulnerability | The weakness that enables the threat |
| Likelihood | Rated score for probability of occurrence |
| Impact | Rated score for consequence severity |
| Risk level | Calculated score (likelihood x impact) |
| Risk owner | Individual accountable for managing the risk |
| Treatment option | Mitigate, accept, transfer, or avoid |
| Existing controls | Controls already in place that reduce the risk |
| Planned controls | Additional controls to be implemented |
| Target risk level | Expected risk level after treatment |
| Status | Open, in treatment, accepted, closed |
| Review date | Next scheduled review |
Each entry should contain enough detail for someone unfamiliar with the risk to understand its nature, significance, and treatment approach. Sparse entries — “server risk, medium, mitigate” — will not satisfy auditors and provide no operational value.
Step 6: Select risk treatment options
ISO 27001 defines four risk treatment options. Every risk that exceeds the acceptance threshold must be assigned one of these options, documented in a risk treatment plan.
Risk modification (mitigate)
Apply controls to reduce the likelihood, the impact, or both. This is the most common treatment option. Controls may be drawn from Annex A of ISO 27001:2022 or from other sources. For example, mitigating the risk of unauthorised access to a production database might involve implementing multi-factor authentication, restricting network access, enabling audit logging, and conducting regular access reviews.
Risk retention (accept)
Accept the risk without additional controls. This is appropriate when the risk level falls within the organisation’s acceptance criteria, or when the cost of treatment significantly exceeds the potential impact. Risk retention must be a conscious, documented decision approved by the risk owner — not a default for risks the organisation has simply not addressed.
Risk sharing (transfer)
Transfer part of the risk to a third party. The most common example is cyber insurance, which transfers the financial impact of certain incidents. Outsourcing specific functions to a specialist provider can also constitute risk sharing, though it does not eliminate the risk entirely — the organisation retains accountability for ensuring the third party manages the risk appropriately.
Risk avoidance
Eliminate the risk by discontinuing the activity or removing the asset that gives rise to it. For example, an organisation might avoid the risks associated with storing payment card data by using a tokenised payment provider instead. Avoidance is often the most effective treatment but is not always practical.
Creating the risk treatment plan
The risk treatment plan translates treatment decisions into actionable work. For each risk being treated, the plan should document:
- The specific controls or actions to be implemented.
- The individual or team responsible for implementation.
- The target completion date.
- The resources required (budget, personnel, tools).
- The expected residual risk level after treatment.
The risk treatment plan is a required document under Clause 6.1.3. Auditors will verify that it exists, that it covers all risks requiring treatment, and that progress is being tracked. Crucially, they will also verify that management has formally approved the plan and accepted the residual risks.
Connecting to the Statement of Applicability
The Statement of Applicability (SoA) is one of the most important documents in the ISMS and is directly driven by the risk assessment. The SoA lists all 93 controls from Annex A of ISO 27001:2022 and states, for each control:
- Whether the control is applicable or not.
- The justification for inclusion or exclusion.
- Whether the control is currently implemented.
The link between the risk assessment and the SoA must be traceable. For every control included in the SoA, an auditor should be able to follow the chain: a risk was identified, a treatment option of “modify” was selected, and this specific control was chosen to address that risk. Controls may also be included for legal, regulatory, or contractual reasons beyond what the risk assessment surfaces — but the risk assessment is the primary driver.
Maintaining this traceability manually is error-prone. As the risk register grows and controls evolve, keeping the SoA synchronised requires disciplined process or a GRC platform that maintains the mappings automatically.
Ongoing risk monitoring and review
A risk assessment is not a one-time exercise. ISO 27001 requires organisations to review and update their risk assessments at planned intervals and whenever significant changes occur. Triggers for reassessment include:
- Organisational changes — mergers, acquisitions, new product launches, changes to ISMS scope.
- Technology changes — migration to new platforms, adoption of new tools, significant architecture changes.
- Threat landscape changes — emergence of new attack techniques, industry-specific threat intelligence.
- Incident findings — security incidents or near-misses that reveal previously unidentified risks.
- Audit findings — internal or external audit observations that highlight gaps.
Effective risk monitoring goes beyond periodic reassessment. Organisations should establish mechanisms for continuous risk awareness: automated vulnerability scanning, threat intelligence feeds, control effectiveness metrics, and regular communication with asset owners.
Practical considerations for implementation
Start with scope clarity. Before beginning the risk assessment, ensure the ISMS scope is clearly defined. Assessing risks for systems and processes outside the scope wastes effort and confuses auditors.
Involve the right people. Risk identification is not a solo activity. Asset owners, IT operations, development teams, and business stakeholders all contribute perspectives that a single assessor cannot replicate. Structured workshops are often more productive than circulating questionnaires.
Calibrate your scales. Run calibration sessions where multiple assessors score the same set of risks independently, then compare results. Significant divergence indicates that your likelihood and impact criteria need sharper definitions.
Document decisions, not just scores. The rationale behind each risk rating and treatment decision is as important as the score itself. When an auditor asks why a particular risk was accepted, “because it scored 6” is insufficient — the reasoning must be articulated.
Use tooling that scales. Spreadsheet-based risk registers work for initial assessments but become difficult to maintain as the ISMS matures. GRC platforms like Prova provide structured risk registers, automated scoring, control mapping, and the traceability that auditors expect.
Risk assessment under ISO 27001 is demanding but not mysterious. The organisations that do it well treat it as an ongoing operational discipline rather than a compliance exercise — and they are rewarded with an ISMS that genuinely reflects their risk landscape, not just one that satisfies an auditor on certification day.