Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Organisational Control

A.5.37 — Documented Operating Procedures

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.37 ISO 27001ISO 27002BSI OPS.1.1.1

The senior system administrator is on holiday when the primary database server crashes at midnight. The on-call engineer knows the system exists but has never restored it. There is no documented procedure. After four hours of trial and error, the database is back online — with data loss that a correct restore sequence would have prevented. A.5.37 requires that operating procedures are documented, current and available to everyone who might need them.

Operating procedures translate policies into actionable steps. While policies define what must be done, procedures specify how to do it. Without documented procedures, operational knowledge resides in the heads of individual employees — and is lost when they are unavailable, leave the organisation or simply forget.

What does the standard require?

  • Document operating procedures. Procedures for activities affecting information security must be documented and made available to the personnel who need them.
  • Cover critical operational activities. Documentation must address system installation and configuration, backup and restore, job scheduling, error handling, restart and recovery, log management, and change management.
  • Define responsibilities. Each procedure must specify who is responsible for performing, approving and reviewing the activity.
  • Include escalation contacts. Procedures must identify who to contact when unexpected situations arise or when the procedure cannot be completed successfully.
  • Review and update regularly. Procedures must be reviewed at planned intervals and after significant changes to systems, processes or personnel.

In practice

Inventory your operational activities. List all recurring and ad-hoc activities that affect information processing security. Prioritise by risk: what is the impact if this activity is performed incorrectly? Start documenting the highest-risk procedures first.

Use a consistent template. A standard template ensures completeness and makes procedures easier to follow. Include: purpose, scope, prerequisites, step-by-step instructions, expected outcomes, error handling, rollback steps, escalation contacts and revision history.

Store procedures where operators can find them. A procedure buried in a document management system that the on-call engineer cannot access at 3 a.m. is useless. Ensure procedures are accessible from the systems where they are needed — ideally through a wiki, runbook platform or operational documentation portal that is available even during outages.

Test procedures through execution. Have someone who was not involved in writing the procedure follow it step by step. If they encounter gaps, ambiguities or incorrect steps, update the document. This walkthrough test is the most effective quality assurance for operational procedures.

Typical audit evidence

Auditors typically expect the following evidence for A.5.37:

  • Procedure library — central repository of all documented operating procedures
  • Procedure inventory — list of all required procedures with owner, version, last review date and next review date
  • Version control records — evidence that procedures are version-controlled with change history
  • Review records — documentation of periodic reviews, including any updates made
  • Access evidence — demonstration that relevant personnel can access the procedures they need

KPI

% of operational procedures documented and reviewed within the last 12 months

This KPI measures the currency and completeness of the procedure library. Track the total number of required procedures, the number that are documented and the number that have been reviewed within the past 12 months. Target: 100%.

Supplementary KPIs:

  • Number of critical systems without a documented operating procedure
  • Average age of procedures (time since last review)
  • Number of procedure updates triggered by incidents or changes

BSI IT-Grundschutz

A.5.37 maps to numerous BSI modules requiring operational documentation:

  • OPS.1.1.1.A3 (Administrative and operational regulations) — requires documented procedures for all security-relevant administrative activities.
  • OPS.1.1.2.A11 / OPS.1.1.3.A11 — operational procedures for system administration and network operations.
  • BSI-Standard 200-2, Chapter 5.2.2 — documentation requirements for the ISMS including operational procedures.
  • ISMS.1.A13 — ISMS documentation management.
  • CON.8.A12 — operational procedures for software development.
  • OPS.1.2.5.A7 — remote maintenance procedures.
  • DER.2.1.A16 — incident handling procedures.
  • SYS.1.1.A21 / SYS.2.1.A40 — operating procedures for server and client systems.
  • NET.3.1.A9 / NET.3.2.A14 / NET.4.1.A10 — operating procedures for network infrastructure.

A.5.37 provides the operational detail layer beneath policies:

Sources

Frequently asked questions

What types of procedures need to be documented?

Any operational activity that affects information security and is performed regularly, infrequently or involves high risk if done incorrectly. Common examples: system startup and shutdown, backup and restore, user account provisioning, patch management, log review, incident escalation, change management and physical access procedures.

How detailed should operating procedures be?

Detailed enough that a qualified person who has not performed the task before can follow them successfully. Step-by-step instructions with expected outcomes, error handling and escalation contacts. Avoid generic descriptions that leave the operator guessing at critical decision points.

Who is responsible for keeping procedures up to date?

The process owner or system owner is responsible for the content. The document control process ensures that updates are reviewed, approved and communicated. Procedures should be reviewed at least annually and after significant changes to the systems or processes they describe.