ISO 27001 Control 5.37: Documented Operating Procedures

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

I am still surprised by how many organisations let their teams document nothing at all. No backup procedure. No recovery procedure. No disaster recovery plan anyone could follow. It all sits in Gavin’s head, and Gavin is very good, and Gavin has never had a day off sick that mattered.

Control 5.37 asks you to write down how your systems are operated and make that available to the people who need it. It sounds like the most administrative control in Annex A. In practice it is one of the most important for a small business, because a small business often has exactly one person who knows how each critical thing works.

This page covers what the control requires, why the documentation does not get written, what happens when the person who knows leaves, and how to get procedures written by people who do not like writing. There is a free procedures register further down.

What control 5.37 actually asks for

The control requires operating procedures for information processing facilities to be documented and made available to the personnel who need them. In practice that means:

• Knowing which procedures matter. The routine and the rare operations on your systems, where getting it wrong or not knowing how would cause real harm.
• Writing them down. Clearly enough that a competent person who has not done it before could follow them.
• Making them available. To the people who need them, including when the usual systems are down. A recovery procedure stored only on the server it explains how to recover is not available.
• Keeping them current. Reviewed when the system changes, with an owner for each.

The standard lists the sort of thing operating procedures should cover: installation and configuration, processing and handling of information, backup and restore, scheduling, handling errors and exceptions, support and escalation contacts, system restart and recovery, and monitoring. In the 2013 edition this was control A.12.1.1.

Which procedures matter most

You do not need to document everything. Start with the operations that are high impact, rarely done, or known by only one person. For most small businesses that means these:

If only one person can do it, it goes to the top of the list. That is the test that matters most for a small business, and it is the one the register below is built around.

It all sits in Gavin’s head

The usual failure is not a badly written procedure. It is no procedure at all. Backups run, deployments happen, servers get patched, and all of it works because one or two people know exactly what to do. Nobody has written it down because nobody has needed to.

Until they do. The person is ill, on holiday, or gone. The backup fails at the same moment and nobody knows how to restore. A deployment goes wrong and nobody knows how to roll it back. The certificate expires and nobody knows where it was installed.

From a security point of view, this is a single point of failure, the same as a single server or a single internet connection. It affects availability directly, and it affects confidentiality and integrity too, because people improvising an operation they do not understand make mistakes, and some of those mistakes expose data.

When the person who knows leaves

In the 1990s I worked at a mortgage company that went through a wave of redundancies. A large part of the technical department went in one round. Only afterwards did the company realise that several of the people it had let go were the only ones who understood how the build and deployment processes worked: how code was built, deployed and kept running.

Nothing was written down. The company had to go back to the people it had just made redundant and ask them to come back, on their own terms, to keep the systems running. That is an expensive and slightly humiliating way to learn the value of documentation, and it happens more often than anyone admits.

Redundancy is the dramatic version. The everyday version is resignation, and it is worse, because notice periods are short and the person leaving rarely spends their last fortnight writing manuals. If a procedure exists only in someone’s head, you are one resignation letter away from losing it.

Why techies do not write it down

Here is something I have seen many times, and it is worth saying plainly because it changes how you fix the problem. Very often, technical people do not like documenting things. Some see it as a chore that gets in the way of real work. Some, consciously or not, feel that knowledge only they have makes them valuable. But at the heart of it, many of them simply do not know how to write documentation, and nobody has ever helped them.

Telling them to write procedures, and then telling them again more firmly, rarely works. Helping them usually does:

• Give them a template. A short, fixed set of headings removes the blank page. The register below includes one.
• Pair them with a writer. Someone who is good at writing sits with the engineer, asks questions and writes down the answers. The engineer then checks it. An hour of this produces more than a month of reminders.
• Record, then write up. Screen-record them doing the task while talking it through, then turn the recording into steps.
• Accept short and accurate. A numbered list of commands with a sentence of context is a perfectly good procedure. It does not need to be a manual.
• Make it part of the job. A change is not finished until its procedure is updated. Put it in the definition of done.

And test it. Have someone else follow the procedure, ideally during a restore test or a DR exercise. A procedure is only really documented when someone other than its author can follow it and get the right result.

