How to make a transition from ISO 27001 2005 revision to 2013 revision
Published by Dejan  Kosutic

If you already implemented ISO 27001 2005 revision, you are probably thinking to yourself: “Oh no, now that the 2013 revision is published, we have to do it all over again.”

Well, this is not quite true – although the 2013 revision did bring some changes, those changes are not so drastic.


First of all, let’s see how much time you have. According to BSI, companies already certified against the ISO/IEC 27001 2005 revision will have a transition period of 2 years to “upgrade” their Information Security Management System (ISMS) to the new 2013 revision.

Since the 2013 revision was published on September 25, 2013, this means that companies will be able to upgrade until September 25, 2015. If your existing ISO 27001 certificate expires after September 25, 2015, then the certification bodies will check if you are compliant with the new revision during the regular surveillance visits; if your certificate expires before September 25, 2015, then you must upgrade by your next re-certification.

Transition steps

In my opinion, the easiest way to make the transition to the 2013 revision is by following these steps:

1) List all interested parties. You should list all your stakeholders (the persons and companies that can influence your information security or can be influenced by it), and their requirements. If you already listed all the statutory, regulatory and contractual requirements according to the old A.15.1.1 control, then you have already done half of your job.

2) Define interfaces in the ISMS scope. According to the 2013 revision, as part of your scope definition you need to identify the interfaces between the activities made by your organization and the activities that are performed by third parties.

3) Align ISMS objectives with the company’s strategy. 2013 requires you to determine whether the information security objectives are compatible with the strategic direction of the company.

4) Changes in the top-level policy. The top-level policy shouldn’t be called “ISMS policy” anymore, but rather “Information security policy.” It doesn’t have to include requirements like alignment with strategic risk management, nor the criteria for evaluation of risk.

5) Make changes to your risk assessment process. First, you need to identify risk owners for each of your risks; second, you don’t need to use the methodology based on identifying the assets, threats and vulnerabilities anymore, so if you wish you can identify your risks in some other (simpler) way; and lastly, you need to identify all the outsourced processes and decide on how to control them – this is best done during the risk assessment process. Accordingly, you need to change both your Risk assessment methodology, and your risk assessment results.

6) Identify status of controls in Statement of Applicability. This is a small change, but significant from an implementation point of view – in the SoA for each control you must indicate whether it has been implemented or not. Of course, you will need to change the structure of the controls in the SoA, as specified in step 11).

7) Obtain approval from risk owners. According to the new revision, you must ask the risk owners to approve your Risk treatment plan and accept your residual information security risks.

8) Plan the communication in a systematic way. You should determine a process for who will communicate to whom, what will be communicated and when. This includes both internal and external parties.

9) Decide what to do with your management procedures. The requirements for preventive actions do not exist anymore (preventive actions basically became a part of the risk assessment process), so you can decide whether to delete that procedure or not; there are no more requirements to keep the remaining management procedures (Document control, Internal audit, Corrective action) documented, so you if you wish you can delete those procedures as well, but you must maintain those 3 processes even though they are not documented.

10) Write new policies and procedures. If you haven’t already written the following documents, you will have to do so now because if you selected related controls as applicable, writing a document became mandatory: Secure system engineering principles (control A.14.2.5), Supplier security policy (control A.15.1.1), Incident management procedure (control A.16.1.5), and Business continuity procedures (control A.17.1.2).

11) Reorganize your controls. Annex A got mixed up quite a bit, but essentially most of the old controls remained, while only a handful of new ones appeared: A.6.1.5 Information security in project management, A.14.2.1 Secure development policy, A.14.2.5 Secure system engineering principles, A.14.2.6 Secure development environment, A.14.2.8 System security testing, A.16.1.4 Assessment of and decision on information security events, and A.17.2.1 Availability of information processing facilities.

12) Measurement and reporting. Requirements became much stricter in the 2013 revision: (1) the objectives should be set in a measurable way (if possible) in order to enable easier measurement (clause 6.2 b); (2) all activities to address risks and opportunities must be evaluated (6.1.1 e 2); (3) when planning how to achieve information security objectives, it must be defined how the results will be evaluated (6.2 j); (4) it must be determined what will be monitored and measured, when it will be done, who will do the measuring and who will evaluate the results (9.1); and (5) the responsibilities for the reporting of the ISMS performance must be clearly assigned (5.3 b).

And this is it – it might seem like a lot, but my guess is that within the 2-year period this won’t take more than couple of hours per month to achieve. Especially because I think these changes really do make sense – they will not only bring your ISMS closer to the needs of your business, but you will also have a system in place to show the usefulness of your information security.

Publications archive:


1. How to Deal With Insider Threats - by Dejan Kosutic
2. The Five greatest Mytths about ISO 27001 - by Deian Kosutic.
3. Planning Business Continuity - bu Nick Orchiston
4. Five security secrets your IT administrators don't want you to know
5. ISO 9001 Consulting - How to Benefit From Using an ISO 9001 Consultant - by Arthur Lewis
6. Disaster Recovery or Business Continuity? - by Paul E. Moor
7. ISO 20000: Choosing the Right Implementation Process - by Isabelle Perron
8. Similarities and Differences Between ISO 27001 and BS 25999-2 - by Dejan Kosutic
9. Managing Risk in Information Technology - by Alan Calder
10. Cloud computing and ISO 27001 / BS 25999 - by Dejan Kosutic
11. How to make a transition form ISO 27001 2005 revision to 2013 revision