A.5.37 Documented operating procedures: evidence and audit

What A.5.37 documented operating procedures requires in practice

A.5.37 asks for operating procedures for information processing facilities to be documented and made available to the personnel who need them. For an audit or a customer questionnaire, that means two things must be provable: a written procedure exists for each operation that matters, and the people who run those operations can actually find and use it. The control is not satisfied by a policy that says procedures exist, and it is not satisfied by a folder that nobody opens. The assessor will look for the procedures themselves, their owners and their dates, and then ask an operator to show where they would find one. The risk the control addresses is inconsistent operation. When a backup restore, a firewall rule change, a server build or a failover depends on what one engineer remembers, the result varies with who is on shift, knowledge leaves with people who resign, and errors appear during change and recovery, which are the moments when systems are least stable. The control carries forward ISO/IEC 27001:2013 control A.12.1.1, so organizations that were certified under the earlier edition already had this expectation. The hard part is drift: procedures are accurate on the day they are written and wrong after the next platform upgrade. ISO/IEC 27002:2022 gives the implementation detail for this control, and it is the right place to read what an auditor will expect beyond the wording of the control itself.

Start by listing the operations that touch information processing facilities: provisioning, patching, backup and restore, monitoring, certificate renewal, capacity changes, and recovery. Confirm with each system owner which of these they run, which are performed by a supplier, and which depend on a supplier's documentation that you have not checked. Then decide who owns each procedure, how often it is reviewed, and what triggers an update, such as a change request, an incident or a new version of the platform. Ask your auditor or certification body how they expect the review cycle to be evidenced, because the answer varies by organization and scope. Procedures that cannot show an owner, a review date and a recent test run tend to be the first findings raised.

Which systems and teams the operating procedures must cover

A.5.37 applies to the information processing facilities the organization actually runs, so the scope decision comes before any writing. Each card below names a system or team whose procedures an assessor will expect to find, and what to confirm about each one in your own environment.

Production systems and applications

Production environments are the first place an assessor looks, because they hold the information the ISMS protects. Procedures should cover how each production service is started, stopped, scaled, patched, monitored and restored, including the order of steps and who may run them. Confirm that every production system in the asset inventory has a matching procedure, and that the procedure names the version of the platform it describes.

Backup and restore operations

Backup jobs are operating procedures in their own right, and a restore is only evidence if someone can follow the written steps. Document schedules, retention settings, encryption handling, restore tests and the escalation path when a job fails. Check that the restore procedure has been exercised by the team that would run it in an incident, not only by the person who wrote it.

Network, identity and logging infrastructure

Firewalls, directory services, certificate authorities and log pipelines are often run by a small group and forgotten in scope discussions, yet they underpin access control and evidence. Procedures for changing rules, rotating keys, onboarding identity providers and forwarding logs should be written and kept current. Confirm that log retention and time synchronization steps are covered, since later investigations depend on them.

Cloud consoles and infrastructure as code

Work done in cloud consoles and through infrastructure as code both count as operating activity, and auditors increasingly ask which one is authoritative. Define which changes must go through code review and pipelines, and which console actions are permitted for break-glass use. Confirm that the procedure for console access covers account creation, administrator roles and how console changes are recorded.

Teams and their handover points

Procedures are only useful to the people who run the systems, so map each procedure to a named team and to the staff who cover it when someone is away. Shared responsibilities, such as platform teams handing off to application owners, are where gaps usually appear. Ask each team to name the procedures it relies on and to confirm that they have read access to them.

Managed and third-party services

Where a provider runs a system, the organization still needs procedures that describe its own part, such as how it requests changes, reviews provider reports and reacts to outages. The provider's own documentation does not replace these records. Check the contract and service descriptions to see which steps the provider performs, and document the organization's steps alongside them.

How an assessor tests operating procedures

This table walks through the test steps an assessor typically follows for A.5.37, the evidence each step requests and the findings that most often appear. Read it as a pre-audit checklist: each row is something the auditor will try to confirm in your environment, not a pass or fail rule.

