Delivering ISO27001 — Part 3 of 4 — The devil is in the detail

Delivering ISO27001 — Part 3 of 4 — The devil is in the detail

In previous posts, I’ve covered Getting Started With ISO27001 and getting the ISMS Scope, SOA, and Application letter in order. I’d recommend reading through those posts before continuing with this post.

Don’t worry, I’ll wait. 💅

Of course, if you’ve already read the last two posts (many brownie points heading your way 👏), we can begin.

In this post, I’ll cover some of the not-so-obvious processes and documentation you’ll need in place ahead of your ISO27001 audit. This post is not definitive, but is written based on my previous experience of ISO27001 audits and will hopefully provide guidance on avoiding some common mistakes. The goal of this post is to help you improve your ISMS, and to ultimately, assist you in CRUSHING your ISO27001 audit!

Statement of Applicability (SOA)

Your SOA is a checklist of things that you need to have in place in order to run a secure and compliant ISMS. By now, you should have worked through your SOA and used that information to put together two lists.

  1. A list of things your business does, and has evidence of.
  2. A list of things that you don’t do, or don’t have evidence to prove the fact that they are carried out.

List 1 is a list of things you’re doing that meet the ISO27001 standard, good job! 💪

List 2? Well, that’s your to-do list. Easy right? Right? 👀

Process, process, process

Processes get a really bad rap from some people, for being boring or restrictive. I don’t disagree — they can be. If a process isn’t adding value to your business, you shouldn’t be following that process, or you’ve implemented it incorrectly. #sorrynotsorry

Businesses are all different (did you know that?), they have different working practices with different people, so, processes should not be used as a one-size-fits-all-silver-bullet. Instead, define processes, based on your current working practices. Once you’ve done this, THEN benchmark against the ISO27001 standard and evaluate whether you need to make any changes (before you go upsetting your Development team 😛).

A good example here is Change Management. As an example, let’s say that you are making your changes via Github, but, you’re not logging the fact that those changes are tested. There are tests in place, however, not logging the fact that tests have run, passed, or failed. Instead of asking people to manually record this information, could you change to your deployment scripts to log the fact that the test has run? Could this information be recorded automatically? Then, at least all of your evidence is within the same place. The best bit? From a people point of view, the process hasn’t changed, and your change management process complies with ISO27001. That’s what we call a win-win situation. 😎

Processes and Controls underpin ISO27001. They’re not only critical when it comes to running a secure and efficient ISMS, but a key part of operating a steady and predictable business. Treat them with the respect that they deserve.

Write s*&t down

You will need to provide evidence to auditors, that you follow the processes you say you follow. Sadly, auditors won’t just take your word for it.

You should be able to provide evidence for example, of past changes to your infrastructure or software. You should be able to provide evidence that incidents were logged, properly managed, and subsequently reviewed. You should be able to provide evidence that everybody within your business has completed their Security Awareness training.

Simply put. If an auditor can’t audit your adhearance to processes, how will they attest to the fact that you comply with an ISO27001 control or not? If this isn’t the case right now, within your ISMS, go fix that.

Roles and responsibilities

Each member of your company must understand not only your role within ISO27001 as the Information Security expert, but their role concerning your business processes and ISO27001. Information Security is everybody’s responsibility.

I’d recommend documenting the expectations of your staff, concerning Information Security, and ensuring that they acknowledge and understand that. Everybody should understand the right, and wrong things to do, on the first day with your company.

Also, document what your responsibilities are — not just to the company, but your responsibility to your customers and the people who’s data you are protecting.

The point here is, if somebody doesn’t know a process or an answer straight away, it’s easy for them to find the right person (or people in a job role) is to ask.

Training and internal audits

By completing ISO27001, we are committing to a process of continuous service improvement. As your business grows and changes, your ISMS changes. This means that we must ensure that employees understand best practices for Information Security, Data Security, and other business processes.

Again here, ensure that your staff understand what is expected of them, and know what the right thing to do is, without having to ask.

Protip: All policies should be available for all staff to review at any time. Use your intranet or Policy Management tool for this (we use Tugboat Logic!).

Access control

Hiring someone? Log the fact that you’ve created their accounts. Firing someone (You meanie)? Log the fact that you’ve disabled their accounts. Changing somebody’s access? Log the fact you’ve changed their permissions and the application for which permissions were changed.

For all of these requests, you must record who requested the change, who made the change, who approved the change, the date the change was made, and the program for which the change was made. You should also regularly review the access that people have to applications, to ensure they’re still appropriate.

Physical security

If you host your infrastructure or store any customer or sensitive data within your office space, Physical Security will also be audited as part of your ISO27001 audit.

Datacentre — If you host infrastructure within a datacentre, that datacentre should be able to provide you with the documentation to prove to your auditor that appropriate physical controls are in place.

Office Space — If you have customer data within your office space (including paper records), you will need to provide evidence that you have appropriate physical controls in place. This could be an access control system, physically secured storage for paper files, and locks on server racks.

Change Management

The point of Change Management is clarity around what has changed on your platform, to understand those changes in the event of an incident. Whether you’re releasing software once a month (RIP), or many times a day (🚢), you need to record the fact a change has been made.

You can record this information in many different ways, whether that’s in JIRA, Microsoft Planner, Notion, or in Github Issues. You need to ensure that the information which you record, meets the ISO27001 standard.

Typically, a good baseline of information to record is details of what the change is, who made the change, who is approving the change, information on how to roll back that change, and then any information on whether this change should be communicated to stakeholders/customers.

Your auditor will ask to view a list of changes and this evidence, so it’s a good idea to get this done as early as possible within the process.

Incident Management

Incident Management isn’t dissimilar to Change management in regards to the requirements of ISO27001. Your Incident Management process should outline what employees need to do to effectively manage and resolve incidents with the least customer impact. Some businesses like to support this process with a suite of run books, based on the type or severity of the incidents.

Following the Continuous Service Improvement theme, all incidents should be reviewed and actions are taken to stop the same incident from occurring again.

Risk management

Risks should be recorded, and are typically negative things, which could occur and affect your business.

Risk management is the process of recording, understanding and mitigating the highest impacting/most likely risks.

You should be recording your risks within a risk register, scoring them based on their impact and likelihood, then reviewing these with your senior stakeholders on at least a quarterly basis.


I know this was a long post and if you’re still with me, I appreciate you. ISO27001 is a science, not an art. There is a formula for getting it right and the information is at your fingertips. The chances are that you’re probably following the majority of the processes in one way or another, but you may just need to tighten up the logging of information.

Next up

Next up and in the final post in this series, we’ll cover the scary bit — the actual audit itself. 👻

Until next time! Be safe.