---

---

---

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 been all 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.

Let’s take a look at the sub-clauses 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.

---

Clause 8.2 – Information Security Risk Assessment (Operational)

Now, I got confused when I first saw Clause 8.2 and 83 – 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 be looking 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, not 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 very dynamic, some might do it more frequently (semi-annually).
• Also, if a big change happens (like launching a new product, an acquisition, a major incident, or 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 2024 you did an initial risk assessment, by 2025 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, maybe an update). In surveillance years, they’ll expect an annual risk review record.

---

Clause 8.3 – Information Security Risk Treatment (Operational)

Clause 8.3 similarly requires the organisation to implement the risk treatment plan from Clause 6.1.3 and retain documented information about those 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 the risk management loop stays active: you regularly check 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

Operational Procedures and Records

If you have specific procedures (SOPs) for ISMS operations (e.g., user access provisioning, incident handling, and backups), follow them and keep records. Many of these align with Annex A controls, but from Clause 8’s perspective, say you have a backup procedure.

Clause 8’s output would be actual backup logs or reports showing that backups occur per schedule.

Risk Assessment Updates (8.2)

Document your periodic risk reviews. Update the risk register with any changes (maybe in a different colour or with a new column for re-evaluation). Keep minutes of risk review meetings if applicable. A quick summary report annually, like “Reviewed risk register, added 2 new risks, updated 5 risk scores due to changes,” is useful.

Risk Treatment Updates (8.3)

Update the risk treatment plan and SoA as needed.

If new controls are added or some are removed, create a new version of the SoA.

Keep evidence of implementation: for each control implemented, there might be evidence (screenshots of tool configurations, policy documents, etc.). You should have it available even if you don’t get asked for it in the audit.

Operational Records

Numerous records show you’re operating the ISMS.

Examples:

• Review access control records (maybe quarterly user access reviews).
• Internal meeting minutes for ISMS operational meetings (if you have a monthly security meeting, those minutes show you are actively running the ISMS).
• Maintenance records for systems (patch logs, etc., if relevant to security).
• Monitoring logs and results (e.g., network intrusion monitoring logs).
• Incident logs (showing you are recording and handling incidents, which is an operational activity).

Not all of these are mandatory, but they naturally result from implementing controls. The key is that you have evidence that “the wheels are turning”.

• Third-party agreements: If part of your operations involves outsourced work, ensure you have contracts or SLAs that cover security (this can serve as evidence that you addressed those operational needs).
• Change logs: If you made changes (Clause 6.3 ties in), any change request forms or approval records show you handled them properly.

---

What Auditors Look For in Clause 8

Auditors will want to see that you did what you said you would do. This often overlaps with Annex A control verification, but it focuses on Clause 8 itself.

Essentially, Clause 8 audit is not a single checklist item; it’s the culmination of all previous clauses being put into action. If Clause 8 is weak, it means you have a “paper ISMS” but not a working one. Auditors will usually spend a lot of time on actual practices (which fall under Clause 8).

Execution of Risk Treatment

The auditor will select some risks from your risk treatment plan and request evidence that the treatments have been implemented. For example, if the risk was “data centre loss of power” and the treatment was “install UPS and test it quarterly,” they might ask whether the UPS is in place and check the test record.

Current Risk Status

They will ensure that your risk register and SoA are up to date at the time of the audit. If you did a risk assessment 10 months ago and, since then, added a new system but didn’t update your register, they’ll catch that during interviews (e.g., you mention a new system, they cross-check that it’s not in the risk docs). That could be a nonconformity for failing to update the risk assessment (Clause 8.2).

Operational Logs

Some examples of things auditors like to see and ask might be;

These tie to controls (Annex A), but by checking them, the auditor validates that Clause 8 (the doing) is effective.

Internal audits and management reviews in practice

Though those are Clause 9, they are part of ISMS operations too. They will be checked in Clause 9 specifically, but the auditor might reference in Clause 8 context that you have an “operational schedule for audits and reviews, and you followed it.”

Ongoing compliance

If you have any regulatory requirements, they may see if you are operationally checking those (e.g., if GDPR applies, are you doing what’s needed operationally, like handling data subject requests, etc. – partially Annex A control A.5.30, etc., but integrated in ops).

Effectiveness of controls

Clause 8 implicitly is about effective operation. Auditors might find evidence in performance metrics (Clause 9) to determine whether operations are achieving desired results.

E.g. If you had a control to reduce malware incidents but still have frequent incidents, they might question if the control is fully implemented or needs adjustment.

---

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.

---

ISO 27001 Clause 8: Operation FAQs

Further Reading

Get the ISO 27001:2022 standard

---