Why Clause 8 Is Where the ISMS Gets Real
Most information security management systems look reasonable on paper. The risk register exists, the policy is signed, the objectives are documented. Then you get to Clause 8 and find out whether any of it is actually happening.
On this page
Clause 8 of ISO 27001 covers operational planning and control. It is the part of the standard where the organisation must demonstrate that it has implemented its risk treatment decisions, repeated its risk assessment and treatment activities at planned intervals, and maintained control over the processes that protect information. For auditors, this is where the evidence either holds up or falls apart.
The challenge with auditing ISMS operations is that Clause 8 does not prescribe specific controls. It tells you to implement what you planned. That means your audit trail runs from Clause 6 planning through to Clause 8 implementation, and then into Annex A where the actual technical and organisational controls live. Understanding how those layers connect is what separates a competent ISMS auditor from someone who just ticks boxes.
This article walks you through what to sample under Clause 8, how to structure your evidence gathering, and where the common gaps tend to appear.
What Clause 8 Actually Requires
ISO 27001:2022 Clause 8 has three subclauses. Each one creates a distinct audit obligation.
Clause 8.1: Operational Planning and Control
This subclause requires the organisation to plan, implement, control, monitor, and review the processes needed to meet information security requirements. It also requires the organisation to implement the plans determined in Clause 6.
In practical terms, this means you are checking whether the risk treatment plan has been executed. If the risk treatment plan said the organisation would implement multi factor authentication for remote access, you need to see evidence that it has been done, that someone owns it, and that it is being maintained.
Clause 8.1 also requires the organisation to keep documented information to the extent necessary to have confidence that the processes have been carried out as planned. This is your licence to ask for records. If a process exists but there is no evidence it is being followed, that is a gap.
Clause 8.2: Information Security Risk Assessment
This subclause requires the organisation to perform information security risk assessments at planned intervals or when significant changes are proposed or occur. The assessments must be performed according to the criteria established in Clause 6.1.2.
The key audit question here is not just whether a risk assessment exists. It is whether the risk assessment is being repeated. A single risk assessment completed during implementation and never revisited is a common nonconformity. The standard expects a living process, not a one time document.
Clause 8.3: Information Security Risk Treatment
This subclause requires the organisation to implement the information security risk treatment plan. It is a short requirement with significant audit implications. You are checking whether the controls selected during planning have actually been put in place, and whether the residual risk has been accepted by the appropriate person.
Exemplar Global Certified Training ProviderRTP No. 310970
How to Structure Your Clause 8 Sampling
Because Clause 8 is an implementation clause, your sampling strategy needs to follow the thread from planning to execution. There are three main sampling approaches that work well in ISMS audits.
Sample from the Risk Treatment Plan
Start with the risk treatment plan. Select a sample of risks, ideally covering different asset categories and different control types. For each selected risk, trace through to the evidence that the control has been implemented.
For example, if the risk treatment plan records that the organisation will encrypt laptops to address the risk of data loss from theft, your sample should confirm that full disk encryption is enabled on a representative selection of devices, that there is a process for verifying this, and that someone is accountable for maintaining it.
A reasonable sample size for a small to medium organisation is five to ten risk treatment items. For larger organisations with more complex environments, you would expand accordingly. The goal is coverage across different risk categories, not exhaustive testing of every control.
Sample from the Statement of Applicability
The Statement of Applicability lists every Annex A control, whether it is included or excluded, and the justification for each decision. For controls that are included, the SOA should also indicate whether they have been implemented.
Select a sample of implemented controls from the SOA and verify that implementation evidence exists. This is particularly important for controls that are marked as implemented but where the evidence is thin. Common examples include controls around supplier relationships, physical security monitoring, and user access reviews.
The SOA is also useful for checking exclusions. If a control has been excluded, the justification should be sound. An exclusion of a control like removable media management at an organisation that regularly uses USB drives is a red flag worth pursuing. You can read more about this approach in our article on sampling Annex A controls.
Sample from Incidents and Changes
Clause 8.1 requires the organisation to control changes and to review the consequences of unintended changes. If the organisation has had security incidents or significant system changes during the audit period, these are excellent sampling opportunities.
For each selected incident or change, ask: Was the risk assessment reviewed? Was the risk treatment plan updated if needed? Were new controls implemented or existing controls adjusted? This tests whether the ISMS is genuinely dynamic or whether it only gets updated when the auditor arrives.
What Evidence to Look for Under Each Subclause
Evidence for Clause 8.1
The evidence you are looking for under Clause 8.1 falls into a few categories.
Process documentation. Procedures, work instructions, and configuration standards that describe how security controls are operated. These do not need to be elaborate, but they need to exist and be followed.
Implementation records. Logs, screenshots, configuration exports, access control lists, and similar records that demonstrate controls are active. For technical controls, this often means asking IT staff to show you a live system rather than relying on a document that says the control exists.
Ownership evidence. Each control should have a clear owner. Ask who is responsible for maintaining the control and how they know it is working. Vague answers about shared responsibility are a warning sign.
Review records. Evidence that controls are being monitored and reviewed. This might be access review logs, vulnerability scan reports, patch management records, or physical security inspection logs.
Evidence for Clause 8.2
For the risk assessment requirement, you need to see that the assessment has been repeated. Look for:
- Version history or date stamps on the risk register showing it has been updated
- Records of risk assessment meetings or workshops
- Evidence that the assessment was triggered by a specific event, such as a system change, an incident, or an annual review cycle
- Consistency between the current risk register and the current risk treatment plan
A common gap is a risk register that was last updated two or three years ago with no evidence of interim review. Even if nothing significant changed, the standard expects the organisation to confirm that through a deliberate review process, not through assumption.
Another gap is a risk assessment that does not follow the methodology established in Clause 6.1.2. If the criteria for likelihood and consequence were defined one way in planning but the actual assessments use different scales or approaches, that is a conformity issue.
Evidence for Clause 8.3
For risk treatment implementation, the key evidence is the link between the risk treatment plan and the actual controls in place. You are looking for:
- A risk treatment plan that identifies specific controls, owners, and implementation dates
- Evidence that controls have been implemented by the recorded dates
- Signed or approved acceptance of residual risk by an appropriate authority
- Any open items in the risk treatment plan and a credible explanation for why they are outstanding
Open items in the risk treatment plan are not automatically nonconformities. Organisations often have treatment plans with phased implementation. What matters is whether the open items are being actively managed, whether the residual risk has been accepted in the interim, and whether the timeline is realistic.
Common Nonconformities Found Under Clause 8
After conducting ISMS audits across a range of industries and organisation sizes, certain patterns come up repeatedly under Clause 8.
The Risk Assessment Has Not Been Repeated
This is the most common Clause 8.2 finding. The organisation completed a thorough risk assessment during implementation and then treated it as a finished document. When asked about the most recent review, staff point to the original assessment. There is no record of subsequent reviews, no defined frequency, and often no awareness that the standard requires repetition.
The fix is straightforward in principle but requires genuine commitment: define a review frequency, schedule it, conduct it, and record it. The record does not need to be elaborate. A meeting note confirming that the risk register was reviewed, that no new risks were identified, and that existing treatments remain appropriate is sufficient evidence for a period of stability.
Controls Are Marked as Implemented but Evidence Is Absent
The SOA says a control is implemented. The risk treatment plan confirms it. But when you ask for evidence, the response is uncertain. The control might exist in some form, but nobody can produce a record of it being configured, tested, or maintained.
This is a Clause 8.1 gap. The standard requires documented information to the extent necessary to have confidence that processes have been carried out as planned. If you cannot produce evidence, the auditor cannot have that confidence.
Risk Treatment Plan Items Are Perpetually Open
Some organisations have risk treatment plan items that have been outstanding for twelve months or more with no resolution and no documented acceptance of the interim risk. This suggests the risk treatment plan is not being actively managed.
When you find this pattern, ask about the governance process for the risk treatment plan. Who reviews it? How often? What happens when a treatment item is overdue? If the answers are vague, the gap is systemic rather than isolated.
Changes Are Not Triggering Risk Reviews
Clause 8.1 requires the organisation to control planned changes and review the consequences of unintended changes. In practice, many organisations have formal change management processes for IT systems but do not connect those processes to the ISMS risk assessment.
A new cloud platform, a change in remote working arrangements, or a new third party data processor should each prompt a review of relevant risks. If the organisation cannot demonstrate that connection, you have a gap in how Clause 8.1 and Clause 8.2 are being applied together.
Exemplar Global Certified Training ProviderRTP No. 310970Practical Audit Techniques for Clause 8
Follow the Thread, Not the Document
The most effective approach in an ISMS operations audit is to follow a specific risk from identification through to implemented control. Pick a risk, find it in the risk register, check the treatment decision in the risk treatment plan, then verify the control is actually in place. This process based approach reveals gaps that clause by clause document review misses entirely.
This is consistent with the guidance in auditing the ISMS risk assessment, where the same thread following technique helps verify that the risk assessment is repeatable and owned.
Ask to See It Live
For technical controls, asking to see a document that describes the control is not enough. Ask the IT team to demonstrate it. Show me the access control configuration. Show me the patch management dashboard. Show me the encryption status on these laptops. Live demonstration is far more reliable than policy documents and configuration guides that may not reflect the current state.
This approach also tends to reveal whether staff actually understand and operate the controls, or whether the documentation exists as a compliance artefact disconnected from daily practice.
Interview at Multiple Levels
Clause 8 touches both technical staff and management. Your interviews should reflect that. Ask the IT administrator how they know the controls are working. Ask the information security manager how they know the risk assessment is current. Ask a business process owner whether they were involved in the risk assessment for their area.
Inconsistencies between what management believes is happening and what operational staff are actually doing are one of the most valuable findings in an ISMS audit. They point to systemic gaps in communication and oversight rather than isolated failures.
Check the Dates
Date stamps on documents are simple but powerful evidence. When was the risk register last modified? When was the risk treatment plan last reviewed? When were access reviews last completed? Dates that cluster around the previous certification or surveillance audit and then go quiet for twelve months tell a clear story about how the ISMS is actually managed.
Connecting Clause 8 to the Broader ISMS Audit
Clause 8 does not exist in isolation. The evidence you gather here should connect to what you found in Clause 6 planning and what you will test in Clause 9 performance evaluation. If the risk assessment has not been repeated, that will likely show up as a gap in the internal audit programme under Clause 9.2 as well. If controls are not being monitored, that connects to the monitoring and measurement requirements of Clause 9.1.
A well structured ISMS audit traces these connections explicitly. When you write your findings, reference the clause where the gap sits but also note the upstream or downstream implications. A Clause 8.2 finding about risk assessment frequency has implications for how the organisation can credibly claim its controls remain appropriate.
For auditors working toward or maintaining their ISO 27001 credentials, understanding how to connect these threads across the standard is a core competency. It is also what distinguishes an audit that drives genuine improvement from one that generates a list of paperwork deficiencies. If you are building or refreshing your ISMS auditing skills, the ISO 27001 Lead Auditor and Internal Auditor courses at Audit Workshop are built around exactly this kind of practical, evidence based approach, covering how to plan and execute an ISMS audit from Clause 4 through to Clause 10 with real scenarios drawn from actual certification audits.
