How to Keep SOPs Up to Date When the Work Changes

To keep a standard operating procedure (SOP) current, connect its review to the changes it describes. Give it an owner, compare the instructions with a recent task, resolve the differences, and have someone try the revised version before it becomes the working copy.

The difficult part is deciding what to change. An old screenshot might still lead someone to the right result. A current screenshot might sit above an approval step that nobody can complete. Updating the pictures alone would miss the more consequential problem.

This guide covers everyday office procedures and the software instructions inside them. It offers a way to repair one outdated guide and keep future changes visible. Use your organization's specialist change process for regulated or safety-critical work.

Start with a task that the instructions no longer explain

Choose a procedure attached to a concrete problem: a renamed field confuses new starters, a team keeps asking the same question, or requests arrive without information the receiving team needs.

Write down the task's start and finish. For example: “Prepare a complete supplier-onboarding request for review.” That is a more manageable scope than “Fix our procurement documentation.” Also identify who uses the guide and what knowledge or access they are expected to have.

Then find the copy people actually open. Check the team wiki, onboarding checklist and saved links. If different teams use different instructions, record which version each team relies on before combining anything. A regional variation may be deliberate.

Name the person responsible for maintaining the procedure and the person who can approve changes to the work. They may be the same person. If the original author has left, assign a new owner before starting a broad rewrite.

Compare the written steps with a recent case

Ask a person who performs the task to walk through an appropriate recent example with the guide open. Explain that you are checking whether the instructions help someone complete the work. Use a sanitized example or a suitable test environment when the real case contains restricted information.

The UK's Health and Safety Executive recommends involving users, walking through tasks and choosing detail suited to the reader and consequences. This guide borrows those design principles from its safety guidance for an office-work review. HSE procedure-design guidance

At each step, ask:

• What does the guide say to do, and what happened in this case?
• Was the required information, access or decision available?
• If the person took a different route, what prompted it?
• What showed that the step was complete and acceptable?

Keep observations and explanations separate. A record may show that a request moved to “Approved,” but the person can explain who reviewed it and where the decision was recorded. When a detail is missing, mark it unresolved rather than filling in a plausible story.

One case can expose a broken instruction. It cannot establish how often the problem occurs or whether every team uses the same route. Include another relevant case when a proposed correction would cover a different role, region or exception.

Decide whether to change the guide, the work, or both

Use the difference to choose the next check. The following categories are a practical review aid, not a compliance classification.

Bring the process owner into the decision, especially when another team's responsibility changes. The aim is to establish a usable, authorized route, not simply to make the document match whatever happened last time.

If you discover instructions that could cause an incorrect action, have the owner provide clear interim guidance through the existing working channel. Record what remains unresolved and who will answer it. A warning with no usable next step leaves the reader stuck.

A worked example: the form changed, but the checks still matter

Consider a fictional operations team reviewing its supplier-onboarding guide. The task ends when a complete request reaches Procurement for review; it does not include approving a supplier or changing payment details.

The guide tells staff to email an attachment to a shared inbox. The organization has since introduced a request portal, but the guide was never updated. During a walkthrough, the reviewer finds three differences:

The reviewer drafts the changed sections instead of rewriting the whole guide. The new wording explains which task the portal handles, what the requester must have ready and what confirmation to look for.

If a screenshot helps, show the relevant controls using fictional data and explain the action in the text. Include exact button labels when needed, but also explain what the step accomplishes. That gives the reader more to work with than a sequence of pictures.

The owner-confirmed responses are part of this fictional example. Each organization needs to establish its own rules.

Try the revision before replacing the working copy

Ask someone with the intended reader's background, who did not write the revision, to follow it using a suitable example. Give them the inputs and access the guide assumes. Let them point out where they need help rather than coaching them through every step.

EPA's April 2007 SOP guidance recommends knowledgeable reviewers, testing by someone other than the writer, and revision with reapproval when procedures change. These are historical quality-management practices, not current requirements for your organization. EPA SOP guidance, sections 2.2–2.3

For the fictional request, try the ordinary path and both exceptions. A complete request should reach the review queue. With the cost center unknown, the reader should ask the budget owner before submitting. With the review record missing, they should save a draft and contact the internal-review team. Check that the guide tells them how to find those contacts.

Record where the reader stopped, what was unclear and whether the expected result was reached. Fix the consequential gaps, then repeat the affected check. A successful walkthrough supports that version for the cases tested; it does not prove the whole process works in every situation.

Once the responsible owner approves the revision, put it at the agreed current location. Update the links people use and mark retained older copies as superseded. Tell affected teams what changed, when it takes effect and where to find the instructions. Confirm which version applies to work already in progress. Arrange any explanation or practice people need to use the changed steps.

Make future changes create a review task

A calendar reminder can catch neglected guides, but it cannot tell you that a tool changed yesterday. Add a documentation check to the existing work that changes a system, responsibility, decision rule or required input: “Which instructions does this change affect, and who will update them?”

For example, GitLab's public handbook asks people to update the handbook with the process and communicate the linked changes. Its working practice illustrates the connection; you can use your existing documentation tools. GitLab handbook usage

Keep a fallback review date for changes that do not arrive through a formal project. Choose its timing according to how often the work changes and what a wrong instruction could affect; there is no universal interval in this guide. If a review finds no change needed, record what was checked. If the task has been retired, remove the guide from current use while retaining any required history.

Give readers a simple way to report a stale step: the guide's link, the step, what they encountered and who needs an answer. Route that report to the owner rather than collecting it in a channel nobody maintains.

A short SOP update record

Keep this with the guide or in the team's existing work tracker. This fictional record shows a proposed revision ready to test. The decisions have been agreed in the example, but testing and final approval have not happened yet.

Start with the guide that is causing a specific problem. Complete the comparison, resolve the changed step and check that another person can use the result. Then connect that guide to the next change that would make it wrong again.