So, the new ISO 27001 is here. After 8  years, the entire ISMS approach has been revamped. The newer version of ISO 27001 aka. ISO 27001:2013 is a much slimmer document. There is no introduction to the process approach and - surprise surprise, no diagram of the Deming’s cycle. No beating around the bush for the new standard. It gets straight to the point. I guess that it assumes the reader is not a novice learning the ropes of infosec, but a professional who knows his threats from his vulnerabilities. The never ending ‘Terms and Definitions’ section is gone. Instead, there is a terse reference to ISO 27000 - almost like saying “If you kids want definitions, read the standard that is meant to provide definitions, do not look here.” If you want a detailed analysis of the differences between the 27001:2013 and the 27001:2005, (sort of like the analysis that I did for BS25999 vs. ISO 22301) you will need to wait a bit longer. However,  I will try to answer the question that will be at the top of every ISMS implementer’s mind. What do I need to add/ change in my current ISMS to be compliant to 27001:2013. Here is a quick and dirty analysis from me: 1. Scope Document - Don’t worry. Your old scope document is still good enough. What you need to add, however, is a section that ‘establishes the context’ - a trend that every ISO standard insists on bringing in now. What do we mean by establishing the context? Basically two things - a) what are the issues that the organisation faces that inhibits the achievement of the ISMS goals, and b) all relevant stakeholders (interested parties) and their requirements. You need to add these to the scope document and you are good to go. 2. SOA - A no brainer. Your SOA will change to reflect the 14 domains and 114 controls. If you need a detailed analysis of the differences here, please write to me. 3. Information Security Objectives - This is probably one of the biggest changes that 27001:2013 has over 27001:2005. Based on your risk assessment, you are expected to document your information security objectives. My guess again is that a summary of the risks that you plan to action upon should be the basis for developing your security objectives. Not only do you need to document these objectives, you will need to also document how you plan to achieve them - who will do it? What will they do? By when? How will you know it is done, etc. If you are used to having a formal implementation plan for your ISMS, you can derive a lot of content for your ‘Information Security Objectives’ document from here. 4. Competence of personnel working on the ISMS - You need to now explicitly keep a record of the competence of the person working your ISMS. A good point to get those training budgets approved and attending that training that you always wanted to :). Records of training are evidence in audit of the competency of the person working on the ISMS. 5. Communication Plan - You may have addressed some portion of this as a part of your incident response or your BCMS, but the key point is that you need to be able to prove that have determined the need for communication under various scenarios - the classic who, what, when, where, whom, why and how. Though the standard does not specify that you need to have a documented process, I recommend having a ‘communication plan’ separated out and ready. This is a very quick analysis of the new standard. A more detailed comparison to come in later.