ISO 27001 Implementation Guide
Writing ISO 27001 documentation
Learn how to write successful ISO 27001 documentation to ensure certification.
Understanding how to write correct and successful documentation to achieve ISO 27001 can be tricky. The standard can be vague and difficult to understand, but hopefully this article will improve your understanding and help you write effective documentation. We will cover:
Reading time: 7 minutes 23 seconds
Our approach to writing ISO 27001 documentation
We strongly believe that only the minimum amount of documentation should be written, and only where it is necessary. It should also be written in a way that is meaningful to those who need it, i.e. your colleagues.
Documentation should NOT be written or structured for the external assessors or internal auditors.
With that in mind, we have developed our set of template examples to be in plain English and as short as possible, with as few documents, logs and registers as possible to meet the requirements and obtain certification. This means that depending on your assets and activities, using the Digital Octopii approach will likely give you around 25 different policies, procedures, forms and spreadsheets to maintain.
- Acceptable Use Policy
- Access Control Policy
- Asset Management Policy
- Asset Register
- Change Management Procedure
- Controlled document format template
- Competencies and Assessment Grid
- Disaster Recovery and Business Continuity Plan
- Documentation Management Procedure
- Employee Life Cycle Policy
- Incident Management Procedure
- Information Security Policy
- Information Security Procedure
- Internal Audit Plan and Reports (both in ISMS Audit Plan template)
- Internal Audit Procedure
- ISMS Manual
- ISMS Tracker form (one form including sections for nonconformities, incidents, issues, change requests, customer complaints and opportunities)
- Management Review Agenda and Minutes
- Network Security Policy
- Physical and Environmental Security Policy
- Risk Consequences and Likelihood scales
- Risk Register
- Statement of Applicability
- Supplier Management Policy
- System Acquisition, Development and Maintenance Policy
- Teleworking policy
Understanding the jargon
As you read the standard, you might notice the phrase “documented information” and “documented” cropping up regularly. To be precise, 34 times respectively!
That’s probably why there’s a common misconception that standards are just about documentation. They’re absolutely not! Some documentation, of course, is essential to make sure everyone is on the same page and things are done consistently over time. Understanding “Documented information” and making decisions around how you will manage it is fundamental to making your life easier.
In plain English, that means documented information includes the policy and procedure documents (documentation) you create as part of your ISMS, along with any evidence (record) you need to demonstrate to an auditor (external or internal) that your policies and procedures are actually being applied.
What does the standard demand from documentation?
According to clause 7.5 of the standard, documented information is where the requirements are laid out. In true ISO standard style, this is somewhat obscure and difficult to understand, so let’s go through each section one by one.
First, 7.5.1 gives you an indication of what you need to hold as documented information.
- a) documented information required by this International Standard. In plain English this means wherever you read “documented information” or “documented” in the standard.
- b) documented information determined by the organisation as being necessary for the effectiveness of the information security management system. In plain English this means in addition to what the standard requires, any other procedure or evidence that you think will make it easier for people in your organisation to perform their job correctly, accurately, at the right time, etc.
This means not every single procedure has to be documented or its implementation evidenced – only those requested by the standard, and those you think will make people’s lives easier.
Once you know what documented information is, 7.5.2 and 7.5.3 become easier to understand. They give you quite clear requirements in terms of what needs to be included and how you control documented information.
The easiest and most common way to comply with those requirements is to have a “Documentation management procedure” which lays out how your documentation needs to look, where you indicate who the author is, the date it was published, date for review, how to manage versions, version history, where it should be stored, how you make it available to people, etc.
Download our Documentation Management Procedure template and you’ll understand better what it’s all about.
The template is easy-to-use and easily adaptable to any organisation, no matter your industry or size.
Documentation storage options
Most organisations store documentation in several places, such as SharePoint 365, Google Docs and local shared drives.
We’ve also helped organisations use various document management systems already in place, as well as using the wiki pages in DevOps and GitLab, Jira & Confluence and dedicated ISMS applications.
What you choose to use is entirely up to you. The key points to consider in deciding where you will store your documentation and evidence are:
- How accessible is the documentation? Everyone in the organisation will need to have access so make sure you have the appropriate licences.
- Some of the evidence will likely have restricted access, and some you’ll want read-only – are you able to manage access & permissions?
- Version control – will you manage versions manually or do you want to use built-in version control, or a mixture of both?
- Location of your ISMS Tracker – there will be lots of activities, tasks and projects to manage and track as part of implementing and running your ISMS. You’ll see in the next section that we like to do this in one central place that we call the ISMS Tracker. It doesn’t have to be complicated and can be done in a spreadsheet.
Documentation version control
Most of us are familiar with the frustration of not knowing whether you have a document’s correct/most up-to-date version. When there are multiple versions of seemingly the same document stored in multiple places, and you don’t know which one is the correct one to use, not only is it a waste of time, but it can cause human error.
Controlling the versions of your ISMS documentation and making sure people have easy access to the most up-to-date version is fundamental. The external assessor will be very quick to point out nonconformities around this.
If you plan on doing this manually, our Documentation Management Procedure template gives more detail around implementing version control in this way. Depending on where you decide to store your documentation, version control might be taken care of automatically by the system you use.
Documents your employees need to confirm they have read
There are six places in the standard where the phrase “shall be communicated” is found:
5.2 f) [The information security policy shall] be communicated within the organisation.
- 3 Top management shall ensure that the responsibilities and authorities for roles relevant to information security are assigned and communicated.
- 2 d) [The information security objectives shall] be communicated.
- 5.1.1 A set of policies for information security shall be defined, approved by management, published and communicated to employees and relevant external parties.
- 7.2.3 There shall be a formal and communicated disciplinary process in place.
- 7.3.1 Information security responsibilities and duties that remain valid after termination or change of employment shall be defined, communicated to the employee or contractor and enforced.
The requirements above, combined with the awareness requirements in clause 7.5, mean that during your certification audit at stage 2, you will be asked by the external assessor to evidence that you have indeed communicated these documents. You will also be asked to evidence that your employees are aware of them.
We all know that just because you’ve emailed out a document, it doesn’t mean that the recipients will actually read them and take the information they contain onboard. Hence the need to evidence awareness.
An easy way to evidence all the requirements above is to email the relevant documents out, ask employees to confirm in reply that they have read, understood and will abide by the policies and procedures contained within the documents received. Combined with a tick list in a spreadsheet, SharePoint, in your HR system or anywhere else convenient for you to evidence that you’ve sent the email and received a reply from everyone and the date it was done.