Exploring the risks your organisation faces.
Contents
Planning Phase of ISO 27001 Implementation
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)
Define Risk Methodology
Overview
The first step in implementing the planning phase is establishing and documenting the risk assessment and treatment methodology.
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.
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.
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.
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?
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).
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.
ความคิดเห็น