Who Is Allowed to Change an SOP? Set the Edit Rules First

Who should own SOP updates? One named person per document, with the authority to change it and the duty to keep it true. Publishing that change live is a second, narrower permission, and it does not have to sit with the same person. Write those two rules down and most of the arguments about your library stop happening before they start.

The polite standoff nobody resolves

The clearest version of this we have heard came from the administrative manager of a multi-site clinic group, about a colleague who had been editing process content in the shared library. "He should not be updating any type of process-related anything without me being involved," she said. "And that's not meant in a negative way."

She was not being territorial. She owns the library, she gets the phone call when something in it is wrong, and nobody had ever told him otherwise.

A few minutes later she described the other half of the trap, and that half was hers. "I don't want to change something somebody else did, which is what I'm stuck on. But I also don't like things being made live when they're not accurate."

Read those two sentences together. Everyone is being considerate, nothing is being corrected, and the library quietly fills with content no one feels entitled to touch. Politeness, not laziness, is a large share of why SOPs collect dust.

Nobody is refusing to fix the document; everybody is waiting for permission to.

Who should own SOP updates? Name one person per document

One person per document, named on the document. Not a department, not a committee, not "the leadership team."

At a construction consulting client, resumes are created by recruiting, updated by field operations, and needed by proposals, and none of the three owns the lifecycle. Roughly 700 proposals a year depend on those resumes being current. The internal verdict was blunt: "If we don't designate a single person accountable, we're going to be tripping over ourselves."

Three touchers is not the problem. Most real processes have several. The missing piece is one name that stops the ball from rolling between them, which is exactly the difference between doing a task and being accountable for it.

The owner is whoever is accountable for the outcome the process produces, not whoever happened to write the document. The person who wrote it may have left, or been a contractor, or just been the one free that week. None of that creates authority. Accountability for the result does.

Who edits and who publishes? Two different permissions

They are two permissions, and collapsing them into one is what produces the standoff. Most platforms can separate them and most teams never bother, so "can I fix this typo" and "can I change what the whole team is trained on" arrive as the same request.

The middle row is where people go wrong. A delegate is not a second opinion, it is a vacation plan: a document with exactly one editor is frozen the week that editor is out. The publishing row is where you keep the discipline, and it is easier to hold if you already run version control on your SOPs so the previous copy is retrievable.

Live but inaccurate is worse than missing

In that same clinic library, a summary of the cash-pay programs had gone live in the shared reference guide listing the program names and nothing else. No explanation of what each program is. No prices.

Picture a new front desk hire finding it. Missing content sends her to ask somebody. Wrong content, sitting in the official guide, sends her to quote a program she cannot describe to a patient who is about to pay for it.

A page goes live only when someone can answer yes to one question: would a new hire acting on this alone do the right thing?

The publish gate matters more as content ages than on the day it is written. Libraries rarely go wrong at launch. They go wrong slowly, which is what happens when the rules change and nobody updates the SOP.

When ownership is genuinely blurry

Sometimes nobody is being precious and the boundary really is unclear. At a staffing agency, one person held hybrid access across two departments, and the same process had been documented twice: two separate entries, two different videos, different lengths, same task.

Sorting it out took several minutes of careful mapping, and the answer was not a coin flip. Downloading applications, entering them, renewals and the audit report all belong to billing. Creating the worker record belongs to back office, and only after the worker goes out on a first assignment.

When we hit a duplicate in a client library, the reconciliation runs in three moves.

1. Put both entries side by side. Not from memory, and not described in a meeting. Open them next to each other so the overlap is visible instead of argued about.
2. Name the owning department. Not which person, and not who wrote the better version. Departments outlive people, and one of them is usually obvious once the question is asked out loud.
3. Split at the handoff. If both departments genuinely own part of it, the document splits where the work changes hands, and each half gets its own name at the top.

The output is one entry per owned task and a short list of documents you now know were wrong. That list is worth keeping, because it is the beginning of a real process audit that finds which documents are fiction.

Make the change request cost thirty seconds

People do not report a wrong step because of what reporting costs them. If flagging an out-of-date screenshot means booking time with the owner and explaining yourself, the flag never happens.

So make the request smaller than the meeting: a comment on the page itself, one line, no diplomacy required, worked by the owner one item at a time.

In our own delivery sessions we run a standing working session per person, 30 to 60 minutes, with a comment thread resolved item by item live on the call. One operator, midway through, asked "Can I resolve it?" That question is the tell: she knew closing a comment is an act of authority, and she was right.

Flagging belongs to everyone. Resolving belongs to the owner.

This only works if there is one copy to comment on. Threads scattered across a shared drive, an email chain and someone's desktop file are not a change process, which is the practical case for one place where the current version lives.

What do you do when someone builds their own version?

Go ask why before you delete anything. In that clinic library, a single marketing role had somehow spawned five separate playbooks.

The manager who owns the library was blunt: "I don't see the purpose of his position needing five different playbooks. I don't have five different playbooks. And I probably should have 20."

Her response was not a purge. She had already asked the role holder, who said he used one and had not realized he had started building the others. Her plan was to go back and ask him why he thinks he needs them, "and maybe he just needs to understand there's a different way it can be done."

A duplicate is usually a symptom of an unmet need: someone could not find the real page, could not edit it, or was working around a structure that did not fit how they train.

The cautionary case came from the same library. A leader split one role's playbook into six sections because that was the order he was walking a single new hire through it. As a colleague put it, "even how he's training that one individual person is not how it's going to be in the future for everybody." Two managers agreed to freeze all edits until they could work out how to undo it, then found the original was gone: that version had never been archived.

Archive before you edit, and ask before you delete. At The Systems Effect, the first pass on a client's existing library is rarely writing at all: it is deciding who owns what and preserving the current version before anyone touches it.

Start with the ten documents your team actually opens. Put one name at the top of each. That is the whole job this week.

Frequently Asked Questions

Who should own an SOP?

The person accountable for the outcome the process produces, not the person who wrote it. Write that name on the document itself so nobody has to guess or ask. Give the owner one named delegate so the document is not frozen while they are on vacation.

Can anyone on the team edit a company SOP?

Anyone should be able to suggest a change, and only the named owner should be able to make one. Those are two different permissions and nearly every documentation platform can separate them. Open editing produces contradictory versions, and locked editing produces content that stays wrong for years because reporting it feels like an accusation.

What do you do when two departments claim the same process?

Put the two versions side by side and ask which department owns the task, not which person wrote the better document. In one staffing agency that exercise resolved a real overlap in minutes: applications, renewals and the audit report belonged to billing, while creating the worker record belonged to back office and only after a first assignment.

How do you stop inaccurate content from going live?

Separate publishing from editing and put one approver on the publish step. The test is a single question: would a new hire acting on this page alone do the right thing? Wrong content costs more than missing content, because missing content sends people to ask a human while wrong content gets followed with confidence. Archive the previous version before you replace it, so a bad publish can be reversed instead of rebuilt from memory.