ISO 27001 risk assessment: a practical guide to Clauses 6.1.2 and 8.2

An ISO 27001 risk assessment is the process you define and repeat to find information security risks, work out how serious they are and decide which ones need treatment. The standard asks for a documented, consistent process (Clause 6.1.2) and for assessments to be repeated at planned intervals and after significant change (Clause 8.2). It does not prescribe one scoring method, so you choose a method that fits your organisation and then apply it the same way every time.

This guide walks through the steps in the order you would do them, shows a worked example, explains what records an auditor expects and covers how the assessment relates to ISO 31000, NIS2 and DORA.

What an ISO 27001 risk assessment is for

ISO 27001 is a risk-based standard. Every control you choose, every policy you write and every item in the Statement of Applicability should trace back to a risk you have identified or to a legal or contractual requirement. The risk assessment is where that chain begins.

According to ISO/IEC 27001:2022, the process establishes risk criteria, identifies information security risks linked to loss of confidentiality, integrity and availability, analyses their consequences and realistic likelihood, and evaluates and prioritises them for treatment. The goal is a ranked, owned list of risks that tells you where to spend effort first.

If you are still deciding whether certification suits your organisation, our page on ISO 27001 and who it covers gives the wider picture. If you want a quick view of where you stand today, the free ISO 27001 readiness test is a good starting point.

What Clause 6.1.2 and Clause 8.2 require

The two clauses do different jobs. Clause 6.1.2 is about designing the process. Clause 8.2 is about running it.

Clause 6.1.2: define the process

The standard requires you to define and apply a risk assessment process that:

1. Establishes and maintains risk criteria, including risk acceptance criteria and criteria for performing assessments.
2. Ensures that repeated assessments produce consistent, valid and comparable results.
3. Identifies the information security risks within the scope of your management system and the owners of those risks.
4. Analyses the potential consequences and the realistic likelihood of those risks and determines the risk levels.
5. Evaluates the risks against your criteria and prioritises them for treatment.

You must also keep documented information about the process. All of this is set out in the text of the standard.

Clause 8.2: run it and keep the results

Clause 8.2 requires you to perform information security risk assessments at planned intervals, or when significant changes are proposed or occur, taking account of the criteria set under Clause 6.1.2(a). You retain documented information of the results. In practice this means a schedule you can show an auditor and a trail of dated assessments you can compare.

Step 1: Write your methodology and risk criteria

Before you list a single risk, write down how you will judge risks. This is the step most often rushed, and it is the one an auditor reads first.

Your methodology document should answer these questions:

• Scope. Which parts of the organisation, which systems, locations and suppliers does the assessment cover? Align it with the scope of your management system.
• Scales. How do you rate likelihood and impact? A common choice is a five-point scale for each, giving a 5 x 5 matrix and scores from 1 to 25.
• Impact definitions. What does each impact level mean for your business? Tie levels to things you can recognise, such as hours of downtime, number of records exposed, contractual penalties or regulatory reporting.
• Acceptance criteria. At what score can a risk be accepted, and who may accept it? Set the threshold in advance so that borderline decisions are defensible.
• Approach. Will you work from assets, from scenarios, from processes or from a mix? ISO 27001:2022 no longer requires an asset-based approach, so choose what your team can apply consistently.
• Frequency and triggers. How often will you reassess and which events trigger an extra assessment?

Keep the method as simple as your organisation can sustain. A small company that scores 40 scenarios consistently is better placed than one that designs a 12-factor model and abandons it after the first round.

An example scoring table

The figures below are an illustration of how a table can be built. Adapt the wording and thresholds to your own organisation.

Write the decision rules in your methodology document and have top management approve it. That approval is part of showing that the process is defined and applied.

Step 2: Identify the risks and their owners

Now you list what could go wrong. Clause 6.1.2 asks for risks associated with loss of confidentiality, integrity and availability of information within the scope, and for an owner for each risk.

Useful sources of risks include:

• Your inventory of information assets and the systems that process them.
• Business processes, for example payroll, customer onboarding or software release.
• Suppliers and cloud services that hold or process your data.
• Incidents, near misses and findings from earlier audits or tests.
• Legal and contractual requirements from customers.
• Results of technical testing. A vulnerability assessment or application test gives concrete input on weaknesses in your systems and feeds the likelihood rating directly.

Write each risk as a scenario with a cause, an event and a consequence. “Laptop theft” is a label. “An unencrypted laptop with customer exports is stolen during travel, exposing personal data” is a scenario you can score and treat.

For technology-heavy organisations, examples of cloud, software and IT environment threats can help you widen the list. This overview of risk assessment for cloud and software environments shows the kinds of systems and exposures that teams often review.

Every risk gets a named owner. The owner is a person with the authority to decide how the risk is handled, such as a head of engineering for a deployment risk. A job title is easier to keep current than a name, but either is acceptable if it is clear who is accountable.

Step 3: Analyse likelihood and impact

For each risk, estimate the potential consequences if it happened and the realistic likelihood that it will. The word “realistic” in the standard matters. Rate likelihood on the controls you actually have in place today and on the threats you have seen, rather than on the worst imaginable case.

A short worked example, using the illustrative table above:

Two habits keep the numbers credible. First, record the reasoning next to each score in a sentence, so that someone else could reach the same result. Second, have more than one person review the scores, because the standard asks for results that are consistent, valid and comparable.

Step 4: Evaluate and prioritise

Evaluation compares each risk level with your acceptance criteria and puts the risks in order. The risks above the threshold go forward for treatment, with the highest first. Those below it are accepted, and the owner’s acceptance is recorded.

The result is a risk register. A useful register holds, for each risk: the scenario, the owner, the likelihood and impact scores, the resulting level, the evaluation outcome and the treatment decision. Because Clause 6.1.2 requires comparable results, keep earlier versions so you can show how risk levels moved after you applied controls.

Step 5: Treat the risks and produce the Statement of Applicability

The assessment is only the first half of the work. Clause 6.1.3 requires you to choose risk treatment options based on the assessment results, determine the controls needed to implement them, compare those controls with Annex A to check that nothing necessary has been missed, and produce a Statement of Applicability. The statement lists the necessary controls, the justification for including them and whether they are implemented, and the justification for excluding any Annex A control. You also formulate a risk treatment plan and obtain risk owners’ approval of it and of the residual risks. See the standard itself for the exact wording.

Typical treatment options are to reduce the risk with controls, avoid it by stopping the activity, share it, for example through a supplier contract or insurance, or accept it within your criteria. Clause 8.3 then requires you to implement the plan and retain documented information on the results of treatment.

After treatment, rate each risk again. The remaining level is the residual risk, and the owner approves it.

Records an auditor expects to see

ISO 27001 asks for documented information at several points in this chain. A practical checklist:

• The risk assessment methodology and criteria (Clause 6.1.2).
• The results of each assessment, dated and retained (Clause 8.2).
• The risk treatment plan and the Statement of Applicability (Clause 6.1.3).
• The results of risk treatment (Clause 8.3).
• Evidence that owners approved the plan and accepted residual risk.

If these records live in separate spreadsheets, version drift is the usual problem. A platform that keeps the risk register, controls and evidence together makes it easier to show how each risk connects to a control and to proof that the control works. This is the approach we take at Guardiso, described below.

How often to repeat the assessment

Clause 8.2 gives two triggers: planned intervals and significant changes. The standard does not name a number of months. You set the interval in your methodology and then keep to it. Many organisations choose a full review once a year and a lighter check each quarter, but the right rhythm depends on how fast your environment changes.

Events that commonly justify an extra assessment:

• Moving a major system to a new cloud provider or changing a core supplier.
• Launching a new product or entering a new market.
• A significant incident or a serious finding from a penetration test.
• An acquisition, a reorganisation or a change in the legal requirements that apply to you.

Write these triggers into the methodology, so the extra assessment is a documented decision and not an improvised one.

How the assessment relates to ISO 31000

