ISO 27001:2017: essential documents for certification

You've applied for certification to ISO 27001 and you're about to undergo your Stage 1 audit.

The auditor's coming to check that your documentation's up to scratch, but you're unsure what documents he'll actually want to see.

Well, don't panic!

In this blog, we explain exactly which documents you must provide. None of them need to be lengthy epics – it's all about ensuring the documents provide the information they're required to, clearly and concisely.

ISO 27001 certification is a two-stage process.

Stage 1 is when the auditor familiarises himself with your organisation, checks you have all the necessary documents, and confirms that your information security management system (ISMS) is established enough for a full audit to be worthwhile.

The Stage 1 audit is usually short – a day or two, perhaps – and the auditor may even review your documents remotely. However he chooses to do it, he'll expect to see the following documentation.

1)  Scope of the ISMS

If you've been certified to another ISO standard, you'll already know what's involved in defining the scope of your quality management system. You're aiming to clearly set out how far the system extends within your operations, and to justify any instances where you're excluding yourself from the standard's requirements.

Where an ISMS is concerned, you need to define which information your ISMS is set up to protect, whether this is information you store in your company offices, in the cloud, or on devices your employees take out of the building (e.g. laptops or USB drives). This is often referred to as your system's intended outcomes.

Clauses 1 and 4.3 of ISO 27001 refer to the scope, and an auditor will look for consistency between both sections in your document of it. This document must specify all the internal and external issues relevant to your organisation, and your interested parties.

Your scope should also describe:

• The nature of your organisation
• The business area in which it operates
• The location(s) in which it's based
• Your assets
• The technology you use

Many organisations store their scope document in an electronic quality management system to ensure the relevant people have access to only the most recent version.

2)  Information security policy

The main purpose of this policy is for your top management to demonstrate their commitment to the ISMS. By setting out your organisation's objectives, purpose, principles and agreed-upon strategy for securing information, they're creating an easy-to-understand document that can be followed to ensure the ISMS is properly implemented.

The policy must:

• Be appropriate for your organisation's size. A policy created for a large manufacturing company won't suit a small IT company, for instance.
• Show how top management will:
  • Satisfy the requirements of all interested parties
  • Make sure the ISMS is continually improved
• Be communicated to all staff and – where appropriate – to interested parties
• Be regularly reviewed
  
  

3)  Risk assessment and risk treatment methodology

ISO 27001 requires you to document how you'll assess and treat risk, which is a crucial early step in implementing your ISMS. Though the 2013 standard has removed the need (as per ISO 27001:2005) to use assets, threats and vulnerabilities as your methodology, this is still the common way to go about it.

Doing a risk assessment involves:

• Identifying risks that could impact your information's confidentiality, integrity or availability
• Identifying the risk owner (the person with the accountability and authority to manage a risk)
• Setting criteria for assessing the likelihood and consequences of identified risks
• Establishing how you'll calculate risk (a one-to-three scale, for example)
• Setting criteria for accepting risks

But before you do any sort of assessment, you must first clarify your methodology – in other words, the rules by which you'll assess the risks to your organisation. Having that document means anyone in your organisation can assess risk using the same methodology.

Defining your risk assessment methodology means considering the following:

• Will you measure risk quantitatively or qualitatively?
• What timeframe should each risk cover?
• What scales should you use?
• Who can accept risk?
• What's your organisation's risk appetite and what's an acceptable level of risk?

Electronic quality management systems can support you in sharing your risk assessment methodology with all the relevant people. In the configuration stage of Risk Manager, for example, you can embed this methodology into your risk management process. 

4) Statement of applicability (SoA)

In your SoA, you're setting out which of the 114 information security controls listed in Annex A of ISO 27001 you're going to apply, and why. This is different to your risk assessment document in that it must also show:

• Which controls you'll apply for reasons other than reducing risk (e.g. legal obligations, contractual obligations etc.)
• Which controls you've already implemented, and how.

Your SoA can be fairly short as it's intended for everyday operational use. However, it may take you a long time to create as it involves thinking about how to implement the necessary controls at a strategic level.

5)  Risk treatment plan

Your risk treatment plan takes the controls you identified in your SoA and defines:

• How you'll implement those controls
• Who's responsible for that implementation
• What resources (and how much time) they'll need to do so

You'll have identified both acceptable and unacceptable risks, but your risk treatment plan is concerned mainly with the unacceptable ones. You'll need to decide how you'll treat those risks you've deemed unacceptable – for instance, you might choose to:

• Apply one of the Annex A controls to reduce the risk
• Avoid whatever action is causing the risk
• Transfer the risk to a third party (i.e. insure yourself against it)
  
  

6)  Risk assessment report

