Calendar and clock on a desk next to a laptop showing an SOP review dashboard, illustrating SOP review cadence

How Often Should You Review and Update SOPs? A Practical Cadence Guide [2026]

A practical cadence guide for reviewing and updating SOPs by type — compliance, software-dependent, high-stakes, and more — plus the trigger events that demand immediate review.

Yuval Karmi
Yuval Karmi

May 3, 2026

Read summarized version with

Last quarter, a finance director walked me through her team’s Sage Paperless SOP. Dated 2022. Pretty Word doc, screenshots, all of it.

The vendor shipped a major UI update in late 2024. Nobody touched the SOP. Four new hires came on in 2025 and dutifully followed steps that didn’t exist anymore. Caught during an internal audit, after weeks of bad data entry.

So here’s the thing. She didn’t have a documentation problem. She had a review cadence problem. Nobody owned “check this thing every quarter,” so nobody did.

If you’re in ops, HR, or compliance and wondering whether your SOPs need a monthly, quarterly, or annual review, the honest answer is: it depends on the type of SOP. No single cadence covers all of them, and that’s where most teams trip up.

I’m Yuval, founder and CEO of Glitter AI. We help teams keep process documentation alive instead of letting it rot on a shared drive. The framework below is what I’ve watched actually work, at companies ranging from 10-person startups to 500-person enterprises.

Stop rewriting SOPs from scratch

Teach your co-workers or customers how to get stuff done – in seconds.

The short answer: cadence by SOP type

SOPs decay at different speeds. A SOX compliance SOP is stable for a year. A SaaS workflow SOP can break overnight when a vendor ships a redesign. Putting everything on the same calendar wastes time on the stable stuff and misses the volatile stuff entirely.

Here’s the cadence I recommend, broken out by SOP type:

SOP typeMinimum review cadenceTrigger reviews
Compliance / audit (SOX, SOC 2, ISO, HIPAA)AnnuallyAny regulation change
Software-dependent (tied to a SaaS UI)QuarterlyVendor UI update
Process-only (no software)AnnuallyProcess change, role change
High-stakes (financial, security, safety)QuarterlyAny near-miss or incident
Onboarding / trainingPer role changeNew hire feedback
Vendor / partner-dependentOn contract renewalVendor migration

Let me go through each one with the reasoning. The “why” matters more than the number.

1. Compliance and audit SOPs: annual minimum

If the SOP exists because an auditor is eventually going to read it (SOX controls, SOC 2 policies, ISO 9001 procedures, HIPAA workflows) you need an annual review at minimum, plus an immediate review whenever the underlying regulation shifts.

Why annual? Auditors expect to see evidence that the document is “current.” Most frameworks define current as reviewed within the last 12 months. If your last review date is 18 months old, expect a finding.

The annual cadence also forces you to verify the SOP still matches what the team actually does. Drift happens. People find shortcuts, swap tools, hand off responsibilities, and the doc quietly stops matching reality.

What qualifies as a regulation-change trigger? New SEC guidance. An updated AICPA Trust Services Criteria. A HIPAA privacy rule revision. A state-level data law (looking at you, every US state in 2025 - 2026). The moment your compliance team flags it, the SOP needs attention.

2. Software-dependent SOPs: quarterly minimum

This is the category where teams get burned the most. If your SOP says “click the blue button in the top right corner of HubSpot,” that SOP has a half-life measured in months, not years.

SaaS vendors ship UI changes constantly. Salesforce releases three times a year. HubSpot, Notion, Asana, Monday - they all push redesigns, rename features, move buttons. Every change quietly breaks any SOP that referenced the old UI.

Quarterly is the floor. I’d push monthly for the most volatile tools (anything still in heavy product development). And immediately when a vendor announces a major release.

The cost of a stale software SOP is hard to see but easy to measure once you bother to look. Every new hire who follows broken steps wastes 20 - 60 minutes troubleshooting. Multiply that by the number of new hires and the number of broken SOPs, and you’re looking at real payroll dollars.

It’s also why I’m a believer in re-recording over editing. If your SOP was generated from a screen recording, fixing it is a 60-second re-record. If it’s a Word doc with manually pasted screenshots, fixing it is a 30-minute editing slog. Guess which one actually gets done?

Stop rewriting SOPs from scratch

Teach your co-workers or customers how to get stuff done – in seconds.

3. Process-only SOPs: annual + on trigger

If your SOP describes a business process with no software dependency (“how we handle a customer escalation,” “how we run a Monday standup,” “how we approve a vendor invoice”) annual is fine.

Process SOPs are stable. The shape of “approve a vendor invoice” doesn’t change just because Adobe pushed a new icon set. What actually changes a process SOP is a deliberate decision: a new approval threshold, a team restructure, a policy update.

