ISO 27001 risk assessment: clauses 6.1.2 and 8.2 explained

What an ISO 27001 risk assessment must do before certification

The organization owns its information security risk assessment and risk treatment under clauses 6.1.2 and 6.1.3, and carries them out in operation under clauses 8.2 and 8.3. An accredited certification body audits that work against the standard but does not perform it, and it cannot tell you which risks matter to your business. Before a customer or contract deadline, the question to answer is whether your ISO 27001 risk assessment already exists as a documented method, a risk register and a decision record that a stranger could follow.

The answer differs by organization. The scope of the ISMS sets which processes, systems, sites and people the assessment must cover, so a narrow scope needs fewer assets than a company that runs customer data across several clouds. The number of assets, the number of third parties that hold or process information, and the risk criteria the organization sets for likelihood, impact and acceptance all change the register and the effort to maintain it. Ask your certification body how it expects you to show that your criteria are consistent and repeatable, and confirm the detail with them in writing before you commit to a scope.

Roles should be split clearly. Your leadership decides the risk acceptance levels and signs off treatment choices. Your security or IT staff own the asset inventory, threat and vulnerability input and the treatment plan. An implementation partner such as DeployOpen can prepare the method, the register templates and the evidence trail, and can help run workshops, but it cannot accept risks on your behalf. Only an independent certification body issues the certificate. If you use guidance from ISO/IEC 27005:2022, which describes the risk management cycle of assessment, treatment, communication, monitoring and review, use it as a reference for your own method rather than as a document you can certify.

How the risk assessment runs in operation under clause 8.2

The sequence below turns the clause 6.1.2 and 6.1.3 method into a repeatable operating cycle, and each step leaves a record that an auditor can sample. The organization sets the criteria, owns the decisions and approves the results, while any implementation partner only prepares the register and the supporting evidence.

Establish context and risk criteria
Before any risk is scored, the organization records the context that shapes it: the scope of the ISMS, the relevant external and internal issues under clause 4.1, the interested parties and their requirements, and whether climate change is a relevant issue under the 2024 amendment. The people who own the business decide the risk criteria, including how likelihood and impact are rated, what counts as an acceptable risk and who may accept residual risk. The output is a criteria document with an approval record. The step is done when a reviewer can read the criteria and apply them to a sample risk and reach the same rating.
Identify assets, owners and threats
Staff list the information assets in scope, such as systems, data sets, services, suppliers and facilities, and name an owner for each. For each asset they identify the threats and vulnerabilities that could affect confidentiality, integrity or availability, and the consequences if they occur. Asset inventories, configuration records and recent incident data are the usual inputs. The output is a register of assets, owners and risk scenarios. The step is complete when every in-scope asset has an owner and at least one documented scenario, and the owner has confirmed the entries. Confirm with your own environment whether your asset source of truth is current enough to support this.
Analyze and evaluate each risk
For each scenario, the risk owner estimates likelihood and impact using the criteria from the first step, and the result is compared against the acceptance thresholds. Analysis should consider existing controls, so the rating reflects what is actually in place. Risks above the threshold move to treatment, and those within it are recorded with a documented acceptance decision. The output is a populated risk register with inherent and current ratings, the method used and the name of the person who evaluated each item. The step is done when every scenario carries a rating and a decision, with no blank entries left.
Select risk treatment options
For each risk that needs action, the organization chooses how to treat it: modify it with controls, avoid it, share it or retain it under acceptance. Where controls are chosen, the organization determines which necessary controls apply and compares them with the 93 Annex A controls, as clause 6.1.3 requires. Any Annex A control that is left out must be justified and any necessary control must be carried into the plan. The output is a risk treatment plan that names the controls, owners, status and approval. The step is done when each treated risk links to at least one control and each Annex A exclusion has a stated reason.
Record the Statement of Applicability
The chosen controls are transferred into the Statement of Applicability, which states for each Annex A control whether it applies, whether it is implemented, and why any control was excluded. The compliance lead checks that every necessary control from the treatment plan appears in the statement and that no control has been dropped without a reason. Senior management or the designated approver signs off the document. The output is an approved Statement of Applicability linked to the risk treatment plan. The step is complete when the two documents agree line by line, and an auditor can trace any control back to a specific risk.
Obtain approval and communicate risk results
The risk assessment results and the treatment plan are presented to the risk owners and the approving managers for formal acceptance of residual risk. The organization records the decisions, any open items with owners, and the people who need to act on them, and it communicates the relevant results to the teams that run the controls. The output is a signed approval record and a distribution list or meeting minutes. The step is done when residual risks have named acceptors and no treatment action is left without an owner.
Review at planned intervals and on significant change
Clause 8.2 requires the organization to repeat the risk assessment at planned intervals and when significant changes are proposed or occur. The interval is set by the organization, so confirm it against the standard text and the organization's own policy, and check whether the wording of the chosen interval is defensible to an auditor. Triggers commonly include new systems, new suppliers, major incidents, acquisitions and changes to the business context. Each review updates the register, the treatment plan and the Statement of Applicability, and it keeps the earlier versions for comparison. The output is a dated review record with the changes made. The step is complete when the next scheduled review is recorded and the triggers are written down.
Retain evidence for surveillance audits
Certification bodies test the cycle by sampling. In each annual surveillance audit they review how the assessment has been carried out in operation, including the continuing operational control that covers risk assessments under clause 8.2. The organization keeps the dated versions of the register, the criteria, the treatment plan, the Statement of Applicability and the approval records so the chain from context to decision can be shown. The output is a retrievable evidence set that a reviewer can follow without help from the person who wrote it. The step is done when an internal reviewer can trace one sampled risk from criteria to control to approval within a short walk-through.

