top of page

ISO 27001 PLANNING PHASE

Updated: Jul 29

Exploring the risks your organisation faces.

button





Contents

 


 

Planning Phase of ISO 27001 Implementation

ISO 27001 Implementation Process diagram

The Planning Phase focuses on identifying, assessing, and treating risks to ensure effective information security management within the Information Security Management System (ISMS) scope.


The principal inputs for this phase include the ISMS scope and the initial Statement of Applicability (SoA).


The main outputs are documented risk management methodologies, risk logs, risk treatment plans, and an updated SoA.


High-Level Summary of the Planning Phase

The Planning phase focuses on:

 

1.      Define Risk Methodology

2.      Identify Risks

3.      Analyse & Evaluate Risks

4.      Determine Risk Treatment Options

5.      Update Statement of Applicability (SoA)

  

Summary of planning phase (clause 6) of Iso 27001

 


 

 

Define Risk Methodology

Overview

The first step in implementing the planning phase is establishing and documenting the risk assessment and treatment methodology.

Define Risk Methodology Steps

The risk methodology sets the framework for identifying, analysing, and managing information security risks and ensures consistency and effectiveness in addressing potential threats to the organisation's information assets.


Risks must be evaluated and addressed, but you can't do everything. So, creating a methodology provides instructions on the organisation's risk appetite and how to handle the levels of risk.


I've provided a methodology below based on a common approach, but your organisation may already have something you should adopt as part of a broader risk management framework.

 

Implementation

Here's a document that should help you accelerate through this section. Adjust as necessary.



Establish Risk Assessment Criteria

Define the criteria for what constitutes an acceptable level of risk for the organisation.


This includes determining the threshold for risk that the organisation is willing to accept without additional controls.


So, for example, your organisation might say, 'I'm not going to sweat the small risks that have little or no chance of materialising or having any real impact, but we are going to focus on our top 10 risks as we perceive them'.


ALL identified risks need to be logged, but you may determine your risk 'appetite' as an organisation.


Develop Risk Process

Any risk process would generally include steps to;


  • Identify Risks: Create a process for identifying risks to information security. This includes recognising potential threats and vulnerabilities that could impact information confidentiality, integrity, and availability. Risks can come from many sources (internal and external to the organisation), so ensure these are identified.


  • Assess Risks: Develop a method for analysing identified risks to determine their potential impact and likelihood. This step involves assessing the consequences of risks materialising and the probability of their occurrence.


  • Prioritise Risks: You likely can't deal with everything, so you'll need a way to determine prioritisation. Some people use a combination of impact and urgency scores to determine priority.


Define Risk Treatment Options

Once you have identified your risks, what are your options for handling them? Define the options that people can choose from.


  • Risk Mitigation: Identify and document measures to reduce the likelihood or impact of risks. This could involve implementing additional controls or enhancing existing ones.


  • Risk Transfer: Consider transferring risks to third parties through insurance or outsourcing activities.


  • Risk Acceptance: Document the conditions under which the organisation will accept certain risks without further action.


  • Risk Avoidance: Determine scenarios where avoiding certain activities or processes can eliminate risks.

Risk Monitoring

Once a risk is treated, clear guidance must be provided on how progress is reported, when, and where.


Communicate and Train

Ensure the risk methodology is communicated to all relevant stakeholders, including management and staff involved in risk assessment and treatment activities.


Provide training to ensure everyone understands and can effectively apply the methodology.


 

Identify Risks

Overview

Now that you've defined your risk methodology, it's time to implement it and identify your organisation's risks regarding its information security.

identify risk steps

This step involves thoroughly assessing potential information security risks within the ISMS scope.

Identified risks are documented in a risk log, a foundational resource for subsequent risk analysis and treatment.



Spreadsheets are great, but I'd strongly recommend it if you can create something in a tool like SharePoint or Monday.com.


I've put several 'starter' risks in the log. It should be enough to get you going, but I recommend seriously considering the risks you uniquely face as an organisation.

 

Implementation

Here are some quick suggestions on how you can go about identifying your risks.


