Process Ownership: Who Should Maintain Each SOP in Your Business

You spent three months writing SOPs. Your team actually adopted them — a minor miracle. Now you’re looking at a shared folder with 40 documents and a quiet dread is setting in: who is responsible for keeping these things current?

If you haven’t answered that question explicitly, you’ve already got a problem. Six months from now, someone will update the intake form, forget to update the intake SOP, and a new hire will spend two hours doing a task the wrong way before anyone notices. Then someone will say “we should really review our SOPs” and nothing will happen because nobody owns that job.

This is post 7 in a series taking you from zero documentation to a fully documented business. Post 6 covered how to get your team to actually follow SOPs. This post covers what happens next: making sure every process has exactly one person whose name is on it.

The Core Problem: Collective Ownership Means No Ownership

When a document belongs to everyone, it belongs to no one. This isn’t a management theory — it’s just how people work. When the responsibility for keeping an SOP current is diffuse (the team owns it, the manager owns it, we all own it), maintenance falls to whoever happens to notice a problem and happens to have time and happens to feel responsible enough to act.

That person is usually nobody.

The fix is simple and a little uncomfortable: every SOP needs exactly one named owner. Not “the ops team.” Not “management.” One person. Their name goes in the document header. They are accountable for keeping it accurate.

(Applying Cialdini’s commitment and consistency principle: the moment someone’s name is on a document as the owner, their sense of personal responsibility for its accuracy increases sharply. Public commitment to a role changes behavior. This is the load-bearing reason to use names, not roles or departments.)

Who Should Own a Process?

The instinct is to assign ownership to managers. Resist it.

The right owner is almost always the person who does the process most — the person who would notice first if a step changed, who has the muscle memory, who gets the questions from newer employees. Managers are often three steps removed from the actual work. They don’t notice when a vendor changed the intake form or when accounting software added a new required field.

A few useful rules of thumb:

The owner should be able to answer “is this accurate?” without asking anyone else. If they have to check with someone before they can confirm a step is still correct, that someone should be the owner.

The owner should be the person who trains others on this process. If you’ve already done the exercise from how to extract tribal knowledge from your team, you probably know who the go-to person is for each process. That’s your owner.

Managers can own strategy processes; frontline people own operational processes. It’s fine for the owner of “how we set quarterly goals” to be the manager. It’s not fine for the manager to own “how we process a customer refund” when they haven’t processed a refund in two years.

One practical test: read the SOP aloud to the person you’re considering as owner and ask “would you have caught it if this was wrong?” If they look at you blankly, wrong person.

The Review Cadence

Naming an owner solves accountability. The cadence solves staleness.

Quarterly is the SMB default. For most businesses with 5–150 employees, a quarterly review cycle is the right starting point. It’s frequent enough to catch most meaningful changes (new tools, new regulations, process improvements). It’s infrequent enough that it doesn’t become an administrative burden.

Some processes need faster cycles:

• Any process that touches a third-party tool (pricing, intake forms, integrations) — review every time the tool has a major update
• Any regulated or compliance process — review on whatever the regulatory cadence requires
• Any process where mistakes are expensive (billing, legal, safety) — at minimum quarterly, possibly monthly

Some processes can go slower:

• Stable, physical processes that almost never change — twice a year is fine
• Pure style guides or brand voice docs — annually

The owner decides the cadence during the review, not during the initial assignment. But they need to pick one and write it down.

The Process Ownership Registry

Once you have owners and cadences, you need one place that tracks this. Don’t skip this step — it’s what prevents the “who owns the refund SOP?” conversation from happening at 4pm on a Friday.

Start with a Google Sheet. Three columns is enough:

Process	Owner	Next Review Date
Customer onboarding	Maria Chen	2026-07-01
Invoice processing	Tom Okafor	2026-07-01
New employee setup	Maria Chen	2026-08-01

