What Are SOPs? Writing Standard Operating Procedures for IT

A new technician asks how to set up a starter, and the answer lives in one colleague's head, two Slack threads and a wiki page nobody has opened since 2023. Writing the steps down once, so the next person gets the same result without asking, is the whole job of a standard operating procedure. This guide answers what are SOPs in an IT team, how they differ from policies and runbooks, which tasks deserve one first, and how to keep them from going stale, with a template and a worked example.

TL;DR

• An SOP is a written, approved set of steps for a task that repeats, so that anyone qualified to do it gets the same result. The EPA's long-standing guidance puts the bar at "someone with limited experience... can successfully reproduce the procedure when unsupervised".
• Policies say what and why. SOPs say who does what, in what order. Runbooks and work instructions carry the keystrokes. Checklists prove it happened. Keep the layers separate and link them.
• Write the first SOPs where three things are true: the task repeats, more than one person does it, and doing it differently costs something (a breach, a failed audit, a client phone call).
• The template has eleven parts. Three of them, the control header, the verification step and the change log, are the ones teams skip, and they are the ones auditors ask for.
• SOPs decay with vendor UI changes, not with time. Review them on triggers (a release, an incident, an audit finding, an owner change) and on a calendar, and record the review date on the document.

What an SOP Is (and What It Is Not)

The clearest definition still comes from a 2007 guidance document the US Environmental Protection Agency wrote for its own laboratories. An SOP, it says, is "a set of written instructions that document a routine or repetitive activity followed by an organization". The same document sets the bar for detail: an SOP should be written so that "someone with limited experience with or knowledge of the procedure, but with a basic understanding, can successfully reproduce the procedure when unsupervised".

That second sentence is the useful one. It tells you who the reader is (the least experienced person allowed to run the task), what the test is (same result, no supervision), and what an SOP is not (a tutorial for someone who has never seen the tool).

Regulated industries have required this for decades. FDA's rule for drug manufacturers, 21 CFR 211.100, requires "written procedures for production and process control", drafted, reviewed and approved by the right units, and it adds a line every IT team should borrow: "Any deviation from the written procedures shall be recorded and justified."

IT is not pharma, but the pressure is the same. A SOC 2 auditor asks how access is granted and removed. A cyber insurer asks how password resets are verified. A client's compliance lead asks how backups are tested. The answer "the senior tech knows" does not pass any of those conversations. Our guide to IT compliance covers what the frameworks expect; this post covers the document they expect to see.

An SOP is also not the same thing as the documentation platform it lives in. Tooling matters, and the IT documentation tools roundup compares the platforms built for it, but a wiki full of screenshots with no owner, no version and no verification step is a photo album, not a procedure.

SOP vs Policy vs Runbook vs Checklist

Four kinds of document get called "the SOP", and the confusion is where half the arguments about detail come from. They sit in layers.

A policy says every leaver's access is removed within 24 hours. The SOP says the service desk disables the account, revokes sessions, reassigns the mailbox and records it in the ticket, in that order, with the manager's confirmation as the closing step. The runbook says which Entra ID blade, which PowerShell line, which licence to pull. The checklist is the ticket template with nine boxes.

Policy and procedure deserve their own post, and a longer one is planned. For now, one test: if a sentence could be enforced by HR, it is policy. If it could be timed with a stopwatch, it is procedure.

Runbooks are the one layer IT teams write more of than anyone else, usually for incidents. If your incident playbooks live in a separate system, that is fine; the incident response plan post covers how small teams build them. The point is to link each playbook from the SOP that owns it, so the step "follow the ransomware runbook" resolves to a document rather than a memory.

Waybook's explainer covers how SOPs, policies, procedures and processes differ:

Which Tasks Deserve an SOP First

Nobody writes SOPs for everything, and a team that tries ends up with a hundred half-finished pages. Three tests sort the queue.

The task repeats. Onboarding, offboarding, the monthly patch window, the quarterly restore test, the new-client network survey. A one-off migration gets a project plan, not an SOP.

More than one person does it, or will. The moment a second technician, a new hire or an on-call rota touches the task, the way it is done starts to drift. An SOP is how two people produce one result.

Doing it differently costs something. This is the test that ranks the list. A password reset done without identity verification hands credentials to whoever is calling. A patch window run without a rollback step turns one bad update into a site outage. A client offboarding done from memory leaves a VPN account alive for a contractor who left in March.

In April 2026 an L1 help desk technician on r/sysadmin described a caller who gave a name, an employee ID and a home address, then pushed hard for a temporary password over the phone. The technician had skipped the verification step in the reset SOP, caught it when the "caller" turned out to be in a meeting on Teams, and escalated. The thread is a clean example of why that one step exists and why it is written down rather than assumed:

Run the three tests across a service desk and the first ten SOPs write themselves: user onboarding, user offboarding, password reset and identity verification, new device setup, the patch window, backup restore testing, access requests and approvals, a new-client or new-site onboarding, major incident declaration, and vendor or contractor access. The MSP onboarding checklist and its offboarding twin are two of those ten already written as checklists, which is the fourth layer; the SOP wraps the checklist with an owner, roles and a verification step.