Test step	What the assessor checks	Common findings
Confirm procedures exist for each in-scope facility	Procedures cover every information processing facility inside the ISMS scope, including data centers, server rooms, network operations and any hosted environments, mapped against the scope statement	Procedures exist for the main data center but not for a secondary site or cloud landing zone in scope
Check approval and ownership	Each procedure has a named owner and an approver, and the approval is recorded with a date	Procedures are unsigned, owned by a departed employee or approved by no one with authority
Check versioning and currency	Version history shows when each procedure changed, what changed and who changed it, and the current version matches the process actually run	Steps reference retired tools, old hostnames or decommissioned platforms; no revision date for years
Sample operators	The assessor asks staff to locate the procedure for a task they perform and to walk through it, comparing their steps with the document	Staff cannot find the document, use a personal copy, or follow a workaround that is not written down
Check accessibility	Procedures are stored where the people who need them can reach them, including during an outage, with access permissions that match the audience	Procedures sit only on the system they describe, so they are unavailable when that system fails
Compare with configuration records	Documented settings, backup schedules and build steps are compared with the live configuration or infrastructure-as-code repository	Documented values differ from production, or configuration changed with no procedure update
Compare with change records	Changes to procedures and to the systems they cover are traced through the change management process, showing that updates followed the change record	Procedures changed informally, or a change ticket exists with no matching procedure revision
Request evidence of review	Records of periodic review, triggered reviews after incidents or major changes, and the outcome of each review	Review date set in the document but no review record exists, or reviews are skipped after platform upgrades

Sequence for documenting and maintaining operating procedures

This sequence takes an organization from an inventory of its information processing facilities to a set of approved, published and reviewed operating procedures that an auditor can trace back to real operation. Each step names its output so the work can be checked as it progresses.

Inventory the facilities that need procedures
Start by listing the information processing facilities that run in the organization's scope: production and staging environments, data center or cloud accounts, network devices, backup systems, logging platforms, build pipelines and the administrative consoles that operate them. Record the owner of each facility and the teams that operate it, using the same boundary as the ISMS scope statement. The output is a register of facilities with an operator and an owner for each, which becomes the list every later step checks against. Confirm with the asset inventory under A.5.9 so that no facility appears in one list and is missing from the other.
Define a template and owner for each procedure
Agree one template that every operating procedure follows, with fields for purpose, scope, preconditions, numbered steps, expected results, rollback or recovery actions, required access, records produced and the version history. Assign a named owner to each procedure, normally the team that performs the task, and a reviewer who understands the system. The output is an approved template and a procedure index listing each planned document with its owner and the facility it covers. Keep the template short enough that operators will actually complete it.
Write procedures from observed operation
Have the owner write each procedure by describing how the task is actually performed, then check the draft by walking through the steps on the system or in a test environment. Capture commands, console paths, configuration keys and approvals as they are used today, not as they were designed years ago. Where the practice differs from what was intended, record the gap and decide whether to change the practice or the document. The output is a draft procedure that a competent operator can follow without asking the author for help, plus a list of open gaps.
Approve and publish to the right audience
Route each draft to its approver, typically the service owner and an information security reviewer, and record the approval with name, date and version. Publish the approved version in a controlled repository that the operators who need it can reach, and restrict edit rights to the owners. Keep superseded versions available for audit. The output is an approved, versioned procedure with an access list that matches the people who run the facility. Check that the publication location is documented and that operators can find it from the facility register.
Link procedures to change and configuration management
Connect each procedure to the change management process under A.8.32 and the configuration management process under A.8.9. Require that any change to a facility, such as a new release, a firewall rule or a backup schedule, updates the affected procedure before or as part of the change record. Record the configuration baseline each procedure assumes so that drift can be detected. The output is a traceable link from each change ticket to the procedure it modified, and a configuration baseline that the procedure describes.
Set review triggers and a periodic review cycle
Define the events that force a review, such as a change to the facility, a security incident, a failed execution during an audit or a new version of the platform, and set a periodic review interval for procedures that rarely change. Assign who receives the trigger and who signs off the updated version. The output is a written review rule for each procedure and a log of reviews completed, including procedures reviewed without change. Ask the organization to confirm its chosen interval and triggers in its own ISMS documentation, since the standard does not prescribe them.
Evidence the procedures during internal review
Before an external audit, sample several procedures and ask an operator to perform the task from the document alone, then compare the result with the recorded change history. Check that the version in use matches the approved version, that the owner and approver are current and that the review log is complete. The output is an internal review record listing the procedures tested, the results and the corrective actions. Independent auditors and certification bodies will decide whether this evidence meets the requirement, and this internal check is the organization's own preparation for that decision.

