ISO 27001/ISO 22301 documents, presentation decks and implementation guidelines


Have a question on ISO 27001 or ISO 22301?

Ask an Expert

Free eBook

Free eBook 9 Steps to Cybersecurity
Becoming Resilient: The Definitive Guide to ISO 22301 Implementation
Sign up for our free Newsletter and as bonus you'll receive my tips on how to launch an information security and business continuity project.



ISO 27001 benefits: How to obtain management support


April 23, 2014


How to make a transition from ISO 27001 2005 revision to 2013 revision

'By 'Dejan Kosutic on October 14, 2013

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. For an overview of changes, see this infographic: New ISO 27001 2013 revision – What has changed?


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. Read more here: Main changes in new ISO 27002 2013.

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.

To learn how to perform each of these 12 steps download the free white paper Twelve-step transition process from ISO 27001 2005 revision to 2013 revision.

  • DvG

    Very nice post !
    2 questions :

    - isn’t the SOA renewed every 3 years (along with certificate) ? So how does this combine with the requirement to register ‘control status’ in it ? Because, this status may change after 2 months from not-implemented to implemented.

    - does every control, or group of controls, need to be measured in 27001:2013 ? Or can a company freely select some top level objectives and only measure these ?

  • Dejan Kosutic

    In 2005 revision SoA needed to be changed any time something changed with particular control – this was normally done every few months; as you noted, with the 2013 revision it will be even more often.

    2013 gives you the flexibility not to measure each and every control – you can measure a group of controls, or a security process, or some top level objectives. But you definitely need to measure the effectiveness of your ISMS much more thoroughly because requirements for measurement in 2013 revision are much more precise than in 2005 revision.

  • DvG

    Thanks.So you mean you can choose more freely WHAT and how much you measure (can be effectiveness of control(s) or ISMS), but the measurements have to be defined and documented much better?

    I’m thinking of setting maybe 6 to 8 objectives in the info sec. policy that relate to the company’s strategic goal(s) (and choose them wisely .. so they cover a broad perspective of the controls). Then setup measurement for them by using our ‘KPI definition templates’ (when, what, who, etc etc) … and of course check those templates against the 2013 requirements.

    Sounds wise ?

  • Dejan Kosutic

    I like your summary – 2013 gives you more freedom on what you will measure, but requires you to be more thorough in doing that.

    Your approach with 6 to 8 objectives for the whole ISMS will probably be acceptable for smaller company (e.g. 50 employees), but for mid-size or larger companies, I guess you should go with more objectives – not only for the top level, but also at the process or control level.

  • Ajay Nikumb

    Thanks Dejan, for valuable input

  • Aditya Agung

    thank you for the inspiring steps Dejan, but I want to ask about point 9 ( 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.) how can we maintain if the document aren,t documented?? with what proof we must maintain?

  • Dejan Kosutic

    Aditya, the proofs you need to maintain for internal audit process are Internal audit programs and Internal audit reports, for corrective action process are the records of corrective actions, and for document control process the proof are the records on how do you approve documents, how do you maintain them, how do you distribute them, etc.

    The point is, you usually have a lots of processes in your company that function normally even though they are not documented, so you can treat these 3 processes in the same way.

  • Stefano

    Thank you for all the info you share here Dejan!
    I have a generic question about the transition to the 27001:2013:
    we have just completed the integration between 27K and 9K ISO standards and we need to plan to move to 27001:2013 by the next survelliance audit in 11m from now.
    Would it be better to split the 2 standards again and migrate the 27001 certification to the 2013 edition or rather wait for the new upcoming 9001? As i don’t see an easy way to integrate 9001:2008 and 27001:2013…
    Splitting the 2 standards and upgrade to 27001:2013 is quite a lot of work, and waiting for the new 9001 may leave us only few months (or weeks…) to complete everything.
    Thanks for your advice!

  • Dejan Kosutic

    Stefano, I see no reason why you should split the two management systems – all the elements that are common for ISO 27001 and ISO 9001 have remained the same in the 2013 revision of ISO 27001 – internal audit, human resources, document control, corrective actions, etc.

    ISO 27001:2013 gives you the possibility to delete procedures for internal audit, document control, etc. but you don’t have to do it since you have ISO 9001 which requires you to have those procedures.

    You can also see this webinar – ISO 27001 implementation: How to make it easier using ISO 9001

  • Sdb

    Arent you skipping ’4.1 Understanding context of the organisation’? I’m a bit struggling with this part. How would you implement this ? I’m thinking of a PEST + SWOT analysis. But will this be enough ?

    When reading the 27001:2013 standard it refers to ‘Establishing external / internal context’ in ISO 31000 section 5.3 . So i guess not the rest of 5.3 .. only 5.3.2 and 5.3.3 need to be taken care of ?

  • Dejan Kosutic

    If you want to be really thorough, PEST and SWOT analysis would be a good choice. However, for a smaller organization you can understand the context by listing all the interested parties & their requirements, and by performing risk assessment.

    If you decide to follow ISO 31000, then I agree with you – one should go for 5.3.1, 5.3.2 and 5.3.3.

  • Sdb

    Thanks Dejan,

    While trying to understand the standard it looks like 2 different kind of risk-assesments can be distinguished:
    1) The HLS / High Level Structure part (4.1, 4.2, 6.1.1): risk and opportunities that can influence the intended outcome of the ISMS.

    2) The ISO 27001 specific part : ‘information security risks’ (6.1.2, 6.1.3).

    So maybe the first one is a PEST / SWOT on ISMS level, followed by preventive actions. And the second one is the known risk assesment on CIA level followed by a risk treatment plan.

    Another way to look at 6.1.1 is to read it as a ‘useless’ / standard HLS text introduction for 6.1.2 and 6.1.3. But i think they meant it as ‘outside’ vs ‘inside’ the box.

  • Dejan Kosutic

    I’m not sure if I agree – 4.1 is the only generic requirement and can be resolved as I mentioned before; 4.2 is very specific; 6.1.1 defines the requirements for the risk assessment methodology.