ISO 27001 Clause 8 Operation: What Auditors Expect

Clause 8 of ISO/IEC 27001:2022 is where your ISMS stops being a plan and starts running. It has three parts: 8.1 operational planning and control, 8.2 information security risk assessment, and 8.3 information security risk treatment. Together they require you to plan, implement and control the processes needed to meet requirements and carry out the actions determined in Clause 6. This guide explains each sub-clause in plain terms, shows what evidence an auditor can ask to see, and gives you a practical order of work.

TL;DR

• Clause 6 decides what you will do about risk. Clause 8 is the proof that you actually do it, repeatedly, and under control.
• 8.1 asks for process criteria, control against those criteria, change control and oversight of outsourced services such as cloud and SaaS providers.
• 8.2 requires risk assessments at planned intervals and when significant changes happen, with documented results. 8.3 requires you to implement the risk treatment plan and keep records of the outcome.
• Auditors look for operating records: procedures, logs, reports, action plans. A policy with no operating trail is the most common gap.
• Nothing here has a fixed timeline. Effort depends on your size, industry and how mature your controls already are.

Table of Contents

• What Clause 8 covers and how it relates to Clause 6
• Clause 8.1: Operational planning and control
• Clause 8.2: Information security risk assessment
• Clause 8.3: Information security risk treatment
• What evidence satisfies an auditor
• How to implement Clause 8 in practice
• Common Clause 8 mistakes
• Our perspective: Clause 8 is where budgets get decided
• Estimate your Clause 8 workload
• FAQ
• Sources

What Clause 8 covers and how it relates to Clause 6

Think of Clause 6 as the design and Clause 8 as the operation. Clause 6 is where you define your risk assessment method, run the first assessment, choose treatment options, produce the Statement of Applicability and set objectives. Clause 8 puts that planning into day-to-day action and operational management.

The practical consequence is that Clause 8 has very little content of its own. It does not invent new requirements. It checks that the outputs of Clause 6 are alive: that the risk method is used again, that the treatment plan gets done, and that the processes behind your controls follow criteria you set. If you want to see how Clause 6 outputs map to evidence before you start, our guide to ISO 27001 Clause 6 outputs and evidence covers it.

A useful way to read the three sub-clauses:

Clause 8.1: Operational planning and control

Clause 8.1 is the catch-all. According to the standard, you must establish criteria for the processes, control them in line with those criteria, and keep documented information to the extent needed to be confident they were carried out as planned. Two more requirements sit alongside it: control planned changes, and control externally provided processes, products or services relevant to the ISMS.

Process criteria and control

“Criteria” simply means what good looks like for a process. For user access reviews, the criteria might be who reviews, how often, what counts as an exception and how fast exceptions are fixed. For vulnerability management, it might be severity levels and remediation targets. Once the criteria exist, you operate the process against them and keep enough records to show it happened.

The phrase “to the extent necessary” matters. The standard does not ask you to document everything. A five-person startup and a regional bank will keep very different volumes of records. The test is whether you, and an auditor, can be confident the process ran as planned.

Change control

The standard says you must control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects as necessary. In practice that means two things:

1. Planned changes go through a recorded route: a request, a security review proportional to the risk, an approval, and a record of what was done. Tickets in your engineering or IT system usually serve.
2. Unintended changes, such as a misconfigured storage bucket or an emergency hotfix, get reviewed afterward. Someone asks what the effect was and what was done about it.

A change that alters your risk picture also feeds Clause 8.2. A new cloud region, a new product handling personal data or an acquisition can all count as significant changes.

Externally provided processes

Outsourcing work does not outsource accountability. One practitioner guide puts it plainly: you must identify and control third-party delivery that affects the ISMS. The same source suggests keeping a register of externally provided processes and services relevant to the ISMS, covering cloud platforms, SaaS tools, managed services, contractors and payroll providers.

For a U.S. SaaS or fintech company, that register is often the quickest win. List each supplier, what it touches (data, infrastructure, access), the risk level, the contract or security review on file, and the next review date. Our guide to ISO 27001 for SaaS and tech companies goes deeper on how this plays out in cloud-heavy environments.

Clause 8.2: Information security risk assessment

Clause 8.2 requires you to perform risk assessments at planned intervals or when significant changes are proposed or occur, and to retain documented information of the results. The method itself comes from Clause 6.1.2. Clause 8.2 is the repeat performance.

What a sound assessment contains

ISO/IEC JTC 1/SC 27, the committee behind the standard, describes the process in its auditing practice material: identify risks to confidentiality, integrity and availability, analyze consequences and realistic likelihood, determine risk levels, compare them with your criteria and prioritize risks for treatment. Notice the word “realistic”. An assessment where every risk is rated high is as useless as one where every risk is rated low, because neither helps you prioritize.