How risk treatment links to the Statement of Applicability

The risk treatment decision drives the control set. Under clause 6.1.3 of ISO/IEC 27001:2022, the organization determines the controls it needs to treat the risks it has identified. Those necessary controls are then compared with the 93 controls in Annex A to confirm that nothing needed has been missed. The outcome of that comparison is recorded in the *Statement of Applicability* (SoA), which lists every Annex A control, whether it is included, and why. IAF MD 26:2023 describes this chain explicitly, so an assessor will expect to trace a risk from the register, through the treatment decision, to a control line in the SoA.

Any Annex A control left out of the SoA needs a documented justification. An exclusion is not a shortcut around a risk. It is a reasoned statement that the control is not needed for the organization's identified risks. Where a control that the risk assessment shows is needed is omitted, the gap must be added to the risk treatment plan with an owner and a status. Before the certification audit, check each excluded control against the current risk register and ask whether the justification still holds after recent changes in systems, suppliers or the scope of the ISMS.

The risk treatment plan and the SoA are two views of the same decisions, so they must stay consistent. Each control in the plan should map to an SoA line with a matching implementation status, and each included SoA line should point to evidence the organization can produce. Review both documents whenever the risk assessment is repeated at planned intervals under clause 8.2, and before any surveillance or recertification audit. Confirm with your certification body how it expects these documents to be version-controlled and presented, since its own procedures govern what the auditor will ask to see.

What auditors look for in the risk assessment

An accredited certification body does not grade the risk scores themselves. It tests whether the organization has a method it follows, a record it can replay, and a clear path from each assessed risk to the controls in the Statement of Applicability. The six points below are what that testing typically comes down to.

Documented and repeatable method

The assessor first asks how risks are identified, analyzed and evaluated, and whether the same method would produce comparable results if a different person ran it. Check for a written risk assessment procedure that names the steps, the inputs (asset register, threat sources, vulnerabilities, legal duties) and the outputs. A method that exists only in one analyst's head will not pass. Evidence is the procedure itself plus two or three completed assessments that followed it.

Defined risk criteria

Assessors look for written criteria for likelihood, impact and the level of risk the organization will accept. Without them, two assessors can rate the same risk differently and the ratings cannot be compared over time. Confirm that the scales are documented, approved by management, and applied consistently across business units. Evidence includes the criteria document, the approval record and a sample of scored risks that show the scales in use.

Traceable link to treatment and the SoA

This is the point where most assessments fail in practice. The assessor picks a risk and follows it forward: which treatment option was chosen, which Annex A controls were determined as necessary, whether those controls appear in the Statement of Applicability, and what status each has. Controls that were left out must be justified and recorded in the risk treatment plan. Evidence is a traceable chain from risk ID to treatment decision to SoA line.

Assessments at planned intervals and on change

Clause 8.2 requires risk assessments at planned intervals and when significant changes are proposed or occur. Assessors check the calendar of planned reviews and then look for records of changes that should have triggered a reassessment, such as a new cloud region, a acquired business or a new supplier handling customer data. Evidence includes dated assessment records, the change log and the review schedule, with any gaps explained.

Named owners who accept residual risk

