Control Definition
Operating procedures for information processing facilities must be documented and made available to the personnel who need them, so that security-relevant operations are performed correctly and consistently rather than from memory.
Control Objective
To make sure systems and security operations run correctly and securely no matter who performs the task, by turning critical operational knowledge into accessible, current documentation.
What This Really Means
Every operations team has a bus-factor problem: tasks that live entirely in one person's head. The restore only one engineer has ever run, the certificate renewal that "Priya handles", the offboarding steps everyone half-remembers differently. A.5.37 is the anti-bus-factor control: write down how security-relevant operations are actually performed, keep the write-ups current, and put them where the people who need them can reach them — including at 3am, mid-incident, when the author is on a plane.
The control sits at the bottom of the documentation hierarchy, and the layers should not blur. Policies (A.5.1) say what the organization requires and why; standards set the measurable spec; procedures say exactly how — steps, commands, screens, owners, error handling — for a specific operator doing a specific task. ISO 27002 offers sensible triggers for when an activity deserves a documented procedure: when many people must perform it the same way, when it is performed rarely enough to be forgotten, when it is new and risky if done wrong, and before it is handed to new personnel. Map those triggers onto a real environment and you get the classic runbook set: backup and restore, incident escalation, onboarding and offboarding (the joiner-mover-leaver flow), deployment and rollback, log review, patching, certificate renewal, and break-glass access.
A usable procedure carries more than steps. It names the responsible roles, the prerequisites and scheduling dependencies, the expected outputs, what failure looks like and what to do about it, escalation contacts including external vendor support, and links to neighboring procedures. Availability cuts both ways: operators must be able to find and open procedures without friction — which is why a searchable wiki near the work beats Word files in a forgotten share — yet some procedures reveal enough sensitive detail (break-glass credentials handling, key ceremonies) that access to them should be restricted. And the procedures you need during an outage cannot live only on the systems that are down: keep an out-of-band copy of the incident and recovery runbooks.
The other half of the control is currency. Procedures are living documents: version controlled, with named owners, reviewed when the systems they describe change — which in practice means wiring them into change management (A.8.32), so a change is not closed until the affected runbooks are updated. Auditors test exactly these seams: they pick a procedure, compare it against observed practice and the recent change log, and check whether someone who did not write it can actually follow it. A runbook last touched two years before a platform migration tells them everything.
Why It Matters
Key-person dependency is an availability risk wearing a personnel badge. Organizations usually discover its price at the worst moment: during an incident, when the only person who knows the recovery sequence is unreachable, or the week after a resignation, when a routine operation suddenly has no operator. Documented procedures are cheap insurance against an expensive and statistically certain event — people leave, rotate, and sleep.
Procedures are also what make operations verifiable and improvable. An undocumented operation cannot be checked for compliance (A.5.36 has nothing to check against), cannot be handed over cleanly, cannot be automated sensibly, and cannot be improved after an incident — the post-incident review has no baseline to compare the actual response to. Consistency, evidence, and learning all start from the written step.
Organizations that run on tribal knowledge face:
- •Key-person dependency – critical operations stall or fail when a single knowledgeable person resigns, falls ill, or is simply on leave during an incident
- •Errors under pressure – recovery and escalation performed from memory at 3am skip steps that a runbook would have enforced, turning incidents into outages
- •Inconsistent execution – the same task done three ways by three people produces unpredictable security outcomes and untraceable failures
- •Slow, risky handovers – every new joiner relearns operations by trial and error against production systems instead of following a tested path
- •Confidently wrong runbooks – stale procedures that describe the previous platform are worse than none, because operators trust them right up to the step that breaks something
Regional Compliance Context
For India-connected organizations, two CERT-In obligations live or die inside operating procedures. The six-hour incident reporting window is met in practice by the escalation runbook — who classifies, who drafts, who submits, with the reporting channel and format pre-staged — not by anyone's memory of the directions. And the 180-day log retention requirement belongs as an explicit parameter inside the log management procedure, so retention survives administrator turnover and platform migrations rather than living as tribal knowledge.
Implementation Guidance
Identify the Operations That Need Procedures
Apply four triggers across IT and security operations: tasks many people must perform identically, tasks performed rarely enough to forget, tasks that are new and risky if done wrong, and tasks facing handover. The usual output: backup and restore, incident escalation, joiner-mover-leaver, deployment and rollback, patching, log review, certificate renewal, break-glass access. Rank by the cost of getting the task wrong — that is your writing order, and your defense against documenting everything.
Pick One Format and One Home
Define a light template — purpose, owner, prerequisites, steps, expected output, error handling, escalation contacts — and a single platform where procedures live: a wiki or runbook tool adjacent to the work, searchable, linkable from alerts and tickets. Scattered Word documents in shared drives are where procedures go to die. One home also makes review status and ownership visible at a glance.
Write at the Level of the Operator, Then Test It
Assume a competent person who has never done this task: exact commands, screens, and decision points, not "configure the backup appropriately". The only test that matters is execution by a non-author — have someone else follow the procedure end to end and fix every step where they stumble. A cheap capture trick: record the screen or shell history while the current expert performs the task, then transcribe.
Build In Error Handling and Escalation
Every procedure needs the unhappy path: what failure looks like at each risky step, the safe rollback or recovery action, restrictions on improvisation (when to stop rather than push on), and who to call — internal escalation and external vendor support with contract or ticket references. Most 3am damage is done after step one fails and the operator starts guessing.
Make Procedures Available — and Restrict the Sensitive Ones
Grant read access to everyone who might need to execute each procedure, including on-call staff and the people covering for them. Restrict procedures whose detail is sensitive — break-glass access, key ceremonies, security tooling internals — to the roles that perform them. Keep an out-of-band copy of incident and disaster recovery runbooks, because the wiki is sometimes part of the outage.
Version Control and Tie Updates to Change Management
Keep procedures under version control with named owners and visible last-reviewed dates. Wire currency into A.8.32: the change workflow includes a "procedures updated" step, and a change is not closed while affected runbooks describe the old world. Docs-as-code — procedures in the repository, updated in the same pull request as the change — is the strongest version of this pattern for engineering-heavy teams.
Keep Procedures Alive Through Drills and Reviews
Exercise the high-stakes runbooks on a schedule — restore tests, incident drills, a walked-through offboarding — and treat every stumble as a documentation defect to fix that week. Add a procedure-accuracy question to post-incident reviews. Sweep the full inventory on a cadence (annually is common): confirm owner, confirm currency, and retire dead procedures, because a graveyard of stale pages buries the live ones.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.37:
Documentation
- Procedure inventory or index with owners, locations, and last-reviewed dates
- Sample runbooks — backup and restore, incident escalation, joiner-mover-leaver, deployment and rollback — at operator level of detail
- Version history showing procedures updated when the systems they describe changed
- Change records demonstrating procedure updates as a step in change closure
- Access configuration for the procedure platform: broad for operators, restricted for sensitive procedures
Interviews
- Operations or platform engineers on where procedures live, when they last used one, and how updates happen after changes
- A recent joiner on whether the documented procedures were actually sufficient to perform real tasks
- The on-call or incident lead on how escalation procedures are reached during an outage, including out-of-band access
Observations
- An operator performing a sampled task — a restore test, an offboarding — against the documented procedure, with deviations noted
- The procedure platform inspected live: search, version history, review dates, ownership, links from alerts or tickets
- A procedure's last-updated date checked against the change log of the system it describes
Practitioner Insights
There are two kinds of operating procedures: written for the auditor and written for the operator, and you can tell them apart in ten seconds. The auditor-facing kind is a 40-page Word file in SharePoint that says "ensure backups are performed appropriately"; the operator-facing kind is a wiki page with the exact commands, the expected output, and what to do when step four fails — and it happens to be the only kind that passes a serious audit, because I ask the engineer on shift to open the procedure they actually use. The test before any audit: hand each critical runbook to someone who has never done the task and watch. Every place they stop and ask a question is a defect in the document, not in the person.
The first thing I cross-check on this control is dates: the procedure's last update against the change log and incident history of the system it describes. A backup runbook untouched for two years while the platform moved to a new cloud provider is not documentation — it is a trap, and it usually predicts what the restore test will show. The deeper issue is governance: management owns key-person risk, and a procedures program is how that ownership becomes visible. I pay attention to whether runbook updates are a required step in change closure, because that single workflow rule is the difference between procedures that decay and procedures that track reality.
Common Challenges & Solutions
Challenge
Engineers resist writing documentation — "the system is the documentation" — and runbooks never get written.
Solution
Lower the cost of authorship instead of arguing: capture the screen or shell history while the expert performs the task once, transcribe it into the template, and have a second person verify by execution. Make runbook creation part of the definition of done for new services, and adopt docs-as-code so procedures live in the repository engineers already work in. An imperfect captured procedure today beats a polished one promised for next quarter.
Challenge
Procedures go stale the moment they are written, because nothing forces updates when systems change.
Solution
Attach currency to existing workflows rather than willpower: a mandatory "affected procedures updated" field in the change template (A.8.32), a procedure-accuracy question in every post-incident review, and a named owner plus visible review date on each document. Surface staleness mechanically — a report of procedures past their review date — and treat the worst offenders as backlog items with owners, not as a someday cleanup.
Challenge
Documentation is scattered across Word files, drives, tickets, and personal notes, so nobody trusts or finds it.
Solution
Consolidate into one searchable home near the work — a wiki or runbook platform — and migrate by priority: the procedures for your riskiest operations first, the long tail as it gets touched. Redirect or delete the old copies so a stale duplicate cannot outrank the live page, and link procedures directly from the alerts, dashboards, and tickets where the work starts. Findability is half of "made available".
Challenge
The procedures needed during an outage live on systems that are down — the wiki, the SSO, the password manager.
Solution
Identify the minimum set needed when everything is broken — incident escalation, disaster recovery, break-glass access — and keep an out-of-band copy: an offline export refreshed on a schedule, a secondary location, or printed copies for the truly critical few. Verify access paths that do not depend on the primary identity provider, and test the arrangement during DR drills rather than during the real thing.
Challenge
Over-documentation: hundreds of procedures exist, most outdated, and the volume itself makes maintenance impossible.
Solution
Prune to what the triggers justify: tasks needing consistency across people, rare-but-critical tasks, risky new tasks, and handover candidates. Retire or archive everything without a plausible operator, and resist procedure-per-click granularity — one well-owned runbook per operation, with judgment left to competent operators. A maintained set of thirty beats an abandoned set of three hundred, and auditors can tell which one they are looking at.
