What are the key changes in the ISO 27001: 2013 revision, as well as the benefits?
The key benefit of this new ISO 27001 is that it can be more easily implemented in smaller companies – a greater degree of flexibility is allowed, and a smaller number of mandatory documents is needed. For instance, the risk assessment process is simplified, and there are no more requirements to document procedures like internal audit or corrective action.
What are the new security controls and how does the 2013 revision deal with new risks?
First of all, the number of suggested controls in the 2013 revision has actually decreased from 133 to 114 – therefore, it is easier now to find the controls that are really needed for a particular risk. The new controls are these: 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.
How much new mandatory documentation is there, and for certified companies is there lots of work involved in implementing these?
As I mentioned previously, there is actually less documentation required. If a company is already certified against the old 2005 revision of ISO 27001, only about 10-20% of the existing documents will need to be changed, and some of the documents may now be deleted. Therefore, the effort to make this transition to the 2013 revision won’t be too big.
How to make a transition from ISO 27001 2005 revision to 2013 revision
Transition steps
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).