The SOP Template for IT Work

The EPA guidance describes a title page, a document control block on every page, and a body that moves from purpose and scope through the steps to quality checks and references. Adapted for IT, the template has eleven parts. The right column is what each part looks like in practice.

Three of these parts get skipped on first drafts, and they are the three that matter in a review. The control header is what tells a technician at 2 a.m. whether the page is current. The verification step is what turns "I did the steps" into "it works". The change log is what an auditor reads first, because it shows the document is alive.

Two format rules from the EPA guidance carry straight over. Write in the active voice and present tense, and leave out "you": "Create the account from the role template", not "You should now create the account". And keep the checklist as part of the SOP, not a replacement for it; the guidance is blunt that "the checklist is not the SOP, but a part of the SOP".

A Worked Example: New-User Onboarding

Here is the body of IT-ONB-001 written to the template, trimmed to the parts that show the shape. The runbook with the exact clicks is a separate, linked document.

Purpose. Provision a starter's identity, access and device so that they can work from their first morning, with every grant traceable to an approved request.

Scope. All employees and contractors of Client A. Service accounts and shared mailboxes are covered by IT-SVC-004.

Roles. The hiring manager requests. An L1 technician executes. The client's IT contact approves any access outside the role template. An L2 technician verifies before close.

Prerequisites. A ticket with start date, job role, reporting manager and device requirement, approved by the hiring manager. A licence available in the tenant. A device in stock or ordered with a delivery date before the start date.

Steps.

1. Create the account in the identity directory from the role template that matches the job role on the ticket. Do not copy an existing user.
2. Assign the licence recorded for that role. If none is available, stop and follow Exceptions.
3. Enable the mailbox and add the user to the role's distribution groups.
4. Register the user for MFA using the temporary access pass. Record the pass expiry in the ticket.
5. Assign the device from inventory, enrol it in device management, and confirm the compliance policy applies.
6. Add any access outside the role template only against a written approval from the client IT contact, pasted into the ticket.
7. Enrol the user in the security awareness course.
8. Send the welcome pack to the hiring manager, never to the personal email on the ticket.
9. Hand the ticket to L2 for verification.

Verification. L2 signs in as the user on a clean browser profile, confirms the MFA prompt appears, opens the mailbox, and confirms the device shows compliant in device management. The hiring manager replies to the ticket confirming the starter can work. Close only after both.

Exceptions and escalation. No licence: escalate to the account manager; do not reuse a leaver's licence. Start date within 24 hours: notify the service desk lead; the device step may ship after day one with the manager's agreement in the ticket. Any step that fails twice: stop and escalate rather than improvise.

References. IT-ONB-001-RB (runbook with screenshots), Access Control Policy v4, IT-OFF-001 (offboarding), the device enrolment runbook.

Change log. Rev 3, 2026-09-14, added step 4 after audit finding A-17 showed starters without MFA for their first week.

Notice what the SOP does not contain: which blade in the admin centre, which PowerShell cmdlet, what the group is called this quarter. All of that goes in the runbook, where it can change every time the vendor moves a menu without the SOP needing re-approval. The SOP changes when the process changes, which should be rare.

How Much Detail Is Enough

This is the fight every team has, and it played out in full on r/sysadmin in September 2026. A sysadmin's SOP was rejected by their manager for saying "Check the log for entries containing Out of memory" rather than spelling out how to SSH in and run tail and grep. The replies split, and several of the top ones landed on the same layered answer: keep the SOP at the level of "check the log", and link a work instruction that shows the commands for anyone who needs them.

Both sides were right about different layers. The EPA's test settles the SOP layer: write for the least experienced person who is allowed to run it, with a basic understanding of the tools. If your L1 technicians are allowed to run the memory-leak procedure, and some of them have never used grep, the SOP needs the link. If only L2 runs it, "check the log" is enough.

Three practices from that thread are worth stealing. Put the intended audience in the scope section, so the level of detail is justified on the page rather than argued in review. Split any sub-task that appears in several procedures into its own SOP and link it, so an update happens once. And treat the act of writing as a review of the process: several commenters said the moment they wrote a procedure down was the moment they noticed it could be shortened or automated.

A separate thread from a solo IT administrator at an SMB makes the opposite case. After three years with everything in personal notes, a new hire arrived, and the first attempt to write anything stalled on questions about headings and screenshots. The fix for a blank page is the template above: fill the control header and the purpose line, write the steps as you do the task next time, and leave the screenshots for the runbook.

Keeping SOPs Current

An SOP written in 2022 for a vendor console that has since moved every menu is worse than no SOP, because a technician will follow it. One r/sysadmin post this spring described two hours lost and a production misconfiguration from exactly that: a "master SOP" written for an old version of the software, trusted because it was labelled verified.

