Menu
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
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.Â
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.
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.
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.
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:
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.
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.
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.
Elisabeth is an Associate Consultant of the British Standards Institute (BSI), a BSI qualified ISO Lead Auditor and member of the Standard Committee responsible for the publication of the BS 10008 Standard.
Elisabeth can help you decide if ISO 27001 is for you and support you through its implementation, all the way to certification.