Conduct Risk Identification Workshops

  • Engage Stakeholders: Involve a diverse group of stakeholders, including IT staff, management, and key business unit representatives, to provide a comprehensive perspective on potential risks.

  • Facilitated Sessions: Facilitated sessions can be effective for brainstorming and identifying risks. Techniques such as SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) and brainstorming can be effective.


Develop Risk Identification Tools

  • Checklists and Questionnaires: Create checklists and questionnaires tailored to your organisation's context to identify risks systematically.

  • Interviews and Surveys: Conduct interviews and surveys with employees to uncover risks that might not be immediately apparent through other methods.


Asset-Based Risk Identification

  • Inventory of Assets: Utilise the asset inventory developed during the Initiation Phase to identify risks related to each asset. Consider risks to hardware, software, data, and personnel.

  • Threat Analysis: For each asset, identify potential threats such as cyber-attacks, physical theft, natural disasters, and human error.


Process-Based Risk Identification

  • Business Processes: Examine key business processes and workflows to identify risks that could impact their effectiveness. Consider the risks associated with operational disruptions, data breaches, and compliance failures.

  • Information Flow: Map out the flow of information within the organisation to identify points where data might be vulnerable to interception, loss, or corruption.


External and Internal Risk Factors

  • External Risks: Identify risks arising from external sources such as regulatory changes, market conditions, and supply chain dependencies. Explore current risks in your sector through technology groups or national cyber threats. They can offer excellent sources of emerging trends.

  • Internal Risks: Consider internal factors like employee behaviour, organisational changes, and technological dependencies that could pose risks to information security.


 


 

Analyse & Evaluate Risks

Overview

The third step in the Planning Phase of the ISO 27001 implementation process is to analyse and evaluate the identified risks.


analyse & evaluate risks steps

This step involves assessing each risk's potential impact and likelihood, comparing the results against predefined risk criteria, and prioritising the risks for treatment.


Proper analysis and evaluation are essential for making informed decisions about risk management and ensuring that the organisation focuses on the most critical threats.


The fact is, I bet you did it as a natural part of the step before as you catalogued the risks. However, make sure this is a consultative task with key stakeholders, like your ISG Steering Group, rather than something someone does locked in a room on their own.


Implementation


Risk Analysis & Scoring


  • Assess Potential Impact: Determine the potential consequences if a risk materialises. This includes considering the direct and indirect impacts on the organisation, such as financial losses, reputational damage, legal consequences, and operational disruptions.


  • Evaluate Likelihood: Assess the realistic likelihood of each identified risk occurring. This can be done using historical data, industry benchmarks, expert judgment, and statistical methods.


  • Combine Impact and Likelihood: Use the risk matrix or similar tool from your methodology to combine the assessments of impact and likelihood, resulting in a risk rating or score. This helps visualise the severity of each risk.


  • Compare Against Risk Criteria: Compare the analysed risks against the established risk criteria defined in the risk methodology. This involves determining whether the risks fall within acceptable levels or if they require further action.


  • Prioritise Risks: Prioritise the risks based on their severity, impact, and likelihood. High-priority risks pose the greatest threat to the organisation and require immediate attention.


  • Create a Risk Map (Optional): Create a risk map to visually represent the prioritisation of risks. It can be a helpful tool for communicating risk levels to stakeholders and for strategic planning.


risk heat map example

 

Update The Risk Register

Update the risk register with the results of the risk analysis and evaluation.


Each entry should include detailed information about the impact, likelihood, and overall risk rating.


Stakeholder Involvement & Approval

Ensure that relevant stakeholders, including risk owners and management, are involved in the risk analysis and evaluation. Their input and perspectives are crucial for accurate assessments and for gaining buy-in for risk treatment plans.


Then, the findings will be presented to senior management, and approval will be obtained for the risk ratings and prioritizations. Thereby ensuring that the organisation is aligned with the focus areas for risk management.


