Most of the time spent building an ISMS goes into documentation. You write the policy, fill in the risk assessment table, finish the Statement of Applicability. By then it feels like the audit is almost within reach.
But nonconformities rarely come from the documents themselves. They come from thin evidence that the rules you wrote were actually being followed. A backup policy exists but no restore test was ever recorded. A supplier check sheet template exists but none were collected this year. A server configuration changed but no approval record survives anywhere. These gaps surface in clause 8 territory.
This article covers what clause 8 (Operation) of ISO/IEC 27001 asks for, expressed as the artefacts you produce and the way auditors examine them — so you can judge how to execute what clause 6 decided, and how much evidence is enough.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
What Clause 8 Asks For
Clause 8 has three subclauses. None of them ask you to decide anything new; they ask you to carry out what you already decided, and to show that you did.
| Subclause | Intent | Decided upstream in |
|---|---|---|
| 8.1 Operational planning and control | Plan, implement, and control the processes the ISMS needs; retain enough documented information to have confidence the processes ran as planned; control planned changes and review unintended ones; control externally provided processes, products, and services | Clauses 6 and 7 |
| 8.2 Information security risk assessment | Perform risk assessments at defined intervals, and when significant changes are proposed or occur; retain the results | 6.1.2 set the criteria and method |
| 8.3 Information security risk treatment | Implement the risk treatment plan and retain the results | 6.1.3 set the treatment approach and the SoA |
The structure is simple: clause 6 decides, clause 8 does, clause 9 checks, clause 10 fixes. Clause 8 sits in the middle, connecting upstream decisions to downstream verification.
Each clause is covered in Clause 4: Context, Clause 5: Leadership, Clause 6: Planning, and Clause 7: Support. For the whole picture, see What Is an ISMS.
"Confidence that it ran as planned"
8.1 asks you to retain documented information to the extent necessary to have confidence that processes were carried out as planned. That phrasing is the practical judgement call. You do not need to log every action, but a verbal "we did it" is not enough.
A workable test: can a third party reconstruct who did what, when, and with what result, from the record alone? If not, the record is insufficient.
Change management made explicit
The 2022 edition states control of planned changes and review of unintended changes explicitly in 8.1, and adds 6.3 (planning of changes) to the main text, so changes to the ISMS itself are planned too.
In practice this means:
- Assess the security impact before changing system configuration or service content
- Keep the record of the change — request, approval, implementation, verification
- Review changes that happened unintentionally (configuration drift, temporary fixes made during incidents, supplier-driven spec changes) and either revert or formalise them
Differences from the 2013 edition are in Transitioning to ISO/IEC 27001:2022.
What You Actually Produce
Clause 8 does not require a new stack of procedures. What it requires is records. But unless you decide in advance where they accumulate and in what form, you will end up recreating them by hand just before the audit.
| Requirement | Example records | How to choose where they live |
|---|---|---|
| Operating processes (8.1) | Access grant/change/revoke requests, backup and restore-test results, vulnerability remediation, log review records, physical entry logs | First check whether output from tools already in use (ticketing, IdP, monitoring SaaS) can serve as evidence as-is |
| Change control (8.1) | Change requests or tickets, security impact assessment, approver, release record, rollback decision | Rather than a parallel process, add an impact field to your PR template |
| Externally provided processes (8.1) | Supplier register, selection assessments, annual check sheets, contractual security clauses, visibility of sub-processors | Treat the supplier register as the source of truth and attach assessments to it |
| Risk assessment (8.2) | Dated versions of the risk assessment with participants and scope; records of assessments triggered by significant change | Keep versions rather than overwriting the table |
| Risk treatment (8.3) | Treatment plan progress, completion evidence, reasons and next-period plans for open items | Keep granularity aligned with the objectives register |
Records should accumulate, not be authored. A monthly hand-filled spreadsheet always breaks in the month the owner gets busy. Designing so that existing tool output counts as evidence is what keeps operation alive.
See ISMS Document Structure and Supplier Security Management.
When to run a risk assessment
8.2 asks for both defined intervals and when significant changes are proposed or occur. Many organisations build only the annual cycle into operation and miss the second trigger.
Listing examples of "significant change" in advance lets the front line make the call:
- Adopting a new cloud service, or changing the region an existing one runs in
- A change in the categories of information handled
- Sites, departments, or subsidiaries entering or leaving scope
- A serious incident
- Changing a supplier, or a serious incident at one
- Revision of applicable laws or guidelines
See Risk Assessment Method and Risk Treatment and Acceptance.
Where It Goes Wrong
1. Record dates cluster just before the audit
The worst impression in an audit is records all created in the week before it. If three quarters of log reviews were written up in the same week, the auditor concludes they were not performed.
The fix is blunt: lower the frequency to what you can sustain. If not monthly, quarterly. If not quarterly, half-yearly. The standard does not prescribe a frequency. Declaring one you cannot keep is far riskier.
2. Change control is buried in the engineering workflow
In engineering organisations, change control usually already runs through pull requests and CI/CD. The problem is that it is not presentable as an ISMS record.
If, asked to show one recent infrastructure change, you can open the PR and point to review approval and the merge record, that is sufficient. If the PR contains no security consideration and the approver is the author, that becomes the finding.
3. Supplier management stops at the contract
Controlling externally provided processes is not finished by adding security clauses. Selection assessment, periodic review, and reassessment on change are all part of it.
Cloud providers are the common blind spot. "AWS is large, so no assessment is needed" leaves you with no record of how responsibility is divided. See Shared Responsibility in AI EMR Security Design.
4. Emergency workarounds never get formalised
Temporarily widening permissions during an outage, or copying production data to verify a fix, genuinely happens. The problem is when it is never reviewed as an unintended change and simply stays.
Defining the emergency-change path in advance — retrospective approval route, time limit, confirmation of restoration — keeps the deviation itself from becoming a nonconformity.
5. "Done" is undefined
A treatment plan line reading "strengthen access control" has no completion test, so no completion evidence can be shown. Write treatment plans at a granularity where completion is decidable.
What Auditors Look At
Clause 8 gets its real examination in the stage 2 (on-site) audit rather than the document review. Auditors sample records and trace whether operation matched what was decided.
| Focus | Typical question | Preparation |
|---|---|---|
| Plan vs execution | "The annual plan says quarterly — show me records for the whole period" | Set an achievable frequency; record reasons and corrections for any missed cycle |
| Reconstructability | "Who approved this work? Can you show it in a record?" | Use formats that capture performer, approver, and date |
| Change control in practice | "Take one or two production changes from the last three months and walk me from request to implementation" | Walk one representative change end to end beforehand |
| Risk assessment triggers | "You launched a new service in this period — was a risk assessment performed?" | Document the definition of significant change and attach the resulting records |
| Supplier control | "Show me the assessment records for these two suppliers from your register" | Keep register and assessments linked |
| Treatment progress | "For the open items in the plan, by when and how?" | Do not hide open items; present reason plus next-period plan |
Having open items is not itself a nonconformity. Not knowing about them, and not being able to explain them, is. This runs straight into clause 10 — see Clause 10: Improvement.
See also Common Nonconformities and What Stage 2 Audits Examine.
Healthcare Examples
In healthcare, clause 8 operation frequently overlaps with the three-ministry guidelines, and whether you can integrate the two drives the workload.
If you provide SaaS to hospitals
Every release affects hospital-side operations, so change records are not purely internal. Keeping pre-release security impact assessment, advance notice to the hospital, and rollback verification as one record set serves both as ISMS evidence and as customer-facing explanation. For the hospital's perspective, see Japan's Three-Ministry Guidelines.
If you perform remote maintenance on EMR systems
The maintenance connection is both an externally provided process and a process you provide to the hospital. Recording connection request, approval, work logs, and confirmed disconnection satisfies clause 8 and the guidelines at once.
If you store medical information externally
Cloud and data centre providers are in scope for supplier management. Documenting the responsibility split and retaining the provider's third-party certifications or audit reports (ISO 27001, ISO 27017, SOC 2) as assessment records keeps the annual review to a realistic effort.
Triggers for risk assessment arrive often
Healthcare regulation and guidance are revised relatively frequently. Including revisions in your definition of "significant change" makes the 8.2 trigger fire naturally. See Integrating ISMS Documents with the Three-Ministry Guidelines.
Incidents test your clause 8 records
When something actually happens, what you reach for is the procedures and records built under clause 8. If the procedure disagrees with the real escalation path, you find out then. See Building an Incident Response Procedure.
Conclusion
- Clause 8 does not decide anything new — it executes decisions and retains evidence. Upstream is clause 6, downstream clause 9
- The evidence test is whether a third party can reconstruct what was done. Not everything needs logging, but verbal assurance is not evidence
- The 2022 edition makes change management explicit: control planned changes, and review unintended ones after the fact
- Risk assessment is required both at intervals and on significant change. Define "significant" in advance
- Supplier control does not end at the contract: selection, periodic review, and reassessment on change
- Thin records are what surfaces first. Lowering the frequency to one you can actually sustain beats declaring one you cannot
Pottech supports ISMS certification and ongoing operation with a focus on healthcare: designing record-keeping that accumulates by itself, connecting change control to your engineering workflow, and setting up supplier assessment formats that fit how you actually work. We also support year two onwards.
See ISMS Certification Support for scope and pricing, or contact us if you want a view on whether your current records would hold up in an audit.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: interpretation of requirements and the handling of certification are governed by the standard itself and by the publications of accreditation and certification bodies. Audit practice varies between bodies and auditors.