ISO/IEC 27001 Clause 6: Planning (Guide)
ISO/IEC 27001 Clause 6 is the “Planning” section of the standard. It covers how an organization plans its Information Security Management System (ISMS) by addressing security risks and setting objectives.
Navigate
ISO/IEC 27001
Templates & Tools
The Importance of Clause 6
Clause 6 focuses on essential ISMS planning activities – identifying and assessing information security risks, implementing measures to manage those risks, and establishing information security objectives. In this phase, organizations decide how to address identified risks and also consider opportunities to improve security. Effective planning ensures the ISMS can achieve its intended outcomes, prevent or reduce security incidents, and drive continual improvement.
Clause 6 is divided into three main sub-clauses:
- 6.1 – Actions to Address Risks and Opportunities: Plan how to manage information security risks and opportunities (primarily through risk assessment and treatment).
- 6.2 – Information Security Objectives and Planning to Achieve Them: Set measurable security objectives and plan the steps and resources to reach them.
- 6.3 – Planning of Changes: Ensure any changes to the ISMS are carried out in a controlled, planned manner.
Below is a breakdown of each sub-clause with guidance on what is required and how to implement it.
Clause 6.1 – Actions to Address Risks and Opportunities
Clause 6.1 is all about risk management planning. Its full title, “Actions to address risks and opportunities,” means your organization must identify what could go wrong (risks) and also consider what could improve security (opportunities). The goal is to proactively manage factors that might affect the ISMS, in line with the organization’s context and stakeholder requirements. This clause is further broken down into three parts: 6.1.1 (General), 6.1.2 (Risk Assessment), and 6.1.3 (Risk Treatment).
6.1.1 General
Clause 6.1.1 lays the groundwork for systematically addressing risks and opportunities. It requires the organization to consider its context (see Clause 4.1) and the needs of interested parties (see Clause 4.2) when determining which risks or opportunities need attention. In practice, this means using the outputs of your context analysis and stakeholder requirements to identify relevant security risks and beneficial opportunities. The aim is to ensure:
- ISMS Outcomes are Achieved: The ISMS is able to meet its intended goals and protect information as expected.
- Undesired Effects are Prevented or Reduced: Security incidents and negative impacts are minimized.
- Continual Improvement: The ISMS can continuously improve and adapt to changing threats and business needs.
To meet 6.1.1, you must plan how you will manage these risks/opportunities. This means defining actions to handle identified risks and integrating those actions into your ISMS processes. You should also determine how you will evaluate the effectiveness of these actions over time. In practice, this involves documenting a risk management procedure (or methodology) that covers identification, analysis, evaluation, and treatment of risks, and then demonstrating that this process works in operation (through records of risk assessments, treatment plans, and monitoring results).
ISO 27001’s approach to risk is aligned with ISO 31000’s risk management principles (per Note 4 of Clause 6.1.3). Following a Plan-Do-Check-Act cycle for risk (plan how to identify/treat, implement controls, monitor risks, review and update) will ensure you meet the intent of Clause 6.1.1.
6.1.2 Information Security Risk Assessment
Clause 6.1.2 requires your organization to establish a formal information security risk assessment process. In other words, you need a defined methodology to identify and evaluate risks in a consistent, repeatable way. Key expectations include:
- Set Risk Criteria: Define your risk assessment criteria, including what is an acceptable level of risk (risk acceptance criteria) and how you will measure risk (likelihood, impact scales, etc.). These criteria ensure everyone assesses risk on the same scale and helps produce “consistent, valid and comparable results” across assessments. For example, you might use a 5×5 matrix for likelihood and impact with a predetermined score above which risks require treatment.
- Identify Risks: Apply the risk assessment process to identify risks to the confidentiality, integrity, and availability (CIA) of information within your ISMS scope. This typically involves identifying your information assets or processes, then determining potential threats and vulnerabilities that could affect them. Risk owners should be identified for each risk – these are individuals responsible for that risk and ideally capable of deciding how to manage it. For instance, a CTO might be the risk owner for risks related to server outages.
- Analyze Risks: For each identified risk, assess the potential consequences (impact) if it materializes and the realistic likelihood of occurrence. Use your defined scales to rate these factors, and then determine an overall risk level (often calculated as Impact × Likelihood). This analysis should be systematic so that two different assessors would get similar results for the same scenario.
- Evaluate and Prioritize: Compare the assessed risk levels against your acceptance criteria to decide which risks are acceptable and which require treatment. Clause 6.1.2 expects you to prioritize risks for risk treatment based on this evaluation. The output of risk evaluation is typically a ranked risk register or list of risks, categorized by severity (e.g., high, medium, low) indicating which need addressing first.
All steps and results of the risk assessment should be documented and retained. This means keeping evidence such as risk assessment reports, filled-out risk matrices or registers, and any tools or questionnaires used. Auditors will look for documentation proving you did a thorough assessment and that it covers all in-scope assets and information. Maintaining a risk register not only demonstrates compliance with 6.1.2, but also serves as a living tool for tracking your organization’s threat landscape over time.
Defining a robust risk assessment methodology can be challenging. We offer templates and tools (like our ISO 27001 Risk Analysis Template) to guide you through identifying assets, threats, and vulnerabilities and to ensure consistent scoring of risks. Our experts (e.g. Virtual CISO services) can help establish risk criteria tailored to your business and train your team to perform repeatable risk assessments, so you meet Clause 6.1.2 requirements confidently.
6.1.3 Information Security Risk Treatment
Once risks are assessed, Clause 6.1.3 mandates an information security risk treatment process. Here, the organization decides how to handle each unacceptable risk. The risk treatment process in ISO 27001 can be summarized in several steps:
- Select Treatment Options: For each risk requiring action, choose an appropriate risk treatment option. Common options (aligned with ISO 31000 terminology) include:
- Risk mitigation (reduce) – Implement controls or other measures to reduce the risk likelihood or impact to an acceptable level. This is the most typical response (often by applying security controls from ISO 27001’s Annex A or other frameworks).
- Risk avoidance (terminate) – Avoid the risk by stopping the activity that causes it. For example, if a certain service is too risky, you might discontinue offering that service.
- Risk transfer (share) – Transfer the risk to a third party. This could involve insurance or outsourcing. For instance, you might move data hosting to a cloud provider that can manage certain security risks, or insure against cyber incidents.
- Risk acceptance (retain) – Accept the risk without further action, usually when the risk level is within your tolerance or when treatment is not cost-effective. Accepted risks must be approved by management/risk owners and revisited periodically. (Note: ISO 27001 expects that residual risks – those remaining after treatment – are explicitly accepted by risk owners.)
ISO 27001 expects you to justify your chosen option for each risk. Many risks will be mitigated by applying security controls. Clause 6.1.3 specifically notes that you should identify all controls necessary to implement your chosen treatments. You have flexibility here – you can design your own controls or adopt controls from any source (not just Annex A) as needed. That said, Annex A of ISO 27001 provides a comprehensive list of best-practice controls, and auditors will typically expect to see a mapping of your risks to Annex A controls.
- Compare with Annex A: ISO 27001:2022 emphasizes that Annex A is a reference list of possible controls (the 2022 revision clarifies it’s not exhaustive). After selecting controls in step above, you must compare those controls against Annex A to ensure you haven’t missed any important control. Essentially, this step is a sanity check to confirm no necessary controls are overlooked. If Annex A lists a control that you haven’t implemented, you should be sure that the risk it addresses is either irrelevant or covered by an equivalent measure in your ISMS.
- Produce the Statement of Applicability (SoA): The SoA is a required document that summarizes your risk treatment decisions. For each control in Annex A (and any additional controls you use), the SoA must state whether it is applicable to your ISMS and if so, whether it’s implemented or not, along with a justification. For any Annex A controls you exclude, you must justify the exclusion (e.g., “Control 6.7 – Remote working – is not applicable because our organization does not allow teleworking”). The SoA essentially captures all controls deemed necessary and why. Auditors treat the SoA as a key document linking your identified risks to the controls you have in place; it shows you’ve systematically considered each control.
- Formulate a Risk Treatment Plan: In addition to the SoA (which is more of a status list), Clause 6.1.3 requires an actual risk treatment plan. This is typically a detailed action plan describing how and when each chosen control will be implemented, who is responsible, and any resource or budget needs. Think of it as a project plan for risk mitigation. For example, if a risk was “unauthorized access to sensitive data,” the treatment plan might include implementing an IAM solution (control from Annex A), with milestones and an owner for that task. The risk treatment plan ensures that your risk responses are not just decided, but actually carried out in a timely manner.
- Approval of Residual Risks: Finally, Clause 6.1.3 says you must obtain risk owners’ approval of the risk treatment plan and their acceptance of any residual risks. This means after implementing controls, if some risk remains, the designated risk owner (often a manager or exec responsible for that area) formally agrees that the remaining risk is at an acceptable level. It’s a good governance practice to have management sign-off on the fact that “we’re going to live with this level of risk,” ensuring accountability.
All the above steps should be backed by documented information. You’ll need to keep records such as the completed risk treatment plan, evidence of control implementation, and the approved Statement of Applicability. These demonstrate compliance and will be reviewed in your ISO 27001 certification audit.
Implementing risk treatment can be complex – from choosing the right controls to developing the SoA. CyberZoni’s team can assist in mapping your risks to suitable controls (drawing from frameworks like ISO 27001 Annex A, NIST, etc.), and help prepare the Statement of Applicability with proper justifications. We also offer Control Design and Implementation services to actually put those controls into action. Our experts ensure that risk owners are engaged throughout, so that treatment plans are realistic and residual risks are acknowledged by the right decision-makers.
Clause 6.2 – Information Security Objectives and Planning to Achieve Them
Beyond risk management, ISO 27001 Clause 6.2 focuses on establishing information security objectives and plans. This is about translating your organization’s security aspirations into concrete, measurable goals. Information security objectives must be set at relevant functions and levels (e.g. company-wide objectives, departmental goals, etc.), and they should meet several criteria:
- Aligned with Policy and Business Goals: Objectives should be consistent with your Information Security Policy (from Clause 5.2) and support broader business objectives.
Essentially, ask: How do these security goals help protect what’s important to the business? For example, if your business goal is to build customer trust, a security objective might be “Achieve and maintain ISO 27001 certification” or “Zero critical vulnerabilities in production systems.” Aligning with business context ensures security isn’t a silo but part of strategic goals. - Consider Requirements and Risks: When defining objectives, factor in applicable information security requirements (e.g. legal/regulatory requirements, customer security requirements) as well as the results of your risk assessment and treatment.
For instance, if a risk assessment found phishing is a top risk, an objective could be “Implement an email phishing defense program and reduce phishing click rates to under 5%.” This ties objectives directly to risk findings and compliance needs. - Measurable (if practicable): Objectives should be stated in a way that you can measure progress. Vague aims like “improve security awareness” should be turned into something quantifiable, such as “conduct quarterly security training and achieve 100% staff completion.” Measurable targets (using numbers, percentages, time frames, etc.) enable you to track if the objective is met. ISO 27001:2022 puts even stronger emphasis on objectives being measurable and documented.
- Achievable and Realistic: Ensure objectives are attainable given your resources and risk appetite. Overly ambitious goals (e.g. “eliminate all security incidents”) can set you up for failure. Instead, set realistic targets (perhaps “reduce average incident response time to <24 hours” or “limit incidents to <5 minor incidents per quarter”). Objectives should also align with what leadership is willing to support (risk tolerance).
- Monitored and Communicated: The standard explicitly requires that you monitor progress on your security objectives and communicate relevant objectives to persons involved. Monitoring might be done via periodic reports or dashboards showing key performance indicators (KPIs) for each objective. Communication ensures that teams know what the security goals are (e.g. an objective to “achieve 100% encryption of laptops by Q4” should be communicated to IT staff who manage devices). Clause 6.2 in the 2022 update added that objectives must be kept updated as appropriate and be available as documented information – in practice, maintain an “ISMS Objectives” document or spreadsheet and revise it when objectives change or are achieved.
Once objectives are defined, planning to achieve them is equally important. ISO 27001 requires a clear plan for each objective, covering: (6.2.h) what will be done, (6.2.i) what resources will be required, (6.2.j) who will be responsible, (6.2.k) when it will be completed, and (6.2.l) how results will be evaluated. In other words, treat each security objective like a mini-project with assigned owners, deadlines, and success metrics. For example, if the objective is to “implement a Security Information and Event Management (SIEM) system by end of Q3,” the plan might specify: what steps to take (tool selection, deployment, tuning), resources needed (budget, personnel, training), responsible owner (e.g. IT Security Manager), timeline milestones, and how to measure success (e.g. SIEM coverage of critical systems, reduction in incident detection time).
A useful framework for setting objectives is the SMART criteria – Specific, Measurable, Achievable, Relevant, Time-bound. ISO 27001 doesn’t mandate SMART explicitly, but auditors will expect that your objectives aren’t vague. They will check that you have documentation of objectives and plans, and that you review them regularly. In fact, part of knowing whether your ISMS is effective is seeing if you meet your security objectives; Clause 6.2 essentially asks, “How do you know if your ISMS is working as intended?” – the answer lies in tracking these objectives.
Setting and achieving security objectives can be facilitated by outside expertise. Our Virtual CISO service can work with your leadership to define meaningful ISMS objectives that align with your business and risk profile. We help establish metrics and monitoring processes (for instance, dashboards for security KPIs) to ensure your objectives are measured and met. Additionally, we can assist in creating the Objectives Plan – documenting the “who, what, when, how” for each goal – and integrating those objectives into your regular management reviews. By treating security objectives like business objectives, CyberZoni ensures your ISMS goals drive real improvements and satisfy Clause 6.2’s requirements.
Clause 6.3 – Planning of Changes
ISO 27001:2022 Clause 6.3 requires that when you make changes to the ISMS, those changes are carried out in a planned manner. Your ISMS shouldn’t be subject to ad-hoc, uncontrolled changes; you need to think through adjustments before implementing them. This concept parallels change management practices in IT or quality management systems – any significant modifications should be analyzed for impact and executed with oversight.
What does “planning of changes” involve? It means that for any planned change to the ISMS, you should consider aspects like:
- Purpose of the change: Why is this change needed? (e.g., to address a new risk, to improve efficiency, to comply with updated regulations).
- Potential impact on security: Assess how the change could affect your ISMS objectives, risk profile, or controls. Could it introduce new vulnerabilities or gaps? Perform a mini risk assessment for the change if appropriate. For example, if expanding scope to include a new office, evaluate any new risks that office brings.
- Resource requirements: Determine what resources (people, budget, technology) are needed for the change. If you’re implementing a new policy or tool, ensure you have the staff and funds allocated.
- Scheduling and coordination: Plan when and how the change will be implemented. Coordinate so that changes cause minimal disruption. For instance, schedule major security system upgrades during a low-usage period.
- Approvals and documentation: Just as with any change control process, get appropriate approval from management for the change, and document the change plan. Depending on the size of your organization and change, this could be as simple as an email sign-off or as formal as a Change Request form and Change Advisory Board review. The level of rigor should be proportionate to the change’s complexity and risk. Minor tweaks (like correcting a typo in a policy) won’t need heavy process, whereas a major ISMS overhaul (like adopting a new framework or merging ISMS with another company) definitely will.
Some examples of ISMS changes that warrant planning include: expanding the ISMS scope to new departments or locations, adopting new security technologies or services (e.g., moving to a cloud provider), updating critical policies or procedures, organizational changes like mergers or outsourcing that affect the ISMS, or even transitioning from ISO 27001:2013 to ISO 27001:2022. In all these cases, Clause 6.3 says: don’t do it on the fly. Have a plan, assess risks of the change, and implement in a controlled way.
You might integrate Clause 6.3 by maintaining an ISMS Change Log or Procedure. Whenever a change is needed, document the analysis (reason and impact), the plan (steps and timeline), and after execution, record what was done and any post-change review. This overlaps with Clause 8.1 (Operational Planning and Control), which already implied controlling changes, but Clause 6.3 makes it an explicit requirement. Think of it as reinforcing the “Plan” aspect – just as you plan risk management and objectives, plan the evolution of your ISMS itself.
Managing ISMS changes can be daunting, especially during growth or when new regulations emerge. CyberZoni can assist by developing a Change Management process tailored to your ISMS. Our consultants help perform impact assessments for proposed changes, ensure all stakeholder concerns are addressed, and incorporate the changes smoothly into your ISMS documentation. We provide guidance so that changes remain aligned with ISO 27001 requirements and don’t inadvertently create security gaps.
Conclusion and Key Takeaways
Clause 6 “Planning” is a critical part of ISO 27001, essentially forming the “Plan” stage of the Plan-Do-Check-Act cycle for your ISMS. To summarize:
- Risk Management (6.1): Identify and assess security risks in a structured way, then treat them with appropriate controls. Maintain records like risk assessment reports, risk treatment plans, and a Statement of Applicability as evidence. This ensures you address what could go wrong before it happens.
- Security Objectives (6.2): Set clear, measurable security goals that support your business and policy, and make plans to achieve them. Review these objectives regularly (e.g., in management reviews under Clause 9) and adjust as needed. Objectives are your gauge for ISMS performance – they tell you if your security efforts are effective.
- Controlled Changes (6.3): Treat changes to the ISMS with due planning. Don’t let significant updates occur without assessment and approval. This keeps your ISMS stable and reliable even as it evolves.
All the planning outputs (risk registers, SoA, objectives plans, change logs, etc.) should be maintained as documented information for audit purposes. Clause 6 is inherently mandatory – an ISMS cannot be certified if you skip risk assessments or have no security objectives. Auditors will scrutinize how well you’ve planned your ISMS, so give Clause 6 sufficient attention.