Overview
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.
SOP vs. policy vs. guideline vs. checklist: which one to use
A policy defines what is required: 'all customer data must be encrypted at rest.' It does not describe how to do it, only that it must be done. Policies are maintained at the leadership or compliance level and rarely change. When an auditor asks 'what is your position on X?', the policy is the answer.
A guideline defines what is recommended: 'when reviewing third-party contracts, we recommend including a security SLA clause.' Guidelines allow exceptions. Someone can choose not to follow them with a reasonable justification. They are orientation, not obligation.
A checklist defines what must be confirmed as done, but not necessarily how to do each item. A product launch checklist might include 'validate production configuration' without specifying who validates it, what steps to follow, or what the evidence of validation should look like. Checklists are useful for confirmation, not for standardized execution.
An SOP combines the rigor of a policy with the operationality of a checklist, and adds what both leave out: sequence, role-based accountability, and an evidence standard. It is the only one of the four that simultaneously answers 'what to do', 'who does it', 'in what order', and 'how to prove it was done.' That is why SOPs are the central instrument of execution-driven compliance programs.
The four components of an SOP that holds up in an audit
The first component is scope: what the SOP covers and under what conditions it applies. A poorly defined scope produces SOPs that people ignore because they believe it doesn't apply to their situation. The scope should answer: which process, in which team or business unit, triggered by which event, and with which documented exceptions.
The second is sequence: each step in order, with the role responsible for each. The distinction between role and person is critical. 'Marcos approves' stops working when Marcos leaves. 'The Compliance Manager approves' works regardless of who holds the role. Each step should have a single responsible role, not two, and the sequence should not allow steps to be skipped or reordered.
The third is the evidence standard: what proof of completion looks like at each step. This is the component most SOPs omit, and it causes the largest problems in audits. 'Completed' is not evidence. 'Screenshot of the system showing approved status, saved in ticket #XYZ before end of day' is evidence. The evidence standard must be specific enough that any auditor, without additional context, can verify the step was executed correctly.
The fourth is version control: who owns the SOP, when it was last approved, what changed in this version, and who approved the change. Without this component, you cannot demonstrate in an audit that the SOP in effect when the work was done is the one the team followed. Version numbers, review dates, and approval records transform a living document into an auditable record.
When to review an SOP: the triggers compliance teams actually use
Calendar-based review is the most common trigger: each SOP has a mandatory review date, typically annual for low-risk controls and semi-annual for critical ones. The problem with calendar-only review is that SOPs can become outdated well before the scheduled date, if a process changes, a regulation is updated, or an audit finding is identified.
Event-based triggers are more reliable: (1) a regulatory change that affects the process covered by the SOP; (2) an internal or external audit finding that identifies a gap in execution; (3) an operational incident or non-conformance tied to the process; (4) a system or tooling change that alters how the work gets done; (5) an organizational change that affects the responsible roles.
The most reliable signal that an SOP needs review is when execution records systematically diverge from what the SOP describes. If the workflow produces evidence of a different sequence than documented, or with different roles than specified, there is a gap between the SOP and reality. That gap is exactly what auditors look for, and what creates regulatory exposure even in teams that believe they are in compliance.