Information Security Management
ISO 27001 Clause 8: Operation
ISO 27001 Clause 8 is where all your planning (Clause 6) is implemented under controlled conditions.
Read my guide on how it’s constructed and what you need to do to implement it.
Written By: Alan Parker, ISO 27001 Consultant
Last Updated: 28/4/26
Explore Each ISO 27001 Clause in More Detail by Selecting One to View
Table of Contents
Watch my 3-minute Clause 8 explainer below, or read on for the full guide.
Clause 8 – Operation Overview
Clause 8 “Operation” focuses on the practical implementation of your Information Security Management System (ISMS). To this point, the other clauses have all been about designing, assessing, and planning your ISMS. Now, it becomes about ‘doing’.
It requires organisations to plan, operate, and control the processes needed to achieve information security objectives and to manage identified risks.
This includes ensuring that operational activities are carried out as planned, that risk assessments are repeated when significant changes occur, and that appropriate treatments are implemented and documented.
The sub clauses within 8 are;
- Clause 8.1 Operational Planning & Control
- Clause 8.2 Information Security Risk Assessment
- Clause 8.3 Information Security Risk Treatment
In short, Clause 8 translates earlier planning into day-to-day action—making sure security controls are effectively applied, maintained, and continuously improved in line with business operations.
What Changed in Clause 8 in the 2022 Update
The changes to Clause 8 in 2022 are small but worth knowing. Clause 8.1 now requires you to establish criteria for your processes (not just run them), retain documented evidence that processes are being carried out as planned, and explicitly control any outsourced processes. Clauses 8.2 and 8.3 are essentially unchanged from 2013.
The transition deadline of 31 October 2025 has passed – if you’re certified, you should already be on 2022.
ISO 27001 Clause 8 — Operation
Where planning becomes action — implementing, running, and evidencing the controls your ISMS requires
Clause 8 is the operational heart of the ISMS. Everything planned in Clause 6 — the risk assessment methodology, the treatment decisions, the Statement of Applicability — is executed here. Controls are implemented, risk assessments are run in practice, and evidence is generated that the ISMS is genuinely operating.
I’ll explain each sub-clause below.
Clause 8.1 – Operational Planning and Control
This clause is a broad requirement that you implement and control the processes needed to meet information security requirements and to carry out the actions determined in Clause 6.
In simpler terms: for all the plans and controls you decided on, carry them out and manage them. You should also keep appropriate evidence (documented information) that processes have been carried out as planned.
Some key aspects:
- You might have operational procedures to follow (e.g., for user account provisioning or backup and restore). Clause 8.1 implies that you should consistently follow those procedures.
- If you outsource any processes or involve external parties, ensure controls extend to them and are coordinated (for example, if using a third-party data centre, you have arrangements to manage its security).
- Essentially, Clause 8.1 is an umbrella reminder: don’t just have paperwork (policies, risk plans) – actually put them into practice. If any changes occur during operation, make them in a controlled manner (in line with Clause 6.3 on planning changes).
In an audit, Clause 8.1 evidence often comes from demonstrating that processes such as backup, access reviews, incident response, etc., are carried out in accordance with your ISMS procedures.
If your risk treatment plan said “implement encryption control by March”, Clause 8.1 would show that by March, you did implement encryption.
ISO 27001 Full Document Toolkit
Every document your auditor
expects to see.
130 Word & Excel templates, ready to edit. Policies, risk register, Statement of Applicability, audit pack, staff communications — all updated for ISO 27001:2022.
130 templates
Instant download
Written by practising consultant
ISO 27001:2022
Clause 8.2 – Information Security Risk Assessment (Operational)
Now, I have to admit that I got confused when I first saw Clause 8.2 and 8.3 – as I thought, ‘Haven’t we already done this in Clause 6? The key thing to understand is that while we put a risk framework in place earlier on, we need to continue monitoring risk, tracking actions, etc. So it’s an ongoing risk management process that auditors will look for.
Honestly, it should be a slam dunk if you have taken Clause 6 seriously.
So, clause 8.2 specifically requires the organisation to perform information security risk assessments at planned intervals or when significant changes occur, and to maintain documented records of the results. This effectively ensures that risk management is continuous rather than a one-time event.
What this means:
- You should define how often you’ll formally reassess risks. Many choose an annual risk assessment as a planned interval. If the environment is highly dynamic, some might do it more frequently (e.g., semi-annually).
- Also, if a big change happens (like launching a new product, an acquisition, a major incident, or a new law), you shouldn’t wait for the periodic cycle – you do a targeted risk assessment for that change.
- You need to keep records of these ongoing risk assessments. So, if in 2025 you did an initial risk assessment, by 2026, maybe you do another; keep both results and note updates (maybe update the risk register with new risks or changed risk levels).
- Essentially, Clause 8.2 connects back to Clause 6.1. It ensures risk assessment isn’t a static document but a living process.
Auditors will expect to see that you have completed at least one full cycle of risk assessment by the time of the audit (the initial one in Clause 6 might count, but if time has passed, an update may be required).
In surveillance years, they’ll expect an annual risk review record minimally, but I’d suggest risk reviews should be happening far more frequently than that, so would suggest at least every quarter.
Clause 8.3 – Information Security Risk Treatment (Operational)
Clause 8.3 similarly requires the organisation to implement the risk treatment plan in Clause 6.1.3 and retain documented information on the results. In practice:
- It asks you to carry out the treatments (i.e., implement the controls) that you planned and do so continuously.
- If any new risks were identified (from 8.2’s re-assessment or changes), treat those as well (update treatment plans, SoA, etc., accordingly).
- Keep records of the treatments performed. For example, if one treatment was “update firewall rules”, a change log or screenshot can show it was done. If it was “conduct training”, have the attendance record (that’s also Clause 7 evidence).
- By the audit, you should have an up-to-date risk treatment status – your risk register should reflect the current status (e.g., this risk is now mitigated by control X implemented on date Y).
Clauses 8.2 and 8.3 effectively ensure that the risk management loop remains active: you regularly assess risks and update controls accordingly.
It’s worth noting that many of the day-to-day ISMS activities will be driven by the controls you chose. For example, Annex A controls (like antivirus management, logging, access control reviews, incident management, etc.) become part of your Clause 8 “operations”.
The auditor in Clause 8 might reference some of those: e.g., if you said in SoA that you do access reviews (Annex A control), then under Clause 8, they’ll want to see you did an access review recently.
So Clause 8 is closely tied to Annex A verification: you need to check that your risks and operations are going as you expected.
Documentation and Outputs for ISO 27001 Clause 8
Clause 8 — What Evidence Is Required?
Documents and records an auditor will expect to see at certification and surveillance audits
Documented information confirming that ISMS processes have been carried out as planned. This is broad by design — it means the logs, records, and outputs produced by each operating control: access review records, backup completion logs, patch records, vulnerability scan reports, incident logs. Not a single document, but a body of evidence across all controls in your SoA marked as implemented.
A structured evidence pack showing how each applicable Annex A control is implemented — configuration screenshots, policy documents, tool reports, or process records. Many organisations maintain this in their SoA as a linked evidence column. Auditors will select a sample of controls and ask to see operational evidence; having this organised in advance is significantly more effective than searching for it on the day.
Records showing that significant changes — to systems, processes, personnel, or the organisational environment — were assessed for their information security impact before or as they occurred. A simple change log noting what changed, when, what IS review was performed, and what action was taken satisfies this. The absence of any change management records is a common Clause 8.1 finding, particularly at surveillance audits.
Evidence that outsourced processes relevant to the ISMS — cloud infrastructure, managed security services, SaaS platforms handling in-scope data — have been identified and are subject to appropriate controls. This links to the supplier management controls in Annex A (5.19–5.22) and should include supplier security assessments, contractual security obligations, and records of ongoing monitoring.
The documented output of each risk assessment performed — an updated risk register showing the risks identified, their assessed likelihood and impact, risk owners, and current treatment status. The standard explicitly requires this to be retained as documented information. Critically, results must be dated and attributable so auditors can verify when the last assessment was conducted and what has changed since.
Documented evidence that the risk treatment plan is being implemented — an active, up-to-date treatment plan showing which actions are complete, in progress, or outstanding, with named owners and target dates. This is distinct from the treatment plan produced at Clause 6.1.3: Clause 8.3 requires evidence of the results of treatment, not just the plan itself. Auditors will check whether treatment actions are being progressed between audits.
What Auditors Look For in Clause 8
Clause 8 — What Auditors Look For
Five areas where auditors test whether your ISMS is genuinely operating — not just documented
Example
Imagine your SoA says, “We implement control A.12.6.1 – Anti-malware controls.”
In the audit, the auditor asks, “What anti-malware solution do you use and how do you monitor it?” You show them your endpoint antivirus console, which logs viruses found. The auditor sees a report of last month’s detections and how they were resolved.
This demonstrates operational control of malware (Clause 8 executed).
Another example: Your risk treatment included training employees on security. The auditor already saw training records (Clause 7), but might ask an employee, “Do you know how to report a security incident?”
The employee says, “Yes, we have an email address or we can call IT.” That shows the incident reporting process (part of operations) is communicated and presumably functional – someone did report an incident last quarter, and IT has that record.
All these little verifications build confidence that Clause 8 – the day-to-day ISMS – is active and effective.
Case Study
I once did a pre-audit health check for a company about a year after they got certified. Friendly engagement, no real concerns going in. I asked to see the risk register, knowing that’s usually where the truth shows up.
The register was last updated on the day they got certified. Twelve months earlier. And I’d like to say this was uncommon, but it isn’t.
The treatment plan was the same: items marked “in progress” with target dates of “Q4 2025”. The Statement of Applicability hadn’t been touched. No record of the quarterly risk reviews their own methodology said, would happen.
To their credit, they hadn’t been negligent. They’d been busy running their business. The ISMS Lead had moved into a different role. Nobody had picked up the operational rhythm.
When I explained that this would be a major non-conformity in their surveillance audit – a complete failure to meet Clauses 8.2 and 8.3 – they were initially defensive. Their argument was “but nothing has changed, so why would we update anything?”
The honest answer is: the standard requires evidence that the system is being operated. Not changed – operated. Reviewed, considered, signed off. Even a quarterly review that concludes “nothing has changed” needs to be documented.
The takeaway: Clause 8 doesn’t require a separate exercise in addition to Clause 6. It requires the Clause 6 work to actually be alive and maintained. If your risk register hasn’t moved in twelve months, your ISMS hasn’t been operating – and the auditor will spot it within the first ten minutes.
Common Mistakes in Clause 8
Clause 8 is where ISMSs quietly fail between certification audits. I see it constantly, especially in the first year before the owner has had the shock of a surveillance audit.
The mistakes below aren’t dramatic – they’re slow-burn failures that build up over months and surface when an auditor asks the obvious question: “Can you show me how this is actually being operated?“
Treating Clause 8 as a separate exercise from Clauses 6 and 7. Some readers see “Operation” as a new requirement on top of everything else. It isn’t. If your Clause 6 risk assessment is being maintained and your Clause 7 awareness programme is running, Clauses 8.2 and 8.3 are essentially automatic. The mistake is over-engineering Clause 8 as if it needed its own separate process – and the bigger mistake is under-engineering it by assuming the certification was the finish line.
Stopping risk assessment after the initial round. This is the single most common Clause 8 failure I see, and it’s exactly what played out in the case study above. The certification project does the heavy lifting, the certificate arrives, and the risk register goes quiet. Clause 8.2 explicitly requires ongoing assessment, not a one-off exercise. A risk register that hasn’t been touched since certification is a major non-conformity in waiting.
Marking controls “implemented” when they’re only partially deployed. Auditors check evidence, not status. A Statement of Applicability claiming antivirus is implemented across “all endpoints” when in reality it’s deployed to 60% of laptops, and none of the servers will be exposed during evidence sampling. Better to mark a control “in progress” with a target date than to claim implementation you can’t fully demonstrate.
Forgetting outsourced processes. Clause 8.1 explicitly requires that externally-provided processes be controlled – cloud platforms, managed IT services, third-party data processors. I see this missed routinely; the SoA is impeccable for what the company does directly, but silent on the cloud infrastructure they actually run on. If a process matters to your information security and you don’t operate it directly, it’s still in scope for Clause 8.
Updating the SoA but not the Risk Treatment Plan. These two documents should evolve together. When a new risk is identified, it gets a treatment plan entry; when a treatment is completed, the SoA reflects the implemented control. I’ve seen audits where the SoA shows a beautifully maintained set of controls, but the risk treatment plan is two years stale, and references controls that no longer exist. The auditor doesn’t even need to dig – the inconsistency is on the surface.
Confusing Annex A control verification with Clause 8 verification. They overlap, but they’re not the same thing. Annex A asks “is the control in place and working?” Clause 8 asks “is the system that operates the control being managed?” An auditor can find your antivirus is running brilliantly (Annex A satisfied) and still flag a Clause 8 finding because nobody’s reviewed the antivirus configuration in 18 months. Both questions need answering.
Ad-hoc operational changes without using Clause 6.3. This is the most common surveillance audit finding I see, and it’s grown more important since 6.3 (Planning of Changes) was added in the 2022 update. A new product launches, a department restructures, a new client onboards onto a different platform – and nothing in the ISMS reflects it. The risk register doesn’t know about it. The SoA doesn’t know about it. The scope statement doesn’t know about it. The auditor will know about it the moment they interview a member of staff who mentions it casually.
ISO 27001 Clause 8: Operation FAQs
What’s the difference between risk in Clause 6 and Clause 8 in ISO 27001?
Clause 6 is about planning – identifying risks, defining objectives, and deciding actions. Clause 8 is about implementing the planned risk treatments, controls, and operational processes. You could think of Clause 6 as creating the map, and Clause 8 as the journey itself.
Do I need to keep evidence for every control I implement?
Yes, ISO 27001 requires you to retain documentation to demonstrate that planned actions were carried out. This doesn’t mean excessive paperwork, but you should be able to show that each control in your treatment plan or SoA is either implemented or actively in progress— with evidence such as logs, screenshots, change records, or meeting notes.
How often should I update the risk register under Clause 8.2?
The standard does not have a fixed interval. Still, most organisations perform a formal risk assessment annually, with additional updates whenever significant changes occur (e.g., new systems, major incidents, or regulatory updates). The key is that your risk register is up to date and reflects your actual environment.
What happens if a planned control isn’t implemented on time?
It depends on the context. You should document the delay, explain why it occurred, and indicate whether any temporary mitigation measures are in place. Auditors may flag this if the risk is high and the control is critical, unless you can show it’s actively managed. Regularly updating the risk treatment plan helps demonstrate oversight and control.
How do Clause 8 activities tie in with Annex A controls?
Annex A controls represent what you might choose to implement to address risks. Clause 8 is about ensuring you actually implement them in practice. So if your SoA says “Control A.12.6.1 – anti-malware – is implemented,” Clause 8 evidence would show that the system is running, monitored, and maintained as per your ISMS procedures.
Further Reading
Get the ISO 27001:2022 standard
Includes all the mandatory document templates — free, no commitment
Author Background
This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.
With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.
Qualifications: ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.
Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.
