10 Steps for ISO 27001 Certification


With data breaches continuously present in the media, businesses are beginning to take a serious approach towards securing their assets from loss or compromise. Alignment with the ISO 27001 standard enables organisations to gain assurance that they are aligned with information security best practices and demonstrate this compliance to customers, suppliers and investors. By achieving compliance with ISO 27001, organisations can reduce the risk to their assets and demonstrate compliance against other legal and regulatory requirements such as the Data Protection Act. The benefits of the standard are  clear, but just how do you go about achieving compliance with the standard? What are the steps to take and can you do this yourself or do you require outside help? This article looks at 10 steps for ISO 27001 certification.
1. Management Buy-In

Any external consultant or company worth their salt will emphasise this point. Management buy-in is imperative in order to have any chance of obtaining ISO 27001 certification. From the start, management need to be well informed of the benefits of achieving ISO 27001 certification and understand the costs and resources required to achieve this. An individual within the company must take ownership for this process, which initially consists of identifying the business requirements for certification and calculating the costs. This enables a detailed cost/benefit analysis to be undertaken. Questions to pose during this phase may include:

  • What is the benefit of ISO 27001 to the organisation? Can we continue to grow and be trusted by clients without this? Who is demanding this?
  • What are the benefits of achieving certification with this standard? Do we need to align with the standard or achieve certification? What will the costs be? Can we afford the resources required to maintain this?

These are typical questions that should be answered during this phase. If you are able to justify the benefits against the costs and senior management are keen to progress, then you are set to go. It is recommended that senior management buy-in is documented and signed-off – this avoids any complications down the line when costs may be more than expected. Management will be responsible for driving a lot of the expectations for the information security management system (ISMS), so it is imperative that buy-in is sought as soon as possible.

2. Scope

With management on-board, you can begin to look at the scope of your ISMS. It is important to get this part right – a poorly scoped ISMS can result in excessive costs or vital assets left unmanaged. The scope of the ISMS should include all key assets – this includes everything of value within the scope of the ISMS. For example, if your scope were to include the sales department only you would include all physical assets (servers, desktops, locations), personnel, information assets (paper, electronic) and any other asset that you would want to protect. Boundaries and interfaces should be determined at this stage, these are areas that the ISMS touches but may be out of the control of the ISMS. For example, a sales department wishing to implement an ISMS around their department only may interface with third parties or suppliers. While these entities may have an impact on assets within your scope, you are not directly in control of these entities and do not own them. Therefore, they become interfaces with the ISMS and should be identified during this stage. A scoping diagram usually helps to demonstrate the scope of the ISMS and should be produced to support this exercise. A tip during this phase is to pick a business process that is within scope of the ISMS and follow that process through from start to finish. For example, a process might be to input customer data to a sales tool which is then sent on to a supplier. The customer data would be the primary asset, however, the sales tool, infrastructure and personnel are all also assets, which could be considered secondary. Once entered onto the system, the data is transferred to the third party which then becomes out of scope once leaving the sales department. The aim of the ISMS will eventually be to implement policies, procedures and controls to secure the confidentiality, integrity and availability of that customer data while it is within scope of the ISMS. This may include screening personnel to prevent data leakage, data in transit encryption to protect data from being intercepted when transitting to the supplier and even non-disclosure agreements (NDA’s) to prevent leakage of that data when out of the ISMS control. These controls will be determined at a later stage, but it is always worth remembering what you are trying to achieve with this process from the outset.

The output from this phase will be a clear understanding of where the scope of the ISMS lies, where the touching points are and where the business can control the security of assets. A scoping diagram should be produced and detailed within the ISMS policy, or information security policy. This will help to demonstrate to any auditor that appropriate scoping of the ISMS has taken place.

3. Asset Register and Valuation

With an understanding of the scope of the ISMS, the organisation can begin to produce an asset register of all assets (of value) within the ISMS. As discussed, this will include both physical and information assets – however, as our focus will be on securing those information assets we should be focusing on data. It is still important to understand the physical assets as there will also be risks to these that we need to take into account e.g. physical controls regarding data residing on servers, access controls to data centres etc. The organisation may build their asset register on pre-existing software/hardware configuration management lists, or opt to build an entirely manual asset register. For large organisations, they key is to apply the correct level of abstraction when grouping assets. You would not, for example, list every physical file in an ISMS that covers a global organisation. You may want to group assets based on their risk profile e.g. customer data, employee data, financial data. This provides a manageable asset register but still allows the organisation to consider risks to all assets within their control. It is vital to capture all assets of value to the organisation at this phase.

