The clause 4.1 of the standard requires identifying the internal & external issues of an organization. But the standard doesn’t tell how to perform the same. The simplest way is to list down all the internal & external issues. But this may not be exhaustive as there are likely chances that we miss some of them. Hence, it is always recommended to go by a structured approach. The two possible approaches from my viewpoint are;
- Mind maps: Create a mind map that depicts the various internal & external issues. For creating the mind map, you may discuss the internal & external issues with all the relevant stake holders, try to get as much possible information as you can. You may also refer the information diagram developed. While performing the activity keep the internal & external context in mind & try to relate the inputs to them. Once the mind map is developed, you can tabulate the same.
- SWOT & PESTLE Analysis : You can do a SWOT (Strength, Weakness, Opportunities & Threat) for finding the internal issues and PESTLE (Political , Economic, Social, Technological, Legal, Environmental) for finding the external issues
While identifying the internal & external issues, I recommend doing it at an organizational level considering the organization as a whole, although our focus is to find the issues that can affect the information security management system. Once the issues are identified you may pick those relevant to information security. This activity will also give inputs to your risk assessment as some of the issues identified will have to be mitigated during your risk assessment.
The best way to start with context of the organization is with an information flow diagram as explained in my previous blog. This will give a clear idea on the organization as a whole & its constituents. For better understanding, let us split the context into internal & external.
Internal – Internal context of the organization constitute the work culture, internal practices, organization structure, policies, processes, organizational values, objectives, resources, business strategies, expertise & capabilities etc.
External – External context includes factors that constitutes market competition , differentiators, supplier/vendor relationships, market trend, political situation where you operate, clients, environmental aspects, social & cultural aspects, legal & regulatory commitments, relationship, external stakeholders, requirements from all the interested parties, etc.
In brief, context of the organization includes all the internal & external factors that can have an influence on its existence & activities.
For ISO 27001, context of the organization is all the factors mentioned above that has an influence on achieving the objectives set forth by the information security management system of the organization.
You may also refer Clause 5.3 of ISO 31000:2009 for guidelines pertaining to internal & external context.
One of the key changes in 2013 version is that, the standard urges to understand the organization before defining the scope of the information security management system. This is referred to as Context of the organization in Clause 4. Perhaps this is the most relevant change that was required for implementing the standard from a real sense.But there are always confusions on how to tackle this requirement. The best approach from my viewpoint to start with is
- Initial Discussion: Have a discussion with a stakeholder(s) who has an overall idea on the entire organization. You should be very particular in selecting the person, a resource with a fair understanding of the processes and has an overall idea of the organization will be the best choice
- Information Flow Diagram: The next step is to create an Information Flow Diagram. The Flow Diagram should clearly depict the departments/entities along with the flow of the data.
The advantages of this approach are
- The entire organization is covered & it is very unlikely that we miss any functions/process/department
- There will be more clarity on the scope that needs to be defined
- This can also give inputs to the Risk Assessment
The first question that come to the mind while planning to upgrade the certification to 2013 version is on the Risk Assessment. It is true that the new version of the standard is transforming to a risk based approach, but at the same time there is a flexibility provided as well.
The 2013 version of the standard is not mentioning how to perform the risk assessment. The clause 6.1.2 of the standard mentions on the risk assessment to be performed & 6.1.3 mentions on the risk treatment. The major changes to the risk Assessment in ISO 27001:2013 compared to ISO 27001:2005 are;
- You can define a methodology for risk assessment based on your choice, whereas in 2005, you had a definite mandate on how to perform the Risk Assessment
- In 2013 you need to identify the risk owner for each of the risk, whereas in 2005 there is no mention on the risk owner
- 2013 require the risk owner to accept the residual risk and approve the treatment options, 2005 requires management to accept the residual risk.
- Unlike 2005 , 2013 does not explicitly mention on risk treatment options like avoiding, accepting ,transferring the risk and implementing controls from Annexue A. You have the flexibility & freedom to choose your own option for risk treatment.
- 2005 required risk assessment to be established as a part of the ISMS Policy (Ref: 4.2.1 b), however 2013 requires a risk assessment approach to be defined, but not at ISMS Policy level.
ISO27001:2013 gives the freedom & flexibility to choose our own methodology & approach for risk assessment. If you feel that the current methodology holds good, you can always continue with it by incorporating points 2 & 3 mentioned above.
There was a concern raised in one of the Audit that ‘Probability’ keyword should not be used in the Risk Assessment because it is a mathematical term and if we use the term, then the value should be between 0 & 1. To elaborate further, if we use the term ‘Threat Probability’ then the value has to be based on the mathematical term.
However, ISO 27005:2008 clearly states (Section 3. Term & Definitions, sub-section 3.5 .risk estimation – Note 2) that ‘likelihood’ is used instead of ‘probability’ in the standard. This gives a clear indication that for the standard, probability & likelihood is the same and we may not worry about the mathematical meaning.
So what about your risk assessment methodology?, are you using the word ‘Probability’ or ‘Likelihood’. In my viewpoint both can be used as the standard clearly says that they are the same, hence we should look at the English meaning rather than the mathematical meaning while using this in the risk assessment.