If you want a U.S. reference for the mechanics, NIST SP 800-30 Revision 1 is widely used. It says an assessment should identify threats, internal and external vulnerabilities, potential harm and the likelihood of that harm, with risk generally determined from the degree of harm and its likelihood. It also structures the work into four activities: prepare, conduct, communicate results, and maintain the assessment. ISO 27001 does not require NIST’s method, but a team that already uses it can usually map its work across.

Making assessments repeatable

Auditors care less about which scale you use than whether two people applying your method would reach similar answers. NIST’s October 2012 bulletin says preparation should settle context, methodology, scope, risk factors, rigor, formality and the requirements for consistent, repeatable determinations. In ISO terms, write down your likelihood and impact scales with examples, define your acceptance threshold, and keep them stable between cycles. If you change the method, record why.

How often

The standard says “planned intervals” and leaves the interval to you. Many organizations choose an annual cycle, while dynamic environments may justify more frequent reviews such as quarterly. Pick a cadence you can defend and keep. A quarterly promise you skip twice is worse than an annual cycle you complete.

Triggers matter as much as the calendar. Define in advance what counts as a significant change: a new system holding customer data, a major supplier change, a serious incident, a new regulatory obligation or a change of hosting. Then connect your change process to your risk process, so a triggering change automatically raises a reassessment.

A practical shortcut

One practitioner view is that Clause 8.2 should be a slam dunk if you have taken Clause 6 seriously. That is fair. If your Clause 6 method is documented and your risk register exists, the 8.2 task is mostly re-running that method on current facts and saving the dated output. Do not rebuild the method each time.

Clause 8.3: Information security risk treatment

Clause 8.3 is the shortest and the one auditors test hardest. The organization must implement the information security risk treatment plan and retain documented information of the results.

The key word is implement. Writing the plan was Clause 6.1.3. Clause 8.3 asks whether the treatment actions actually happened: whether the multi-factor authentication rollout finished, whether the backup restore test was run, whether the supplier contract was amended. A plan where every action sits at “planned” a year later will draw a nonconformity.

Good treatment records have a few things in common:

• Each risk links to a treatment decision (reduce, accept, avoid or share) and a named owner.
• Each action has a target date and a current status, updated as work proceeds.
• Completed actions point to evidence: a ticket, a configuration screenshot, a signed document.
• Residual risk is re-evaluated after treatment and approved by the risk owner.

Our ISO 27001 risk treatment guide and the risk treatment plan template show how to lay this out so an auditor can follow a risk from assessment to closed action.

Where Annex A fits

Annex A is not the starting point for treatment. The SC 27 auditing note on Annex A says you determine necessary controls through risk treatment and then compare them with Annex A to verify that none have been omitted. The same note says necessary controls and justified exclusions go in the Statement of Applicability, and that Annex A is not an exhaustive list, so other control sources may be used. For how to implement individual controls, ISO/IEC 27002 is the companion guidance.

In other words, the flow is: assess risk (8.2), choose and implement treatment (8.3), check the result against Annex A, and record it in the Statement of Applicability. If your SoA says a control is implemented, Clause 8 records should show it operating.

What evidence satisfies an auditor

Clause 8 is an evidence clause. Practitioner audit checklists point to material such as operational procedures, control operation records, service management records, periodic risk assessment reports, treatment action plans and implementation records. For 8.1, vendor risk assessment reports and service management logs are typical additions.

Here is a working evidence map:

Technology evidence

For technical controls, the best evidence is generated by the systems themselves rather than assembled before the audit. Logs, scheduled job output and restore test results show that a control ran repeatedly. Backups are a common example: a run log and a retention setting say more than a policy sentence. Teams in U.S. audit programs often use material such as SOC 2 backup requirements when working out which backup records to retain, and much of that thinking carries over to ISO 27001 operating evidence. For monitoring-related records, see logging and monitoring for ISO 27001, and for a broader view of what counts, our guide to types of evidence for ISO 27001 audits.

Two habits make audits calmer. First, name an owner for each evidence stream so it does not depend on one person’s memory. Second, keep records under document control, with dates and versions, as covered in our Clause 7.5 register and evidence pack guide.

How to implement Clause 8 in practice

There is no standard duration for this work, and anyone quoting one without knowing your environment is guessing. NIST’s guidance treats risk assessment as an ongoing management input rather than a compliance snapshot: results inform risk responses, reach decision-makers and are updated as conditions change. That is a good mindset for the whole clause. Use this sequence and adjust to your size.