Continuous Monitoring


  • Regular Reviews: Establish a process for regularly reviewing and updating the risk analysis and evaluation. This ensures that the risk landscape is continuously monitored and any organisational or external environment changes are promptly addressed.


  • Adjustments: Make necessary adjustments to the risk assessments as new information becomes available or the organisation's context evolves.

 


 


 

Determine Risk Treatment Options

Overview

The fourth step in the Planning Phase of the ISO 27001 implementation process is to determine appropriate risk treatment options. What will we do with those pesky risks, and which ones don't warrant attention?

Determine risk treatment options steps

This step involves selecting and implementing the measures to mitigate, transfer, avoid, or accept the identified risks based on their evaluation. We capture this information in the Risk Treatment Plan(s) or RTP.


The goal is to reduce information security risks to an acceptable level in alignment with the organisation's risk appetite and compliance requirements.

 

Implementation

Determine Risk Treatment Options

The options you have here were outlined in the Risk Methodology earlier (mitigate, transfer, avoid, accept, etc).


Broadly define what your approach to each risk is going to be.


The Statement of Applicability (SoA), the list of ISO 27001 controls, will need reviewing. Risk treatments will be needed to meet some of the controls, which may require RTPs.


Develop Risk Treatment Plans

Once you know what your risk treatment direction is going to be, you'll need to create Risk Treatment Plans for each risk you are handling.


You can approach this in several ways;


1.      Create an overarching risk treatment plan for the ISMS as a whole.

2.      Create individual risk treatment plans for every risk.

3.      Have risk treatment plans for each risk over a certain level.


I tend to prefer the third option here, as I prefer to have robust treatment plans (like mini project plans) for each significant risk, and smaller ones might have an entry in the risk log saying, "Mike's got this – he's going to turn off this feature to stop any future risk".

 


Here are the key aspects that a risk treatment plan should capture


  • Detail Actions: For each selected treatment option, outline specific actions required to implement it. This includes defining the necessary resources, timelines, and responsible parties.


  • Define Controls: Identify and document the controls needed to manage the risk. Controls should be aligned with the ISO 27001 Annex A controls to ensure comprehensive coverage.


  • Allocate Responsibilities: Assign risk owners and action owners to ensure accountability. Clearly define who is responsible for implementing and monitoring each control.


 


 

Update Statement of Applicability (SoA)

Overview

The final step in the Planning Phase is to update the Statement of Applicability (SoA).


updating the statement of applicability step

This document is crucial as it lists the controls selected to mitigate the identified risks and justifies their inclusion or exclusion.


The whole process can be a little cyclical here, with you jumping between steps within the Planning Phase, but you'll need to make sure your risk treatments are reflected in the SoA where there are matching controls.



The SoA ensures that the organisation's information security controls are comprehensive and tailored to its specific risk environment.


It can be challenging with 93 controls in the SoA, but I've gone through the version here and made some recommendations on how you can respond to the controls. Hopefully, that'll kick-start your SoA completion, but it won't handle everything.


I'd recommend breaking it into small chunks and going through the SoA as a group with key stakeholders, looking at a control group at a time. For example, you might have a session focusing on People Controls with IT and HR.

 

Implementation


Review Identified Controls


  • Align with Annex A: Compare the controls determined during the risk treatment process with those listed in Annex A of the ISO 27001 standard (i.e. those listed in the SoA). Ensure that no necessary controls have been omitted and that all relevant controls are considered.


  • Select Appropriate Controls: Choose appropriate controls for mitigating the identified risks, including both technical and organisational measures.


Document Control Justifications


  • Include Justifications: For each control included in the SoA, provide a clear justification based on the risk assessment and treatment findings. This should explain why the control is necessary and how it addresses specific risks.


  • Exclude Controls with Rationale: If any controls from Annex A are excluded, document the rationale for their exclusion, ensuring transparency and providing evidence that the decision was based on a thorough risk assessment.


Update the SoA


  • Detailed Descriptions: Ensure that the SoA includes detailed descriptions of each control, including its objectives and how it will be implemented.


  • Status of Implementation: Indicate the current status of each control (e.g., implemented, in progress, planned) to provide a clear picture of the ISMS's progress.


