SekitCrosswalk
ENES
Start now
ISO/IEC 27001:2022 · derived mapping target

A.5.37Documented operating procedures

Document the procedures for operating your IT and information processing facilities, and make them available to those who need them. Clear procedures keep operations consistent and reduce mistakes.

Mapping at a glance
A.5.37Documented operating proceduresISO/IEC 27001:2022
RCF-0003Policy managementGovernance & Risk · TechnicalRCF-0055CMDB qualityAsset Management · PolicyRCF-0218Vulnerability scanningVulnerability & Configuration · ProcessRCF-0221Vulnerability remediation SLAsVulnerability & Configuration · ProcessRCF-0230Patch prioritizationVulnerability & Configuration · Process

A.5.37 is covered by 15 Sekit CSF controls. +10 more in the table below. Open in the full graph →

Mapped from the Sekit CSF

The Sekit controls that cover this requirement, lens by lens.

RCF-0003Policy management · TechnicalsupportsThis technical control enforces key policy rules automatically at the system level, one form of the documented, consistently applied operating behaviour A.5.37 requires.RCF-0055CMDB quality · PolicyenablesThis policy control designates a single authoritative source of asset and configuration information, the foundation operating procedures under A.5.37 reference when describing how systems are run.RCF-0218Vulnerability scanning · ProcesssupportsThis process control runs vulnerability scans on their planned schedule and assigns findings for action, a documented recurring procedure A.5.37 expects for this operational task.RCF-0221Vulnerability remediation SLAs · ProcesssupportsThis process control tracks every open vulnerability against its deadline and escalates before it slips, the kind of documented operating discipline A.5.37 requires.RCF-0230Patch prioritization · ProcesssupportsThis process control applies patch prioritisation consistently each cycle and records exceptions to the standard schedule, the documented procedure A.5.37 expects for patching.RCF-0239Backup policy · ProcesssupportsThis process control executes backups on schedule and investigates every failed run rather than letting failures accumulate, the operating discipline A.5.37 requires for backups.RCF-0248Restore testing · ProcesssupportsThis process control restores data from backups on a recurring schedule and records whether recovery worked, the documented verification step A.5.37 expects.RCF-0256Runbooks for recovery · PolicysupportsThis policy control requires documented step-by-step recovery procedures for every failure that would stop a critical system, one instance of the documented procedures A.5.37 requires across IT operations.RCF-0257Runbooks for recovery · ProcesssupportsThis process control keeps recovery runbooks current with system changes and requires responders to follow them rather than memory during incidents, the currency A.5.37 demands of operating procedures.RCF-0258Runbooks for recovery · TechnicalsupportsThis technical control provides tooling that walks responders through recovery steps and records what was done, operationalising the documented procedures A.5.37 requires.RCF-0265Playbooks · PolicyrelatedThis policy control maintains short, approved incident response playbooks for likely scenarios such as ransomware and phishing, a related category of documented procedure alongside the operating procedures A.5.37 covers.RCF-0343Cloud logging · PolicyrelatedThis policy control states in writing which cloud activity must be logged and for how long, a documented operating requirement adjacent to the procedures A.5.37 covers for IT facilities.RCF-0400Change management · PolicysupportsThis policy control requires that no change reaches production without prior review and approval, one instance of the documented operating procedures A.5.37 requires for change management.RCF-0415Problem management · PolicysupportsThis policy control establishes a written expectation that recurring incidents are investigated to root cause and tracked to resolution, a documented operating procedure A.5.37 covers.RCF-0424Patch/compensating controls (ICS) · PolicysupportsThis policy control defines a written approach for handling vulnerabilities in systems that cannot be patched normally, including when compensating measures apply, one of the operating procedures A.5.37 requires documented.

NIST CSF 2.0 counterparts

Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.

RC.RP-01 Recovery plan executedID.RA-05 Inherent risk understoodRC.RP-02 Recovery actions performedRC.RP-03 Backup integrity verifiedPR.PS-02 Software maintainedPR.IR-04 Adequate capacity maintainedID.RA-07 Changes and exceptions managedRS.MA-04 Incidents escalatedDE.CM-01 Networks monitoredID.AM-05 Assets prioritized by criticalityID.RA-01 Vulnerabilities identified and recordedPR.DS-10 Data-in-use protectedGV.PO-02 Cybersecurity policy maintainedDE.CM-03 Personnel activity monitoredGV.RM-06 Standardized risk method establishedPR.PS-03 Hardware maintainedID.IM-04 Response and recovery plans maintainedID.AM-02 Software inventory maintainedID.AM-01 Hardware inventory maintainedRS.MA-02 Incident reports triagedDE.AE-03 Information correlatedGV.PO-01 Cybersecurity policy establishedID.IM-02 Improvements from tests and exercisesRS.MA-03 Incidents categorized and prioritizedRS.AN-07 Incident data preserved

ISO/IEC 42001:2023 — Annex A counterparts

A.6.2.5 AI system deployment

Cyber Essentials counterparts

CE3.2 Apply critical updates within 14 daysCE2.2 Change default and guessable passwordsCE2.3 Enforce device unlocking credentials

Evidence that proves this control

What an auditor, or Sekit's evidence engine, asks for.

Backup configuration and restore-test record
How backups are made (what is backed up, how often, where they are stored) and the proof that a restore has been tested successfully.
Disaster recovery plan and runbooks
The plan defining how long each critical system can be down (RTO/RPO) and the step-by-step guides to recover it after a serious failure.
Change and release management records
The process to review and approve changes to production systems before applying them, and how new versions are released in a controlled way.
From the Sekit evidence catalog

In practice

In practice this control shows up as runbooks: a written, step-by-step procedure for each recurring or high-risk operation, from applying a patch to restoring a backup to responding to an incident, kept current enough that someone unfamiliar with the system could follow it. Auditors ask to see the runbook used in the last real incident or restore test and compare it against what happened during that event. The common failure mode is a procedure written once for the audit and never updated after the environment changed underneath it.

Common gaps

Change and release records show approvals happened, but the underlying operating procedure was never updated to match how the change was carried out.
The restore-test record exists for one system but the documented recovery runbook was not followed step by step during the test.
Recovery runbooks reference server names and tools that were retired months ago, so the document would mislead a responder during a real incident.

Questions your auditor will ask

Can you show the runbook a responder followed during a recent incident?
The playbook for that incident type, matched against the disaster recovery plan and runbooks record showing the steps taken and their timestamps.
How current are your operating procedures against the live environment?
Runbooks are reviewed and updated after every system change, verified by the change and release management records showing the procedure was checked at that time.
Is a restore from backup tested on a schedule, or only assumed to work?
The backup configuration and restore-test record shows a scheduled test with a documented outcome, not merely a backup job completing.
Do you have a written procedure for patching systems that cannot be patched on the normal schedule?
The patch and compensating-controls procedure for these systems states the alternative measures used and who signed off on the deferral.

Where regulation demands it

NIS2 6.4 requires documented change management, repairs and maintenance procedures, the exact operating procedures A.5.37 asks the company to write down and keep current.
ENS op.exp.5 requires Gestión de cambios, a documented change process that is one instance of the operating procedures A.5.37 covers.

Related controls

Via the shared Sekit CSF topic, not the framework's own index.

A.5.1 Policies for information securityA.5.4 Management responsibilitiesA.5.7 Threat intelligenceA.5.9 Inventory of information and other associated assetsA.5.24 Information security incident management planning and preparationA.5.26 Response to information security incidentsA.5.27 Learning from information security incidentsA.5.30 ICT readiness for business continuity
Ask Sekura: “What evidence proves A.5.37?”
Also via MCP, free with account