ISO 27001 Clause 6 requires documented plans to address risks and opportunities, measurable information security objectives with implementation plans, and planned handling of ISMS changes. The immediate outputs auditors expect are a risk assessment record, a risk treatment plan, a Statement of Applicability, documented objectives with monitoring evidence, and change records showing what was decided and why.
TL;DR:
- Auditors expect documented risk assessment methodology, risk register with clear ownership, and a traceable risk treatment plan with justified control choices.
- Objectives must be directly linked to top risks, measurable with KPIs, assigned owners, and regularly reviewed with documented progress reports.
- Change planning requires formal records of reasons, impact analysis, approvals, and implementation evidence stored in a centralized, cross-referenced system.
- Maintaining traceability from risks to treatments, controls, and objectives is essential to pass a precise, evidence-based audit.
- Using assessment tools can help estimate effort and prioritize Clause 6 tasks, but focus on connecting risks, treatments, and objectives over document polish.
Table of Contents
- Clause 6 at a glance: 6.1, 6.2, 6.3 and their role in the ISMS
- Deep dive: 6.1, from risk assessment to the Statement of Applicability
- Deep dive: 6.2, objectives that hold up under scrutiny
- Deep dive: 6.3, planning changes without losing the audit trail
- What auditors expect to see for Clause 6
- Pre-audit checklist and the pitfalls that trip up implementers
- How ISMS Calculator’s tools support Clause 6 planning
- Prioritizing audit readiness without losing sight of real security value
- Practical next steps for planning your Clause 6 work
- Sources
- FAQ
Clause 6 at a glance: 6.1, 6.2, 6.3 and their role in the ISMS
Clause 6 sits at the center of the ISO/IEC 27001 management system because it turns policy intent into planned, checkable work. It has three subclauses, and each one produces a distinct set of records an auditor will ask to see.
Clause 6.1, actions to address risks and opportunities, is where you identify what could go wrong (or right) for information security and decide what to do about it. This is where risk assessment and risk treatment live, and it is the subclause most auditors spend the most time on because everything else in the ISMS traces back to it.
Clause 6.2, information security objectives and planning to achieve them, asks you to set measurable goals tied to your risk picture and business priorities, then plan the resources and timelines to hit them. Clause 6.3, planning for changes, introduced in the 2022 revision, requires that when you decide the ISMS needs to change, you plan that change rather than let it happen informally.
These three subclauses do not operate alone. Clause 6.1’s risk treatment decisions feed directly into Annex A, since the controls you select and justify (or exclude) in your Statement of Applicability come from the risk treatment plan. Clause 6.2’s objectives connect to Clause 9’s monitoring and to management review, because leadership needs objective status reports to make informed decisions. Clause 6.3 connects change decisions back to both 6.1 and 6.2, since a change to scope or services usually means new risks to assess and possibly new objectives to set.
At a glance, the record mapping looks like this: 6.1 produces the risk methodology, risk register, risk treatment plan, and Statement of Applicability. 6.2 produces objective statements, KPI definitions, and progress reports. 6.3 produces change requests, impact assessments, and approval records. An auditor who understands this mapping will move through your evidence file expecting to find each piece in a specific place, and organizing your documentation this way saves time on both sides of the audit table.
Deep dive: 6.1, from risk assessment to the Statement of Applicability
Clause 6.1 is the engine room of the ISMS, and getting it right on paper (not just in practice) is what separates a smooth certification audit from a stressful one.
Start by documenting your risk assessment methodology before you assess a single risk. Auditors want to see this as a standalone document or a clearly defined section of your ISMS manual, and it should specify:
- Scope: which assets, processes, and locations are in scope for the assessment.
- Asset inventory: a list of information assets with owners assigned to each.
- Risk criteria: how you define and score likelihood and impact, and the threshold above which a risk requires treatment.
- Roles: who identifies risks, who analyzes them, and who approves treatment decisions.
Once the methodology is fixed, identification and analysis follow a repeatable pattern. Asset-threat-vulnerability mapping remains the most common technique: for each asset, list plausible threats (a phishing attack, a supplier outage, a misconfigured cloud bucket) and the vulnerabilities that would let the threat succeed. Larger organizations often add a data flow diagram to focus attention on where sensitive information moves between systems, and most also treat supplier and third-party access as a distinct risk category, since Protiviti’s transition guidance notes that Clause 6.1 requires these actions to be integrated into ongoing ISMS processes, not treated as a one-time exercise.
The stepwise process is identify, analyze, evaluate, then decide treatment. A simple scoring model multiplies likelihood (1 to 5) by impact (1 to 5) to produce a risk score from 1 to 25, with anything above a set threshold, commonly 12 or 15, routed to mandatory treatment and lower scores accepted with a documented rationale. Treatment decisions fall into four categories: modify (apply a control), retain, avoid, or share (transfer, often through insurance or a contract clause).
Each decision then becomes a line in your risk treatment plan, which should record the risk, the chosen treatment, the specific control applied, the owner, the target date, and the approval signature. The Statement of Applicability follows directly from this: every Annex A control gets marked as applicable or not applicable, with a justification tied back to a risk treatment decision, and a version number so auditors can see how the document evolved.
Pro Tip: Give every risk a unique ID the first time you log it, and reuse that ID in the treatment plan and the SoA justification column so an auditor can trace one risk from identification to control in under a minute.
Keep as evidence: dated risk register entries, minutes or notes from risk evaluation meetings, and records showing when each treatment was actually implemented, not just approved.
Deep dive: 6.2, objectives that hold up under scrutiny
Objectives that exist only as a slide in a management review deck rarely survive an audit. Clause 6.2 objectives need to trace back to specific risks or business drivers, and they need evidence of progress.
Start from your highest-scoring risks and your organization’s own priorities. A risk around unpatched endpoints might become an objective to reduce mean patch time; a risk tied to customer data exposure might become an objective to complete encryption of a specific data store by a set date. The objective should read as a commitment, not an aspiration.
- Specific: name the system, process, or metric the objective targets.
- Measurable: attach a number or a clear pass/fail state, not a general direction.
- Achievable: check the objective against available budget and staff time before committing to it.
- Relevant: tie it explicitly to a risk treatment decision or a business requirement.
- Time-bound: give it a review date, not just a due date.
Planning elements matter as much as the objective statement itself. Auditors expect to see who owns each objective, what resources were allocated, the timeline, and how often progress gets checked, monthly is common for fast-moving objectives, quarterly for slower ones tied to a broader program.
One of the most consistent points in transition guidance for the 2022 revision is that objectives and planning for changes both received specific updates, and organizations are expected to show traceability from risk treatment to measurable outcomes (Protiviti). That traceability is exactly what an objective statement, a KPI report, and a management review minute together demonstrate.
Keep as evidence: the objective statement itself, KPI or metric reports at each review interval, and the management review record showing objectives were actually discussed, not just filed.
Deep dive: 6.3, planning changes without losing the audit trail
Clause 6.3 is the shortest subclause in Clause 6, and that brevity is exactly why implementers underestimate it. It applies whenever you determine the ISMS needs to change, and the triggers are broader than most teams expect.
Common triggers include a scope expansion (a new office, a new product line), the addition of a new service or supplier, a security incident that exposes a gap in current controls, or a regulatory or organizational shift such as a merger or a new data protection obligation. Protiviti’s guidance is direct on this point: when an organization determines changes to the ISMS are needed, those changes must be carried out in a planned manner, with evidence retained of approvals, communications, implementation, and review.
A defensible change record generally includes:
- The reason for the change, stated plainly.
- An impact and risk review covering what the change affects.
- A list of affected documents and controls that need updating.
- Approvals from the relevant owner or committee.
- A record of communications to affected staff or stakeholders.
- Implementation evidence showing the change was actually made.
- A post-change evaluation confirming the change achieved its intended result.
Pro Tip: Store change records in the same system you use for your risk register and objectives, and cross-reference IDs, so a scope change that triggers a new risk assessment or a revised objective is visible as one connected thread rather than three disconnected files.
Version your change log the same way you version your SoA, with a date, an author, and a summary of what changed since the last entry. During an audit, present change records chronologically so the assessor can see the ISMS evolving in a controlled, traceable way rather than reacting to problems after the fact.
What auditors expect to see for Clause 6
Auditors checking Clause 6 compliance work from a fairly consistent list of artefacts, and having them organized in advance changes the tone of the entire audit.
- Documented risk assessment methodology.
- Risk register with owners, scores, and dates.
- Risk treatment plan with approvals.
- Statement of Applicability, versioned.
- Objective statements with KPIs attached.
- Monitoring logs or KPI reports at defined intervals.
- Change records covering reason, impact, approval, and evaluation.
- Management review minutes referencing objectives and risk status.
The strongest audits happen when traceability is visible without extra explanation: a specific risk entry points to a treatment decision, the treatment decision points to a control in the SoA, and the control’s effectiveness feeds into an objective KPI report. When that chain is broken, auditors typically raise one of these common findings:
- Risk register exists but treatment decisions aren’t dated or approved, fixed by adding an approval field and a signature or sign-off log.
- SoA justifications are generic (“control implemented”) rather than tied to a specific risk, fixed by referencing the risk ID in the justification column.
- Objectives are listed but no KPI evidence exists, fixed by scheduling a recurring KPI check and logging the result each time.
- Change records are missing for a known scope change, fixed by retroactively documenting the change with whatever evidence still exists and building the habit going forward.
Pre-audit checklist and the pitfalls that trip up implementers
A short pre-audit pass through Clause 6 catches most of the issues that would otherwise surface mid-audit.
- Confirm the risk assessment methodology is written down and dated, not just understood informally by the security team.
- Confirm every risk in the register has an owner, a score, and a treatment decision.
- Confirm the SoA references specific risk IDs, not generic statements, and carries a version number.
- Confirm each objective has a KPI and at least one logged measurement.
- Confirm every ISMS change in the last cycle has a corresponding change record.
Common pitfalls include treating the risk methodology as a formality rather than a living document, writing objectives that sound good but cannot be measured, and skipping change records for changes that felt too small to document. Each of these is a quick fix once flagged, but each one, left unaddressed, tends to surface as a nonconformity.
For an upcoming surveillance or certification audit, prioritize traceability first: make sure risks connect to treatments, treatments connect to controls, and controls connect to objectives. A detailed certification checklist can help sequence this work against your broader certification timeline.
How ISMS Calculator’s tools support Clause 6 planning
Planning Clause 6 deliverables takes real effort to scope, and estimating that effort accurately is its own challenge. Readiness checks and cost calculators can give organizations a starting estimate based on company size, industry, and current security maturity, benchmarked against model reference values so a team can see whether its planned timeline is realistic.
The maturity assessment across the four Annex A control themes works as a practical input to a Clause 6.1 risk assessment, since it highlights weak domains before formal risk scoring begins. The customizable Gantt timelines translate directly into the resource and timeline planning that Clause 6.2 objectives require, and exported PDF reports can sit alongside a risk treatment plan as supporting planning evidence. None of these replace the risk register or the SoA, but they shorten the time it takes to build a defensible one.
Prioritizing audit readiness without losing sight of real security value
The temptation with Clause 6 is to build documents that look complete rather than documents that trace. A risk register with fifty entries and no linked treatments passes a skim but fails a close read, and it does nothing for actual security. Prioritize the chain from risk to treatment to objective over polish.
Short-term audit prep should feed a longer program, not exist separately from it. Small organizations can often start with a lean risk register covering their ten highest risks and one or two sharp objectives. Larger organizations need the same discipline applied across more domains, not a heavier process.
— Martin
Practical next steps for planning your Clause 6 work
Clause 6 work goes faster when you know roughly what it will cost and how long it will take before you start writing policy documents. ISMS Calculator’s free 2-minute check gives a quick readiness snapshot you can use to prioritize which Clause 6 task to tackle first.
- Run the free 2-minute check for an instant readiness snapshot.
- Use the ISO 27001 Readiness Assessment to validate your risk treatment plan and objectives before an audit.
- Get a tailored estimate with the ISO 27001 Cost Calculator to plan resourcing for objectives and risk treatment.
Save your estimate, export the report, and use it as a working reference alongside your risk register as your Clause 6 documentation takes shape.
Sources
This article draws on the official ISO/IEC 27001:2022 standard and Protiviti’s transition guidance on 2022 clause changes and practical readiness steps.
- ISO/IEC 27001:2022 - Information security management systems
- ISO 27001:2022 – Key changes and approaches to transition (Protiviti whitepaper)
FAQ
Can you explain ISO 27001 in a simple way?
ISO 27001 is an international standard that sets requirements for building and running an information security management system, a structured way to identify security risks and put controls in place to manage them. It applies to organizations of any size and works through clauses covering planning, operation, and continual improvement, with ISO/IEC 27001 as the official reference.
What are the 10 clauses of ISO 27001?
ISO 27001 has 10 main clauses covering scope, normative references, terms and definitions, context of the organization, leadership, planning, support, operation, performance evaluation, and improvement. Clause 6, planning, is where risk assessment, risk treatment, objectives, and change planning are defined, and it connects directly to the Annex A controls referenced by the ISO/IEC 27001 standard.
Is ISO 27001 a legal requirement?
ISO 27001 is a voluntary certification standard, not a legal requirement, though some contracts, industries, or regulators may require it or an equivalent as a condition of doing business. Organizations pursue it to demonstrate security maturity to customers and partners rather than to satisfy a general legal mandate.
What are ISO 27001 requirements?
ISO 27001 requires an organization to establish an information security management system covering leadership commitment, risk assessment and treatment, measurable objectives, resource planning, and continual monitoring and improvement. Clause 6 specifically requires planned actions to address risks and opportunities, documented objectives with implementation plans, and planned handling of any changes to the management system, all backed by retained evidence.
How do I start implementing Clause 6 for certification?
Start by writing down a risk assessment methodology, then build a risk register, a risk treatment plan, and a Statement of Applicability from it before moving to objectives and change planning. A step-by-step risk assessment methodology guide and an implementation timeline reference can help sequence the work realistically.