Each individual organisation will face unique information security challenges, which is which is why ISO 27001 doesn’t attempt to impose a generic security approach.

Instead, implementing ISO 27001 encourages you to put into place the appropriate processes and policies that contribute towards information security. You can demonstrate your success, and thereby achieve ISO 27001 certification, by documenting the existence of these processes and policies.

The documentation listed in this article is mandatory for ISO 27001 certification.

Scope of the Information Security Management System

This document sets out the type of operations your Information Security Management System (ISMS) will be applied to, and the boundaries that will be placed upon it.

Outlining the applicability of the management system will involve describing the types of products and services provided by your organisation, and where they are provided (i.e. regionally/across the UK/throughout Europe/worldwide).

Establishing the boundaries will require you to outline which parts of your organisation will be subject the ISMS will apply to. This will include processes, sites, departments, divisions, etc.

In most cases, your ISMS will be applied to your entire organisation, but there may be circumstances where it is either inappropriate or impossible for a process, site, or team to fall under the scope of your management system.

Information security policy and objectives

Your Information Security Policy acts as a statement that your organisation’s goal is to handle information in a secure manner that complies with any legal regulations and ethical obligations, as well as showing evidence of a desire for continual improvement. Your policy should also demonstrate a commitment to any action that will improve the security of the information you hold.

Risk assessment and risk treatment methodology

This document sets out how you identify risks to information security, and your approach to mitigating those risks and addressing them when they occur. You do not need to list the potential risks in this document, only your process for identifying them.

Risks might include:

• accidental loss
• accidental destruction
• incorrect storage
• inadvertent sharing
• unauthorised access by an employee
• unauthorised access by an external party.

Your methodology should address:

• How you will identify risks
• Who will own the risk
• How you will assess the potential consequences of a risk
• How you will determine the likelihood of the risk
• How you will determine the severity of the risk
• How you determine acceptance of a risk.

Statement of Applicability

This document explains which of the 114 information security controls outlined in Annex A of ISO 27001 you will adopt and why.

With so many information security controls to address, this document has the potential to become unwieldy, but you only need to:

1. identify which of the controls apply to your organisation
2. outline why these controls apply
3. state how the controls have been implemented
4. explain why any controls have not been chosen (known as exclusions).

Risk Treatment Plan

Once you’ve established which controls you have chosen, your Risk Treatment Plan outlines:

1. how you’ll implement the controls which apply to your organisation
2. who is responsible for implementation
3. what resources will be required and how much time is needed.

Risk assessment and risk treatment report

This document is a report on a risk assessment, and any risk treatment, performed in line with the methodology you outlined in the document above. It will describe the findings of your assessment, including any risks identified, and any treatment undertaken to mitigate or avoid the risks.

Definition of security roles and responsibilities

This document outlines the tasks and responsibilities of each role which has a part to play in information security. You do not need to include full job descriptions, and these roles do not have to be held by employees whose sole responsibility is information security. For example, a sales manager might have access to the customer database, and so has a security role in ensuring that their access is kept protected and out of the hands of an unauthorised individual.

Inventory of assets

You will need to document any asset that is involved in data storage. This includes desktop computers, laptops, servers, phones and tablets, physical documents, financial records, email systems, cloud computing services. Depending on the size of your organisation, this might be one of the biggest tasks associated with ISO 27001, but it’s vital in order to conduct a comprehensive information security risk assessment.

Acceptable use of assets

As the assets you identified in your inventory handle sensitive information, they must be used in the appropriate way. Establishing acceptable use makes it clear to all employees, both permanent and temporary, and also contractors, how they are permitted to use a device in order to maintain information security.

Examples of acceptable uses include:

• complex passwords must be used
• assets must not be left unattended
• assets must not be used for personal purposes
• computers must be locked when moving away from the desk
• information must be kept encrypted
• information should not be copied, transferred, or altered without authorisation.

Access control policy

The policy will help your organisation ensure that only the appropriate people are granted access to sensitive information. This document should outline

• how an individual is deemed to warrant access to information
• what requirements they must have to warrant privileged access
• how access is granted
• how access is reviewed
• how and why access would be revoked.

Operating procedures for IT management

Documented procedures should be considered for areas of the business where sensitive information is at risk through incorrect operation of IT equipment. These areas should be identified by your risk assessments, but could potentially involve:

