ISO 27001 · Step-by-step series · Article 5 of 7

ISO 27001 Clause 8: Operation — Risk Assessment and Risk Treatment in Practice

Clause 8 of ISO 27001:2022 is where the Information Security Management System (ISMS) stops being a set of policies on paper and becomes something the organization actually runs day to day. It covers how you plan and control the operational processes needed to meet information security requirements, how you carry out — not just design — your information security risk assessment, and how you actually implement the risk treatment plan you committed to in clause 6. This guide breaks down each subclause with practical explanations and concrete examples.

Structure of clause 8: from planning to execution

Clause 8 of ISO 27001:2022 is organized into three subclauses that follow a clear operational logic:

• 8.1 Operational planning and control: how you plan, implement and control the processes needed to meet information security requirements and to implement the actions determined in clause 6.
• 8.2 Information security risk assessment: performing risk assessments at planned intervals, or when significant changes occur, and retaining documented information of the results.
• 8.3 Information security risk treatment: implementing the risk treatment plan and retaining documented information of the results.

Where clause 6 is about designing the risk assessment methodology, the risk treatment plan and the Statement of Applicability, clause 8 is about actually running the assessment on a cadence and actually executing the treatment — with evidence to show for it. This is a subtle but critical distinction that many organizations preparing for their first certification audit miss.

8.1 Operational planning and control: turning the ISMS into daily practice

Clause 8.1 requires the organization to plan, implement and control the processes needed to meet its information security requirements, and to implement the actions determined in clause 6 (addressing risks and opportunities, and the risk treatment plan). It also requires the organization to implement plans to achieve information security objectives set under clause 6.2.

In practice, 8.1 asks you to answer, for every operational process that touches information security, three questions: what are the criteria for the process, how do you control the process against those criteria, and what evidence do you keep that the process was executed as planned? This applies broadly — access provisioning and de-provisioning, change management, backup execution, vulnerability patching cycles, vendor onboarding, secure development practices — anywhere information security controls are exercised in day-to-day operations.

A second requirement of 8.1, made more explicit in the 2022 revision, is the control of planned changes and the review of the consequences of unintended changes, taking action to mitigate any adverse effects as necessary. This means a change management process is not optional infrastructure — it is a direct ISO 27001 requirement whenever changes could affect the security of information.

Clause 8.1 also requires the organization to ensure that externally provided processes, products or services that are relevant to the ISMS are controlled. This links directly to the supplier relationship controls in Annex A and means outsourced IT operations, managed security services and cloud providers all fall inside the scope of operational control, not outside it.

8.2 Information security risk assessment: running the process, not just designing it

Clause 6.1.2 defines the risk assessment process and methodology. Clause 8.2 is the operational counterpart: it requires the organization to actually perform information security risk assessments at planned intervals, and additionally whenever significant changes are proposed or occur, taking account of the criteria established in 6.1.2. Documented information of the results must be retained.

Two triggers therefore drive when a risk assessment must be run:

• Planned intervals: most organizations run a full risk assessment cycle annually, aligned with management review, though some higher-risk environments run it more frequently (quarterly or semi-annually) for critical assets.
• Significant changes: a new system going into production, a major cloud migration, a merger or acquisition bringing new assets into scope, a new regulatory requirement, or a significant incident that reveals gaps in the current risk picture. Any of these should trigger an ad hoc risk assessment rather than waiting for the next scheduled cycle.

The output of each risk assessment cycle under 8.2 should feed directly into the risk register: new risks identified, changes in likelihood or impact for existing risks, risks that have been closed because the associated asset or process no longer exists, and any risks that have moved between risk levels because a control was implemented, degraded, or removed. Retaining the dated results of each cycle — not just the current snapshot — is what gives an auditor confidence that the process actually runs periodically rather than being reconstructed just before the audit.

8.3 Information security risk treatment: executing the plan and closing the loop

Clause 6.1.3 is where the risk treatment plan and the Statement of Applicability (SoA) are produced. Clause 8.3 requires the organization to implement the risk treatment plan and to retain documented information of the results of the risk treatment.

In practice, implementing the risk treatment plan means tracking each planned action to closure with evidence, which typically includes:

How clause 8 connects to clause 6 and clause 9

Clause 8 does not exist in isolation. It is the execution engine between clause 6 (Planning — where risks, objectives and the treatment plan are designed) and clause 9 (Performance Evaluation — where the effectiveness of what was implemented gets measured). A useful way to think about it: clause 6 asks "what should we do about our risks?", clause 8 asks "are we actually doing it, on schedule, with evidence?", and clause 9 asks "is what we did actually working?"

