Clause 6 Planning — Risk Assessment and Treatment Done Right
The Reality of Risk-Based Security Management
Clause 6 is where your ISMS either becomes a living, breathing system or a collection of dusty documents that nobody reads. I've audited organizations with beautifully formatted risk registers containing 47 risks, all conveniently rated "Medium" with identical treatment plans. I've also seen lean startups with scrappy spreadsheets that genuinely drove security decisions. Guess which ones actually passed their certification audits with flying colors?
The standard dedicates Clause 6 to planning for a reason. Without proper risk assessment and treatment, you're just implementing random controls and hoping they address actual threats. That's not information security management—that's security theater with an expensive annual subscription.
What many organizations miss is that Clause 6 creates the bridge between your high-level ISMS context (Clause 4) and the actual controls you implement from Annex A. Get this wrong, and you'll find yourself justifying why you implemented Control 8.9 (Configuration management) when your risk assessment never identified configuration drift as a concern.
Understanding the Architecture of Clause 6
Clause 6 splits into three subclauses, and understanding their relationship is crucial. Clause 6.1 covers actions to address risks and opportunities, Clause 6.2 handles information security objectives, and Clause 6.3—new in the 2022 revision—addresses planning of changes. These aren't independent checkboxes; they form an integrated planning framework.
The hierarchy matters. Your risk assessment (6.1.2) identifies what could go wrong. Your risk treatment (6.1.3) determines what you'll do about it. Your objectives (6.2) translate treatment decisions into measurable targets. And your change planning (6.3) ensures you don't accidentally blow up your risk posture when modifying the ISMS.
Most organizations treat these as separate documents maintained by different people who never talk to each other. That's how you end up with risk registers showing "implement backup solution" as a treatment while your security objectives mention nothing about backup recovery times, and your change management process allows infrastructure modifications without risk reassessment.
For organizations implementing cloud-specific controls under ISO 27017 or handling personal data under ISO 27018, this integration becomes even more critical. Your cloud migration risk assessment should directly inform your objectives around data residency and access control implementation.
Risk Assessment: Beyond the Compliance Checkbox
Clause 6.1.2 requires you to define and apply an information security risk assessment process. The standard is deliberately non-prescriptive about methodology—it doesn't mandate NIST, OCTAVE, FAIR, or any other framework. What it does require is that your process is repeatable and produces "consistent, valid, and comparable results."
That last requirement is where I fail organizations most often. If two different analysts can assess the same risk scenario and arrive at wildly different ratings, your methodology isn't consistent. If your risk criteria don't reflect business reality, your results aren't valid. If you can't compare this year's assessment to last year's, you can't demonstrate improvement.
Here's what a defensible risk assessment methodology actually requires:
- Clear risk criteria: What constitutes Low, Medium, High, or Critical impact? Define this in business terms your leadership understands. "Significant financial loss" isn't criteria—"£500K-£2M unplanned expenditure" is.
- Likelihood calibration: Your likelihood scale needs anchor points. "Probable" is meaningless. "Expected to occur 2-4 times per year based on industry incident data and internal history" is usable.
- Defined scope boundaries: Are you assessing risk to the organization, to specific assets, to information, or to processes? The 2022 standard emphasizes risk to information—keep that focus.
- Risk ownership assignment: Every identified risk needs an owner who has authority to make treatment decisions. Assigning all risks to the CISO isn't ownership—it's abdication.
The 2022 revision also emphasizes the need to consider risks and opportunities. This isn't just about threats—it's about identifying where improved information security could enable business opportunities. Maybe better access controls would allow remote work expansion, or enhanced monitoring could support new customer data processing services.
Common Risk Assessment Failures
I once audited a financial services firm with a risk register containing 156 meticulously documented risks. They'd hired a Big Four consultancy to build it three years prior. The documentation was immaculate. The problem? Nobody had touched it since implementation.
When I interviewed the infrastructure manager about their top-rated risk—"ransomware infection leading to complete data loss"—he laughed. They'd since implemented immutable backups, network segmentation, and endpoint detection. The risk rating should have been dramatically lower. Meanwhile, they'd migrated to a new cloud provider six months ago, and that vendor concentration risk appeared nowhere.
Their risk register wasn't a management tool; it was a compliance artifact. The real risk discussions happened in weekly ops meetings, but those decisions never flowed back to the register. They failed the audit—not for having the wrong risks, but for having a risk assessment process that didn't meet the "consistent, valid, and comparable" requirement because it wasn't actually being used.
Risk Treatment: Where Strategy Meets Reality
Clause 6.1.3 demands a risk treatment process that produces a risk treatment plan. This isn't a shopping list of controls—it's a strategic document that explains why you're implementing specific measures and how they address identified risks.
The standard allows four treatment options: modify, retain, avoid, or share the risk. Most organizations default to "modify" (implement controls) without considering whether risk sharing through insurance or contractual arrangements might be more cost-effective.
Your treatment plan must identify:
- What will be done (specific controls or other actions)
- Who is responsible for implementation
- When actions will be completed
- What resources are required
Here's where the Annex A controls become relevant. If your risk assessment identifies unauthorized access to customer data as a high-impact scenario, your treatment plan might reference Control 5.15 (Access control management), Control 8.5 (Secure system development), and Control 8.16 (Monitoring activities). Each control selection should trace back to specific risks.
For organizations with complex supplier relationships, ISO 27036 provides additional guidance on supplier relationship security that should inform your risk treatment decisions around third-party access and data processing.
Information Security Objectives: Making Risk Treatment Measurable
Clause 6.2 requires you to establish information security objectives at relevant functions and levels. This is where many organizations stumble—they write objectives that sound impressive but can't be measured or don't relate to their actual risk treatment decisions.
"Improve information security" isn't an objective—it's a wish. "Reduce successful phishing attempts by 50% within 12 months through implementation of email security controls and quarterly awareness training" is an objective. It's specific, measurable, achievable, relevant to identified risks, and time-bound.
Your objectives should cascade from your risk treatment plan. If you've decided to treat email-based attacks through technical controls and awareness training, your objectives should measure the effectiveness of both approaches. Consider metrics like:
- Mean time to detect security incidents (technical effectiveness)
- Percentage of staff reporting suspicious emails (awareness effectiveness)
- Number of security policy violations (compliance effectiveness)
- Recovery time from major incidents (resilience effectiveness)
Planning of Changes: The 2022 Addition That Matters
Clause 6.3 is new in the 2022 revision, and it addresses a gap I've seen in countless audits. Organizations would implement changes to their ISMS—new technologies, modified processes, organizational restructuring—without considering the security implications until after problems emerged.
The requirement is straightforward: when changes to the ISMS are planned, they shall be carried out in a planned manner. This means:
- Understanding what might go wrong during the change
- Ensuring changes don't inadvertently increase risk
- Maintaining the integrity of the ISMS during transitions
- Considering resource implications of changes
This is particularly critical for cloud migrations, where organizations often focus on functional requirements while overlooking security implications. A structured change planning process would identify the need to reassess risks, update the Statement of Applicability, and potentially implement additional controls before migration begins.
What the Auditor Looks For
During a Clause 6 audit, I'm looking for evidence that your planning activities are genuinely driving your ISMS implementation. Specifically:
Risk Assessment Evidence
- A documented methodology that produces consistent results
- Risk registers that reflect current business context, not outdated scenarios
- Evidence that risk assessments are actually performed, not just documented
- Clear traceability between identified risks and business impacts
- Regular review and updating of risk assessments
Risk Treatment Evidence
- Treatment plans that address all significant risks
- Clear justification for control selection from Annex A
- Evidence that risk owners have actually approved treatment decisions
- Implementation schedules that are realistic and tracked
Objectives Evidence
- Measurable objectives that connect to risk treatment decisions
- Regular monitoring and reporting on objective achievement
- Evidence that objectives influence resource allocation and priorities
- Clear responsibility assignment for objective delivery
Change Planning Evidence
- A defined process for evaluating ISMS changes
- Examples of change impact assessments
- Evidence that changes consider security implications before implementation
- Documentation showing how change outcomes are evaluated
Integration with Other Management Systems
Clause 6 planning activities don't exist in isolation. If your organization has other management systems—quality (ISO 9001), environmental (ISO 14001), or business continuity (ISO 22301)—look for integration opportunities. Risk assessments can share common methodologies, objectives can support multiple system requirements, and change planning can address all management system implications simultaneously.
For organizations in regulated sectors, your Clause 6 planning should also consider regulatory risk scenarios. Financial services organizations need to consider regulatory action as a potential impact, while healthcare organizations must address patient safety implications of security failures.
Making Clause 6 Work in Practice
The key to successful Clause 6 implementation is treating it as business management, not IT compliance. Your risk assessment should inform business decisions about technology investments, process changes, and resource allocation. Your objectives should align with business goals, not just security metrics. Your change planning should be integrated with project management and business development activities.
Start simple. A well-managed spreadsheet that's actually used is infinitely more valuable than a sophisticated tool that gathers digital dust. Focus on the 10-15 risks that genuinely keep your leadership awake at night, create treatment plans that make business sense, and set objectives you can actually measure and achieve.
Most importantly, make sure your Clause 6 planning feeds into your operational activities under Clause 8. If your risk assessment doesn't influence your operational planning and control, you're not implementing a management system—you're creating documentation.
Pro tip: Schedule quarterly "planning reviews" where you revisit your risk assessment, check progress against objectives, and evaluate any planned changes. This keeps your Clause 6 activities current and demonstrates continuous improvement to auditors.
Remember, Clause 6 is the foundation that supports everything else in your ISMS. Get this right, and your support processes and operational activities will follow logically. Get it wrong, and you'll spend years implementing controls that don't address your actual risks while wondering why your security program isn't delivering business value.
For organizations serious about building effective information security management systems, the ISO 27001 Info Hub provides ongoing guidance and practical resources. Connect with experienced practitioners at https://t.me/ISO27001_INFO_BOT or consider professional consultation to ensure your Clause 6 planning delivers real business value.
Need personalized guidance? Reach our team at ix@isegrim-x.com.