Approval and Review


  • Senior Management Approval: Obtain approval from senior management for the updated SoA. This ensures that there is top-level support for the selected controls and that they align with the organisation's strategic objectives.


  • Regular Review: Establish a schedule for regular reviews and updates to the SoA. Make sure that it remains relevant and reflects any changes in the risk environment or organisational context.


Integration with Risk Management


  • Link to Risk Treatment Plans: Ensure the SoA is integrated with the risk treatment plans. This helps track the implementation of controls and their effectiveness in mitigating risks.


  • Continuous Improvement: Use feedback from the implementation and monitoring phases to improve the SoA continually. Adjust controls as necessary based on changes in the risk environment or the effectiveness of current controls.


 

 

Summary of Clause 6 Compliance in ISO 27001:2022

The Planning stage of our implementation plan is targeted on Clause 6 of ISO 27001:2022, which focuses on planning actions to address risks and opportunities, establishing information security objectives, and planning changes to the ISMS.


The following sections detail how each requirement of Clause 6 is met through the activities conducted in the Planning Phase.


Actions to Address Risks and Opportunities (6.1)

General (6.1.1)


  • Understanding the Context (4.1) and Needs (4.2): We ensure that the issues and requirements identified in Clauses 4.1 and 4.2 are considered to determine the risks and opportunities.


  • Risk and Opportunity Determination: We identify and assess the risks and opportunities that can affect the ISMS's performance, aiming to achieve its intended outcomes, prevent undesired effects, and achieve continual improvement.


Information Security Risk Assessment (6.1.2)


  • Risk Criteria Establishment: We define and maintain risk criteria, including risk acceptance criteria and criteria for performing information security risk assessments.


  • Consistent Risk Assessments: We ensure that repeated assessments produce consistent, valid, and comparable results.


  • Risk Identification and Analysis: We identify information security risks that could impact the confidentiality, integrity, and availability of information within the ISMS scope and analyse the potential consequences and realistic likelihood of these risks.


  • Risk Evaluation: We evaluate the identified risks against our established criteria and prioritise them for treatment.


Information Security Risk Treatment (6.1.3)


  • Treatment Options: We select appropriate risk treatment options based on the assessment results and determine the necessary controls to implement these options.


  • Control Comparison with Annex A: We compare our controls with those listed in Annex A to ensure no necessary controls are omitted, formulating a Statement of Applicability that includes necessary controls, their justification, and implementation status.


  • Risk Treatment Plan: We develop a risk treatment plan, obtaining approval from risk owners and ensuring acceptance of residual risks.


Information Security Objectives and Planning to Achieve Them (6.2)


  • Objective Setting: We establish information security objectives at relevant functions and levels, ensuring they are consistent with the information security policy, measurable, and take into account applicable requirements and risk assessment results.


  • Monitoring and Communication: We ensure that these objectives are monitored, communicated, and updated appropriately, maintaining documented information.


  • Action Planning: We determine what actions will be done, the resources required, responsible persons, completion timelines, and evaluation methods to achieve the information security objectives.


Planning of Changes (6.3)


  • Planned Changes: We ensure that any changes to the ISMS are planned and carried out in a structured manner, considering their impact on the ISMS's performance and objectives.

 

 

 

 

 


 

 


Important Notice

This document is provided for personal use only. Commercial or consultative use requires a licence. For detailed terms of use, please visit https://www.iseoblue.com/terms.

 

Comments


image.png

Play Crossy Chicken

Never miss another article.

About the author

Alan Parker is an IT consultant and project manager who specialises in IT governance, process implementation, and project delivery. With over 30 years of experience in the industry, Alan believes that simplifying complex challenges and avoiding pitfalls are key to successful IT management. He has led various IT teams and projects across multiple organisations, continually honing his expertise in ITIL and PRINCE2 methodologies. Alan holds a degree in Information Systems and has been recognised for his ability to deliver reliable and effective IT solutions. He lives in Berkshire, UK, with his family.

bottom of page