This means the risk register, the risk treatment plan and the SoA are living documents that clause 8 keeps updated through operational activity — not static deliverables produced once before the certification audit and left untouched afterward.

Most common audit findings on clause 8

Across ISO 27001 certification and surveillance audits, these are the recurring nonconformities and observations tied to clause 8:

• 8.1 — No evidence of change control being followed in practice: a documented change management procedure exists, but sampled changes in production systems show no corresponding approval or review record.
• 8.1 — Outsourced processes outside operational control: a managed service provider or cloud platform relevant to the ISMS scope has no defined security requirements in the contract and no monitoring of their performance against those requirements.
• 8.2 — Risk assessment not actually run on the stated interval: the risk assessment methodology says "annually," but the risk register has not been updated in over a year, or the only assessment on file predates the current asset inventory.
• 8.2 — No ad hoc reassessment after a significant change: a major system migration or new third-party integration went live with no corresponding risk assessment triggered by that change.
• 8.3 — Risk treatment plan actions with no owner or no target date: the plan lists what should be done but not who is accountable or by when, so progress cannot be verified.
• 8.3 — SoA claims a control is implemented with no supporting evidence: the Statement of Applicability marks a control as applicable and implemented, but there is nothing in the evidence trail — no configuration record, no log, no policy acknowledgment — to demonstrate it.

Frequently asked questions about ISO 27001 clause 8

What is the difference between clause 6.1.2/6.1.3 and clause 8.2/8.3?

Clause 6.1.2 and 6.1.3 are about design: defining the risk assessment methodology, the risk acceptance criteria, and producing the risk treatment plan and Statement of Applicability. Clause 8.2 and 8.3 are about execution: actually performing the risk assessment at planned intervals or after significant changes, and actually implementing the risk treatment plan with retained evidence. You can have a perfect risk assessment methodology under 6.1.2 and still fail an audit on 8.2 if you cannot show the assessment was actually carried out on schedule.

How often does ISO 27001 require a risk assessment to be performed under clause 8.2?

ISO 27001 does not mandate a fixed frequency. Clause 8.2 requires risk assessments "at planned intervals" as defined by the organization, plus whenever significant changes are proposed or occur. Most organizations set an annual full-cycle assessment aligned with management review, with higher-risk or fast-changing environments running semi-annual or quarterly cycles for critical assets. Whatever interval you choose, it must actually be followed — an interval defined but not honored is a common nonconformity.

Does every Annex A control listed as applicable in the SoA need documented evidence under clause 8.3?

Yes, in effect. If the Statement of Applicability marks a control as applicable and implemented, clause 8.3 requires that the risk treatment plan implementing that control be executed and that documented information of the results be retained. An auditor sampling the SoA will expect to see corresponding evidence — configuration settings, logs, policy acknowledgments, review records — for controls marked as implemented, not just a checkbox.

What counts as a "significant change" that should trigger an ad hoc risk assessment under 8.2?

ISO 27001 does not give an exhaustive list, but common triggers accepted in practice include: a new system or application entering production, a major infrastructure or cloud migration, a merger, acquisition or divestiture that changes the asset inventory, a new or changed regulatory requirement affecting information security, a significant security incident revealing a gap in the current risk picture, or a substantial change in the threat landscape relevant to the organization's sector. The key test is whether the change could plausibly alter the risk profile of an asset or process already in scope.

Who should own residual risk acceptance under clause 8.3?

The risk owner identified during the risk assessment process (clause 6.1.2) is responsible for accepting residual risk once treatment actions are implemented, provided the residual level falls within the organization's stated risk acceptance criteria. This should not default to the ISMS manager or information security team alone — risk ownership sits with the business function that owns the asset or process, since they are best placed to judge whether the residual exposure is tolerable.

How does clause 8.1's requirement on outsourced processes relate to supplier controls in Annex A?

Clause 8.1 requires the organization to ensure that externally provided processes, products or services relevant to the ISMS are controlled. This is the operational hook that connects to the supplier relationship controls in Annex A, which set out expectations for security requirements in supplier agreements, monitoring of supplier service delivery, and managing changes to supplier services. In practice this means any managed IT provider, cloud platform, or subcontracted development team touching in-scope information must have defined security requirements and some form of ongoing monitoring — not just a signed contract filed away.

Expert ISO 27001 · Updated 2026-07-31 · ISO 27001 step-by-step series: Article 1 — Clause 4 · Article 2 — Clause 5 · Article 3 — Clause 6 · Article 4 — Clause 7 · Article 6 — Clause 9 · Article 7 — Clause 10