SOP review checklist
SOP Review Checklist: Test Every Step Before Approval
Direct answer: Before an SOP is approved, a reviewer should confirm its scope and prerequisites, perform every action, compare the observed result with the expected result, exercise its exception branches, and record evidence for any failure. A second person should then follow the procedure without coaching. The owner corrects the draft and the approver decides whether it is ready. This checklist records that review; it does not certify compliance or approve an SOP automatically.
1
Set the review scope and starting state
- Identify the exact SOP ID and version under review, its process owner, approver, intended reader, trigger, finish condition, and exclusions. Do not test an undated copy or assume two similar procedures are interchangeable.
- Create the starting state in a controlled environment with synthetic or sample data. List every role, permission, tool, input, and prior approval the operator needs before step one.
- If the draft is missing those fields, start with a complete SOP template before reviewing the individual instructions.
2
Test each action, expected result, and evidence field
- Perform one step at a time. Record the action, expected result, observed result, evidence reference, and a status of Pass, Revise, or Blocked. Do not mark a step complete because its wording sounds plausible.
- Replace vague actions such as “configure as appropriate” with a named control and one observable action. Replace vague results such as “confirm it worked” with the exact state the operator should see.
- If the procedure begins with a recording, you can draft steps from a recorded workflow. Review that output as a draft: add off-screen prerequisites, permissions, exception owners, and results the recording could not establish.
3
Check permissions, minimum data, and accessibility
- Confirm that the named role is allowed to perform each action. Put irreversible, destructive, or permission-changing work behind an explicit authorization check and a stop condition.
- Request and retain only the information needed to perform or verify the procedure. Prefer synthetic data during review, and exclude secrets, authentication codes, payment details, health information, and unrelated personal data.
- Keep every instruction available in text. Do not rely only on color, sound, motion, or a screenshot, and give informative images alternative text that states the relevant control or result.
4
Exercise every branch and name its owner
- Test the happy path and each meaningful exception. Write decisions as observable conditions: “If Export displays Disabled,” not “If the account is misconfigured.”
- For every branch, name the next action, the role that owns it, and the evidence that role needs. A direction such as “contact the appropriate team” is not a complete handoff.
- Use the support handoff SOP example when the procedure crosses queues or teams. It shows how to keep a communication owner while another role investigates.
5
Run a second-person dry run without coaching
- Give the draft to a trained person who did not write it. Ask them to follow only the written instructions while the reviewer records pauses, questions, skipped steps, unexpected states, and dead-end branches.
- Do not explain the intended action during the run. Coaching can hide the same missing prerequisite or ambiguous result that will block the next reader.
- The filled Northstar Docs review below shows three specific failures: an operator without the required role, an expected result that says only “correct,” and an exception with no receiving owner.
6
Collect the smallest safe demonstration or evidence
- Use text, a cropped screenshot, a short recording, a ticket field, or a controlled test record according to what the result requires. Evidence should confirm the observed state; it does not automatically prove the cause.
- When the process owner must show motion, timing, or a changing interface, request a safe demonstration that names the task, starting screen, expected result, stopping point, and information to exclude.
- Confirm that each intended reviewer can open the evidence and that the approved retention rule is recorded. Replace inaccessible or overbroad evidence before approval.
7
Hand the corrected version to its approver and schedule review
- Classify the outcome as Ready for approval, Needs revision, or Blocked. A completed checklist is review evidence; it is not the approval decision.
- Assign every revision to the process owner, issue a new draft version, and repeat the affected tests. The approver should receive the corrected version and its review record, not the failed draft alone.
- Record the approved version, effective date, change summary, and next review date. Add event-based triggers such as a renamed control, permission change, new owner, changed policy, repeated workaround, or evidence that two operators choose different branches.
Blank SOP review checklist
Copy, download, or print the plain-text checklist. Adapt the approval roles, evidence rules, and review triggers to your organization before using it.
SOP REVIEW CHECKLIST
REVIEW RECORD
SOP title:
SOP ID:
Version under review:
Process owner (role):
Approver (role):
Reviewer:
Review date:
Test environment:
Review scope:
PREREQUISITES, STARTING STATE, AND SCOPE
[ ] The SOP names one procedure with a clear trigger and finish condition.
[ ] The version under review is identified and no older copy is being tested by mistake.
[ ] Required roles, permissions, tools, inputs, and approvals are listed before step one.
[ ] The reviewer can create the stated starting state without using live customer data.
[ ] The SOP says what is out of scope and where a different procedure begins.
[ ] Any irreversible, destructive, or permission-changing action has an explicit authorization check.
ACTION → EXPECTED RESULT → EVIDENCE
Complete this block for every step.
Step number:
Action:
Expected result:
Observed result:
Evidence reference:
Status: Pass / Revise / Blocked
[ ] The step contains one observable action and starts with a specific verb.
[ ] The named role is allowed to perform the action.
[ ] The expected result is visible or otherwise verifiable.
[ ] The evidence is sufficient to confirm the result without collecting unrelated data.
[ ] The next step starts from the state this step actually creates.
[ ] A reader can tell when to continue, retry, stop, or use a different branch.
DECISION POINTS, EXCEPTIONS, AND OWNERS
[ ] Every decision uses an observable condition rather than an assumed cause.
[ ] Each branch names the next action and the role that owns it.
[ ] Stop conditions appear before an unsafe or irreversible action.
[ ] Escalation instructions name a destination, required evidence, and communication owner.
[ ] No branch ends with vague wording such as "handle as needed" or "contact the appropriate team."
[ ] A missing prerequisite leads to a defined correction or handoff rather than a guess.
DATA, PERMISSIONS, AND ACCESSIBILITY
[ ] The procedure asks for only the data needed to complete or verify the task.
[ ] Synthetic or sample data is used for the review when possible.
[ ] Secrets, authentication codes, payment details, health information, and unrelated personal data are excluded.
[ ] Permission boundaries are stated where the action occurs.
[ ] Instructions do not depend only on color, sound, motion, or an image.
[ ] Informative screenshots have useful alternative text and the instruction remains available in text.
[ ] Links, recordings, and referenced documents are accessible to the intended reader.
SECOND-PERSON DRY RUN
[ ] A trained person who did not write the SOP followed it without coaching.
[ ] The reviewer recorded every pause, question, skipped step, and unexpected branch.
[ ] The operator reached the stated finish condition or a documented stop condition.
[ ] A second reviewer is scheduled when the task has meaningful operational, security, or data risk.
[ ] The owner received the review notes and assigned each required revision.
APPROVAL AND MAINTENANCE HANDOFF
Review outcome: Ready for approval / Needs revision / Blocked
Required revisions:
Evidence retained at:
Owner response:
Approver decision:
Approved version:
Effective date:
Next review date:
Change-log entry:
Event-based review triggers:
[ ] Every required revision has an owner.
[ ] The approver is reviewing the corrected version, not the failed draft.
[ ] The revision history records what changed and who approved it.
[ ] Calendar and event-based review triggers are recorded.
[ ] Linked screenshots, recordings, and supporting documents match the approved text.
[ ] Superseded instructions are clearly marked or removed from the normal workflow.Filled synthetic review: Northstar Docs export-control SOP
This fictional review shows a failed prerequisite, an ambiguous expected result, and an exception with no owner. It contains no customer or production data.
SYNTHETIC REVIEW: NORTHSTAR DOCS EXPORT-CONTROL SOP
REVIEW RECORD
SOP title: Resolve a missing Export control
SOP ID: SUPPORT-EXPORT-01
Version under review: 1.0 draft
Process owner (role): Support Operations Lead
Approver (role): Product Support Manager
Reviewer: Documentation QA
Review date: 2026-10-11
Test environment: Fictional Northstar Docs test workspace with sample projects
Review scope: Determine whether a support agent can inspect a reported missing Export control and choose the correct handoff without changing workspace policy.
RESULT 1 — FAILED PREREQUISITE
Step under review: "Open Workspace settings, select Roles, and open the affected user's role."
Expected result in draft: "The role settings appear."
Observed result: The test operator has the Member role and cannot open Workspace settings.
Evidence: The navigation does not include Workspace settings for the test role.
Status: Blocked
Required revision: State before step one that a Workspace Administrator must inspect the role. Give the support agent a separate action: ask an authorized administrator to report the displayed Export state.
RESULT 2 — AMBIGUOUS EXPECTED RESULT
Step under review: "Confirm the Export setting."
Expected result in draft: "The setting is correct."
Observed result: The fictional interface displays Enabled, Disabled, or Custom. The draft does not say which value permits the operator to continue.
Evidence: Controlled test of the three synthetic permission states.
Status: Revise
Required revision: Replace "correct" with the exact observable values. Define the next action for Enabled, Disabled, and Custom.
RESULT 3 — MISSING EXCEPTION OWNER
Branch under review: "If Export is enabled but the control is still missing, contact support."
Observed result: The operator cannot tell which team receives the case, what evidence to attach, or who updates the requester.
Evidence: Second-person dry run stopped at the branch without coaching.
Status: Revise
Required revision: Name Product Support as the destination, list the safe project ID, role, client version, timestamp, and redacted permission-state screenshot, and keep the intake agent as the communication owner.
DATA AND ACCESSIBILITY CHECK
Draft problem: The evidence instruction requests a screenshot of the entire project.
Required revision: Request only the permission state and navigation context. Exclude project contents, workspace-member lists, and unrelated tabs. Add alternative text that states the displayed Export value instead of relying on a colored outline.
SECOND-PERSON DRY RUN
Operator: Trained support agent who did not write the SOP.
Outcome: The operator stopped before the first action because the required administrator role was missing. After reading the remaining draft, the operator also could not choose the Enabled branch or identify the escalation owner.
Coaching provided: None.
Review outcome: NEEDS REVISION
Approval status: Not submitted for approval.
Owner action: Correct the prerequisite, expected-result values, evidence boundary, and escalation branch; issue draft 1.1 for another dry run.
Event-based review triggers: Permission-model change, renamed Export control, new escalation destination, or repeated cases where agents choose different branches.