• software development
• financial accounting
• customer management
• supplier management.

Remember, though, that information can be breached by an act as simple as failing to use the Blind Carbon Copy (BCC) function, so a degree of common sense should be used.

Documented operating procedures are not required for every instance of IT operation, only where it makes sense.

Secure system engineering principles

Secure engineering describes how you will apply security when you develop any new IT projects or how you will apply it to existing infrastructure. This security isn’t limited to firewalls or secure passwords; it also incorporates disaster planning and business continuity.

As such, when establishing these principles, you need to account for more than malicious human behaviour; you need to account for accidents, system failures, and even natural disasters.

Supplier security policy

There is little point in establishing security around sensitive information if flaws in a supplier’s security are going to expose that information to theft or destruction. As such, it’s important to establish a policy regarding the information security of suppliers.

Such a policy needs to be grounded in reality. A dictatorial policy isn’t going to be conducive to supplier relations. It might also be unfeasible; your business might not be in a position to dictate policy to much larger suppliers. Instead, try to create a collaborative policy that engenders close working relationships with suppliers who have access to or who could potentially compromise your data security.

Don’t forget, too, that some suppliers will have little or no impact on your security; focus your attention on those suppliers who are highlighted by your risk assessments.

Incident management procedure

Documented procedures need to be in place that make it clear how your organisation will react to an information security incident.

These procedures should establish how your organisation will determine who takes ownership of managing an incident, and how that individual will:

• gather evidence following the incident
• establish the circumstances surrounding and leading to the incident, including ascertaining the root cause, what happened, who was involved, etc.
• ensure that any activities undertaken in response to the incident are recorded for later analysis
• make management and leadership figures aware of the incident
• raise the incident with regulators or independent bodies, if necessary
• handle any weakness found to have either caused or contributed to the incident.

Business continuity procedures

Your organisation needs documented procedures to ensure that it can continue to operate in the wake of an information security incident. Part of these procedures should set out the acceptable level of continuity, and then outline:

• responsibilities
• actions
• timescales
• work required.

These procedures should also establish a management structure and generally agreed criteria for escalating the incident to appropriate regulators or other independent bodies. You will also need to establish when your organisation expects to return to business as usual.

Legal, regulatory, and contractual requirements

The way you handle information will be subject to all three of these types of requirements, and this document not only demonstrates your awareness of them, but also serves as an easy reference document for any employees.

You should make clear whether a requirement is legal, regulatory, or contractual, and you should also make clear how this requirement impacts your information security processes.

Naturally, these requirements may change over time, so you need to regularly review them and ensure that any changes are fed into your ISMS.

Records of training, skills, experience and qualifications

This document will demonstrate that every employee has the appropriate level of competence. It also helps your organisation demonstrate that it takes data security seriously and seeks continual improvement by showing the ongoing training and experience your employees gain.

Monitoring and measurement of results

One of the greatest strengths of ISO 27001 is its emphasis on continual improvement. That’s why a key part of an ISMS is a procedure to monitor its performance and measure the effectiveness of its results. You’ll need to have a record of these evaluations alongside evidence that your organisation has considered what to measure, how and when, and that the outcomes from any decisions are ensuring appropriate process control.

Internal audit programme and results

An internal audit is a key aspect of an ISMS, assessing not just its effectiveness, but also your organisation’s overall performance in regards to information security. These audits also help to demonstrate your compliance with the processes implemented for your ISMS.

This record will hold the details of a regular internal audit programme, as well as the results of any issues or opportunities for improvements such audits uncover.

Results of the management review

Senior management should regularly review the ISMS to make sure that it remains effective, and a record should be kept of the results of these reviews in line with the standard.

Non-conformities and results of corrective actions

Your organisation needs to document any non-conformities in your information security processes and operations, and the actions you took as a result. You’ll need to include clear evidence as to how your organisation ensured that any corrective action has achieved conformity again.

Your record should:

1. Document the details of non-conformity
2. Describe the actions taken
3. Detail any concessions obtained
4. Identify responsible individuals.

Logs of user activities, exceptions, and security events

Logging activity is a vital tool for maintaining security. Logging user activities, exceptions, and security events doesn’t just help you ascertain how incidents occurred, but it can also help with your risk assessments and help identify weaknesses in your information security.