ISO 27001 Documented Operating Procedures Explained

Security breaks down when critical tasks rely on memory, habit, or assumption. Over my 30 years in governance, risk, and compliance, I have seen far too many businesses build impressive technical architectures, only to suffer catastrophic outages or data leaks because “Dave in IT” was on holiday and nobody else knew how to execute a complex database failover, apply a firewall patch, or perform a routine backup restoration. Relying on individual knowledge rather than documented, repeatable procedures is an operational risk waiting to explode. Operational discipline is what keeps your business resilient when key personnel move on or chaos strikes.

ISO 27001:2022 includes Annex A 5.37 to ensure your organisation documents, maintains, and makes available operating procedures for all security-relevant activities. This control updates former 2013 requirements (12.1.1) and shifts the focus toward practical, usable playbooks that eliminate variability, enforce consistent security controls, and protect operations during routine and emergency scenarios.

Quick Summary: What ISO 27001 Annex A 5.37 Requires

At a practical level, Annex A 5.37 is about capturing operational knowledge so tasks are performed consistently, securely, and reliably regardless of who carries them out. It does not require creating bureaucratic, 50-page manuals for making coffee or sending routine emails; it expects a risk-based approach to documenting critical procedures. Here is what you need to do in plain English:

Identify Security-Relevant Tasks: Map all operational activities across IT, facilities, HR, and SecOps where human error or inconsistency introduces security risk.
Write Clear, Practical Playbooks: Document exact step-by-step instructions—covering tools required, exact command-line syntax, permissions, and security precautions.
Define Roles & Responsibilities: State explicitly inside each procedure who is authorized to execute the task, who approves changes, and who acts as the escalation point.
Include Error Handling & Escalation: Detail precise steps to take when a procedure fails midway, including rollback instructions and emergency contacts.
Ensure Accessibility & Version Control: Store operating procedures in a central, searchable, access-controlled repository (e.g., central wiki/knowledge base) and keep them updated.
Review and Test Procedures Regularly: Re-evaluate procedures annually, after major incidents, or whenever underlying systems undergo significant change (Annex A 8.32).

Why Undocumented Operations Present Critical Hazards

When security-relevant operations exist only as “tribal knowledge” in someone’s head, your business becomes dangerously vulnerable to single-point-of-failure human risks, inconsistent security enforcement, and prolonged outage recovery times.

Ignoring documented operating procedure controls exposes your business to severe hazards:

Single Point of Failure (“Key-Person Risk”): Critical systems going unmaintained or failing during emergencies because the sole employee who knows the operational steps is unavailable, ill, or has resigned.
Inconsistent Security Configurations: System administrators deploying new servers or network switches using ad-hoc, unapproved settings that introduce unpatched vulnerabilities (Annex A 8.9).
Failed Disaster Recovery Execution: Technical teams panicking during a ransomware outbreak or backup restoration because step-by-step recovery playbooks do not exist (Annex A 5.26).
Severe Onboarding Friction: New hires making critical operational mistakes or delaying project timelines because standard operating procedures (SOPs) are missing.

My 8 Step Plan to Implement Annex A 5.37 Fast

You do not need an army of technical writers to satisfy an ISO 27001 auditor. Here is my pragmatic, 8-step plan to establish an audit-ready operating procedure framework.

1. Catalog Security-Relevant Operational Activities

Audit your operational environment to identify every task requiring formal documentation (Annex A 8.9):

System Administration: Server provisioning, OS patching routines, active directory management, and firewall rule changes.
Data Management & Backups: Backup execution, off-site media transfer, tape rotation, and backup restoration testing (Annex A 8.13).
Incident & Event Management: SIEM alert triage, malware containment steps, and security event reporting workflows (Annex A 6.8).
Physical & Facilities Ops: Server room access management, HVAC/UPS testing, and physical badge provisioning (Annex A 7.2).

2. Standardize Your Operating Procedure Template

Ensure all SOPs follow a consistent, easy-to-read structure so staff can execute them flawlessly under stress:

Header Info: Document title, owner, version number, approval date, and security classification level.
Purpose & Scope: What the procedure achieves and which systems/teams it applies to.
Prerequisites & Roles: Required user permissions, specialized software, and authorized execution roles (Annex A 8.3).
Step-by-Step Execution: Numbered, chronological instructions with screenshots, code snippets, and exact CLI commands.
Rollback & Error Handling: Instructions on how to revert changes safely if the procedure encounters an unexpected error.