Add a fourth column for the SOP location (link to the doc or the process in your SOP tool) and a fifth for “last reviewed date” when you need a paper trail. That’s your registry.

The registry has one owner too. In a team of 5–20, that’s usually the operations lead or office manager. In a team of 2–4, it’s probably you.

Review the registry at the start of every quarter. Anything with a “next review date” in the past 30 days gets flagged. The relevant owner gets a calendar reminder (or a message) to do their review. Reviews don’t have to be elaborate — “I read it, it’s still accurate, noting the date” is a valid review. The goal is deliberate, dated confirmation, not a full rewrite every 90 days.

If you’re using a dedicated SOP tool like What’s the Process For, this registry should live in the tool, not in a separate spreadsheet — your processes already have a home there, and ownership and review dates can sit alongside the process itself rather than in a disconnected document.

What Happens When the Owner Leaves

People leave. This is the most common reason SOP maintenance collapses — the person who knew the process walked out the door and took that knowledge with them.

The trigger for reassigning ownership should be formal departure, not “we’ll figure it out.” When someone gives notice:

1. Pull up every process they own in the registry.
2. As part of the offboarding, have them walk their successor through each one and confirm it’s still accurate.
3. Update the registry with the new owner before their last day.

If you do how to delegate tasks effectively, offboarding process ownership transfer is just another item on the knowledge-transfer checklist.

What if no obvious successor exists? That’s a signal, not a problem to defer. It means a critical process is owned by one person with no backup — which means you already had a fragility problem before they left. Assign an interim owner from the people closest to the process, even if the fit isn’t perfect, and flag that process for a full review within 30 days.

What If You’re a Team of Four?

You probably own most of your processes yourself. Or you and one other person split them between you.

That’s fine. Document it anyway.

Write your name next to every process. Pick review dates — even if it’s just “I’ll review these every quarter in January and July.” The act of making it explicit does two things: it prevents the “I thought you were keeping that updated” conversation, and it gives you a concrete list when you’re ready to delegate.

As you hire, the first natural handoff is any process where the new hire does the work and you do the review. Eventually, they become the owner. That transition is easier to have explicitly (“you’re now the owner of this process — you’re responsible for keeping it accurate and flagging it when something changes”) than implicitly (“I guess you know this better than me now”).

Getting Started: The First-Pass Ownership Audit

If you have existing SOPs but no owners assigned:

1. List every process you have. (If they’re in a tool, export or screenshot the list. If they’re in docs, open the folder and list them.)
2. Next to each one, write the name of the person who would notice first if a step was wrong.
3. For any process where you can’t name anyone, write your own name as interim owner.
4. Share the list with those people. Tell them explicitly: “You’re the owner of these processes. That means you review them quarterly and flag any changes. I need your confirmation you’re taking this on.”
5. Set up a shared registry — even a Google Sheet — with review dates.

That’s it. An hour of deliberate work gives you a functioning process ownership system. It doesn’t have to be sophisticated to work.

Once your SOPs are owned and current, the natural next step is turning them into a training system — so new hires aren’t just reading documents, they’re completing structured onboarding tracks. That’s covered in the next post: how to turn your SOPs into a full training system.

The Real Cost of Skipping This

Unowned SOPs don’t stay useful. They drift. Steps that used to be accurate stop being accurate. New hires follow outdated procedures. Mistakes get made that an accurate SOP would have prevented. Eventually someone says “we can’t trust our SOPs” and proposes a documentation overhaul — a project that takes months and which often doesn’t include process ownership either, so the cycle repeats.

Process ownership is a 10-minute conversation per process, done once. The alternative is an ongoing, background operational drag that you’ll never fully identify as the cause of your problems.

Name the owner. Set the date. Move on.

---

If your SOPs are documented but you don’t have a clean home for ownership and review tracking, What’s the Process For lets you keep process metadata — including ownership and review dates — inside the same tool where your SOPs live. Free trial, no credit card required.