Clause 8 is the Do phase of the PDCA cycle — the point where the ISMS moves from planning into execution. Everything that Clauses 4 through 7 produced — the scope, the risk assessment, the risk treatment plan, the controls in the SoA, the awareness programs, the documented procedures — has to actually run as a functioning operational system. Clause 8 is how ISO 27001 requires that to happen.
The clause is intentionally compact — just three sub-clauses covering operational planning and control, operational risk assessment, and operational risk treatment. Its brevity is deceptive. Clause 8 is where more ISMS implementations quietly fail than anywhere else. The gap assessment is completed, the risk register is populated, the SoA is produced, the policies are written — and then the organization certifies and the operational rigor slowly degrades. Controls that were implemented for the audit are not maintained. Risk assessments are not repeated when the business changes. Suppliers are onboarded without security review because the procurement team was not briefed. Clause 8 failures are usually invisible until the next audit.
This article explains what Clause 8 actually requires in daily ISMS operations, how to keep the risk assessment current without treating it as an annual bureaucratic event, and how to manage the outsourced processes that represent some of the most significant information security risks for modern Indonesian organizations.
Clause 8 at a Glance
Clause 8 has three focused sub-clauses, each bridging a specific planning output to its operational execution:
8.1 Operational Planning & Control Execute plans, control processes, manage outsourcing | 8.2 Risk Assessment (operational) Re-run assessment at defined intervals or on change | 8.3 Risk Treatment (operational) Implement and maintain treatment plan |
The Relationship Between Planning and Operation
Clause 8's requirements make more sense when they are understood as the operational counterpart to the planning requirements in Clauses 5 and 6. Every planning clause has an operational execution requirement in Clause 8. The table below maps the key planning-to-operation relationships:
| Planning clause | What it produces | Operational clause | What it executes |
| Clause 6.1.2 — Risk Assessment (planning) | Define the methodology, identify risks, analyze and evaluate them, determine acceptance thresholds | Clause 8.2 — Risk Assessment (operational) | Execute the assessment using the defined methodology; repeat at defined intervals and on significant change; retain results as documented information |
| Clause 6.1.3 — Risk Treatment (planning) | Select treatment options, choose Annex A controls, produce the risk treatment plan and SoA | Clause 8.3 — Risk Treatment (operational) | Implement the risk treatment plan; maintain the implemented controls; update the plan when risks or controls change |
| Clause 6.2 — IS Objectives (planning) | Set measurable objectives with action plans | Clause 8.1 — Operational Control (objectives) | Execute the action plans for objectives; monitor progress; adjust when implementation encounters obstacles |
| Clause 5.1 — Leadership (governance) | Establish management commitment and resource provision | Clause 8.1 — Operational Control (outsourcing) | Control outsourced processes that affect ISMS; ensure supplier security obligations are contractually established and monitored |
This mapping reveals something important about how ISO 27001 is structured: the standard treats planning and operation as two phases of a single continuous cycle, not as separate compliance activities. A risk assessment that is only conducted once during implementation and never revisited violates Clause 8.2 regardless of how comprehensive it was at the time. A risk treatment plan that is produced in Clause 6 but never tracked for implementation progress violates Clause 8.3.
Clause 8.1 — Operational Planning and Control
Clause 8.1 requires the organization to plan, implement, control, and maintain the processes needed to meet information security requirements — and to implement the actions determined in Clause 6. It also specifically addresses the control of externally provided processes, products, or services that are relevant to the ISMS.
The most important word in Clause 8.1 is 'maintain'. A control that was implemented for the certification audit but has since been misconfigured, disabled, or circumvented is not maintained. An incident response procedure that was documented but has never been tested is not maintained. The operational standard that Clause 8.1 sets is one of sustained execution — not one-time implementation.
The Four Operational Process Areas
Clause 8.1's requirement to implement and maintain processes covers four distinct operational areas that together constitute the ISMS's day-to-day functioning. The checklist below provides an operational compliance reference for each area, including the evidence auditors look for:
| Change Management |
Change control procedure documented and communicated to IT and engineering teams Evidence: Change management policy; change request templates; change log entries |
Security impact assessment included as a mandatory step in the change approval process Evidence: Change request form with security assessment field; approval records showing security sign-off |
Emergency change process defined with post-implementation security review requirement Evidence: Emergency change procedure; post-implementation review records for emergency changes |
Changes to ISMS documentation processed through Clause 6.3 change planning mechanism Evidence: ISMS change log; document version histories showing controlled updates |
| Outsourcing & Supplier Security |
All outsourced processes affecting ISMS scope identified and documented Evidence: Supplier register; outsourcing risk assessment; ISMS scope statement referencing key suppliers |
Security requirements established contractually with all in-scope suppliers Evidence: Supplier contracts with security addenda; DPAs for personal data processors; security SLAs |
Supplier security performance monitored at defined intervals Evidence: Supplier review records; audit rights exercised; SLA compliance reports; SOC 2 reports or ISO 27001 certificates from key suppliers |
New supplier onboarding includes security due diligence appropriate to risk level Evidence: Supplier security assessment questionnaire; due diligence records; risk-based tiering of supplier security requirements |
| Annex A Control Operation |
All applicable controls from SoA are implemented and operational (not just documented) Evidence: Control evidence for each applicable Annex A control — system configurations, logs, access reviews, training records, audit results |
Control effectiveness is being monitored — not just whether controls exist but whether they work Evidence: Access review records; vulnerability scan results; phishing simulation outcomes; SIEM alert and response logs |
Control gaps identified during implementation are tracked in the risk treatment plan Evidence: Risk treatment plan with implementation status; corrective action records for controls behind schedule |
Partial implementations documented with interim compensating controls and remediation timeline Evidence: Risk treatment plan entries with interim status; management approval of compensating controls; target completion dates |
| Incident Management Operations |
Incident management procedure operational — not just documented but tested and known to relevant staff Evidence: Incident management procedure; tabletop exercise records; staff awareness training records covering incident reporting |
Incident log maintained with all security events recorded regardless of severity Evidence: Incident register; escalation records; severity classification evidence; stakeholder notification records |
Post-incident review conducted for significant incidents with findings fed back to risk register Evidence: Post-incident review reports; risk register updates triggered by incidents; corrective action records |
UU PDP and OJK/BI notification obligations covered in incident response procedure Evidence: Incident response procedure showing notification triggers and timelines; KOMINFO notification procedure; regulatory notification log |
| THE MAINTENANCE STANDARD | Auditors testing Clause 8.1 do not just ask 'is this control implemented?' — they ask 'is this control functioning?' The difference matters. An access review process that was implemented in Q1 but has not produced a review report since Q1 is not functioning. A SIEM that generates logs but has no alert rules tuned to detect the threats in the risk register is installed but not functioning. Operational evidence must show ongoing execution, not one-time setup. |
Controlling Outsourced Processes
The second major requirement in Clause 8.1 is the explicit requirement to ensure that externally provided processes, products, and services that are relevant to the ISMS are controlled. This is where the operational consequences of the supplier relationships identified in Clause 4.2 (interested parties) and Clause 4.3 (scope) manifest in practice.
ISO 27001 does not allow an organization to define a narrow ISMS scope and then ignore the security of the suppliers and cloud providers that handle its data and run its systems. If a cloud provider suffers a breach that exposes your customer data, your ISMS failed regardless of whether the provider is 'outside scope'. The standard requires that outsourced processes are controlled — meaning that security requirements are established contractually, supplier security performance is monitored, and the organization responds when suppliers fail to meet those requirements.
The table below maps the minimum control requirements and monitoring obligations for the key supplier categories relevant to Indonesian regulated organizations:
| Supplier type | Risk | Minimum contract security requirements | Ongoing monitoring |
| Cloud Infrastructure Provider (AWS, GCP, Azure, local IDC) | Critical | Security addendum specifying: encryption in transit and at rest, access logging, incident notification SLA (<24hr for critical), right-to-audit, penetration testing disclosure, data residency compliance (Indonesian data) | Annual SOC 2 Type II or ISO 27001 certificate review; quarterly SLA compliance report; incident notification log; annual configuration review |
| SaaS Application Providers (CRM, HR, Collaboration tools) | High | Data processing agreement (DPA) per UU PDP; security questionnaire response; incident notification obligation; data deletion on contract termination; subprocessor disclosure | Annual DPA review; annual security questionnaire; SOC 2 or ISO 27001 certificate; vulnerability disclosure notifications |
| Payment Gateway / Financial Infrastructure Providers | Critical | PCI-DSS compliance certification; BI/OJK regulatory compliance evidence; transaction security controls; fraud monitoring SLA; incident notification within 4 hours; right-to-audit | PCI-DSS certificate annual review; BI/OJK compliance evidence; transaction anomaly reports; quarterly security review meetings |
| Software Development Outsourcing / Contractors | High | Secure coding standards compliance; background check requirement; NDA; IP ownership clause; code delivery via secure channel; no production data access; code review participation | Code security review integration; SAST scan results; annual security training verification; access revocation on project completion |
| Professional Services (Consultants, Auditors) | Medium | NDA; data handling restrictions; need-to-know access only; device security requirements; incident notification obligation | Access revocation on engagement completion; data handling confirmation; output ownership verification |
| Bitlion supplier management module: Bitlion's platform maintains a supplier register linked to the ISMS risk register — each supplier's security risk rating, contractual security requirements, and monitoring evidence are tracked against Annex A controls 5.19 through 5.22 (supplier relationships) and 5.23 (cloud services). Upcoming supplier review dates trigger automated reminders, and monitoring evidence can be uploaded directly against the supplier record. |
Clause 8.2 — Information Security Risk Assessment
Clause 8.2 is the operational execution of the risk assessment planning that Clause 6.1.2 established. It requires the organization to perform information security risk assessments at planned intervals or when significant changes are proposed or occur — retaining documented information of the results.
This is where many organizations stumble. The risk assessment completed during initial ISMS implementation is thorough and well-documented. The subsequent assessments — required annually at minimum, and more frequently when triggered by changes — often receive less attention. The risk register from the initial assessment is reviewed briefly, a few items are updated, and the review is recorded. This produces a risk register that reflects the threat landscape and business context of two years ago, not today.
When Must a Risk Assessment Be Performed?
The standard requires risk assessments 'at planned intervals' (the scheduled review) and 'when significant changes are proposed or occur' (event-driven reviews). The table below maps the full set of triggers that should prompt a risk assessment update — distinguishing planned, triggered, and directed reviews:
| Trigger | Timing | Type | What to assess |
| Scheduled periodic review | At defined intervals — typically annually or semi-annually | Planned | Full risk register review; update scores for risks where context has changed; identify new risks introduced by business changes during the period |
| Significant organizational change | Before or immediately after the change occurs | Triggered | Scope expansion, new product launch, major technology platform change, acquisition or merger — each introduces new assets, new threats, and new stakeholders that require risk assessment |
| New or amended regulation | Within 30 days of regulation publication or enforcement date | Triggered | UU PDP implementing regulations, new POJK circulars, Bank Indonesia technical standards — assess whether new regulatory requirements create risks not covered by current controls |
| Significant security incident | During post-incident review (within 5 working days of resolution) | Triggered | Any incident that succeeded despite controls in place signals that the risk was either underestimated or controls were ineffective — update risk register and treatment plan accordingly |
| New significant threat intelligence | On identification of relevant threat intelligence | Triggered | Major new attack vectors (e.g. new ransomware targeting Indonesian financial services), vulnerabilities in systems in scope, threat actor activity patterns specific to the sector |
| Third-party / supplier security incident | On notification or discovery | Triggered | A breach at a key cloud provider or software vendor may affect risks in scope — assess whether third-party incident creates new or elevated risks for the organization |
| Management review direction | As directed in management review outputs | Directed | Management review may identify specific areas where risk re-assessment is warranted — these directions must be tracked as ISMS improvement actions |
What Constitutes a Meaningful Operational Risk Review?
A meaningful operational risk review is not a rubber-stamp exercise. It should produce one of four outcomes for each risk reviewed: the risk rating is confirmed unchanged (with documented rationale), the risk rating is updated upward or downward (with documented rationale), a new risk is added to the register, or an existing risk is closed because it no longer applies. A review that produces no changes and no new risks is either comprehensive confirmation that nothing has changed — or it is a perfunctory exercise. Auditors will probe the rationale.
The review must be documented. Updated risk assessment results must be retained as documented information per Clause 8.2's explicit requirement. The updated results feed directly into Clause 8.3 — if new risks are identified in the operational review, the risk treatment plan must be updated to address them.
| Operational risk review cadence for Indonesian organizations in 2026: Given the active pace of regulatory change — UU PDP implementing regulations being progressively issued, OJK AI governance guidance developing, BSSN technical standards evolving — Indonesian organizations should treat their annual scheduled risk review as a minimum baseline and actively monitor for triggered reviews. A new OJK circular on IT governance for financial institutions constitutes a significant change that warrants a targeted risk review, not a note in the next annual review twelve months later. |
Clause 8.3 — Information Security Risk Treatment
Clause 8.3 requires the organization to implement the information security risk treatment plan. This is the operational execution of the planning output from Clause 6.1.3 — the risk treatment plan and Statement of Applicability that were produced during the planning phase must now be actively implemented and maintained.
The key operational requirement in Clause 8.3 is not just that the risk treatment plan is implemented but that it is maintained — meaning it is updated when risks change, when new controls are identified, when implementation timelines shift, and when residual risk acceptance decisions change. A risk treatment plan that was finalized at certification and never touched since is not being maintained.
Tracking Risk Treatment Implementation
Effective risk treatment tracking requires more than a spreadsheet with RAG status indicators. For each risk being treated, the operational record should include: what was planned (from the risk treatment plan), what has been implemented (evidenced by control configuration records, training records, or procedure documents), what the current implementation status is, what the target completion date is, what the residual risk is after partial implementation, and whether the risk owner has reviewed and accepted the current residual position.
Controls that are partially implemented — a common state between risk treatment planning and full certification readiness — must be tracked with interim residual risk assessments. A risk where 60% of the treatment plan has been executed is not at the same risk level as an untreated risk, but it is also not at the target residual risk level. The risk treatment tracking must reflect this intermediate state accurately.
| The treatment plan as a living document: The most common Clause 8.3 finding is a risk treatment plan that was produced during initial implementation and never updated. Risks that were High at implementation and have since been fully treated still appear as 'in progress' in the plan. New risks identified in subsequent risk assessments are not reflected. Controls that were planned but deprioritized have no updated timeline or compensating control. A living risk treatment plan has an active custodian who updates it when any of these conditions change — not someone who produces a new version annually for the audit. |
Required Outputs from Clause 8
Clause 8 produces four categories of documented outputs. Three are explicitly required by the standard's text; one is required by implication to demonstrate outsourcing control:
| § | Required document / output | Status | What auditors examine |
| 8.1 | Evidence that operational processes are being carried out as planned | EXPLICIT | Records demonstrating that the ISMS operational processes — risk treatment implementation, control operation, change management, supplier management — are executing per documented procedures. |
| 8.1 | Outsourcing / supplier controls documentation | Required | Supplier contracts with security requirements, supplier assessment records, monitoring evidence. Not explicitly named but required to demonstrate control of outsourced processes. |
| 8.2 | Results of information security risk assessments | EXPLICIT | Updated risk register results from periodic and triggered assessments. Same requirement as Clause 6.1.2 — must be retained as documented information. |
| 8.3 | Results of information security risk treatment | EXPLICIT | Updated risk treatment plan showing implementation status, completion evidence for implemented controls, and residual risk acceptance records. |
The operational evidence requirement in Clause 8.1 is the broadest and most flexible — it covers all evidence that the ISMS is running as planned. This includes control configuration records, access review reports, vulnerability scan results, incident logs, supplier monitoring records, change management records, and awareness training outcomes. The standard does not prescribe specific evidence formats; it requires evidence that processes are being carried out.
Common Clause 8 Nonconformities
Risk assessment not updated after significant change
An organization that launched a new mobile application, migrated to a new cloud provider, and acquired a competitor in the past year — but whose risk register shows the same risks from the initial implementation assessment — has a significant Clause 8.2 nonconformity. Significant changes require triggered risk assessments. The question auditors ask is not 'when did you last do a risk assessment?' but 'what significant changes have occurred since your last assessment, and how are those changes reflected in your risk register?'
Suppliers onboarded without security review
A common operational gap: the procurement process does not include a security review requirement, and suppliers are onboarded based on commercial criteria alone. By the time the ISMS team identifies a new cloud provider or SaaS tool in the environment, it may have been in use for months with no security assessment, no data processing agreement, and no contractual security obligations. Clause 8.1's outsourcing control requirement is violated before the supplier is even registered in the ISMS.
Risk treatment plan not reflecting current implementation state
A risk treatment plan that shows 'Q1 2025' as the completion date for a control that was implemented in Q3 2025 — with no update to the record — signals poor operational tracking. More seriously, a plan that shows controls as 'planned' when they have not been started signals that the risk treatment is not being operationally managed. Auditors check dates and ask for implementation evidence. Discrepancies between the plan and the evidence are findings.
Controls implemented for audit but not maintained
This is the most consequential Clause 8 failure mode — and the hardest to detect from the outside until something goes wrong. An access review process that produced reports in the quarter before the certification audit and nothing since. A vulnerability management program that ran scans for three months before certification and has not run since. A secure coding training program that was delivered once and never repeated. These controls were implemented; they are not maintained. The Stage 2 audit may pass them; the first surveillance audit will not.
| The surveillance audit reality check: Clause 8 failures are most commonly discovered at the first surveillance audit (12 months after certification) rather than during the initial certification audit. The initial audit tests whether controls were implemented. The surveillance audit tests whether they are still functioning. Organizations that treat certification as the finish line and relax operational rigor after the certificate arrives consistently face difficult surveillance audits — and in some cases, suspension of certification when controls are found to be non-operational. |
Clause 8 as the Operational Proof of the ISMS
If Clauses 4 through 7 define what the ISMS is supposed to be, Clause 8 is the test of whether it actually is that. An ISMS that exists only in documentation — risk registers that were populated once and never updated, controls that were implemented for the audit and then quietly disabled, supplier relationships that were risk-assessed on paper but never monitored — is not a management system. It is a documentation collection.
The organizations that build genuinely effective ISMS programs embed Clause 8 activities into their operational rhythms — not as separate compliance events, but as integrated parts of how the business runs. Change management processes that include security impact assessment as a standard gate. Procurement processes that trigger supplier security review automatically. Risk register reviews that happen when the business changes, not just when the audit calendar approaches. Incident reviews that produce risk register updates as a standard output.
When Clause 8 is operating this way, the ISMS is not something the security team does in addition to running the business — it is part of how the business manages itself. That is the standard ISO 27001 is designed to produce. Clause 8 is where that ambition becomes operational reality.