3. Embed Security Controls Directly into Procedures

Procedures should not just describe how to make a system work; they must detail how to make it work *securely*:

Incorporate mandatory verification steps (e.g., “Verify SSL certificate validity before putting server into load balancer”).
Specify least-privilege requirements (e.g., “Execute script using dedicated service account, never root/domain admin”).
Include change management reference tags linking the procedure execution to an approved Change Request ticket (Annex A 8.32).

4. Document Exception Handling and Incident Escalation

Operational tasks do not always go smoothly. SOPs must guide operators when unexpected scenarios arise:

Define explicit thresholds for when an operational anomaly should be escalated to senior management or SecOps.
List primary and secondary emergency contact details (names, phone numbers, on-call schedules) directly inside the SOP.
Detail immediate containment actions (e.g., “If server fails health check post-patching, isolate machine from network immediately”).

5. Centralize and Secure SOP Access

Operating procedures add zero value if staff cannot find them or if unauthorized users can tamper with them:

Host all SOPs inside a centralized, searchable digital repository (such as a secure internal wiki, Confluence, or SharePoint).
Apply strict Role-Based Access Control (RBAC) ensuring only authorized technical leads can edit procedures (Annex A 8.3).
Ensure offline or out-of-band copies of critical disaster recovery SOPs are available during total network/cloud outages.

6. Train Staff and Verify Operational Transferability

A procedure is only successful if a qualified colleague can execute it without calling the author for help:

Conduct cross-training sessions where junior engineers or secondary staff execute procedures under observation (“dry runs”).
Use feedback from dry runs to refine ambiguous steps, update outdated screenshots, and fix broken command syntax.
Incorporate SOP walkthroughs into technical onboarding checklists for new hires.

7. Synchronize SOPs with Change Management

Systems change constantly. Ensure your documentation evolves alongside your technical infrastructure:

Mandate that every system upgrade, architectural modification, or new tool deployment includes a requirement to update relevant SOPs before change approval (Annex A 8.32).
Include “SOP Updated?” as a mandatory checkbox on your formal Change Advisory Board (CAB) review forms.
Archive deprecated procedure versions cleanly to maintain an auditable historical trail without confusing operational staff.

8. Conduct Routine Annual SOP Reviews and Audits

Outdated operating procedures create false confidence and lead to severe operational mistakes during crises:

Assign explicit named owners to every SOP who are responsible for reviewing and re-certifying accuracy at least annually.
Trigger mandatory SOP reviews immediately following any major security incident, operational outage, or audit finding.
Provide anonymized sample SOPs (e.g., backup restore SOP, user offboarding SOP) as evidence during ISO 27001 audits.

Common Implementation Pitfalls and How to Fix Them

When preparing clients for ISO 27001 audits, I frequently spot the same operating procedure mistakes. Here are the main traps and how to solve them:

Problem: Over-Documenting Every Minor Activity Creating Document Maintenance Paralysis
Ninja Solution: Focus strictly on high-risk, security-relevant, multi-person, or infrequent tasks where inconsistency creates real business risk.
Problem: Procedures Written as High-Level Vague Bullet Points Lacking Step-by-Step Instructions
Ninja Solution: Write SOPs as practical, executable recipes with exact command strings, file paths, parameters, and screenshots.
Problem: SOPs Stored in Scattered Personal Folders or Hard Copies Locked in a Desk Drawer
Ninja Solution: Centralize all procedures in a single, access-controlled internal wiki or document management system.
Problem: Outdated Procedures That Reference Retired Servers, Legacy Apps, or Departed Staff
Ninja Solution: Link SOP updates directly to your change management workflow and enforce automated annual owner review reminders.

The ISO 27001 Ninja Bottom Line

ISO 27001 Annex A 5.37 is about replacing individual memory and informal habits with repeatable, auditable operational discipline. Technology alone does not deliver security; secure, day-to-day execution by your people is what keeps your information assets protected.

By mapping security-relevant tasks, standardizing playbook templates, embedding security checks into daily tasks, detailing rollback steps, centralizing access in a secure wiki, cross-training staff, linking updates to change management, and enforcing annual reviews, you build true operational resilience, eliminate key-person risk, and satisfy your ISO 27001 auditor with complete confidence.