ISO 27001 A.5.37: Write Operating Procedures People Can Use

What A.5.37 requires in practice

Control A.5.37 requires operating procedures for information processing facilities to be documented and made available to the personnel who need them. Operating procedures describe how routine tasks are done, such as starting and stopping systems, backup, handling errors and maintenance.

Two things matter in practice. First, the procedures exist in a form people can follow, covering the tasks that affect security. Second, they are available to those who need them at the point of work, not locked away. The control says nothing about format or length. A short checklist may serve better than a long manual, and a procedure that nobody uses fails the intent however polished it looks. Procedures should also be kept up to date as systems change.

Choose detail according to the task and audience

Identify activities where incorrect performance could affect information security. Consider the competence of the intended users, frequency of the task and consequences of a mistake. An experienced administrator may need prerequisites and decision boundaries more than screenshots of familiar screens; a new operator may need a clearer sequence and explanation.

State the purpose and conditions for starting. Identify required authority, dependencies and information needed before execution. A procedure that begins halfway through an expert’s mental process will fail when another competent person follows it without that background knowledge.

Explain the expected result and how it is checked. Completing all steps does not prove success if the procedure never asks whether the intended state was achieved. Use clear decision points where results differ from expectations and identify when the operator should stop or seek support.

Document exceptions without encouraging improvisation

Operating instructions should address foreseeable errors and escalation. Avoid telling users simply to “resolve any issue” when that could mean changing permissions, bypassing controls or losing evidence. Identify the limits of authorised action and the route to someone competent to decide.

Include dependencies on other tasks and teams. A backup restoration may need application coordination; a scheduled process may depend on a previous job completing. The procedure should reveal these relationships so that an apparently successful local action does not create a wider failure.

Why usable operating procedures matter to the business

When procedures live in one person's head, the business depends on that person being present and consistent. Errors during routine operation, such as a missed backup or an incorrect configuration, often come from tasks done differently by different people. Clear, available procedures reduce mistakes, speed up the training of new staff and make handover and cover arrangements dependable. They also support continuity, since a stand-in can follow what the regular operator would do. Auditors look at whether procedures match what is done, which shows whether documentation is trusted by those who use it.

How to implement A.5.37

Write procedures with and for the people who do the work. A practical approach follows. Procedures fail when they are written at a desk by someone who does not do the task. Sit with the operator, watch the task and capture what really happens, including the awkward steps. Aim for short documents with clear steps, supported by screenshots or checklists where they help. Review each procedure whenever the underlying system changes, and ask users, not just owners, whether the instructions still work.

1. List the routine tasks that support information processing and affect security.
2. Ask the people who do them to describe how the task is actually performed.
3. Write short, clear steps in the language of the team, including what to do when something goes wrong.
4. Make the procedures easy to find at the point of work.
5. Assign an owner who keeps each procedure current.
6. Update procedures when systems or tasks change.
7. Check with a new or stand-in operator that the procedure can really be followed.

Illustrative IT example: a restart procedure assumes hidden knowledge

Illustrative manufacturing example: a rarely used archive export

A hypothetical manufacturer exports historic production records only when a customer requests them. The written procedure references an old software version and does not explain how to protect the resulting files. Staff improvise a shared folder when the usual export destination is unavailable.

The record owner and system administrator revise the instructions, including authorised destination, retrieval verification and handling of failed exports. A test uses representative non-sensitive data. The procedure now supports both the task’s technical outcome and the protection of the information it creates.

Make the current procedure available at the point of use

Store procedures where authorised personnel can find them when needed. Consider whether an outage could make essential instructions inaccessible. Availability does not mean unrestricted publication: operating procedures can reveal sensitive configuration and recovery information.

Manage local copies and embedded links carefully. A printed emergency instruction or saved offline version may be justified, but it needs an owner and an update route. A link that always opens the current procedure can help during normal work, yet it may not solve access during disruption.

Update instructions when the operation changes

Assign responsibility for reviewing and authorising changes. System updates, new dependencies and lessons from incidents can all make an instruction inaccurate. Connect relevant changes with change management so that implementation and documentation remain aligned.

Ask users to report unclear or incorrect steps through a usable route. A procedure repeatedly bypassed by experienced staff may be out of date or impractical. Investigate the reason before assuming that more forceful wording will improve compliance.

Evidence should demonstrate usability

Common nonconformities with A.5.37

Findings often show documents that do not match practice. Findings often show documents that do not match practice. An auditor may watch an operator perform a routine task and compare what happens with the written procedure, noting any differences and asking the operator whether the document is ever used.

• Routine tasks performed from memory with no written procedure.
• Procedures that are out of date after a system change.
• Procedures held where operators cannot reach them.
• Staff doing the task differently from what the procedure describes.