Yes, runbooks kept in a repository can serve as documented operating procedures for Annex A control 5.37, if they are findable, owned, versioned and current. Git history gives you review dates and approvers for free, which is useful evidence that the procedures are maintained and not abandoned.
What 5.37 is about
Control 5.37 is titled "Documented operating procedures" and sits at the end of the organizational theme in the 2022 edition of Annex A. The title is plain: the way you operate systems should be written down and available to the people who need it. The standard text sets the detailed requirement, so read it before you decide what format is enough.
For software teams the candidates are deployment runbooks, rollback steps, on call guides, backup and restore procedures, access request steps and release checklists.
Why a repository works well
A repository gives you things a shared document folder often lacks.
| Property | Why it helps as evidence |
|---|---|
| Version history | Shows when each procedure changed and why |
| Pull request review | Shows an approver for every change |
| Code owners file | Names who is responsible for each document |
| Search and links | Staff can find the procedure from the code it describes |
| Branch protection | Stops silent edits |
The weak point is findability for people outside engineering. If a support lead needs the procedure and cannot open the repository, publish a rendered copy and note where it lives.
Steps to make runbooks assessment ready
- List the operational tasks that matter: deploy, rollback, restore, rotate credentials, onboard, offboard, respond to an alert.
- Make sure each one has a runbook, even a short one, in a standard folder.
- Give every runbook a header with owner, last reviewed date and the system it covers.
- Assign owners through a code owners file so reviews route correctly.
- Set a review interval, such as every six months, and track it with a recurring ticket.
- Test at least the restore and rollback runbooks by following them, and save the notes from each test.
The last step is what separates a procedure from a wish. A runbook that someone has followed under realistic conditions is far stronger than one that reads well.
Signs a runbook is stale
It references a tool you no longer use. It names a person who has left. It has no review date. Its commands fail when pasted into a terminal. A restore guide that was never run counts here too.
Pick the ten runbooks that matter most and walk through them in one sitting. Fix what is broken, date the review in the header and commit it. That commit is your evidence.
Where Safeguard fits
Safeguard offers compliance and evidence automation alongside SBOM and dependency scanning, which can help you collect dated records in one place. You can try the free scan at gold.safeguard.sh/scan. The decision on whether evidence is sufficient stays with your assessor.
Quick check
Does a runbook need to be a formal document?
The title asks for documented procedures but does not set a format. Short, clear, owned and current pages in a repository are common in software teams. Check your certification body expects nothing more.
How many runbooks do we need?
Cover each operational task that affects security or availability. Quality and currency matter more than count.
Sources
- ISO 27001 Annex A controls list, Security Compliance Guide
- ISO 27001 Annex A controls explained, Glocert International
Last reviewed: 19 October 2026.
