Annex A 5.37: Documented Operating Procedures

Annex a 5.37: documented operating procedures requirement means you must write down how critical, security-relevant operational tasks are performed, keep those procedures current, and prove people follow them. To operationalize it, inventory repeatable operations, standardize procedures with owners and change control, train users, and retain execution evidence tied to each procedure (ISO/IEC 27001 overview; ISMS.online Annex A control index).

Key takeaways:

• Document the “how” of operations that affect information security, not just high-level policies (ISO/IEC 27001 overview; ISMS.online Annex A control index).
• Make procedures controlled documents: owners, versioning, approvals, and periodic review records.
• Audit-readiness hinges on evidence that procedures are followed (tickets, logs, checklists, sign-offs), not the document alone.

A 27001 audit rarely fails because an organization has no policy. It fails because the “policy stack” does not translate into consistent execution. Annex A 5.37 addresses that execution gap by requiring documented operating procedures for activities that need to be performed consistently and correctly to protect information security (ISO/IEC 27001 overview; ISMS.online Annex A control index).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat 5.37 as an operations control: identify the security-relevant routines your teams perform, document the minimum viable procedure for each routine, then build a simple mechanism to prove the routine happened as designed. This control becomes a backbone for auditability across IT, Security, and business operations because it forces clarity on roles, tools, steps, and approvals.

This page gives requirement-level implementation guidance you can put in motion immediately: applicability, step-by-step execution, artifacts to retain, common audit questions, and a practical 30/60/90-day plan. It is written to support assessment readiness under ISO/IEC 27001:2022, with operator-focused interpretation of Annex A 5.37 (ISO/IEC 27001 overview; ISMS.online Annex A control index).

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.37 implementation expectation (Documented Operating Procedures).” (ISO/IEC 27001 overview; ISMS.online Annex A control index)

Operator meaning: You need written procedures for operational activities that impact information security, and those procedures must be controlled (kept current, accessible to users, and used in practice). Auditors will test two things: (1) the procedure exists and is appropriately managed as documented information, and (2) teams follow it with evidence that the procedure is executed.

Plain-English interpretation

Documented operating procedures are the “runbooks” and work instructions that convert intent into repeatable action. Policies say what must be true; procedures say how staff make it true, step by step. Under Annex a 5.37: documented operating procedures requirement, you should be able to answer, for any critical security-relevant operation:

• Who does it?
• When does it happen and what triggers it?
• What exact steps do they follow?
• What tools/systems do they use?
• What records prove it happened correctly?

Who it applies to (entity and operational context)

Applies to: Organizations implementing an ISO/IEC 27001:2022 ISMS, particularly service organizations where repeatable operations must be consistent across staff, shifts, and locations (ISO/IEC 27001 overview).

Operational contexts that typically fall in scope:

• IT operations: account provisioning, backups, patching, change management handoffs.
• Security operations: alert triage, incident response steps, vulnerability handling workflow.
• Platform/SaaS operations: release processes, break-glass access, customer support actions that touch production data.
• Business operations with security impact: onboarding/offboarding, physical access administration, records disposal.

Scoping rule you can use: If an activity is (a) repeatable and (b) a mistake could cause confidentiality, integrity, or availability harm, it should have a documented procedure and evidence trail.

What you actually need to do (step-by-step)

Step 1: Build a “procedure inventory” tied to security outcomes

Create a list of operational activities that must be performed consistently. Start with:

• High-risk systems (identity provider, endpoint management, cloud control plane, core databases).
• High-risk events (employee termination, privileged access grant, production change, incident declaration).
• Compliance dependencies (controls that require repeat performance and evidence).

Practical output: A spreadsheet or GRC register with columns: Process name, owner, system(s), trigger, frequency (if applicable), evidence type, repository link.

Step 2: Set a standard procedure template (reduce document sprawl)

Use one template for all operating procedures. Keep it short and testable:

Minimum fields

