Every operations team eventually builds a SOP library. Detailed documents. Clear sections. Formatted consistently. Then an auditor asks to see the controls that ran last quarter, and the honest answer is: here's the document we wrote, but we can't prove it was followed. That gap — between the SOP as a document and the SOP as an executed record — is the most common compliance failure mode.
An SOP — Standard Operating Procedure — is a written document that defines exactly how a recurring task must be performed. Unlike a policy (which defines what is required) or a guideline (which defines what is recommended), an SOP defines precisely how the work gets done: the sequence of steps, who is responsible for each, what inputs are required, and what the output must look like. SOPs exist wherever consistency matters — regulated industries, quality management, compliance controls, customer-facing operations.
Three things separate a useful SOP from documentation theater. First: it specifies an owner by role, not by name — 'the Finance Manager approves this step' survives turnover, 'Marcos approves this step' doesn't. Second: it defines a sequence that cannot be reordered — the evidence requirement for step 4 assumes step 3 was completed. Third: it produces a record at the end of each run — not a status update, but proof that the specific person in the specific role completed the specific step with the specific output.
The reason most SOP programs fail is not bad writing — it's that SOPs live where they're created, not where work happens. A PDF in a wiki gets consulted before the task. An SOP embedded in the workflow tool gets executed during the task. The difference is whether the SOP is a reference artifact or a runtime. Reference artifacts get out of date. Runtimes get enforced.
A useful SOP has four components: (1) the scope — what it covers and under what conditions it applies; (2) the sequence — each step in order with the role responsible; (3) the evidence standard — what proof of completion looks like at each step; (4) the version and review date — who owns it, when it was last approved, and what triggered this version. Without the fourth component, you cannot prove in an audit that the SOP in effect when the work was done is the one the team actually followed.
The practical starting point: pick the one SOP that caused the most problems in your last audit cycle. Not the most complex — the one with the most 'we couldn't produce the evidence' moments. Write it as a four-component document. Then build it as a workflow. Run both in parallel for one cycle. After that, the workflow is the SOP.