# Clause 6: Planning > When planning for the ISMS, the organisation shall consider the issues referred to in 4.1 (Context) and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to \[ensure intended outcomes, prevent undesirable effects, and keep improving\]... Section 6 concerns itself with the preparation and execution of processes that ensure the ISMS can - achieve intended outcomes, whilst - preventing or reducing undesired effects, and - achieving continual improvement (6.1.1). It alerts of the need to conduct risk assessments (6.1.2) and apply risk treatments (6.1.3), alongside establishing consistent, documented IS objectives and goals (6.2) that are change resilient (6.3). **Risk as opportunity** - There are all sorts of risk, and all sorts of ways to treat risk. I like to start by categorising the risk as an opportunity or an inevitability. Some risks (such as the risky nature of a certain industry) are just part and parcel of working in given industry, and so are actioned and treated in a way so as to minimise their impact if they eventuate. Other risks (such as the incompetence of employees) are very clearly opportunities to improve our organisation, and should be energetically engaged with as such. ### Risk Assessments (6.1.2) > Set Risk Criteria > Understanding Impact > Who owns risk? > Prioritising risk. an Information Security Risk assessment process requires a risk acceptance criteria, and a criteria (or methodology) for performing IS risk audits. Risk acceptance criteria is our risk appetite as an org. Often, people see the '*impact x likelihood*' equation as a common sense approach to standardising language as relating to discussing risk, but look at the standard and you'll see that this exact equation is shared in 6.1.2d. refer to departmental leads and subject matter experts to determine risk impact, severity and likelihood, but temper that against a consistency of the risk acceptance criteria This methodology must be able to produce consistent, valid and comparable results - and is used to identify risks to the CIA triad within the scope of the ISMS. >💡 **Information Security risks must always have an owner.** A good litmus test for a good risk criteria is one that directly or indirectly assesses the significance of a risk based on the impact to Confidentiality, Integrity, and Availability (Within the scope of the ISMS). 6.1.2d Introduces the need to assess the likelihood and consequences of risks materialising to determine the level of risk. Once these risks are analysed they can be prioritised for risk treatment. ***Examples of risk?*** - Unclear processes and responsibilities - Poor awareness among employees - Poor engagement from management - Poor risk management - Poor awareness of Risks - Poor management of the ISMS documentation and processes >💡 **Risks are analysed by comparing the output of 6.1.2d with the risk criteria established in 6.1.2a** (The aforementioned risk acceptance criteria!). ### Risk Treatment (6.1.3) >Analyse assessment > Produce [[Statement of Applicability]] > Justify and apply controls The creation of an Information Security Risk Treatment process analyses risk assessment results to select risk treatment options (6.1.3ab) that utilise controls (6.1.3b). These controls should be included in a Statement of Applicability that contains justifications for the inclusion of each control, and justification for those controls excluded from use in the ISMS that are present in Annex A (6.1.3d). justification of inclusion of all controls helps demonstrate maturation of controls over time and CPD as per later clauses. it also provides provenance of controls to help quantify and assess risk when change inevitably comes or you later remove dependancies for risk treatment etc. risk treatment plan (RTP) → formulate RTP → obtain risk owners approval → document implementation of risk treatment process. treatment is not binary, and controls will need to mature. this will be reflected in the SOA - it is possible to have controls to be planned to be implemented and still achieve certification, so it is more than accepted that you can start on the biggies and work your way down over time (It is even possible to set a scope for your ISMS that focuses only on business critical risks and expands in 'scope' - where expansion is the inclusion of Information Security risks with lower risk scores over time). >💡 **Organisationally determined controls should be considered in comparison with Annex A to ensure that all necessary controls are in place (6.1.3c),** and as this Annex is not an exhaustive list of options, it is possible to exclude irrelevant controls from the Scope of Applicability, and include org designed controls. This process will help formulate a IS Risk Treatment plan with the approval from relevant risk owners, alongside residual risks after this process. ### Information Security Objectives (6.2) > Awareness of results > Create objectives > Plan to meet them The organisation needs to establish Information Security objectives that are consistent with the Information Security policy, and account for existing requirements and results that stem from risk assessment and treatment (6.2ac). These objectives should be measurable, monitored, and communicated, updated frequently, and documented (6.2bdefg). ***How can Information Security objectives be expressed?*** - Numerical values with limits - Targets for measurements of ISMS performance - Targets for effectiveness of the ISMS - Compliance levels with 27001 - Compliance with ISMS procedures - The need to complete actions and plans - Risk criteria to be met Once these objectives are set they can be planned for by determining things such as what resources are needed, who is responsible for enactment, and when it will be completed (6.2hijk). Interestingly, results do **need** to be evaluated (6.2l). ### Planning of Changes (6.3) When the organisation determines the need for changes to the information security management system, the changes need to be carried out in a planned manner.