• Purpose and scope (what systems/environments)
• Roles and responsibilities (RACI-style)
• Preconditions (access required, approvals, change ticket required)
• Procedure steps (numbered, tool-specific)
• Exceptions and escalation path (what to do when it fails)
• Records/evidence produced (tickets, logs, reports)
• Version history + approval
• Review cadence trigger (e.g., “review on major system change”)

Avoid long narrative prose. Auditors and operators both prefer steps they can execute.

Step 3: Assign ownership and change control (make it “documented information”)

Operating procedures must not be personal notes. Put them under document control:

• Named owner (functionally accountable)
• Approver (often security/IT management)
• Versioning and change log
• Defined publishing location (single source of truth)

Decision point: If procedures live in a wiki, enforce page controls, approvals, and version history. If you use a ticketing tool, link each procedure to the relevant workflow and required fields.

Step 4: Embed procedures into the way work happens

A documented procedure that is not used will fail an audit test. Hardwire procedure usage into execution paths:

• Ticket templates that require selecting the procedure and capturing outputs.
• Checklists in change tickets (pre-change, post-change validation).
• Required attachments (e.g., backup verification report).
• Automation hooks where feasible (e.g., scheduled reports saved to an evidence folder).

Rule: A procedure should produce at least one piece of evidence without extra work. If evidence requires manual screenshots, adoption drops.

Step 5: Train and confirm competence for procedure users

For each procedure, identify “users” and ensure they can find and follow it:

• New-hire onboarding for operators includes procedure walkthroughs.
• Change communications include “procedure updated” summaries.
• Acknowledgement can be lightweight (ticket comment, LMS attestation, or recorded team training).

Step 6: Prove operating effectiveness with recurring evidence capture

Annex a 5.37: documented operating procedures requirement becomes audit-ready when you can show:

• The procedure exists, is approved, and is current.
• Recent executions follow the procedure.
• Exceptions are handled via defined escalation.

Evidence approach that works in practice: For each critical procedure, keep a rolling set of recent execution records in a structured evidence folder, mapped to the procedure ID.

Step 7: Periodically review and rationalize

Procedure sets grow quickly. Set a review mechanism:

• Review on material change (tool migration, org change, system re-architecture).
• Review after incidents or near misses (procedure gap often emerges).
• Consolidate duplicates; retire irrelevant procedures with a record of retirement.

Required evidence and artifacts to retain

Retain artifacts that show both design (the procedure) and operation (proof it is used).

Core artifacts (design)

• Procedure document/runbook in a controlled repository (owner, version, approval).
• Procedure inventory/register mapping procedures to systems/processes and control coverage.
• Change history or document revision log.
• Access controls on procedure repository (who can edit vs view).

Operating evidence (effectiveness)

• Tickets showing procedure execution (change, incident, access requests).
• Checklists completed within ticketing tool.
• System logs or reports produced by the procedure (backup verification outputs, patch reports).
• Approvals (CAB notes, manager approval records, security approval).
• Training/attestations for staff who execute the procedures.

Retention tip: Keep evidence in a way that survives staff turnover. Personal folders and ephemeral chat threads do not hold up well in audits.

Common exam/audit questions and hangups

Auditors tend to probe the same failure modes:

1. “Show me the procedure for X and the last time you ran it.”
   Expect selection of a high-impact routine: backup restore testing, joiner/mover/leaver, production access grants.

2. “Who approves changes to procedures?”
   They look for controlled change, not ad hoc edits.

3. “How do you ensure people follow procedures?”
   Strong answers reference workflow embedding: ticket templates, required fields, and evidence outputs.

4. “How do you handle exceptions?”
   Auditors expect an escalation path with documented approval and retrospective review.

5. “Are procedures available to those who need them?”
   If procedures are locked away, execution becomes tribal knowledge.

Frequent implementation mistakes and how to avoid them

Mistake 1: Writing “policy-like” procedures

Symptom: A one-page document that says “backups are performed” with no steps.
Fix: Force numbered steps, tool names, and records produced.

Mistake 2: No link between procedure and evidence

