A runbook is a specific kind of SOP: a procedure for operating, maintaining, or recovering a technical system. Everything true of a good SOP is true of a runbook, plus one constraint that changes how it is written.
That constraint is the reader's state. A runbook is often followed at 3am by someone who did not build the system, under time pressure, with something already broken. That is a much less forgiving context than a business process document written for office hours.
What that constraint changes
- No prerequisites left implicit. Access, credentials, and where to run the command all have to be stated, because the reader cannot go and ask.
- Exact commands, copyable. Not a description of what to do, the literal thing to run.
- Verification after each significant step. How to confirm it worked before continuing, since an unnoticed failure mid-recovery makes things worse.
- An explicit escalation point. When to stop and wake someone else, stated as a condition rather than left to judgement.
- A rollback path. What to do if the fix makes it worse.
What stays the same
The structure that makes any procedure followable: a clear trigger, named roles, one action per step, and decision branches where the path forks. A runbook that is a wall of prose fails for the same reason any procedure does, only faster.
Do you need both?
If you run systems, yes. Runbooks cover operating and recovering them; SOPs cover the business processes around them, such as how an incident gets communicated to customers and how the post-mortem produces a documented change. The two reference each other at the handoff.