ISO 27001 offers little direction on what your risk assessment report needs to include. But by the time you come to create your report, it's likely you'll have compiled a lot of the information already.

• Your risk assessment methodology
• Risk owners
• Risks you've identified, their impact and likelihood, and whether or not they're acceptable
• For unacceptable risks, how they'll be treated
• Controls

Most of this information you'll have in your risk assessment methodology document, your risk assessment and your risk treatment report.

7)  Definition of information security roles and responsibilities

You should have a written record of the roles and responsibilities of those employees involved in managing your information security.

Where you document this information is up to you. But it should be somewhere logical and easy to find – it could be job descriptions, your organisational chart, or your information security policy.

8)  Inventory of assets

When the standard talks about assets (though, unhelpfully, it doesn't define the term!), it means anything that has value to your organisation. So this covers everything from hardware (laptops, PCs, printers, mobile phones) to data (electronic, paper and other formats) to your buildings and employees.

Assets are important to ISO 27001 as they help with identifying risks and protecting the confidentiality, integrity and availability of your information. As mentioned above, the 2013 revision has removed the need to use assets, threats and vulnerabilities to assess risk, but as a methodology it still makes sense.

You'll need to:

• Put together an inventory of your assets
• Nominate an owner (or owners) for each asset – a person responsible for managing the information relating to that asset
  
  

9)  Acceptable use of assets policy

In this document, you're setting out clear rules for how your information system and other information assets must be used.

10)  Access control policy

Your access control policy demonstrates how you mitigate risk by managing what assets you make available and how.

You might want to lock down some of your networks and services so that only certain employees can access them.

The rules you set will be based on various factors – the sensitivity of the asset, where those employees accessing the asset are based, and any laws or regulations that might apply (e.g. the Data Protection Act or GDPR).

You might choose to restrict access to certain types of users or roles (e.g. system admins, managers).

Bear in mind that the policy also covers physical access to secure areas in your buildings and other locations.

A software solution like EQMS can be used to deploy an access control policy.

11)  Operating procedures for IT management 

This document provides a framework for all management procedures to make sure that correct and secure information can be acquired.

This includes written descriptions of the management processes and activities necessary to plan, operate and control the ISMS.

12)  Secure system engineering principles

Secure engineering is applying security while you develop your IT system. And this means security against a whole host of threats and vulnerabilities, from fire and natural disasters to terrorism, hacking and industrial espionage; from poor management of passwords to inadequate supervision of staff.

The principles are the high-level rules you set to apply this security. You'll need to devise a detailed procedure for each one to ensure they're followed throughout your organisation. And the principles will apply to every phase of your development projects, and to all architectural layers (business, data, applications, and technology) of your final products.

13)  Supplier security policy

Some of the information your organisation uses might not be under your direct control, but handled by third parties. Suppliers, partners, customers, cloud services – these may all have access to sensitive data about your company and its finances or inner workings.

As a result, you'll need a policy that dictates how you will work with these kinds of third parties. What systems will you use to manage how they handle your information? 

Suppliers and other third parties must agree to allow all aspects of their information security management system to be audited.

Organisations with complex supply chains or thousands of suppliers use Supplier Manager to track and manage suppliers' performance.

14)  Incident management procedure

Unfortunately, there's often little you can do to prevent a hacker or an employee determined to flout procedure. But by quickly detecting security breaches and weaknesses, and reacting even more promptly, you can prevent damage to your reputation and even improve your brand.

Your incident management procedure is where you outline your procedures for managing these kinds of incidents. 

Incident & Accident Manager can be used to cut the response time from hours to minutes by instantly notifying the relevant parties when a breach or incident has occurred. 

15)  Business continuity procedure

When a crisis hits, every minute counts. So it's essential to build a business continuity procedure which defines exactly how you'll manage your stakeholders managed to ensure your business continues as normal. The procedure should outline how you'll recover from critical activities within a set time frame.

16)  Statutory, regulatory and contractual requirements

This section of ISO 27001:2013 outlines the need to provide information about statutory, regulatory and contractual requirements. This will help you to demonstrate how you comply. Some of the information and data management regulations include:

• Official Secrets Act 1989
• Public Records Acts 1958 and 1967
• Data Protection Act 1998
• Freedom of Information Act 2000
• Environmental Information Regulations 2004
• Human Rights Act 1998 
• Computer Misuse Act 1990
• Copyright (Computer Programs) Regulations
• Civil Evidence Act 1968
• Police and Criminal Evidence Act 1985
• Wireless Telegraphy Act 1949
• Communications Act 2003
• Regulation of Investigatory Powers Act 2000
• Telecommunications (Lawful Business Practice) (Interception of Communications) Regulations 2000
• Civil Contingencies Act 2004

What you should do now

For more information about ISO 27001, download our toolkit.