How a version-controlled wiki keeps procedures current

A wiki or document platform gives an auditor for A.5.37 Documented operating procedures the things they ask for most: a visible history of each procedure, a record of who changed it and when, and a way to see what the procedure said on any past date. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. Those features matter because an auditor testing this control wants to see that the procedure in use on a given day is the one that was approved, not a copy edited later. Confirm in your chosen version and edition that page history, diff views and restore are enabled and that history cannot be purged by ordinary editors.

Version history only helps if the people who can change a procedure are limited. In BookStack, user abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical setup gives operations staff edit rights on the books for their own systems, gives approvers the ability to publish, and gives a broader audience read-only access to the rest. Document this matrix as part of the procedure set itself, because an assessor will ask who could have edited a runbook and who actually did. Confirm the role and permission model, the available override levels and the audit trail for permission changes in the version you plan to run, since the exact options can differ between releases.

Neither tool approves a procedure on its own. The organization still needs a named owner for each procedure, a review interval, and a record of approval that sits alongside the wiki version, such as a ticket or a sign-off field in the page. Decide whether the wiki is the system of record or only a pointer to one, and set a rule for how emergency changes are written up after the fact. Ask any implementation partner to show how a page moves from draft to approved to retired, and how a retired version is kept for the retention period your records control requires. Be clear that these platforms produce the evidence; the independent auditor decides whether it satisfies the control.

Evidence that satisfies A.5.37 and how to keep it current

An auditor testing A.5.37 looks for three things: procedures that exist, reach the people who run the facilities, and stay accurate as systems change. The cards below cover the artifacts that show each of these, and the routines that keep them current between assessments.

Procedure library with owners and approval dates

The core artifact is a register of every operating procedure for information processing facilities, with a named owner, the approver, the approval date and the next review date on each entry. Auditors usually start by picking a few systems, such as a backup job, a firewall rule change or a server build, and asking for the matching procedure. A procedure with no owner or no approval date is hard to defend, even when its content is correct. Confirm that the register covers hosting, network, and identity operations, not only the security team's own runbooks.

Version history of each procedure

Auditors want to see how a procedure changed, not only its current text. Wiki or document tools that keep every revision, record who changed it and when, and allow two versions to be compared give that trail without manual copies. Check that a rollback does not erase the record of the change that was rolled back. The version history is also the evidence that a procedure was reviewed rather than written once and forgotten.

Access records for who can read procedures

A.5.37 requires procedures to be available to the personnel who need them, so access settings are evidence too. Export the role and permission assignments for the shelf or space holding the procedures, and confirm that operators can read their runbooks while people outside the operating group cannot edit them. Review these records during access reviews, since a departed engineer who can still edit a runbook is a finding. Shared or public links to procedures should be listed and justified.

Acknowledgements and training records

Availability is not the same as awareness. Keep records showing which staff were told about a procedure, when they acknowledged it, and which version they acknowledged. Tie these to role membership so that a new operator is assigned the relevant runbooks at onboarding. When a procedure changes materially, the acknowledgement should be reissued. Ask the owners to confirm that the records match the people who actually perform the task, not only the people on the org chart.

Change tickets linked to procedure updates

Most procedures go stale through change, not through the calendar. Require that a change ticket affecting a facility, such as a new hypervisor, a revised backup schedule or a new firewall zone, names the procedures it touches and records their update. Auditors often sample recent changes and trace them forward to the procedure. A ticket that changes a system while leaving its runbook untouched is a common nonconformity. Confirm the link is enforced in the change workflow rather than left to memory.

Scheduled reviews between audits

Between audits, keep procedures current with a review calendar that assigns each procedure a cycle based on how often the system changes and how much harm a stale instruction could cause. Each review should record that the owner checked the steps against the live system, not only that the document was opened. Overdue reviews are visible in the register and should be escalated to the owner's manager. The review cycle itself should be stated in the procedure policy, so the auditor can compare practice against what the organization promised.

What meeting A.5.37 costs in money and effort

