ISO 27001 Annex A 5.37: documented operating procedures

The due-diligence questionnaire asks who else can restore production if your lead engineer is unavailable. The honest answer is nobody, and the deal waits. This guide covers ISO 27001 Annex A 5.37, the control for documented operating procedures, written for heads of engineering and security leads at UK firms of 25–250 people.

It shows how to size the runbook set, test it, keep it reachable during an outage and prove it to an auditor. The route we recommend is short: eight to twelve runbooks, held in git, tested by a colleague who did not write them.

Why does A.5.37 turn key-person risk into an audit and diligence problem?

Because at 25–250 people the platform's operational knowledge usually sits in one or two heads. If that engineer resigns, falls ill or goes on holiday, the firm cannot restore its own systems. Enterprise buyers probe exactly this in diligence, and UK GDPR Article 32 expects timely restoration of availability after an incident.

What reassures a buyer is evidence rather than assurance: a named second person, the runbook that person follows, and a record of them using it. The ICO Guidance on Data Security Measures makes the legal angle plain. Measures must let you restore access and availability to personal data in a timely manner after a physical or technical incident. A restore that waits for one engineer to return from leave is hard to call timely.

The concentration also makes incidents worse. A ransomware response improvised from memory at 2 a.m. is slower than one worked from a tested runbook, and the improvising creates its own secondary mistakes.

A runbook only its author can follow is a memory with a filename.

There is a compounding audit effect as well. When sampled work contradicts the documented process, the finding tends to spread across the whole assessment. Undocumented operations is usually where that pattern starts.

Read this way, A.5.37 is a transfer of capability: the platform stops being one person's property and becomes the team's.

How is a procedure different from a policy?

A policy states the rule and its intent: the what. A procedure is the executable how, with steps, commands, owners and escalation. A.5.1 anchors the policy layer, and A.5.37 demands the written-down operational layer beneath it. Auditors expect both layers and check that they agree with each other.

Many teams already hold a policy suite and assume it covers the control. A sentence such as "backups shall be performed daily" states intent and nothing else. No colleague could run a backup from it, and no auditor will accept it as a procedure.

The layers fit together like this:

• Policy (A.5.1): the rule, the intent and who is accountable for it.
• Procedure (A.5.37): the steps, commands, owner, dependencies and escalation route that carry the rule out.
• Record: the ticket, log or completed checklist showing the procedure was followed.

Your existing policy is the anchor, not the answer. It gives each runbook its authority, so every runbook should trace back to the policy sentence it executes. When the policy says daily and the runbook says weekly, that disagreement is the finding.

The control also sits close to clause 7.5, which governs how ISMS documentation is controlled. The version and approval habits you already apply to policies therefore apply to runbooks too. A team that has them for one layer can extend them to the other without inventing a new process.

What do documented operating procedures require under ISO 27001 Annex A 5.37?

Annex A 5.37 requires step-by-step instructions for security-relevant operational work, such as restoring a backup, offboarding a leaver, deploying a patch or handling a malware alert. The procedures must be available to the people performing the tasks and kept current as systems change, under simple governance covering ownership, versions and authorised edits.

The scope is security-relevant operational work, not every task the team performs. If botching a task could expose data, break availability or leave access open, it belongs in scope. A sprint-planning ritual does not.

Simple governance needs five things on every procedure:

• An ID, so the auditor and the on-call engineer name the same document.
• A version history showing what changed and when.
• Restricted edit rights, limited to the owning team, with read access for everyone who performs the task.
• Archived superseded versions, so a runbook for the old stack cannot be mistaken for the current one.
• Authorised changes, with an approver on record rather than a silent edit.

The NCSC makes a similar case for change management in its NCSC Cloud Security Principle 5 Operational Security. Changes to a service should be assessed for their security impact, then managed and tracked through to completion. Procedures deserve the same treatment as the systems they describe.

Currency is the harder property. Make "procedure updated?" a closure check on infrastructure change tickets, and sweep the full set once a year as a backstop.

A procedure describing last year's stack is worse than none: it is confidently wrong.

The common failure is access. Runbooks locked in one person's drive, or in a tool half the team cannot open, fail the availability test however good the content is. Inaccessible counts as undocumented, and an auditor who asks the on-call engineer to open the document will find out in seconds.

How many runbooks does a 50-person firm actually need?

Usually eight to twelve. Use the standard's own triggers to choose them: tasks several people must perform identically, jobs rare enough to be forgotten, risky new activities, and looming handovers. Cover joiner/mover/leaver access, backup and restore, patching, deployment, alert handling, incident escalation, log review and core platform recovery. The triggers size the set, not a target count.

The four triggers map onto the set like this:

• Many hands: joiner/mover/leaver access, where least privilege on entry and a provable cut-off on exit must happen identically every time.
• Rare tasks: backup restore and core platform recovery, which are forgotten between runs.
• New risk: deployment and change, where one botched step reaches production.
• Looming handover: whatever one engineer alone does today, which is often alert handling, patching and log review.

Proportion follows the estate. A firm with one cloud platform and a single deployment pipeline will land near the bottom of the range. Add a regulated data store, an on-premises site or a second production platform and the count climbs towards the top.

One consolidated operations manual is fine at the smaller end. The standard does not demand a document per task, and a single findable manual beats a dozen scattered pages. Split into modular runbooks only when the estate genuinely warrants it, for example when separate teams own separate platforms.

The belief that every task needs its own standalone policy document is a vendor habit rather than a requirement. What an auditor tests is findability, ownership and currency, not document count.