Assessors check that each risk has an owner with the authority to accept it and that residual risk, the level left after treatment, was formally accepted by that person. A risk accepted by a team lead with no record of management approval is a finding waiting to happen. Confirm that owners are named in the risk register, that acceptance is signed or recorded in a tool with an audit trail, and that accepted risks are reviewed on the same cycle as the assessment.

Consistency with scope and context

The assessment must cover the assets, processes, locations and interested party requirements that sit inside the ISMS scope, and it must reflect the context set in clause 4.1. Assessors compare the risk register against the scope statement and the list of external and internal issues. A risk register that omits a site or service named in the scope, or ignores a legal requirement the organization has documented, will raise questions. Evidence is a mapping from scope elements to risk register entries.

How ISO/IEC 27005 guidance fits a 27001 risk method

Teams with no existing risk method can use ISO/IEC 27005:2022 as the reference structure. The guidance is not certifiable on its own, and it does not give a single formula. It describes a risk management cycle of assessment, treatment, communication, monitoring and review, aligned with ISO 31000 principles. The organization decides how to define assets, threats, likelihood, impact and risk criteria, then writes those choices down so they can be repeated.

Define criteria first: Set the scales for likelihood and impact, and the level at which a risk is accepted, before scoring anything.
Map the cycle to clause 8.2: Show how each assessment run in operation produces the inputs for risk treatment under clause 8.3.
Record the method: Keep a document that states the steps, roles, and how results are compared across assessments.
Test with one scenario: Run a small illustrative assessment, such as a cloud backup failure, to find gaps in the scales before the full run.
Plan the review: Set when the method itself is reviewed, not only the risk register.

Check that the method produces a consistent, repeatable result, because an auditor will ask how two people would score the same risk.

Why risk assessments fail audits and how to avoid it

Most failed risk assessments are not missing analysis. They are records that do not agree with each other: criteria, asset inventory, scope, the Statement of Applicability and sign-off. Each pitfall below breaks the chain from risk to treatment to control, and each has a preventive step you can check before an auditor does.

Criteria set after scoring

When risk acceptance criteria are written after the risks are already scored, the criteria appear to justify the outcome rather than drive it. Auditors look for the criteria for risk acceptance and the criteria for performing the assessment, and they check that the scoring used them. Before any scoring, fix the likelihood and impact scales, the risk levels and the acceptance thresholds, approve them, and date them. Then confirm that every scored risk can be traced to those criteria.

Register out of step with inventory

A risk register that lists systems, suppliers or locations absent from the asset inventory or the ISMS scope signals that the assessment was not run on the real environment. Reconcile the register against the asset inventory and the scope statement at each assessment. Any asset in scope with no risk entry, or any risk pointing to an asset that no longer exists, should be explained in the record. An illustrative example is a cloud account added last quarter that appears in the inventory but nowhere in the register.

Exclusions without justification

Under clause 6.1.3, controls determined to be necessary are compared with Annex A, and omitted controls must be justified and recorded in the Statement of Applicability. Exclusions with no reason, or with a reason that does not match the risk treatment plan, are a frequent nonconformity. Each excluded Annex A control should name the risk it does not address and why that risk is absent or accepted. Review the exclusions against the risk treatment plan so the two documents tell the same story.

No reassessment after major change

Clause 8.2 requires risk assessments at planned intervals and when significant changes are proposed or occur. An acquisition, a new hosting provider, a major architecture change or a serious incident should trigger a documented review, even when the next scheduled assessment is months away. Keep a change log that records each trigger, the decision whether to reassess, and the result. Surveillance auditors check continuing operational control, which includes these assessments.

Risk owners who never signed off

Risk treatment decisions are management decisions, so the register should show who owns each risk and who accepted the residual risk. A register with blank owner fields or a single name against every line suggests nobody with authority reviewed the results. Assign each risk to an accountable owner by role, record the acceptance with a date, and retain the approval. Owners who cannot explain their risks during an audit interview are a warning sign.

Climate and third-party risks missing

Amendment 1:2024 requires the organization to determine whether climate change is a relevant issue, and interested parties may hold climate-related requirements. Third-party risks, such as a cloud provider outage or a supplier with weak access controls, also belong in the assessment when they affect the ISMS. If neither appears in the context or the register, record the determination even when the answer is that they are not relevant, with the reasoning. Confirm the current amendment text with the standard before drafting.

Questions buyers ask about ISO 27001 risk assessment

How often must an ISO 27001 risk assessment be repeated?