This table breaks down each cost component of keeping A.5.37 operating procedures documented, who is paid for each one, and whether it is one-time or recurring. Read it to see where money and staff time go, what pushes those costs up, and what to request in a written quote. No price or duration is given because none has been researched for this control.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Writing procedures	Internal process owners, possibly an external consultant for drafting	One-time for the first set, then recurring for new or changed processes	Number of information processing facilities, system complexity and how many procedures already exist in some form
Approval and sign-off	Control owners and managers who authorize each procedure version	Recurring with each revision	Number of approvers, whether approval is formalized in a workflow, and how often procedures change
Tooling and licenses	Software vendor or no license fee for open-source wiki platforms	Recurring if commercial, otherwise minimal	Choice of platform; self-hosting removes license spend but not hosting or administration
Hosting and administration	Internal platform team or an implementation partner under a written scope	Recurring for hosting, upgrades, backups and access administration	Deployment model, backup frequency, number of users and integration with identity systems
Periodic review	Process owners and the security function checking procedures against actual practice	Recurring at the review interval set in the organization's own procedure	Churn rate of systems and processes, and whether reviews are tied to change management
Auditor sampling time	Set by the certification body in its audit plan, paid through the certification fee	Recurring at each audit visit	Number of procedures sampled, number of sites and how easily staff can show the current version
Optional external review	Independent reviewer or consultant, engaged under a fixed scope	Optional and occasional	Scope of review, number of procedures examined and whether internal staff have capacity to prepare evidence

Who writes, reviews and tests the procedures

Your organization owns its controls, so the people who run the facilities own the procedures that describe how those facilities are operated. Operators and system owners write and maintain the day-to-day steps, while a named approver, usually the owner of the process or service, signs off each procedure before it is published. Your information security function sets the standard for what a procedure must contain and checks that approvals happened.

Procedure owners: Name one accountable owner for each procedure, recorded in the document itself, so an auditor can see who answers for its accuracy.
Operators as authors: The people who perform a task write its steps, because they know the actual sequence, tools and exceptions.
Approval records: Keep a dated approval for each version, showing who approved it and what changed.
Review schedule: Set review dates per procedure, triggered by a schedule and by significant changes to systems or staff.
Retirement: Remove or archive superseded procedures so staff cannot follow outdated steps.

Before any outside help starts, confirm that your staff can name the owner of every procedure in scope and can show the last approval for each.

Where operating procedures fail audits

Most procedure failures are not missing documents. They are documents that stopped matching the systems they describe, had no accountable owner, or could not be reached when someone needed them. Each card below names one gap, why an assessor notices it under A.5.37, and the check that closes it.

Written once, never reviewed

A procedure with an approval date from the original rollout and no later review record tells an assessor that the document is treated as a one-time deliverable. A.5.37 expects procedures to stay usable, so auditors ask for the last review date and the change that prompted each update. Check every procedure for a review date and a named reviewer. Set the review interval in the document itself so the gap is visible.

Procedures describing a retired system

When a platform is migrated, upgraded or replaced, the operational steps often stay in the wiki while staff work from memory or chat messages. An assessor who walks through a backup restore or a patch run and finds steps that no longer match the console treats the procedure as ineffective, even if the control itself works. Walk one procedure step by step against the live system during each review.

No named owner

A procedure without an owner has no one accountable for accuracy, so changes slip through and nobody answers the auditor's questions about it. The owner should be the role that operates the process, not a generic team mailbox. Record the owner on every procedure page and confirm that the owner still holds that role when access reviews run.

Unavailable during an outage

Procedures stored only on the system they describe disappear when that system fails, which is exactly when staff need them. A.5.37 asks that procedures be available to personnel who need them, and assessors test this by asking staff to locate a recovery procedure without help. Keep an offline copy of recovery procedures in a location that does not depend on the failed platform, and test access from outside the production network.

Not linked to change records

When a procedure changes but the change ticket does not reference it, the auditor cannot tell whether the document was updated for the change or drifted afterward. Linking procedures to change management under A.8.32 gives a traceable record of what changed and why. Require a procedure update as a closing step in each change that alters an operated process.

Versions without a traceable history

Editing a shared document in place removes the record of what the procedure said last quarter, which is the evidence an assessor uses to test whether the procedure was followed at a given time. Version history should record what changed, when and by whom, and older versions should be recoverable. Confirm that your documentation platform keeps that history and that the audit trail is retained for the period the auditor samples.

Questions buyers ask about A.5.37

How much effort does documenting operating procedures for A.5.37 take?

