Clause 6 is where the ISMS earns its name. The previous clauses — context, leadership, and governance — establish the management architecture. Clause 6 is where the actual information security work begins: identifying what could go wrong, deciding how much risk is acceptable, selecting the controls that will treat unacceptable risk, and setting objectives that hold the ISMS accountable for improvement.
It is also the clause that separates organizations with a genuine ISMS from those with a compliance program dressed up as one. A genuine risk assessment produces uncomfortable findings. It identifies risks that are expensive to treat. It forces prioritization decisions that require management judgment. It creates accountability for controls that must actually be implemented, not just listed in a spreadsheet.
This article walks through every component of Clause 6 in full — from defining the risk assessment methodology through to the Statement of Applicability and the change planning requirement introduced in the 2022 revision. The emphasis throughout is on what makes a Clause 6 implementation credible to auditors, defensible to regulators, and genuinely useful for managing information security risk.
Clause 6 at a Glance
Clause 6 spans five sub-clauses that together constitute the entire planning infrastructure of the ISMS:
6.1.1 Risks & Opportunities Actions to address uncertainty | 6.1.2 Risk Assessment Identify, analyze, evaluate risks | 6.1.3 Risk Treatment Select controls & produce SoA | 6.2 IS Objectives Set measurable security goals | 6.3 Change Planning Plan ISMS changes (new 2022) |
Clauses 6.1.2 and 6.1.3 — risk assessment and risk treatment — are the intellectual core of ISO 27001. Everything else in the standard exists to support, execute, and evaluate what these two sub-clauses require. They are also the source of more audit findings than any other clause, because the quality of risk assessment work is difficult to fake and easy for experienced auditors to probe.
Clause 6.1.1 — Actions to Address Risks and Opportunities
Clause 6.1.1 is the HLS preamble to the risk-specific sub-clauses that follow. It requires the organization to consider the context and stakeholder requirements identified in Clause 4 and determine the risks and opportunities that must be addressed to ensure the ISMS can achieve its intended outcomes, prevent undesired effects, and achieve continual improvement.
In practice, this sub-clause is satisfied through the risk assessment process that follows in 6.1.2. The explicit mention of 'opportunities' is worth noting — ISO 27001 does not just require risk mitigation; it requires active identification of opportunities for improvement. This aligns with the PDCA philosophy: the planning phase should identify not just what could go wrong, but what could go better.
For documentation purposes, the output of 6.1.1 is typically absorbed into the risk assessment methodology and risk register. No separate document is required, but the methodology should explicitly reference how context issues and stakeholder requirements feed into the risk identification process.
Clause 6.1.2 — Information Security Risk Assessment
ISO 27001 does not prescribe a specific risk assessment methodology. It prescribes the properties that your methodology must have, and then requires you to define, document, and consistently apply that methodology. This flexibility is valuable — it allows organizations to choose approaches that fit their size, maturity, and existing risk management culture. It also means that the methodology document itself becomes an auditable artifact.
The Eight-Step Risk Assessment Process
A complete risk assessment under ISO 27001 follows a structured sequence. The eight steps below map the standard's requirements to the practical activities required:
| # | Step | What it requires |
| 01 | Define the Methodology | Before assessing a single risk, document how you will assess risks. Define: what is an asset, how likelihood and impact are scored, what makes a risk unacceptable, and how the methodology will be consistently applied. This is required before the assessment begins. |
| 02 | Identify Information Assets | Catalog the information assets within the ISMS scope. Group them logically — systems, data types, processes, people, third-party services. Assign asset owners. The depth of this register determines the quality of the risk assessment. |
| 03 | Identify Threats | For each asset or asset group, identify the threats that could affect it. Use structured threat libraries (ENISA, MITRE ATT&CK, ISO 27005 Annex C) as starting points. Supplement with threats specific to your sector and the Indonesian threat landscape. |
| 04 | Identify Vulnerabilities | Identify the weaknesses in your controls, systems, or processes that could be exploited by each threat. Vulnerabilities can be technical (unpatched systems), procedural (no formal change management), or human (insufficient awareness training). |
| 05 | Analyze: Likelihood & Impact | For each threat-vulnerability-asset combination, assess: how likely is this risk to materialize? What would the impact be on CIA? Score both dimensions using your defined scale. The combination produces the inherent risk rating before controls. |
| 06 | Evaluate: Risk Acceptance | Compare the analyzed risk level against the risk acceptance criteria defined by top management. Risks above the acceptance threshold require treatment. Risks below may be accepted. All acceptance decisions must be documented with the risk owner. |
| 07 | Select Treatment Options | For risks requiring treatment, determine whether to: modify (implement controls), retain (accept), avoid (stop the activity), or share (transfer via insurance/contract). Document the rationale for each treatment decision. |
| 08 | Produce the Risk Treatment Plan | For risks being modified, create a risk treatment plan: which controls will be implemented, who is responsible, what is the target completion date, what resources are required, and what is the expected residual risk after treatment. |
Defining Risk Acceptance Criteria
Before a single risk can be assessed, the organization must define what level of risk is acceptable — the risk acceptance criteria. This is a management decision, not a technical one, and it must be documented and approved by top management as part of the risk assessment methodology.
Risk acceptance criteria are typically expressed as a threshold on the risk scoring scale. Any risk scoring below the threshold may be accepted without further treatment. Any risk above the threshold requires a documented treatment decision. The threshold must be realistic — if it is set so low that every minor risk requires treatment, the risk treatment plan becomes unmanageable. If it is set so high that critical risks are routinely accepted, the ISMS is failing its purpose.
The Risk Scoring Matrix
The most common risk quantification approach in ISO 27001 implementations uses a likelihood-impact matrix. The matrix below illustrates a standard 5×5 approach with color-coded risk levels — from Minimal through Critical. The specific scale and thresholds must be defined in the methodology and applied consistently:
| Likelihood \ Impact | 1 — Negligible | 2 — Minor | 3 — Moderate | 4 — Significant | 5 — Critical |
| 5 — Almost certain | 5 MINIMAL | 10 MEDIUM | 15 HIGH | 20 CRITICAL | 25 CRITICAL |
| 4 — Likely | 4 MINIMAL | 8 LOW | 12 MEDIUM | 16 HIGH | 20 CRITICAL |
| 3 — Possible | 3 MINIMAL | 6 LOW | 9 LOW | 12 MEDIUM | 15 HIGH |
| 2 — Unlikely | 2 MINIMAL | 4 MINIMAL | 6 LOW | 8 LOW | 10 MEDIUM |
| 1 — Rare | 1 MINIMAL | 2 MINIMAL | 3 MINIMAL | 4 MINIMAL | 5 MINIMAL |
| Methodology consistency requirement: ISO 27001 requires that risk assessment results are 'consistent, valid, and comparable'. This means the same risk assessed by different people at different times should produce similar results. This is achieved through clear definitions of each scoring level — not just a number, but a specific description of what constitutes a likelihood of '3' or an impact of '5' in your organizational context. |
Sample Risk Register Entries
The risk register is the primary output of the risk assessment process. It must capture sufficient information to demonstrate that each risk was properly identified, analyzed, evaluated, and assigned a treatment decision. The sample below illustrates four risks typical for an Indonesian fintech organization:
| ID | Risk description | Threat scenario | L | I | Score | Treatment decision & plan |
| R-001 | Customer payment database — unauthorized access via phishing attack on privileged accounts | Credential theft → lateral movement → data exfiltration | 4 | 5 | 20 CRITICAL | Treat — Implement MFA (A.8.5), privileged access management (A.8.2), security awareness training (A.6.3). Owner: CTO. Due: Q2 2026. |
| R-002 | Cloud hosting provider — prolonged service outage affecting payment processing availability | Third-party dependency → SLA breach → operational disruption | 2 | 4 | 8 MEDIUM | Treat — Multi-cloud redundancy plan (A.8.14), DR testing program (A.5.30). Owner: Head of Engineering. Due: Q3 2026. |
| R-003 | API keys embedded in source code — exposed in public repository | Developer error → secrets exposure → unauthorized API access | 3 | 4 | 12 HIGH | Treat — Secret scanning in CI/CD pipeline (A.8.29), mandatory code review policy (A.8.28). Owner: Head of Engineering. Due: Q1 2026. |
| R-004 | Ex-employee retains access to internal systems after offboarding | Process gap → stale access → insider threat | 3 | 3 | 9 MEDIUM | Treat — Formal offboarding checklist (A.6.5), access revocation SLA, quarterly access reviews (A.8.3). Owner: HR Director. Due: Q1 2026. |
| RISK REGISTER DEPTH | The sample above reflects the minimum content for an auditable risk register entry. A production risk register typically also captures: the asset(s) affected, the current controls in place before treatment (inherent vs. residual risk), the risk owner's name and acceptance signature, the date of last review, and links to the control evidence for implemented treatments. |
Clause 6.1.3 — Information Security Risk Treatment
Once risks have been assessed and evaluated, the organization must decide what to do about each one that exceeds the acceptance threshold. Clause 6.1.3 requires the organization to select appropriate information security risk treatment options, determine the controls necessary to implement those options, and then do something specific that no other risk framework requires quite as explicitly: produce a Statement of Applicability.
The Statement of Applicability (SoA)
The Statement of Applicability is the document that connects your risk treatment decisions to the full set of 93 controls in ISO 27001:2022 Annex A. For every control, the SoA must state: whether the control is applicable to your organization, whether it has been implemented, and the justification for the applicability or exclusion decision.
The SoA is one of the two documents most scrutinized in a certification audit — the other being the risk register. Auditors use it to verify that your control selection is genuinely risk-driven rather than arbitrary, that exclusions are defensible, and that the controls you claim to have implemented actually exist. The sample below shows what a credible SoA entry looks like across five controls, including one justified exclusion:
| Ctrl | Control title | Applicable? | Implemented? | Justification and implementation notes |
| 5.7 | Threat intelligence | YES | Partial | Applicable — identified as relevant to detect emerging threats targeting Indonesian fintech sector. Implementation in progress: threat intelligence feed subscription procured, integration with SIEM planned for Q2 2026. |
| 8.5 | Secure authentication | YES | Yes | Applicable — required by risk assessment (R-001, critical). MFA implemented for all privileged accounts. TOTP for standard user access. Implementation evidence: access management policy v2.1, audit log sample. |
| 8.10 | Information deletion | YES | Partial | Applicable — UU PDP Article 39 right to erasure obligation. Deletion procedure documented; automated deletion for inactive accounts implemented; customer-initiated deletion workflow in development. |
| 7.4 | Physical security monitoring | NO | N/A | Excluded — organization operates fully remote with no physical office. No physical premises where in-scope information systems are located. Exclusion justified under 6.1.3. |
| 8.28 | Secure coding | YES | Yes | Applicable — software development is core to in-scope service delivery. Secure coding standard v1.0 published. Developer training completed Q4 2025. SAST tooling integrated in CI/CD pipeline. |
What Makes a Strong SoA
The most common SoA weakness is vague justification language. An entry that states 'applicable — required by ISO 27001' for every control provides no information about why this specific organization needs this specific control. Justifications should reference specific risks from the risk register, specific regulatory requirements by article number, or specific business requirements by name.
Exclusion justifications are held to a particularly high standard. An auditor who sees 'not applicable — low risk' without any risk assessment evidence supporting that conclusion will raise it as a finding. Every exclusion must be traceable to a documented rationale — typically a risk assessment finding that the risk the control addresses is below the acceptance threshold for this organization.
| SoA and the 2022 revision: The 2022 revision reorganized Annex A from 14 domains and 114 controls to 4 domains and 93 controls, with 11 new controls. If your SoA was built against the 2013 version, it needs a structural update — not just mapping old controls to new numbers, but reviewing the 11 new controls and making fresh applicability determinations for each. Controls like 5.7 (Threat intelligence), 8.10 (Information deletion), and 8.28 (Secure coding) are particularly relevant for Indonesian organizations and must be explicitly addressed in the SoA. |
The Risk Treatment Plan
For each risk being treated through control implementation, the risk treatment plan documents what will be done, by whom, by when, with what resources, and what the expected residual risk will be after treatment. The plan is a commitment device — it creates accountability for control implementation and gives management a mechanism to track whether the ISMS's risk reduction objectives are being achieved.
Risk owners must review and approve the risk treatment plan for risks in their domain. Their approval — typically documented through a sign-off or electronic confirmation — constitutes the formal acceptance of the residual risk that will remain after treatment is complete. This approval is required before the audit and must be retained as documented information.
| Treatment plan vs. implementation: A common audit finding is a risk treatment plan that documents what controls will be implemented but shows no evidence that implementation has actually occurred. The risk treatment plan is a Plan — the Stage 2 audit verifies whether the plan was executed. By the time of the certification audit, the controls in the treatment plan must be implemented (or the implementation must be at a stage where the auditor is satisfied that it will be complete within a reasonable timeframe after certification). |
Clause 6.2 — Information Security Objectives
Clause 6.2 requires the organization to establish information security objectives at relevant functions and levels. These objectives serve a different purpose from the risk treatment plan — they are forward-looking targets for improvement rather than responses to identified risks. In practice, the best ISMS implementations derive their objectives directly from the risk assessment findings: if the risk register identifies credential theft as a top-three risk, an objective around MFA implementation is both risk-driven and objectively measurable.
The standard is specific about what makes a valid information security objective. Each requirement is shown below alongside its practical meaning and an example:
| Clause 6.2 Requirement | What it means in practice | Example |
| Consistent with the information security policy | Objectives must align with and support the commitments made in the policy — if the policy commits to UU PDP compliance, objectives must address personal data protection. | Objective: Achieve 100% staff completion of UU PDP awareness training by Q3 2026. |
| Measurable (where practicable) | Objectives should be quantifiable where possible — not 'improve security awareness' but 'reduce phishing simulation click rate to below 5% by year-end'. | Objective: Reduce mean time to detect security incidents from 72 hours to 24 hours by Q4 2026. |
| Take into account applicable requirements and results of risk assessment | Objectives must be grounded in the risk landscape identified in 6.1.2 — they are not arbitrary targets but responses to specific risk findings. | Objective: Implement MFA across all privileged accounts (addressing R-001 critical risk) by Q2 2026. |
| Monitored, communicated, and updated as appropriate | Progress against objectives must be tracked, reported to management, and the objectives themselves must be reviewed — typically at management review — for continued relevance. | Quarterly ISMS scorecard presented at management review; objectives revised annually based on risk register changes. |
| Documented | Information security objectives must exist as documented information. A management review agenda item is not sufficient — there must be a dedicated objectives register or equivalent. | Annual IS Objectives document, version-controlled, approved by CEO, published to relevant staff. |
| Plans for how to achieve them must define: what, resources, responsible persons, completion date, how evaluated | For each objective, an action plan must exist — not just the objective statement. Who will do what, with what resources, by when, and how will success be measured. | MFA implementation plan: IT team, budget IDR 45M, milestone dates Q1 delivery, Q2 completion, measured by access log audit. |
How Many Objectives?
ISO 27001 does not specify a number. Organizations typically set between four and eight objectives per certification cycle — enough to represent meaningful improvement priorities without creating an unmanageable tracking burden. Objectives should be genuinely stretching: 'maintain current security controls' is not an objective; 'reduce mean time to detect incidents by 50%' is.
Objectives must be reviewed at management review and updated when the risk landscape changes. An objective that was set in response to a risk that has since been treated should be replaced by a new objective responding to the next priority risk. Static objectives that never change year over year signal an ISMS that is not genuinely driving improvement.
Clause 6.3 — Planning of Changes (New in 2022)
Clause 6.3 is the newest sub-clause in Clause 6, introduced in the 2022 revision. It requires that when the organization determines the need for changes to the ISMS, those changes shall be carried out in a planned manner.
This addresses a real weakness that existed in the 2013 version: organizations would make significant changes to their ISMS — updating scope, removing controls, changing risk assessment methodology, adding new systems — without any structured change management process. These unplanned changes created gaps, inconsistencies, and audit evidence problems.
The requirement is deliberately non-prescriptive — it does not mandate a specific change management process. What it requires is that ISMS changes are considered, documented, and approved before implementation. In practice, this means maintaining a change log for the ISMS itself: when the risk assessment methodology was revised, who approved the revision, and what impact the change had on existing risk assessments. When scope was expanded, what was the decision-making process. When a control was removed from the SoA, why, and what compensating measures were considered.
| Integration with IT change management: Organizations with an existing IT change management process (ITIL-based or otherwise) can extend that process to cover ISMS changes rather than building a separate mechanism. The key is ensuring that changes to ISMS-specific artifacts — the risk register, SoA, scope statement, policy documents — are captured in the change record and approved by the appropriate authority. A note in the management review minutes authorizing a scope change satisfies the spirit of Clause 6.3 if it is specific, dated, and retained. |
Required Outputs from Clause 6
Clause 6 produces more explicitly required documented information than any other clause in ISO 27001. The outputs below represent the complete set of documents auditors will request during a certification audit:
| § | Required document / output | Status | What auditors examine |
| 6.1.2 | Risk assessment methodology document | Required | Documented criteria for risk identification, analysis, and evaluation — including the rating scale, risk acceptance threshold, and consistency requirements. |
| 6.1.2 | Risk assessment results / Risk register | EXPLICIT | Documented results of every risk assessment — the identified risks, their scores, and the evaluation outcomes. Must be retained and available for audit. Major nonconformity if absent. |
| 6.1.3 | Risk treatment plan | EXPLICIT | Documented plan for each risk requiring treatment — controls selected, owners, timelines, and expected residual risk. One of the most scrutinized documents in a certification audit. |
| 6.1.3 | Statement of Applicability (SoA) | EXPLICIT | The SoA listing all 93 Annex A controls, their applicability status, justification, and implementation status. Must exist as documented information. Absence is a major nonconformity. |
| 6.2 | Information security objectives register | EXPLICIT | Documented objectives with plans for how to achieve them (what, who, when, resources, evaluation). Must be aligned with the risk assessment and policy. |
| 6.3 | Documentation of planned ISMS changes | Required | Records showing that changes to the ISMS were planned in a structured manner — not made ad hoc. Change records, decision logs, or ISMS change register entries. |
Three of these outputs — the risk assessment results, the risk treatment plan, and the Statement of Applicability — are 'explicitly required' as documented information in the standard's text. Their absence constitutes a major nonconformity and will prevent certification. The others are required by implication: without them, the explicit requirements cannot be demonstrated.
Common Clause 6 Nonconformities
Risk assessment that is asset-centric rather than risk-centric
A common approach is to list assets and assign generic risk scores without actually analyzing the specific threat scenarios and vulnerabilities that create risk for each asset. Auditors can identify this pattern quickly: if every asset of the same type has the same risk score, the assessment was templated rather than analyzed. ISO 27001 requires genuine analysis — the same asset can carry very different risks depending on how it is used, who has access, and what compensating controls exist.
SoA with no justification for exclusions
Excluding a control without a documented rationale is a nonconformity. Saying 'N/A' with no explanation leaves auditors unable to verify whether the exclusion is legitimate. Every exclusion must be traceable to either a risk assessment finding (the risk this control addresses is below acceptance threshold), a business reason (the organization does not perform the activity this control covers), or a scope boundary (the activity is outside the ISMS scope).
Objectives that are not measurable or not tracked
An objective that reads 'improve our security posture' satisfies neither the measurability requirement of Clause 6.2 nor its monitoring requirement. Auditors will ask how progress is being tracked and what metrics demonstrate achievement. If no answer is available, the objective was written for the document rather than for the ISMS.
Risk register not updated after incidents or significant changes
A risk register that was completed at ISMS launch and has not been updated since — despite security incidents, new regulatory requirements, or significant business changes — signals an ISMS that is running on autopilot rather than genuinely operating. Clause 6.1.2 requires risks to be reassessed at planned intervals and whenever significant changes occur. The management review (Clause 9.3) is the standard trigger for this review.
| The most expensive Clause 6 failure: The failure mode with the highest downstream cost is a risk assessment that is completed once for certification and then treated as a static document. Subsequent audit cycles will examine whether the risk register has been updated, whether new risks have been identified, and whether the treatment plan has been executed. An organization that certifies on a strong risk assessment and then lets it stagnate will face major nonconformities at its first surveillance audit — typically 12 months after certification. |
Clause 6 as the Engine of the ISMS
Every other clause in ISO 27001 depends on Clause 6 for its direction. The awareness training in Clause 7 is shaped by the risk assessment findings. The operational controls in Clause 8 implement the risk treatment plan. The audits in Clause 9 verify whether the controls are working. The improvements in Clause 10 respond to gaps identified through monitoring. Take Clause 6 seriously, and the entire ISMS has a coherent, risk-driven logic. Treat it as a documentation exercise, and every subsequent clause becomes a compliance performance rather than a management system.
The risk assessment is not a one-time project to be completed before the certification audit. It is the recurring analytical heartbeat of the ISMS — the activity that keeps the management system calibrated to the actual threat environment, the organization's actual risk profile, and the regulatory obligations that continue to evolve in Indonesia's dynamic compliance landscape.