So the cadence is annual review + immediate review on trigger events. For process-only SOPs, the triggers are usually:

  • A team or department restructure
  • A policy change (new approval limits, new escalation paths)
  • A complaint pattern that suggests the process is broken
  • A merger, acquisition, or office opening that changes who does what

If none of that happens, the annual touch-up is enough.

4. High-stakes SOPs: quarterly + after every near-miss

Anything where a mistake costs real money, leaks sensitive data, or hurts someone (wire transfer SOPs, access provisioning, lab safety procedures, incident response playbooks) needs a quarterly review minimum plus an immediate review after any near-miss.

The reason is psychological. After an incident, everyone’s attention is locked on the failure. That’s the moment the SOP gets the scrutiny it deserves. A near-miss is a free lesson. Don’t waste it by waiting until the next scheduled review.

I’ve watched companies treat near-misses as “no harm, no foul” and move on. Six months later they have a real incident, caused by the exact same gap.

For high-stakes SOPs, also think about who reviews. The original author shouldn’t be the only reviewer - pull in someone outside the immediate team for a fresh read. They’ll catch assumptions the author can’t see anymore.

5. Onboarding and training SOPs: after every role change

Onboarding SOPs have a unique trigger: the role itself changes. If “Customer Success Manager” responsibilities expanded last quarter to include account expansion, the onboarding SOP for that role is already out of date.

The cadence here isn’t really a cadence. It’s a process. Every time a role’s responsibilities shift, the onboarding doc needs an update before the next hire starts.

Beyond role changes, also review onboarding SOPs:

  • After every cohort of new hires (collect their feedback on what was missing or confusing)
  • When you swap a tool in the new-hire stack (new HRIS, new productivity suite)
  • When you change the onboarding structure (e.g., moving from 1-week to 2-week ramp)

The fastest signal that an onboarding SOP is broken is a new hire asking the same question three weeks in a row. That’s a doc gap, not a hire problem.

6. Vendor and partner-dependent SOPs: on contract renewal

If your SOP depends on an external vendor or partner (a 3PL warehouse, an outsourced help desk, a payment processor) review it on contract renewal at minimum.

Renewals are a natural forcing function. You’re already negotiating SLAs, scope, and pricing. That’s the moment to check the SOP against the new agreement.

Also trigger an immediate review when:

  • The vendor migrates platforms (e.g., your 3PL moves to a new WMS)
  • You add or remove a service line with the vendor
  • The vendor has a major incident on their side that affected your operations

Trigger events that demand immediate review (regardless of cadence)

Beyond the type-based cadence, there’s a universal list of triggers. The moment any of these happen, the relevant SOP gets touched within the week, not the next quarterly cycle:

  1. Regulatory change - new law, new standard, new audit requirement
  2. Software update - vendor pushed a UI change or renamed a feature your SOP references
  3. Near-miss or incident - anything that almost went wrong, or did
  4. Employee turnover in the role - the person carrying the tribal knowledge is leaving
  5. Complaint pattern - multiple complaints suggest the process or the doc is wrong
  6. Audit finding - internal or external auditor flagged a gap

The goal isn’t “stay on top of everything.” The goal is making sure no SOP silently rots between scheduled reviews.

If you want the deeper structural reasons docs drift, my post on why documentation gets outdated digs into that.

Stop rewriting SOPs from scratch

Teach your co-workers or customers how to get stuff done – in seconds.

Who owns the review (and who approves)

A cadence is useless without an owner. Every SOP needs two named roles:

  • Owner: The person responsible for keeping the doc accurate. Usually the team lead or process owner.
  • Approver: The person who signs off on changes. For compliance SOPs, this is often the compliance officer or department head. For operational SOPs, it can be the same person as the owner.

No owner, no review. No approver, no scrutiny.

I’ve watched teams try to make the whole team responsible. That’s the same as making nobody responsible. Pick a name.

Version-bump rules and sunsetting old versions

When you update an SOP, follow simple version rules:

  • Minor edit (typo, broken screenshot): bump the patch version (1.2.1 → 1.2.2). No re-approval needed.
  • Process change (new step, changed order): bump the minor version (1.2 → 1.3). Approver re-signs.
  • Major change (new tool, restructured workflow): bump the major version (1.0 → 2.0). Approver re-signs and notifies all users.

Always archive the previous version with the date it was retired. Don’t delete it. Auditors love to see version history, and you’ll occasionally need to prove what the process was on a specific date.

For the day-to-day mechanics of keeping SOPs alive, see my guide on how to keep process documentation updated.

Build a review calendar (and actually use it)

The framework only works if you operationalize it. Here’s the simplest setup that actually gets used:

  1. Pick one tool - Asana, Notion, Monday, ClickUp. Whatever your team already lives in.
  2. Create a recurring task per SOP - set it to the cadence you assigned (quarterly, annually, etc.).
  3. Assign the owner - the named person from the section above.
  4. Set a 2-week lead time - the reminder fires two weeks before the review is due so there’s time to actually do it.
  5. Track completion - a simple “last reviewed” date on the SOP itself, updated after every review.