With a comprehensive list of information and physical assets, the organisation should value their assets in accordance with the impact that loss or compromise would have on the business. This is usually described as a business impact analysis. A consistent scoring method should be defined to support this e.g. 1 is minor loss to operations while 5 is catastrophic losses. If it helps, you can use quantative or qualitative methods to achieve this, as long as the outcome is consistent and repeatable then you will meet the requirements of ISO 27001. It is recommended to value your assets based on confidentiality, integrity and availability where possible – this helps to provide more context as to what is important about that asset. For example, publicly available information would have minimal impact on the organisation if compromised for confidentiality, however, this might be information that is required at all times resulting in a major impact for availability. Ensure you have a consistent, repeatable scoring methodology before proceeding at this stage and value your assets realistically.

4. Threat Assessment

A threat assessment should be undertaken based on the realistic threats towards the organisations information assets. This should take into account accidental or deliberate attacks on assets, misuse, loss or events outside the organisations control e.g. environmental factors. Defining a threat list will support this process. The list should consider all threats and vulnerabilities.

The next stage will be to compile a matrix with these threats and your asset list and determine the likelihood of each threat for each asset. For example, environmental factors may have limited threat to paper assets stored on the top floor of a protected building, however, may have increased threat to data stored on servers within the data centre next to a river that is prone to flooding. During this stage, you should be realistic about your threats and likelihoods. It is important to capture the key threats to the key assets during this stage. It may help to build on incidents that have occurred in the past as a starting point, however, this should not be holistically relied upon as the organisation may need to consider other factors e.g. change in landscape, higher motivation of threat actors in recent years.

5. Risk Assessment

Once a thorough threat assessment has been undertaken, you should have a value for assets business impact (stage 3) and the threat likelihood (stage 4). A simple way to produce a risk assessment may be to multiply your values (if quantative) for impact and threat likelihood. This way, you are considering how important those assets are to your business and how likely it is that they will be lost or compromised. In this scenario, those assets worth the most to the business and most likely to be compromised by a threat will pose the biggest risk. If you are using a qualitative approach to measure this then a risk assessment methodology can be used to support this process.

The output of this will be a through risk assessment with prioritised risk list. The key point to remember here is that ISO 27001 certifiers will be looking for evidence that you have a consistent, repeatable approach and are proactively looking for risks in your business – how you approach this is up to you.

6. Statement of Applicability (SOA)

The statement of applicability identifies which controls you are wishing to implement to reduce the risks identified in the previous steps. The control set listed in Annex A of the ISO 27001 standard may be a good starting place, however, it is not mandatory to implement every control. The outputs of the risk assessment coupled with business/legal/regulatory requirements should help to build a picture of which controls are imperative to implement, and which controls can be omitted. If a clear justification is provided for not implementing a control then this will be sufficient for the ISO 27001 certifier. Having said that, where high risks are identified the organisation may wish to implement a lower level set of controls to mitigate the risk. This may include further controls from other frameworks. This should be documented in the statement of applicability.

7. Risk Treatment Plan

Similar to the SOA, the risk treatment plan documents the outputs of the risk assessment and logs controls next to each risk. The idea is to provide a living document that can be updated as the risk changes or as controls are implemented. This document can be used as evidence for ISO 27001 certification that the department is taking active steps to implement controls against the appropriate risk.

8. Document Everything!

As you may be aware, ISO 27001 requires a stringent set of documentation. This is required to demonstrate that appropriate policies and procedures have been implemented. As well as putting together these policies, the certifier will look for evidence that they are being followed and communicated to staff where appropriate. It is therefore worth detailing where these policies are stored, who has access to them and tracking compliance with procedures, where applicable. Assigning ownership and establishing review periods is also imperative, so the document owner should regularly review policies to ensure alignment with business requirements.

9. Internal Audit

Establish an internal audit function and ensure that the ISMS is rigorously tested by individuals outside the ownership. An internal audit function can act as practice for the main audit and is a requirement of ISO 27001 to review project milestones and implementation plans. Audits should take place periodically and audit reports maintained to act as proof to ISO 27001 certifiers.

10. ISO27001 Audit

Be prepared for the audit itself. Auditors will need to cram a lot into their limited time on-site so ensure all documents and key individuals are available. This should be a time to demonstrate to the auditor that all controls are met and that risks are mitigated proportionally.

About Lee Hazell

Lee Hazell is a cyber security consultant with a keen interest in anything tech or security related. Follow Lee on .

Recommended for you

Leave a Reply

Your email address will not be published. Required fields are marked *