Resist documenting the trivial. Procedures for self-evident tasks create a review burden, and that burden guarantees the whole set goes stale. A short set that gets reviewed beats a long one that nobody opens.

What is the cold-start walkthrough test for a runbook?

The cold-start test asks whether a competent colleague who has never done the task could complete it from the document alone. A passing runbook gives the actual commands and screens, the order, a named owner, error branches and escalation contacts, including vendor support. If the reader must ask the author anything material, the runbook is unfinished.

Check each runbook against six questions:

1. Commands and screens: does it give the exact command, console path or screen, rather than "restart the service"?
2. Order: are the steps numbered, with prerequisites stated before the step that needs them?
3. Owner: is a named person or role accountable for the document and the task?
4. Error branches: does it say what to do when a step fails?
5. Escalation: does it say who to call, including the vendor's support route?
6. Evidence: does it say what to capture, such as a ticket reference or log extract?

Dependencies are where cold starts usually fail: the job that must finish before the backup starts, the service account that expires, the scheduling quirk nobody mentioned. Write each one beside the step it affects.

For incident runbooks, the NCSC Cyber Incident Response Process and Playbook Guidance is the external reference. It expects explicit instructions covering triage criteria, containment steps, key contacts and evidence retention, which maps neatly onto questions four to six above.

A document nobody has executed from is a hypothesis, not a procedure.

Prove transferability by having someone other than the author walk a procedure through. A restore test is the classic choice. Keep the record: it is both the competency evidence and the honest test of the document. Every gap the colleague hits becomes an edit before an auditor finds it.

Where should incident and recovery runbooks live when production is down?

Keep an offline export or independent store of incident and recovery runbooks, refreshed on a schedule, so on-call staff can reach them during a total outage. A recovery runbook held only inside the environment it exists to restore is out of reach exactly when it is needed.

Scope the out-of-band copy to the emergency subset: incident escalation, core platform recovery and restore. Copying the whole library creates a second set to keep current. The copy needs four properties:

• Independent of production: it does not rely on the cloud tenant, identity provider or network you would be rebuilding.
• Reachable by on-call: the people holding the pager can open it, and someone has checked that they can.
• Refreshed on a schedule: the export date is visible, and a change to an emergency runbook triggers a fresh copy.
• Documented: the arrangement itself is written down, because auditors ask for it as evidence.

The trap catches teams that keep recovery steps in the same wiki, repository host or single sign-on they describe rebuilding. Ask the auditor's question yourself before they do: if this environment is down, can the on-call person open the incident runbook?

What do auditors ask when testing ISO 27001 Annex A 5.37?

Auditors pair each procedure with its execution evidence: the offboarding document against the latest leaver's ticket trail, the backup runbook against restore test logs. They interview operators while reading the runbook. Missing procedures for critical operations grade major; stale content or a sampled task that does not match its document grades minor, aggregating to major as a pattern.

Expect questions along these lines:

• "Your engineer is unreachable. Show me what the person covering would follow to run tonight's backup or restore it."
• "Show me the offboarding procedure, then show me it followed for your most recent leaver."
• "This procedure references your old infrastructure. When was it last updated, and who approved the change?"
• "Where do these live, and can the on-call person reach the incident runbook if this environment is down?"
• "Who is allowed to change these documents?"

The auditor is looking for daylight between document and record. A leaver ticket trail that omits a step the runbook lists is exactly the kind of gap that gets probed. Interviews attack the same gap from the other side. An operator who describes a different process from the one on the page has just shown the drift.

Have the evidence assembled before the room:

• The runbook set, showing owners, version histories and approval of changes.
• Repository or tool permissions showing who can edit and who can only read.
• Review records: the annual sweep, and change tickets showing procedure updates checked before closure.
• Execution records such as restore test logs, completed offboarding checklists and deployment tickets.
• The out-of-band copy arrangement, plus walkthrough or training records for operational staff.

An incident or failed restore that has already exposed a missing procedure makes the major grade much harder to argue against. Version-control slips and a runbook that mentions retired infrastructure are minor on their own, so the aim is to stop them forming a pattern.

How does docs-as-code keep runbooks current and audit-ready?

Markdown runbooks in a git repository inherit owners, pull-request approval, version history and access control from the workflow engineers already trust. Automation then shrinks the manual surface, staleness detection raises update tickets when systems change, and ticketed execution leaves completion evidence as the work happens.

Four mechanisms do the work:

• Runbooks in the repo: pull-request review is the change authorisation, and history and access control come free. The governance the control asks for becomes a by-product of normal engineering.
• Automate the procedure away: provisioning, patching and backup verification moved into a pipeline or script leave the code and its run logs as both procedure and proof. What stays documented is the judgement layer: when to run it and what to do when it fails.
• Staleness detection: link each runbook to the systems it describes, and let an infrastructure change or a review-age threshold raise an update ticket to the owner. Freshness stops depending on the annual sweep.
• Execution capture: offboarding checklists, restore tests and deployment steps run through the ticketing system, so completion evidence exists the moment the work finishes. The audit-time evidence hunt disappears.

The commercial upside is speed in diligence. The buyer's question about who else can restore production gets answered with a repository, a pull-request history and a ticket trail, not a promise.

Together these remove the six failure modes that sink the control, mapped in the table below. At this scale, a small repo, a ticket template and a staleness check give you a set that an auditor can sample and a new engineer can run on day one.

Frequently asked questions