For compliance-heavy environments, you’ll also want a separate dashboard showing review status across every SOP - green if reviewed in the last cadence window, yellow if approaching due, red if overdue. Auditors love that view. So does your CFO.

If you want to go deeper on review mechanics, how to audit documentation covers the practical audit workflow.

The Glitter angle: re-record instead of edit

Here’s why I keep circling back to that finance team and their broken Sage Paperless SOP. The real problem wasn’t that nobody reviewed the doc. The problem was that reviewing the doc was painful.

To fix that 2022 SOP they would have had to open the Word doc, hunt down each broken screenshot, take new screenshots in the updated UI, paste them in, rewrite the captions, re-export to PDF, re-upload to SharePoint. An hour of work, easy.

So nobody did it.

That’s the whole reason I built Glitter the way I did. When the vendor changes the UI, you re-record the affected steps in 60 seconds, not 60 minutes. New screenshots, new captions, new flow, all generated from the recording. The SOP updates itself.

The cadence framework above works either way. But if your SOPs live in Word docs with manually pasted screenshots, cadence loses to friction every single time. The team will skip the quarterly software-dependent review because it’s a half-day of work. With re-recording, it’s a coffee break.

That’s the pitch. Make review easy and reviews actually happen.

Putting it all together

If you take one thing from this post, take this: don’t pick one cadence for all your SOPs. Sort them by type, assign the right cadence to each, name an owner, build a calendar, and trust trigger events more than calendar dates.

For the broader playbook on managing SOPs over time, my post on SOP management best practices covers the rest of the system.

Your SOPs are only as good as the last time someone touched them. Make sure “last time” wasn’t 2022.

Frequently Asked Questions

How often should SOPs be reviewed and updated?

It depends on the SOP type. Compliance SOPs need annual reviews, software-dependent SOPs need quarterly reviews, high-stakes SOPs need quarterly reviews plus reviews after any near-miss, and process-only SOPs need annual reviews. Always trigger an immediate review for regulation changes, software updates, incidents, or audit findings.

What is a good SOP review cadence for compliance documents?

Annual at minimum, with immediate reviews triggered by any regulatory change. Most compliance frameworks like SOX, SOC 2, ISO, and HIPAA expect documentation reviewed within the last 12 months. Older review dates typically result in audit findings.

How often should I review SOPs that depend on SaaS software?

Quarterly at minimum, plus immediately whenever the vendor announces a UI update or major release. SaaS vendors change interfaces constantly, which silently breaks any SOP that references specific buttons, menus, or workflows. Software-dependent SOPs decay faster than any other type.

What trigger events require an immediate SOP review?

Six trigger events demand immediate review regardless of scheduled cadence: regulatory changes, software updates, near-misses or incidents, employee turnover in the role, complaint patterns, and audit findings. The relevant SOP should be touched within a week, not the next scheduled cycle.

Who should own the SOP review process?

Every SOP needs two named roles: an owner responsible for keeping the doc accurate (usually the team lead) and an approver who signs off on changes (often the department head or compliance officer). Making the whole team responsible is the same as making nobody responsible - assign individual names.

How do I build an SOP review schedule that people actually follow?

Use a tool your team already lives in like Asana or Notion, create a recurring task per SOP set to the assigned cadence, assign a named owner, set a two-week lead time on reminders, and track a 'last reviewed' date on each SOP. Compliance-heavy teams should also build a dashboard showing review status across all SOPs.

How often should onboarding and training SOPs be updated?

Onboarding SOPs should be reviewed every time a role's responsibilities change, after every cohort of new hires (collecting their feedback), and when you swap a tool in the new-hire stack. The fastest signal that an onboarding SOP is broken is new hires asking the same question repeatedly.

What version-bump rules should I follow when updating SOPs?

Use a three-tier system: patch versions for typo or screenshot fixes (no re-approval), minor versions for process changes like new steps (approver re-signs), and major versions for restructured workflows or new tools (approver re-signs and notifies users). Always archive the previous version with the retirement date for audit trail purposes.

How often should I review high-stakes SOPs like financial controls or security procedures?

Quarterly at minimum, plus an immediate review after any near-miss or incident. After an incident is the moment when attention is highest and gaps are most visible - don't waste that opportunity by waiting until the next scheduled review. A near-miss is a free lesson.

What happens if you don't review SOPs frequently enough?

Stale SOPs cause real costs: new hires follow broken steps and waste hours troubleshooting, audit findings accumulate, compliance certifications are at risk, and the team eventually stops trusting the documentation entirely. Once trust in the docs is gone, people fall back on tribal knowledge - which leaves with whoever knew it.

Recent Posts