Overview
Most compliance teams have both SOPs and workflows, and use the words interchangeably without realizing they're describing different things. That confusion creates real gaps: SOPs that are thorough on paper but unenforceable in practice, and workflows that are executed consistently but produce no evidence of the standard they followed. Getting the relationship right between the two is what separates a compliance program from a compliance library.
An SOP (Standard Operating Procedure) is a document that defines the standard. It specifies what should be done, in what order, by whom, and with what evidence of completion. It is static, a record of what the organization has decided the correct approach is. When an auditor asks 'what is your process for X?', the SOP is the answer.
A workflow is the runtime that executes the SOP. It assigns tasks, enforces sequence, triggers handoffs, gates approvals, and records evidence. It is dynamic, a live execution that produces a timestamped record of what actually happened. When an auditor asks 'show me that it ran correctly last quarter', the workflow record is the answer.
Turn SOPs into execution records
Cadenio runs your SOPs as live workflows, role-based assignment, approval gates, per-run evidence, and version links built in. The standard and the proof, in one system.
Start free, no credit cardThe difference matters most in regulated environments. An SOP without a workflow tells you what should have happened, it cannot tell you what did happen, who was responsible when it deviated, or whether the deviation was approved. A workflow without an SOP tells you what happened but not whether it was the right thing, there's no documented standard to measure against. Compliance requires both: the SOP defines the standard, the workflow proves adherence.
“The SOP defines the standard. The workflow proves adherence.”
There's a common failure mode for teams that mistake one for the other. Treat your workflow tool as an SOP library and you end up with task lists that have no documented standard, where every run can diverge without anyone noticing. Treat your SOP wiki as a workflow tool and you end up with documentation that proves nothing: the SOP was followed because someone says so, not because the system recorded it.
The practical model: maintain SOPs in your documentation system (Notion, Confluence, SharePoint). Implement them as executable workflows in your workflow tool. Version both together. When the SOP changes, the workflow version changes. When the workflow produces an unexpected record, you have evidence to update the SOP. Each system does what it does best: the SOP is the standard, the workflow is the proof.
SOP vs. workflow: four differences that matter in an audit
The first difference is static vs. dynamic. An SOP is authored once and updated deliberately, through a formal review and approval cycle. A workflow runs continuously, every time the process executes, and produces a new record each time. One is a specification; the other is a runtime. You update the SOP when the standard changes. The workflow updates when the execution changes. Both should happen together.
The second difference is what each one owns. An SOP has an author and a review owner, typically a process owner or compliance manager, responsible for keeping the standard current. A workflow has executors: the people assigned to each task in each run. Confusing who owns the document with who executes the process is one of the most common gaps auditors flag. Someone can be listed as a process owner in the SOP while having no assigned role in the actual workflow.
The third difference is what they produce. An SOP produces a standard, a statement of how the organization has decided work should be done. A workflow produces evidence: a timestamped record of what actually happened, who did it, when each step completed, and what was submitted as proof. Auditors need both. The standard tells them whether your controls are adequate. The evidence tells them whether you followed them.
The fourth difference is how they're versioned. SOPs follow document versioning: v1.0, v1.1, v2.0. Workflows follow execution versioning: every run is a record tied to the version of the process that was in effect when it ran. When you update the workflow, historical runs should still show what was running when they were created. This is what allows you to answer the audit question: 'which version of the process governed the Q3 runs?'
When to update the SOP vs. when to update the workflow
Update the SOP when the standard changes: a regulatory requirement shifts, a risk is reclassified, or the organization decides a different approach is correct. The SOP is the answer to 'what should we do?' Any change to that answer requires a SOP revision, with a new version number, a review sign-off, and a record of what changed and why.
Update the workflow when the execution changes: a step is restructured, an approval gate is added or removed, a role assignment changes, or a timing constraint is modified. The workflow is the answer to 'how do we actually do it?' Changes to the execution require a workflow update. Both changes should happen together when one causes the other: updating a SOP without updating the corresponding workflow creates a gap immediately.
The sync problem is the most common audit finding. Not that teams have no SOPs, and not that they have no workflows, but that the two exist independently with no process to keep them aligned. When the SOP changes, nobody updates the workflow. When the workflow drifts through informal adjustments, nobody updates the SOP. The result is a compliance program that looks complete on paper but produces evidence that doesn't match the documented standard.
Three ways teams create gaps between SOPs and workflows
The first is using a wiki as a workflow tool. Notion, Confluence, and SharePoint are excellent SOP repositories. They are not workflow execution systems. When teams try to run compliance processes through a wiki, task assigned in a page, completion marked by editing the document, there's no enforcement of sequence, no role-based assignment, and no evidence that survives an audit. The wiki records that someone edited the page. It does not record that the process was completed correctly, by the right person, within the required window.
The second is versioning the SOP but not the workflow. Most teams have a discipline around SOP versioning. Far fewer apply the same discipline to their workflow definitions. When a SOP is updated to v2.0, the workflow should be updated to reflect the new standard, and historical runs should remain linked to the version that was in effect when they ran. Without this link, you cannot answer the question an auditor will ask: 'prove that the process running in Q3 matched the v1.2 standard that was in effect at the time.'
The third is running workflows with no SOP backing them. The opposite problem: teams build efficient workflows in their process tool without documenting the underlying standard. The workflow exists, runs reliably, and produces evidence. But there is no document stating why the process is structured this way, what risk it mitigates, or what regulatory requirement it addresses. An auditor can see that something happened. They cannot evaluate whether it was the right thing to do, or whether it satisfied a specific control requirement.