This post is in continuation to my previous post about the differences between ISO 27001:2005 and ISO 27001:2013. You check it out here. My quick and dirty analysis of the differences can be found here. ’Tis all a matter of context. One of the most prominent differences between the old standard (ISO 27001:2005) and the new standard (ISO 27001:2013) is the presence of ‘context’ in the new one. This context forces the implementor to focus on the question ‘Why are we doing this?’. In the old standard, one could not question the reason for doing an ISMS. We had to take it as a matter of faith and go straight to the task of defining the scope and the boundaries of the ISMS. The new standard, however, allows you to question yourself - Why do you want an ISMS? What are the issues that an ISMS can resolve? If you already have an ISMS that you have implemented with the old standard, you will have to take a step back and think this through. Remember that the context determines the scope, not the other way around. To implement this new aspect, you will have to take into consideration all the interested parties for the ISMS. It could be your customers, your vendors, your employees, management, board of directors, anyone who has some interest in the information security of your organisation. Different interested parties would have different requirements - customers may want to protect the privacy of their data, regulators may want data to be available for a fixed number of years, etc. Once you know the requirements that your ISMS needs to fulfil, you can identify the scope of the ISMS based on these requirements. The context of the organisation helps define the scope of the ISMS. For an organisation that already has a documented scope from the old standard, what are the changes that need to be done? This is not an easy question to answer. In theory, everything you do will be based on this context. If your context is different from your currently implemented ISMS, your entire scope could change. However, it will not make a difference to an organisation that has already implemented this with a bit of thought on their requirements. It will, however, make a difference to organisations that have randomly defined the scope of the ISMS. You will be surprised at the number of organisations that have done that! The solution can be as easy as adding a section called ‘Context of the Organisation’ to your scope document or it could be as complex as redefining the entire scope of the ISMS, including new areas and excluding old ones. Do you want a recipe to define context in easy steps? Here you go:

1. Prepare an exhaustive list of all ‘interested’ parties. These could be internal to your organisation or external. Make sure you list every one of them.
2. Identify what these interested parties expect from your organisation in terms of information security. Write down the requirements next to the interested parties.
3. Send an email to the top management about this and marinate for a week.
4. Meanwhile, take a blank piece of paper and make a list of all issues that you think your organisation faces. This is best done in a gathering of the senior team to allow everyone’s creative juices to flow.
5. By now, the replies to your mails would have cooked themselves. Take all inputs and identify which areas of the organisation require to have additional infosec controls to handle all the expectations of interested parties, as well as deal with identified issues.
6. Serve this as a document along with the scope details on the side.
7. The same document can be used as a base for preparing your next recipe - your infosec objectives - but that recipe is for another day.