What is an SOP, and how do you write one people actually follow?

An SOP is ignored for one of four reasons, and none of them is that staff are careless:

• It was written by someone who does not do the task, so it describes the process as management imagines it rather than as it runs.
• It has no owner per step, so when a step is skipped nobody is the person who skipped it.
• It says nothing about what to do when a step fails, so the first exception sends the reader back to asking a colleague, and the document is never opened again.
• It was written once, the tool changed, and the document now describes a screen that no longer exists.

Each of those failures has a fix that is part of writing the document, not part of enforcing it. The method below is those fixes in order.

Start with one process, bounded at both ends: a trigger that starts it and a result that ends it. Onboarding a new starter begins when the offer is accepted and ends when the person has access, equipment and a signed acknowledgement. Handling a records request begins when the request arrives and ends when the response is sent and logged. A process with no clear end is two processes, and a procedure that tries to cover both will be followed for neither.

Give the process one owner, named by role. The owner is the person who runs the process most days, not the most senior person in the department. The owner walks the process with you, approves the draft and opens the review when something changes. If two people claim ownership, the procedure will be reviewed by neither.

Every step can fail: the system is down, the approver is away, the document the step needs has not arrived. For each step that can fail in a way that stops the process, say what the person should do: wait and retry, use the named alternative, or escalate to the named role. This is the section that keeps the document open after the first exception. Without it the reader learns that the procedure covers the easy case only, and stops consulting it.

Every procedure in the organisation goes on the same template:

• a header with the document ID, the version, the owner, the approver, the effective date and the review date
• a purpose and scope paragraph
• the roles
• the inputs
• the numbered steps
• the decision points
• the records and where they are kept
• the related documents
• the revision block that records each change

A reader who has used one procedure then knows where to look in all of them. A register of procedures can be kept because every document carries the same fields.

ISO 9001:2015 is a useful reference here even for an organisation that is not certified to it, because its clause 7.5 says what a controlled document looks like. The requirements sit in clauses 7.5.2 and 7.5.3 [1].

Clause 7.5.2 asks that documented information be:

• identified and described, by a title, date, author or reference number
• in a suitable format and medium
• reviewed and approved for suitability and adequacy when it is created and when it is updated

Clause 7.5.3 asks that it be available where and when it is needed, adequately protected, and changed under control, with version control as the example the standard gives.

ISO has since withdrawn the 2015 edition and replaced it with ISO 9001:2026. The clauses cited here are from the 2015 text. A template that carries those fields is structured the way auditors expect to read a controlled document, whichever standard they work to.

The table shows the numbered steps of an SOP for onboarding a new starter, not the whole procedure. A full version adds the inputs, the decision points and the failure route for each step.

Step four's failure route reads: if the access matrix has no entry for the role, the IT administrator asks the line manager to confirm the nearest listed role and records the decision on the checklist. Step five's reads: if the acknowledgement is not returned within five working days, the HR lead reminds the line manager and records the date. Two sentences, and the procedure survives its first two exceptions.

Some sectors do not leave it to convention. In healthcare administration, the HIPAA Security Rule at 45 CFR 164.316 requires covered entities and business associates to keep the policies and procedures that implement the rule in written form, which may be electronic. Paragraph (b)(2) of the section then sets three requirements for that documentation [2]:

• retain it for six years from the date it was created or the date it was last in effect, whichever is later
• make it available to the people responsible for carrying out the procedures
• review it periodically, updating it in response to environmental or operational changes that affect the security of electronic protected health information

That is a description of a controlled SOP library, written as a rule.

Healthcare organisations write procedures for access requests, workforce access, incident handling and records retention to this requirement. Clinical procedures and clinical SOPs are a different discipline and are out of scope for this guide and for our work.

Financial services has the same kind of rule. In the United States, FinCEN's customer due diligence rule at 31 CFR 1010.230(a) requires covered financial institutions to establish and maintain written procedures reasonably designed to identify and verify the beneficial owners of legal entity customers, and to include those procedures in their anti-money-laundering programme [3].

Procedures of that kind are the operational half of an AML/KYC manual: customer due diligence, enhanced due diligence, monitoring and reporting. Each is written step by step with the record it leaves, because the examiner samples the records.

Where no rule names the procedures, the business decides which to write first. A small business usually starts with the HR procedures that sit under its handbook, such as leave requests, grievances and onboarding, because those are the ones a new manager asks for first.