ISO 27001 Clause 6.1.2: Three Risk Assessment Methods

Teams preparing for ISO/IEC 27001:2022 certification often start the same way: a spreadsheet listing every laptop, server, application and document, each with threats and vulnerabilities attached. Months later the register is out of date and nobody owns it. This article explains ISO 27001 clause 6.1.2 risk assessment methods that avoid this outcome, and what a certification auditor actually needs to see.

What clause 6.1.2 requires

Clause 6.1.2 of ISO/IEC 27001:2022 requires the organization to define and apply an information security risk assessment process. The standard does not prescribe a tool, a formula or an asset inventory. It sets out four elements that the process must have.

1. Risk criteria. The organization establishes and maintains criteria for accepting risk and for performing assessments. In practice this means an agreed scale for likelihood and impact, and a stated threshold above which risk must be treated.
2. An assessment method. The process identifies information security risks, analyses them and evaluates them against the criteria. The method must be defined, not improvised for each assessment.
3. Consistent, valid and comparable results. If two people assess the same risk, or the same person assesses it a year apart, the outcome should be explainable and comparable. This is where unclear scales and undefined terms cause trouble.
4. A documented process. The organization retains documented information about the process and about its results.

Nothing in these four elements asks for completeness at the level of individual assets. An auditor tests whether the process is defined, followed and repeatable. That is why an oversized register tends to fail: it shows effort, but not control.

Why exhaustive inventories get rejected

The usual gaps we see described in readiness discussions are practical rather than technical:

• Risks are recorded per asset, so the register grows faster than anyone can review it.
• Likelihood and impact scales are never defined, so scores cannot be defended.
• Risk owners are missing, or are the ISMS lead by default.
• The register is not connected to the Statement of Applicability, so the link between a risk and a selected control cannot be shown.
• There is no evidence that the assessment has been repeated or reviewed.

A smaller register that is current, owned and linked to treatment is a stronger audit position than a large one that is none of these.

Three identification methods that work

Clause 6.1.2 requires you to identify risks associated with the loss of confidentiality, integrity and availability of information within the ISMS scope. It does not dictate how. Three approaches are widely used, and they can be combined.

1. Asset-centric: critical systems first

Start with the systems and information that the business cannot operate without, such as core platforms, customer data stores and key suppliers. For each, record the main risks to confidentiality, integrity and availability. Lower-value assets are grouped by type rather than listed individually.

This suits mid-sized organizations with a defined set of critical services and an IT team that already knows where they are. The inventory stays short because it is bounded by criticality.

2. Scenario-based: common threats

Begin with a list of realistic scenarios, for example ransomware on file servers, compromised privileged credentials, loss of a cloud provider, or a data leak through a third party. Each scenario is assessed once against the criteria and mapped to the systems it affects.

This suits smaller organizations, or those with limited asset data. It gives management a readable register in which each line is a risk they recognize, and it scales well as new scenarios are added.

3. Compliance-driven: regulatory controls

Here the starting point is the control expectations that apply to the organization, such as those issued by the National Cybersecurity Authority, SAMA for financial institutions, or the Saudi Data and AI Authority under the Personal Data Protection Law. Gaps against those expectations are treated as risks and assessed against the same criteria.

This suits regulated organizations that already track control gaps. It avoids a second parallel exercise, but it should not be the only input: a compliance gap list does not by itself describe business-specific threats.

Which method fits which organization

• Small organization, limited documentation: scenario-based, with a short list of critical systems added for context.
• Mid-sized organization with defined critical services: asset-centric for the critical tier, with scenarios for cross-cutting threats.
• Regulated or multi-framework organization: compliance-driven as the baseline, supplemented by scenarios so that risks not covered by a regulation are still seen.

Whichever you choose, write down why. The rationale for the method is part of the documented process, and auditors often ask for it.

The evidence a stage-two audit expects

Stage 2 looks for proof that the process has operated, not only that it exists. Three records carry most of the weight:

• Risk register. Each risk has a description, an owner, a likelihood and impact rating under the stated criteria, and a resulting level.
• Risk assessment report. A short document stating the method, the criteria, the scope, the date, who took part and the outcome, so a reader can see how the register was produced.
• Risk treatment plan. For each risk above the acceptance threshold, the chosen treatment, the controls selected, the owner, the timeline and the residual risk accepted by management. It should trace to the Statement of Applicability.

Add evidence of review: meeting minutes, a dated revision, or a management review item that shows the results were considered.

A sensible order of work

1. Confirm the ISMS scope and context, so the assessment has clear boundaries.
2. Define risk criteria and have leadership approve them.
3. Choose the identification method and document the reason.
4. Run the first assessment and populate the register.
5. Write the assessment report and the treatment plan.
6. Update the Statement of Applicability from the treatment decisions.
7. Review the results at management review, then repeat on a defined schedule.

How we help

Our ISO/IEC 27001 ISMS Implementation service covers this work end to end. We implement your ISO/IEC 27001:2022 ISMS: scope, risk assessment, Statement of Applicability, policies, internal audit and management review. Our delivery follows four stages: plan, build, check and certify. The risk assessment sits in the build stage, alongside the Statement of Applicability, policies and controls. The deliverables include a risk register and treatment plan, a Statement of Applicability, an ISMS manual and policies, an internal audit report and a certification readiness review. We support you through the stage 1 and stage 2 audits. A project typically runs 4–8 months.

Next step

If your team is deciding how to approach clause 6.1.2, a short conversation about your scope and critical services is usually enough to choose a method. Talk to us about ISO/IEC 27001 ISMS Implementation to plan a risk assessment your team can maintain and an auditor can follow.