The EPA guidance says SOPs should be reviewed "on a periodic basis, e.g. every 1-2 years", updated and re-approved whenever the procedure changes, and withdrawn and archived when the process is no longer followed. For IT, the calendar is the backstop; the triggers do the real work.

Four events should force a review, and each one should be wired to the document rather than to someone's memory. A vendor release or UI change: subscribe the SOP owner to the vendor's release notes and open a review ticket on each one that touches a step. An incident or post-mortem: if the procedure was followed and the outcome was still wrong, the procedure changes. An audit finding: the change log entry cites the finding number. An owner change: a departing owner's SOPs are reassigned before their last day, as part of the offboarding SOP.

Two fields on the control header make this visible: "last verified" and "next review". A date in the past on either one is a signal to the reader, not a failure. Platforms that flag stale pages do this automatically; a spreadsheet master list, which the EPA guidance also asks for, does it well enough for a small team.

Fewer screenshots helps more than any tool. A screenshot captures a version; a named setting ("Conditional Access, policy CA-07, Grant: Require MFA") survives a redesign. Keep screenshots in the runbook, caption each one with the version it was taken from, and accept that the runbook is reviewed more often than the SOP.

Finally, measure use. A page nobody has opened in a year is either a candidate for the archive or a sign that the team is doing the task from memory. Either answer is worth knowing.

Where SOPs Live and Who Owns Them

The platform matters less than three decisions: one home, one owner per document, and one path from a ticket to the procedure.

One home means the SOP is wherever the technician is when the ticket arrives. If that is the PSA's knowledge base, put it there. If it is a documentation platform built for MSPs, put it there and link it from the ticket category. If the team is comparing platforms, the IT Glue alternatives post covers the field; what matters for SOPs is version history, an owner field, a review date and a search that finds the document by the words a technician would type.

One owner means a name, not a team. The owner approves changes, answers the review ticket, and is the person a technician messages when a step does not match the screen. The master list carries the owner against every ID, and the offboarding SOP reassigns them.

Some teams keep procedures in a git repository as Markdown, with pull requests as the review and the commit log as the change log. It works well for teams who already live in git and badly for everyone else, because the service desk will not open a terminal to read how to onboard a user.

A note on automation. The verification step is the first part of any SOP to script. A check that every starter has MFA registered, or that no leaver's account is still enabled, is one script run across a client's devices with the output collected; OpenFrame runs scripts that way across a client's fleet. The SOP still owns the step; the script is how the step gets done at scale, and its output is the evidence the checklist used to be.

Paul Green's MSP Marketing Edge podcast has an episode on building SOPs for MSPs (episode 145):

The Short Version

An SOP is the written, owned, versioned answer to "how do we do this here", pitched at the least experienced person allowed to do it. Keep policy, SOP, runbook and checklist as four linked layers rather than one document. Write the first ten where a task repeats, more than one person runs it, and variation costs something. Use the eleven-part template, and do not skip the control header, the verification step or the change log. Review on triggers and on a calendar, and date the review on the page.

Start with onboarding and offboarding, because the checklists for both exist already. Then read the security audit procedures guide, which is what an auditor will do with your SOPs once they exist.

FAQ

What does SOP stand for?

SOP stands for standard operating procedure: a written, approved set of steps for a task that repeats, so that anyone qualified to do it gets the same result. The term comes from manufacturing, laboratories and regulated industries, and IT teams use it for procedures such as user onboarding, patching and password resets.

What is the difference between an SOP and a policy?

A policy states what the organization does and why, and it is written for leadership and auditors; "every leaver's access is removed within 24 hours" is policy. An SOP states who does what, in what order, with what checks, and it is written for the people doing the work. One policy is usually implemented by several SOPs.

What is the difference between an SOP and a runbook?

An SOP describes the procedure at the level of decisions and steps: create the account, assign the licence, verify sign-in. A runbook or work instruction carries the exact commands, menus and values for a specific tool and version. The SOP changes when the process changes; the runbook changes when the tool does, which is far more often, so keeping them separate saves re-approving the SOP every time a vendor moves a menu.

How detailed should an SOP be?

Detailed enough that the least experienced person allowed to run it, with a basic understanding of the tools, gets the right result without supervision. Name that audience in the scope section. Keystroke-level detail belongs in a linked runbook, so the SOP stays short and the runbook can change often.

How often should SOPs be reviewed?

Review on triggers first: a vendor release that touches a step, an incident where the procedure was followed and the outcome was still wrong, an audit finding, or an owner leaving. Then review on a calendar as a backstop; the EPA guidance suggests every one to two years, and in practice, IT procedures tied to cloud consoles need it closer to the one-year end. Record the review date on the document every time.

Who should write SOPs in an IT team?

The people who do the work, reviewed by someone who has not. The EPA guidance recommends subject-matter experts who perform the task write the first draft, and that someone other than the writer tests the draft before it is approved. In practice a technician writes the steps during the next run of the task, a peer runs it from the draft, and the owner approves.