1. Inventory the processes that carry security weight. Access management, change management, supplier management, incident handling, backup, vulnerability management. For each, write the criteria and name the owner.
2. Build the supplier register. Start with anything that stores, processes or can reach your data. Record the review you did and when the next one is due.
3. Connect change management to risk. Add a field or checklist item to your change ticket asking whether the change is significant for risk. If yes, it triggers a reassessment.
4. Fix your assessment cadence and triggers. Write the interval and the list of triggers into your risk procedure. Put the next date on a calendar with an owner.
5. Run the assessment and save the output. Use your Clause 6 method, update the risk register, and keep a dated report that shows scope, method, results and priorities.
6. Execute the treatment plan. Give every action an owner and a date. Attach evidence as each one closes. Report status at management review. Our management review agenda guide shows where those inputs land.
7. Communicate results. Risk owners and decision-makers should see the output. A communication plan makes that routine rather than ad hoc.
8. Test your own evidence. Before the auditor does, pick three controls from your Statement of Applicability and trace each back to records from the last few months. Gaps you find now are cheap.

If you are sizing the effort, the ISO 27001 implementation timeline article explains what drives duration, and it is worth reading before you commit dates to your leadership.

Common Clause 8 mistakes

• Treating the first risk assessment as the only one. Clause 8.2 expects repetition, at planned intervals and after significant change.
• A supplier list with no review trail. Naming vendors is not control. Evidence of due diligence and periodic review is.
• Policies without operating records. A procedure that says access is reviewed quarterly needs quarterly review records.
• A treatment plan that never moves. Stale statuses signal that Clause 8.3 is not being implemented.
• Changing the risk method between cycles without a record. Results become impossible to compare, and auditors notice.
• Over-documenting. The standard says “to the extent necessary”. Excess paperwork you cannot keep current creates findings of its own.

Our perspective: Clause 8 is where budgets get decided

We built ISMS Calculator because the question we heard most was not “what does the standard say?” but “what will this cost us, and how much work is it?” Clause 8 is where that question gets real. Clauses 4 to 7 can be written in a focused stretch. Clause 8 is recurring work: assessments, treatment actions, supplier reviews, change control and the evidence that goes with them. It is the part that keeps costing effort after certification.

So we encourage teams to estimate Clause 8 honestly. Count how many suppliers you have to review, how many treatment actions your risk assessment will create, and who owns each. The gap between the controls you have and the controls your risk assessment says you need is what drives effort, and it differs a lot between a ten-person startup and a financial firm with many systems and vendors. Our assumptions are editable and our methodology is versioned, so you can challenge any figure rather than take it on trust.

Our view: do not chase a perfect Clause 8 on day one. Make a small set of processes run reliably, keep evidence as a by-product of the work, and grow the scope as the ISMS matures.

— Martin

Estimate your Clause 8 workload

If you are planning an ISO 27001 project and want to know how much effort the operational side will take, start with the free 2-minute readiness check. It needs no signup for the first result. When you want a figure for your company size, industry and security maturity, the ISO 27001 cost calculator gives a real-time estimate you can save, compare across scenarios and export, and the readiness assessment looks at maturity across the four Annex A control themes.

FAQ

Is Clause 8 of ISO 27001 mandatory?

Yes. Clauses 4 to 10 are mandatory for certification, and you cannot exclude any of them. Only Annex A controls can be excluded, and only with justification in the Statement of Applicability.

What is the difference between Clause 6.1.2 and Clause 8.2?

Clause 6.1.2 defines your risk assessment process and criteria. Clause 8.2 requires you to carry that process out again at planned intervals and when significant changes occur, and to keep the results. One is the method, the other is the repeated use of it.

How often must we run a risk assessment under Clause 8.2?

The standard does not set a number. It asks for planned intervals plus reassessment after significant changes. Many organizations choose annual cycles, and faster-moving environments may review more often. Whatever you choose, write it down and follow it.

Do we need documented procedures for every Clause 8 process?

Not necessarily. Clause 8.1 asks for documented information to the extent necessary to be confident processes ran as planned. Size, complexity and the competence of your staff influence how much you need. Records of operation usually matter more than long procedures.

How does Clause 8.3 relate to the Statement of Applicability?

The Statement of Applicability records which controls are necessary and why exclusions are justified. Clause 8.3 requires the treatment plan behind those choices to be implemented, with results documented. An auditor will sample controls marked as implemented and look for operating evidence.

Sources

• ISO/IEC 27001:2022 (ed. 3)
• ISO 27001 Clause 8 Explained: Operating the ISMS in Practice
• ISO 27001 Clause 8.1: Operational Planning and Control
• ISO/IEC JTC 1/SC 27 N 23202, auditing practice material
• NIST Special Publication 800-30 Revision 1
• NIST ITL Bulletin, October 2012
• NIST: Guide for Conducting Risk Assessments
• ISO/IEC JTC 1/SC 27/WG 1 N 3297, Annex A auditing practice note
• ISO/IEC 27001:2022 Audit Checklist

Recommended

• ISO 27001 Clause 7: Five Support Areas Auditors Check
• Logging and Monitoring for ISO 27001: What Auditors Expect
• 5 Steps Auditors Accept for ISO 27001 Corrective Action (ISMS Teams)
• ISO 27001 Internal Audit: The Certification-Ready Playbook