ISO 27001 borrows its risk vocabulary from the wider family of risk management standards. ISO 31000 offers general guidelines on managing risk of any kind, and ISO 27001 applies the same logic of identifying, analysing and evaluating risk to information security. You can use ISO 31000 as a reference when your organisation already runs enterprise risk management, because then the information security register can use the same scales and reporting lines as other risks. ISO 27001 does not require you to follow ISO 31000, and the standard’s own requirements in Clause 6.1.2 are what an auditor checks.

If your organisation also works on business continuity, the same register can feed your plans under ISO 22301. For personal data, ISO 27701 extends the management system with privacy controls.

ISO 27001, NIS2 and DORA: what to keep apart

For organisations in the European Union, the risk assessment often serves several rules at once. It helps to separate what the standard asks from what the law asks.

• NIS2. The NIS2 Directive requires entities in scope to take appropriate and proportionate technical, operational and organisational measures to manage the risks to their network and information systems. Article 21 lists the areas those measures must address. A documented ISO 27001 risk assessment supplies much of the evidence, but your national transposition and your regulator define what applies to you.
• DORA. Regulation (EU) 2022/2554 sets out ICT risk management requirements for financial entities, with its own rules on ICT third-party risk and incident reporting. An ISO 27001 risk process can support these duties, but DORA’s text defines the obligations.
• GDPR. Security of processing under the GDPR is judged against risk to individuals, so privacy impact belongs in your impact definitions as well as business impact.

A single register that tags each risk and control with the regulations it supports lets you reuse the same evidence in several places. Certification under ISO 27001 is voluntary in general. A customer contract, a tender or a regulator may still ask for it or for something equivalent, so check the requirement that applies to you.

Common mistakes to avoid

• No acceptance criteria. Without a threshold set in advance, every borderline decision becomes an argument.
• Scores with no reasoning. Numbers that nobody can explain do not produce comparable results.
• Risks without owners. Clause 6.1.2 expects owners, and unowned risks tend to remain untreated.
• A one-off assessment. Clause 8.2 expects repetition and a record of each round.
• Treatment that does not trace back. Each control in the Statement of Applicability should link to a risk or a requirement.
• A method too heavy to sustain. A simpler model applied every time beats a sophisticated one used once.

Running the assessment in Guardiso

Guardiso is a platform for managing information security and regulatory compliance, and it is run by an ISO 27001 certified company. Teams use it to keep the risk register, policies, controls and evidence in one place. The platform shows compliance status, risks and open tasks, and it collects evidence from tools such as Microsoft 365, GitHub and AWS through integrations. One set of documents and evidence is designed to serve ISO 27001, GDPR, NIS2, DORA and other standards, so you do not repeat work for each framework.

Plans start at €199 per month for Starter and €499 per month for Professional, with Enterprise priced on request. See the plans and pricing to compare them. If you want expert help with the assessment itself, our virtual security officer service and security audits are available alongside the platform.

FAQ

Does ISO 27001 require a specific risk assessment method?

No. Clause 6.1.2 requires a defined process with risk criteria, consistent and comparable results, identified risks and owners, analysis and evaluation. You choose the scales and the approach, document them and apply them the same way each time.

How often must an ISO 27001 risk assessment be done?

Clause 8.2 requires assessments at planned intervals and when significant changes are proposed or occur. The standard does not state a number of months, so you set the interval in your methodology. Many organisations review annually.

What is the difference between a risk assessment and a risk treatment plan?

The assessment identifies, analyses and evaluates risks. The treatment plan, produced under Clause 6.1.3, says what you will do about the risks that need action, with controls, owners and timing. The Statement of Applicability records which controls are necessary and why.

Is ISO 27001 mandatory?

The standard itself is voluntary. Customers, tenders or sector regulations can make certification or a similar level of assurance a practical requirement. Laws such as NIS2 and DORA set their own duties, which an ISO 27001 risk process can help you evidence.

Sources

• ISO/IEC 27001:2022, Information security management systems requirements
• ISO 31000 risk management guidelines
• Directive (EU) 2022/2555 (NIS2)
• Regulation (EU) 2022/2554 (DORA)

Recommended

• ISO 27001: what it is, who it covers
• Free ISO 27001 readiness test