Symptom: Procedure exists, but tickets/logs are scattered with no traceability.
Fix: Add a required “Procedure ID/link” field in tickets and standardize where outputs are stored.

Mistake 3: Procedures drift after tooling changes

Symptom: Cloud console screenshots no longer match reality.
Fix: Trigger a review when systems change. Make “procedure updates” a task in the change plan.

Mistake 4: Over-documenting low-value tasks

Symptom: Hundreds of procedures, none maintained.
Fix: Start with security-relevant repeatables. Expand only when a gap appears in audits or incidents.

Mistake 5: Single person dependency

Symptom: Only one admin knows how to execute a critical procedure.
Fix: Cross-train and require at least one backup operator to execute periodically, producing evidence.

Enforcement context and risk implications

ISO 27001 is a certifiable standard rather than a regulator with direct fines in the way a government agency operates, so “enforcement” typically shows up as:

• Audit nonconformities (minor/major) tied to missing or stale procedures, or lack of operational evidence.
• Customer due diligence failures where buyers expect runbooks for critical operations, especially in service organizations (ISO/IEC 27001 overview).

Risk-wise, undocumented procedures correlate with operational fragility: inconsistent access removal, incomplete incident steps, unreliable backups, and ad hoc production changes. Those failures can become security incidents, availability events, or contractual breaches, even if the root cause is “process,” not “technology.”

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Appoint an executive sponsor and an operational owner for procedure governance.
• Build the procedure inventory for critical operations (identity, access, backups, changes, incidents).
• Publish a standard template and a controlled repository location.
• Draft or clean up the top procedures that map to your highest-risk systems.
• Define evidence expectations per procedure (what you will retain and where).

Days 31–60 (embed into workflows)

• Add ticket templates/checklists that reference each procedure.
• Train operators and managers on “where procedures live” and “what evidence to attach.”
• Run a tabletop or dry-run audit: pick two procedures and trace end-to-end evidence.
• Add exception handling: define who approves deviations and how they are recorded.

Days 61–90 (operate, measure, and close gaps)

• Perform internal sampling: select recent tickets and verify procedure adherence.
• Tune procedures based on operator feedback (remove friction, clarify steps).
• Implement periodic review triggers (system changes, incidents, quarterly ops review meeting).
• Centralize recurring evidence capture so auditors can self-serve samples.

Where Daydream fits (without adding process debt)

If you are tracking ISO controls in spreadsheets, 5.37 becomes a scramble during audits because evidence is scattered. Daydream is a natural fit when you want one place to map Annex A controls to documented procedures and recurring evidence capture, then keep that evidence organized for assessment readiness (ISO/IEC 27001 overview; ISMS.online Annex A control index).

Frequently Asked Questions

Do we need a documented procedure for every IT task?

No. Focus on repeatable activities where mistakes can create security risk or service impact. Start with identity/access, backups, changes, incident handling, and platform operations.

Can our ticketing workflow count as the “documented operating procedure”?

Often yes, if the workflow is explicit, controlled, and accessible, and it includes the steps, responsibilities, approvals, and required evidence. Auditors still expect it to be managed like documented information (owner, change control, version history).

What’s the difference between a policy, standard, and operating procedure under ISO 27001?

A policy sets intent and management direction. A standard sets required rules or configurations. An operating procedure provides step-by-step instructions operators follow and the records they produce.

How do we prove people followed the procedure without screenshots?

Prefer system-generated records: tickets with required fields, automated reports saved to a controlled folder, and immutable logs from administrative systems. Design procedures so execution naturally produces these artifacts.

What if a procedure can’t be followed in an emergency?

Document an exception path: who can approve a deviation, what minimum safeguards apply, and what retrospective review is required. Then retain the approval and post-event review notes as evidence.

Can third parties execute our procedures?

Yes, but you still own the control outcome. Ensure contracts and onboarding require the third party to follow your procedures (or their equivalent), and ensure you receive the execution evidence you need for audits.