ISO/IEC 27001:2022 requires the information security risk assessment to be carried out at planned intervals under clause 8.2, and again when significant changes are proposed or occur. The standard does not set a fixed number of months, so the organization defines the interval in its own ISMS and must be able to justify it. Common triggers for an extra assessment include a new product or service, a new cloud region or major architecture change, an acquisition, a serious incident, a new regulatory obligation, or a new critical supplier. Confirm the interval your certification body expects and record the trigger list in your risk management procedure.

Can a certification body write our ISO 27001 risk assessment for us?

No. A certification body cannot write your risk assessment because its impartiality rules prevent it from doing the work it later audits. The organization owns its risk criteria, its risk register and its risk treatment decisions, and it must be able to explain them to the auditor. An implementation partner can help prepare the method, the asset inventory, the risk register and the evidence, and can facilitate workshops, but the decisions and sign-off stay with the organization. Ask any consultant to show how they keep ownership of the risk decisions in writing.

How much effort does an ISO 27001 risk assessment take, and what drives it?

The effort depends mainly on the number of assets and processes in scope, the number of people who must review risks, the number of third parties and cloud services the ISMS depends on, and how much of the asset inventory already exists. The first assessment is the most expensive because it builds the method, the inventory and the baseline register. Later cycles cost less if the register is maintained continuously. Ask any provider to break its estimate into inventory, workshops, analysis, treatment planning and documentation, and to state which of these are one-time and which recur at each review.

Can a small team run an ISO 27001 risk assessment on its own?

A small team can run the assessment itself if it has a defined scope, a simple asset list and someone who understands both the business and the information security risks. Most small teams struggle with consistency rather than volume: they score risks differently over time, skip third-party risks, or do not link the results to the Statement of Applicability. Using a documented method, such as the approach in ISO/IEC 27005:2022, and a short review by someone outside the team helps. Confirm with your certification body how it will test the method and whether it expects a named risk owner for each risk.

Is ISO/IEC 27005 required for ISO 27001 risk assessment, and what does it cost?

ISO/IEC 27001 does not require ISO/IEC 27005 by name. ISO/IEC 27001:2022 sets the requirements for risk assessment in clause 6.1.2 and risk treatment in clause 6.1.3, and ISO/IEC 27005:2022 is guidance that helps an organization meet them. It covers the risk management cycle of assessment, treatment, communication, monitoring and review, aligned with ISO 31000 principles. The standard is published by ISO at CHF 225 for the 62-page fourth edition, published 25 October 2022. Using a different documented method is acceptable if it meets the requirements, so confirm with your certification body what it expects to see.

How do auditors judge the risk assessment at surveillance audits?

At surveillance audits, auditors check whether the risk assessment is being carried out as planned and whether its results still drive the risk treatment plan and the Statement of Applicability. European Accreditation FAQ 44.2 explains that surveillance audits cover continuing operational control, which for an ISMS includes the risk assessments carried out under clause 8.2. Expect the auditor to sample recent risk reviews, check that new assets and suppliers were assessed after changes, and confirm that treatment decisions have owners and dates. Keep dated versions of the register, the criteria and the review minutes so the trail is easy to follow.

How DeployOpen prepares the risk assessment evidence

DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside the client's own infrastructure. For ISO 27001 risk assessment, we prepare the systems, records and evidence that the organization uses to run its assessments and treatment decisions, while the organization keeps ownership of its risks and controls and an accredited certification body makes the certification decision.

How we scope

Agree a written scope covering the systems, sites and asset types that the risk assessment must include before work starts.
Confirm with the organization which risk owners, criteria and review intervals it will approve under clause 6.1.2.
Define the deliverables for risk register, treatment plan and Statement of Applicability linkage in the fixed-scope agreement.

How we build

Configure a self-hosted risk register and asset inventory inside the client's own infrastructure, with access controls set by the organization.
Map each identified risk to its treatment decision, then compare necessary controls with the Annex A controls under clause 6.1.3.
Set up workflows that capture risk assessments at planned intervals and after significant changes, as clause 8.2 expects.

How we hand over

Document the risk assessment method, criteria and records so the organization can explain each decision to an auditor.
Provide a handover walkthrough so staff can run future assessments and update the treatment plan without outside help.
Deliver evidence packs showing dated assessments, approvals and changes, ready for the certification body to sample.

How we support

Offer ongoing support as a retainer for platform upgrades, backups and changes to the risk method or tooling.
Support the organization's annual cycle of reviews, including preparing records for surveillance audits and internal audits.
Confirm with the organization which tasks remain with its own staff and which the retainer covers before signing.

ISO 27001 risk assessment