SOP Governance: Ownership, Review Cycles, and Accountability

A procedure library is not the hard part. Writing four constraints for a usable document and picking the five processes worth documenting first, I already covered in the guide to building an agency procedure library, and keeping those documents accurate once the work underneath them moves is answered separately in the piece on why procedures go stale. Neither answers the question that actually determines whether a procedure library survives its first year: who is accountable for it, and what happens when someone ignores it anyway.

This is not a document problem. Every constraint above assumes someone already owns the outcome. Most agencies never assign that role, so the fixes get applied inconsistently, if at all, by whoever happens to notice something is wrong that week.

Who actually owns a procedure?

Every procedure needs a named owner, and the word named matters more than it sounds. Not the person who happened to write the first draft, and not whoever is currently the most reliable person on the team. The owner should be a role: the Head of Client Success owns the onboarding procedure, not Sarah. The Ops Manager owns the QA checklist, not whoever has run QA the longest. A role survives the person filling it. A name does not.

The practical version of this is smaller than it sounds. It does not need a new system. It needs a field in whatever tool already runs the work: a custom field in ClickUp or Asana, a dedicated column in Airtable, a property in Notion. One line, next to the procedure, naming the role responsible for it. If nobody can answer who owns a given procedure without guessing, the procedure does not have an owner. It has an author, which is a weaker and much less useful thing.

That is a different question from whether the document itself is current, which is what a trigger is for. Ownership answers who is responsible when it is not, not what to do about it in that moment.

What should approval require, and what should it stop requiring?

Approval is where governance quietly kills itself in either direction. Require sign-off for every edit, including a fixed typo or an updated field name after a tool’s interface changed, and people stop fixing small things because the friction is not worth it. Require none, and anyone can rewrite a client-facing commitment on a Tuesday afternoon with nobody else finding out until the client asks about it.

• No approval needed: broken links, renamed fields, typos, formatting. Anyone who catches one should be able to fix it the same day, no sign-off, no ticket.
• Owner approval needed: a change to the sequence of steps, who does what, or anything a new hire would read as the current standard.
• Owner plus one downstream approval needed: anything that changes what a client sees, is billed, or is promised. The downstream approver is whoever inherits the consequence if the change is wrong, not whoever happens to be senior.

The test for whether the tiers are right is simple. If a small fix requires the same process as a scope change, the small fixes stop happening. If a scope change requires no more than a typo does, accountability has not actually been assigned, only a formality has.

How often does an owner have to prove the procedure still works?

The piece on why procedures go stale lays out four events that should trigger an immediate review: a tool change, a client complaint, a new hire’s hesitation, a deliberate redesign. That system catches most drift as it happens. It does not answer a different, quieter question: how often does the owner have to show anyone else that the document still holds, even when nothing obvious has gone wrong.

That is a governance cadence, not a maintenance one, and it should be shorter and less flexible than it is tempting to make it. Attach it to a meeting that already exists rather than inventing a new one: the recurring ops review, the quarterly planning session, whatever room the owner already sits in. Once there, the ask is small. Confirm you still own this. Confirm nothing has quietly drifted since the last check. If something has, say so out loud, in front of someone else.

The cadence is not there to catch what a trigger missed. It is there to catch an owner who has gone quiet, which a trigger-based system cannot detect on its own, because a trigger only fires when someone notices something is wrong. An owner who has stopped paying attention notices nothing, and the calendar is the only thing left checking on them.

What happens when the owner leaves?

Role-based ownership solves half of this problem by construction. If the QA checklist belongs to the Ops Manager rather than to a specific person, the procedure has an owner again the moment someone fills the role, without anyone deciding anything. The other half still has to be done on purpose: the list of what a departing person owned needs to appear on the offboarding checklist itself, next to the client accounts and the password rotations, not discovered three weeks later when a procedure fails and nobody can say who was supposed to be watching it.

Agencies that skip this step usually have person-based ownership hiding underneath a role-based label. The title says Ops Manager, but everyone still mentally files the document under the name of whoever wrote it, and when that person leaves, the document is functionally unowned even though the org chart says otherwise. Fixing the label without fixing the habit does not fix the problem.

What actually happens when someone ignores a documented procedure?

Ask this question inside most agencies and watch the pause before the answer comes. Someone skips a step, does the client update from memory instead of the checklist, closes a ticket without the QA pass the procedure requires. What follows?

For most agencies I have worked inside, the honest answer is nothing. Maybe a comment in a hallway that gets forgotten by the next sprint. No conversation tied to the actual document, no visible consequence, nothing that reaches the review cadence above or the owner who is supposed to be watching for exactly this. If that is the honest answer at your agency, the ownership structure, the approval tiers, and the review cadence are all decoration sitting on top of a library nobody is actually required to use.

The fix is not a punishment system. Consequence does not need to mean discipline, and building an escalation ladder for a five-step checklist violation would be its own kind of theater. What it needs is visibility: the deviation gets named, in the same review where the owner already confirms the document holds, so a pattern of skipped steps is something the owner is structurally required to notice rather than something that only surfaces after a client complains. A procedure ignored once with no comment anywhere is a rounding error. A procedure ignored repeatedly with no comment anywhere is the actual state of your delivery process, wearing a document that says otherwise.

The question nobody answers is not whether to punish people for skipping a step. It is whether anyone would even notice if they did, and whether that noticing goes anywhere. Answer that honestly before writing the next procedure, because a library built on top of a silent answer to that question was decorative from the day it was approved.

So who should own SOP governance, structurally?

My basis for the structure above is twelve years running delivery operations inside marketing agencies and 92 completed engagements, working inside ClickUp, Asana, Monday.com, Airtable, and Notion, with n8n handling what should move to automation instead of staying a manual step buried inside someone’s procedure. None of that replaces checking whether the structure fits your agency specifically, but it is the record I would ask any consultant selling you a governance system to produce before believing a word of it.

Governance is not a fifth document next to the four you already wrote. It is four decisions applied to the documents you have. A named role, not a name, behind each one. Approval that scales with the size of the change instead of treating a typo and a scope change identically. A cadence that checks whether the owner is still paying attention, separate from the trigger system that checks whether the document is still accurate. And a visible answer, worked out before you need it, to what happens when someone ignores the document anyway. Skip the last one and the other three are furniture.

If you would rather someone else design and run this layer than build it yourself, that is what SOP consulting covers.

Where to start

The fastest way to find out where your library is decorative is to pick three procedures at random and ask, out loud, who owns each one, when it was last confirmed rather than just edited, and what happened the last time someone ignored it. If any of those three answers is a shrug, you have found the gap before it costs you a client. That question, asked across your whole delivery operation rather than three documents, is what the Agency Ops Audit checks: $1,500 fixed, two weeks, a written 90-day roadmap, and a 60-minute readout call that tells you exactly where ownership is real and where it is a job title with nothing behind it.