Where to keep them

Somewhere the people who need them can find them, and somewhere that still works when things are broken. That second point matters more than people think. The procedures you most need in a crisis, recovery, failover and incident response, are the ones you will reach for when your main systems are unavailable.

• Keep everyday procedures where the team already works: the wiki, the shared drive, the repository alongside the code.
• Keep a copy of recovery and incident procedures somewhere independent of the systems they recover, such as a printed copy, an offline copy, or a separate account.
• Control who can edit them, and keep the history, so you know what changed and when.
• Link each procedure from the register, so there is one place to look.

What auditors will look for

In an audit, I would typically work through 5.37.

1. Which procedures exist. Is there a list, and does it cover the operations that matter: backup, recovery, access, change, patching?
2. A procedure, read. I will pick one, usually backup and restore, and read it. Could someone who has not done it before follow it?
3. A procedure, followed. I may ask someone other than the author how they would carry it out, or ask for the record of a restore test that used it.
4. Availability. Where is the recovery procedure kept, and could you get to it if your main systems were down?
5. Currency. When was it last reviewed, and does it match the system as it is now? A procedure for a server you retired last year is not evidence.
6. Single points of knowledge. Which operations can only one person do?

Common issues

• No documented procedures at all. Everything known, nothing written.
• Critical operations, especially recovery and deployment, known by one person.
• Procedures written once for certification and not updated since the systems changed.
• Recovery procedures stored only on the systems they describe.
• Procedures so long and generic nobody would use them in practice.
• Procedures never tested by anyone other than their author.
• Outsourced operations with no procedure on your side, so nobody knows what the IT provider actually does or how to check it.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• If your most technical person left tomorrow, which operations could nobody else perform?
• Is your backup and restore procedure written down, and has someone other than its author followed it?
• Could you reach your recovery procedures if your main systems were unavailable?
• When did your systems last change, and were the procedures updated?
• Does your IT provider’s work rely on procedures you have seen?

The first is the one to sit with. Make the list, then write those procedures first.

A worked example

The details below are typical rather than drawn from a single engagement. This is a composite of a first look at 5.37 in a small technology business.

A 20-person software company. One senior engineer had built most of the infrastructure and handled deployments, backups and recovery. Two other engineers could deploy but had never restored anything. There was no written procedure for any of it.

What the review found

• Of 12 critical operations listed, 7 could be performed by only one person.
• The only description of the backup arrangement was a comment in a configuration file.
• Nobody but the senior engineer knew where the TLS certificates were managed or when they expired.
• The DR plan, such as it was, lived on the cloud account it described.

What changed

• The 12 operations went into a register, with the 7 single-person ones prioritised.
• A colleague who writes well spent two half-days with the senior engineer, asking questions and writing. The engineer reviewed every page.
• Each new procedure was then followed by one of the other engineers, with the senior engineer watching but not helping. Three needed corrections.
• Recovery procedures were copied to a separate account and printed, and a procedure review was added to the change process.

Total effort was around four days spread over a month. The single-person list went from 7 to 1, and the remaining one had a date set.

How control 5.37 links to other clauses and controls

• Control 8.13, Information backup. The backup and restore procedure is usually the first one an auditor asks to see.
• Control 5.29, Information security during disruption. and Control 5.30, ICT readiness for business continuity. Recovery depends on procedures someone else can follow under pressure.
• Control 8.32, Change management. Changes should update the procedures they affect.
• Control 5.18, Access rights. Starters, movers and leavers is a procedure in its own right.
• Control 5.26, Response to information security incidents. The first steps of incident response need to be written down for whoever is on hand.
• Control 5.36, Compliance with policies, rules and standards. Checking that procedures are followed is part of compliance checking.
• Clause 7.5, Documented information. Procedures are documented information and need the same control over versions, access and review.

What I find in audits

In my audits I increasingly find procedures generated with AI that describe a process nobody actually follows. The test is simple: ask the person who does the job to walk you through it, and compare. More detail is in my findings report.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• Small organisations guide to cyber security. NCSC guidance, including backing up and recovering your data.
• Incident management. NCSC guidance, including preparing response playbooks.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call