The effort depends less on the number of procedures than on how many information processing facilities, platforms and teams the procedures must cover, and how many of them already exist in some form. Most of the work is in identifying which activities are repeatable and critical, writing them as step-by-step procedures, getting owners to review them and keeping them current afterwards. Ask any consultant or partner for a written scope that lists the systems, the procedures per system and the review cycle before agreeing a figure. The ongoing cost is the recurring review and update work, which is easy to underestimate because it continues after the first release.

Can we document A.5.37 procedures in-house without outside help?

Yes, an organization can write and own its operating procedures without outside help, and many do. The control asks for procedures that are documented, approved, available to the people who need them and kept accurate, which an internal team can run. Outside help is most useful when internal staff lack time to write procedures for every platform, need a documented format that an auditor will accept, or want a second reviewer. Whichever route is chosen, the organization remains accountable for the content, and an implementation partner can prepare the documentation but does not own the control.

How long does preparing documented operating procedures take?

Preparation time depends on the number of systems in scope, how much documentation already exists, and how quickly the procedure owners can review drafts. No standard duration is set by ISO/IEC 27001, so the schedule should come from a written plan rather than a generic estimate. Ask for a milestone plan that lists which platforms are documented first, who reviews each procedure and when the first full review cycle is due. Starting with the most critical facilities usually makes the early evidence easier to show during a readiness review.

What does the work need from system operators and procedure owners?

The work needs operators who know how the systems really run, because a procedure written from memory or from a vendor manual often misses local steps. Procedure owners must approve the content, confirm it matches practice and commit to reviewing it when the system, configuration or team changes. Operators also need to know where the current version lives and how to request a change. Typical inputs include:

Runbooks, scripts and configuration files already in use
Change records that show when steps were altered
A named owner and approver for each procedure
Access to the wiki or document system where staff look for procedures

Which procedures should we document, and how do we keep them current?

Document the procedures an operator needs to run information processing facilities correctly and consistently, such as installation, backup, restore, monitoring, startup, shutdown and routine maintenance. Keep them current by linking each procedure to a review date, an owner and the change process, so that a configuration or platform change triggers an update. Version control in the documentation tool helps, because it records what changed, when and by whom. Under the self-hosted approach, a wiki such as XWiki can keep page history and allow comparison and rollback, while BookStack can restrict editing and viewing by role. Confirm how each tool handles approval workflows and access before relying on it for evidence.

Can a consultant sign off that we comply with A.5.37?

No, a consultant or implementation partner cannot sign off compliance with A.5.37. Only an independent certification body can certify an organization against ISO/IEC 27001, and only an accredited auditor can assess whether the control is met during an audit. A partner can prepare the procedures, organize the evidence and run a readiness review, but the organization owns its controls and the auditor issues any report or certificate. Ask any potential partner to state this role split in writing before engaging.

Where do auditors expect to find our operating procedures?

Auditors expect to find procedures in a controlled, identifiable location that the people who run the systems can reach, with evidence that the current version is approved and that older versions are retired. They usually sample a procedure, ask the operator to demonstrate it and compare the steps with the system's actual configuration and change records. A clear index, owner names, approval dates and review history make this process faster. Ask your auditor early which repository and format they will accept, since requirements can vary between certification bodies.

How DeployOpen prepares operating procedures for assessment

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the operating procedures those platforms depend on for assessment. The organization keeps ownership of its controls, and an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which systems, facilities and procedures fall inside the A.5.37 procedure set before work starts
Map each procedure to the owner who approves it and the staff who must be able to find it
Confirm the document platform, access model and review cycle that the written scope depends on

How we build

Draft procedures from how the self-hosted platforms are actually installed, operated, backed up and upgraded
Set up the documentation platform with version history, approval records and role-based access to the pages
Test that a sample of procedures matches the running configuration, and correct any gaps found

How we hand over

Deliver the procedure set, its ownership register and the review schedule as documented in the agreed scope
Walk your operations and platform teams through where procedures live, how to request changes and how to retire them
Provide a record of the version history and approvals that an assessor can sample during review

How we support

Offer ongoing support as a retainer to update procedures after upgrades, configuration changes and staff turnover
Review procedures on the cycle your ISMS sets, so the documented steps keep matching the live environment
Confirm with your certification body which evidence it will sample, since assessors set their own sampling approach