Requirement
Requirement lens
Treat this as the control objective. The implementation, evidence, and audit sections explain how to make it operational and provable.
“Operating procedures for information processing facilities shall be documented and made available to personnel who need them.”
Plain-language meaning
The organization must document operating procedures for information processing facilities and make the current approved procedures available to the people who need to use them.
Why this matters
Operations fail when critical work depends on memory, tribal knowledge, stale documents, or supplier instructions nobody can find. Documented procedures reduce mistakes, support consistency, protect confidentiality/integrity/availability, and give auditors evidence that operations are controlled.
Implementation guidance
Implementer focus
Turn this section into owners, procedures, records, review cadence, and evidence locations. A control is not implemented until it operates repeatedly.
- Identify operational activities that require documented procedures, such as start-up, shutdown, backup, restore, monitoring, maintenance, media handling, mail handling, CCTV usage, mobile working, safety, cloud administration, network operation, and incident-related operating tasks.
- Scale procedure detail to the size, complexity, risk, and frequency of the activity. Complex or infrequent procedures need clearer work instructions.
- Treat operating procedures as controlled documents with owner, approver, version, review date, change history, and access control.
- Ensure procedures are available to personnel who need them and that staff know where to find the latest version.
- Protect procedure documents from unauthorized modification and prevent use of obsolete versions.
- Include supplier or outsourced operations where relevant, using contracts, service documentation, and supplier procedures where operational responsibility sits outside the organization.
- Review whether procedures are actually followed and whether associated controls can be bypassed.
Audit guidance
Auditor focus
Look for evidence that the process operates in practice, not just that a document exists.
Auditors should verify that operating procedures are documented, complete enough for the operational environment, controlled against unauthorized change, current, accessible to personnel who need them, and actually used. Auditors should include outsourced network/cloud/service operations where responsibility is held by another team or supplier.
Evidence examples
Evidence quality
Strong evidence links requirement, owner, action, date, review, and outcome. Weak evidence usually proves only intent.
| Evidence | What it proves |
|---|---|
| Operating procedure register lists procedures, owners, approvers, users, scope, version, review date, and storage location. | Supports design, implementation, operation, or review |
| Procedures cover relevant day-to-day and infrequent operational activities. | Supports design, implementation, operation, or review |
| Procedure documents have version control, approval, change history, and access protection. | Supports design, implementation, operation, or review |
| Personnel can find the current approved procedure and explain when to use it. | Supports design, implementation, operation, or review |
| Supplier or outsourced operating procedures | Supports design, implementation, operation, or review |
Strong evidence
- Operating procedure register lists procedures, owners, approvers, users, scope, version, review date, and storage location.
- Procedures cover relevant day-to-day and infrequent operational activities.
- Procedure documents have version control, approval, change history, and access protection.
- Personnel can find the current approved procedure and explain when to use it.
- Supplier or outsourced operating procedures are available and aligned with contracts/service requirements.
- Compliance checks show procedures are followed and bypasses are identified.
Weak evidence
- Procedures exist but are scattered across chats, personal folders, or old wikis.
- Operators rely on experienced staff rather than documented steps.
- No version control or approval is applied to procedure changes.
- Obsolete procedures remain accessible.
- Supplier procedures are assumed but not available or reviewed.
- Staff cannot identify the current procedure for critical tasks.
Common failures
Implementation watchouts
These are the fastest ways this topic fails in real ISMS work.
| Failure | Why it matters |
|---|---|
| Procedures are undocumented or tribal | Operations become dependent on specific individuals |
| Procedure changes are uncontrolled | Incorrect or unsafe instructions can be introduced |
| Latest versions are not accessible | Staff may use obsolete or inconsistent methods |
| Procedures are too complex or unclear | Mistakes are more likely during stress or rare activities |
| Outsourced operations lack documented procedures | The organization cannot prove controlled operation across supplier boundaries |
Exam traps
Exam focus
Read these as distractor patterns. Exams often test scope, timing, ownership, applicability, and evidence quality.
- A.5.37 is about documented operating procedures for information processing facilities.
- Procedures must be available to personnel who need them, not just written somewhere.
- Procedures should be formal controlled documents with authorized changes.
- The level of detail should match organizational size, complexity, risk, and operational need.
- Supplier and outsourced operations still need documented procedures and service expectations.
Related controls and concepts
- A.5.36 Compliance with Policies, Rules and Standards for Information Security
- Policy Register
- Policy Review Checklist
- Supplier Security Agreement Requirements Checklist
- Supplier Service Review and Change Log
- Internal Audit
- Access Control
KB-ready summary
Quick refresher
Use this section for last-day review and for explaining the topic to a control owner.
A.5.37 is part of the assurance and operations governance layer. The practical test is whether the organization can show planned review, controlled work, competent owners, documented evidence, traceable findings, and corrective action where the process does not work.
Templates and checklists
- Iso27001
- Iso27002
- Annex a
- Organizational controls
- Governance
- Audit
- Operating procedures
- Operations
- Procedure control
- Change control
Note Metadata
Aliases: A.5.37, Documented Operating Procedures
Source: 02 Annex A Organizational Controls/A.5.37 Documented Operating Procedures.md
Control dependency map
How this control connects to work products
Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.
9
links
Requirement context
Primary control text, framework notes, or adjacent controls this note points to.
Implementation artifacts
Templates and working records that help operate the control.
Audit checks
Audit questions, checklists, or review material connected to the control.
Graph-sourced resources
Templates and evidence
Implementer templates
Working artifacts for control owners and operators.
Auditor evidence packs
Evidence collections and audit-facing verification material.
Related Notes
- Internal Audit
- ISO 27001 A.5.15 - Access Control
- ISO 27001 A.5.36 - Compliance with Policies, Rules and Standards for Information Security
- A.5 Organizational Controls MOC
- ISO 27001 A.7.13 - Equipment Maintenance
- A.5.37 Audit Evidence Pack
- AQ-ISO27001-A.5.37 Documented Operating Procedures
- ISO 27001 A.8.19 - Installation of Software on Operational Systems
- ISO 27001 A.8.20 - Networks Security
- ISO 27001 A.8.31 - Separation of Development Test and Production Environments
- ISO 27001 A.8.32 - Change Management
- ISO 27001 A.8.9 - Configuration Management
- A.5 Organizational Controls Implementation Guide
- ISO27001-A.5.37 Documented Operating Procedures
- A.5 Controls Implementation Audit Risk Mapping
- EXAM-015 - Assurance, Compliance, and Operating Procedures
- ISO 27002 Annex A Control Interpretation Map
- A.5.37 Audit Checklist
- Building Management System Security Review
- Operating Procedure Register
- Operating Procedure Review and Change Checklist
- Operational Software Installation Procedure
- Patch Testing and Rollback Checklist
- Template - Policy Register
- Template - Policy Review Checklist
- Source Code Change Control Checklist
- Supplier Security Agreement Requirements Checklist
- Supplier Service Review and Change Log
- Annex A Controls MOC