Free IT SOP Template

Q: What should an IT SOP include?

An IT SOP should name the systems and tools in scope and their owners, the access and change-control rules that apply, and a step-by-step procedure with quality checks. This template adds a systems-in-scope table and a least-privilege/change-control note to the standard SOP sections, with a worked incident-response example.

Q: What is an incident severity matrix?

A severity matrix classifies incidents — typically Sev1 to Sev4 — by customer impact, and sets a response and resolution target for each level. It tells the on-call engineer how fast to react and who to involve. The worked example includes a Sev1–Sev4 table with response targets.

Q: What is the difference between an SOP and a runbook?

An SOP defines how a recurring procedure is done, with roles, scope, and quality checks. A runbook is the more specific, often command-level set of steps for one task or alert. Teams usually keep a governing SOP and link the detailed runbooks from its Related Documents section, which this template provides.

Q: Why does an IT SOP emphasize least privilege and MFA?

Least-privilege access and MFA limit the blast radius if an account is compromised and keep every action attributable to a named user — both are baseline security controls and common audit requirements. The template calls them out in a dedicated note so they are not left implicit.

An IT SOP built for real operations — systems, access, change control and incident response.

Part of our free sop templates.

Download Word (.docx)

Download PDF Free · No signup · No watermark

Blank template Filled exampleIncident Response SOP

1.Title Block & Document Control

SOP Title	{{SOP Title}}
SOP ID	{{SOP ID}}
Version	{{Version}}
Effective Date	{{Effective Date}}
Review Date	{{Review Date}}
Document Owner	{{Document Owner}}
Approver	{{Approver}}

Keep this block on page one so anyone can audit the document at a glance. Set a Review Date 6–12 months out and assign a single Document Owner who is accountable for keeping it current.

2.Purpose

State in one or two sentences why this procedure exists and what result it delivers when followed correctly.

Write the “why”, not the steps. Example: “This SOP ensures every customer refund is processed accurately, within policy, and within two business days.”

3.Scope

Define which teams, locations, systems, and situations this SOP applies to — and explicitly note what it does not cover.

Naming the boundaries prevents the procedure from being applied to the wrong cases. List any exclusions on their own line.

Systems & Tools in Scope

System / tool	Purpose	Owner	Criticality
{{System}}	{{What it is used for}}	{{Team / role}}	{{Critical / High / Low}}
{{System}}	{{What it is used for}}	{{Team / role}}	{{Criticality}}
{{Identity / access tool}}	{{SSO, MFA, provisioning}}	{{IT / Security}}	{{Critical}}

List the systems this procedure touches, who owns each, and how critical it is. Naming the system of record and its owner is what keeps access, changes, and incidents from falling through the cracks.

4.Definitions & Abbreviations

Term	Definition
{{Term}}	{{Plain-language definition}}
{{Abbreviation}}	{{What it stands for}}

Only define terms that could be misread by someone new to the process. If there are none, keep this section and write “None” — auditors expect it to exist.

5.Roles & Responsibilities

Role	Responsibility
{{Role}}	{{What this role is accountable for in this procedure}}
{{Role}}	{{What this role is accountable for in this procedure}}

Assign responsibilities to roles, not named individuals, so the SOP survives staff changes. Keep each role to one or two lines.

6.Prerequisites, Materials & Equipment

{{Access or permission required before starting}}
{{Tool, system, or login needed}}
{{Material or document that must be on hand}}

List everything that must be ready before step one. A short checklist here prevents half-finished runs.

7.Safety & Compliance

Note any safety precautions and the regulations or internal policies this procedure must comply with.

If this procedure has no safety or compliance angle, keep the section and write “N/A”. Reference the specific policy or regulation by name where one applies.

8.Procedure (Step-by-Step)

Step	Action	Owner	Expected Result
1	{{Start with a verb — one action per step}}	{{Role}}	{{What “done right” looks like}}
2	{{Next action}}	{{Role}}	{{Expected result}}
3	{{Next action}}	{{Role}}	{{Expected result}}

Aim for roughly 5–15 numbered steps. Begin each with a verb, keep it to one action, and make the Expected Result observable so anyone can confirm the step is complete.

9.Quality Checks & Acceptance Criteria

{{Measurable check that confirms the work was done correctly}}
{{Second acceptance criterion}}

Write 2–4 checks that are measurable — a reviewer should be able to answer each with a clear yes or no.

10.Troubleshooting & Exceptions

Failure scenario	What to do	Escalate to
{{Common thing that goes wrong}}	{{Corrective action}}	{{Role / contact}}
{{Edge case}}	{{How to handle it}}	{{Role / contact}}

Capture the failures you have actually seen. Naming the escalation point keeps exceptions from stalling.

11.Related Documents & References

{{Form, checklist, or policy this SOP relies on}}
{{Upstream or downstream SOP}}

Link the forms, policies, and adjacent SOPs a reader will need next.

12.Revision History

Version	Date	Author	Summary of change
1.0	{{Effective Date}}	{{Document Owner}}	Initial release
{{Version}}	{{Date}}	{{Author}}	{{What changed}}

Update this table every time the SOP changes. The v1.0 row is pre-filled as an example.

13.Approval

Document Owner Name Signature Date

Approver Name Signature Date

Both sign-offs confirm the procedure is accurate and authorised for use.

A worked example for a SaaS / IT operations team, with a Sev1–4 severity matrix and response targets.

1.Title Block & Document Control

SOP Title	Production Incident Response
SOP ID	IT-031
Version	1.0
Effective Date	June 1, 2026
Review Date	December 1, 2026
Document Owner	SRE Lead
Approver	VP Engineering

2.Purpose

This SOP ensures production incidents are detected, communicated, and resolved quickly and consistently, so customer impact is minimized and every incident produces a learning.

3.Scope

Covers customer-facing outages and degradations of the SaaS platform from detection to a published post-incident review. It does not cover routine changes (IT-018) or security breaches, which trigger the IR-Security playbook.

Systems & Tools in Scope

System / tool	Purpose	Owner	Criticality
Monitoring & alerting	Detects and pages on SLO breaches	SRE	Critical
On-call / paging	Routes the page to the on-call engineer	SRE	Critical
Status page	Communicates impact to customers	Support	High
Incident channel	Real-time coordination during an incident	Engineering	High

4.Definitions & Abbreviations

Term	Definition
Incident Commander (IC)	The single person coordinating the response (not necessarily fixing it)
SLO	Service Level Objective — the reliability target an alert is based on
MTTR	Mean Time To Resolve
PIR	Post-Incident Review — the blameless write-up after resolution

Incident Severity & Response Targets

Severity	Definition	Response	Resolution target
Sev1	Full outage or data risk; most customers affected	Page IC + on-call immediately	< 1 hour to mitigate
Sev2	Major feature down or severe degradation	Page on-call	< 4 hours
Sev3	Minor or partial impact; workaround exists	Ticket within business hours	Next business day
Sev4	Cosmetic or low impact	Backlog	Scheduled

5.Roles & Responsibilities

Role	Responsibility
Incident Commander	Coordinates the response, owns decisions and timeline
On-call Engineer	Investigates and applies the fix or mitigation
Communications Lead	Updates the status page and internal stakeholders
SRE Lead	Reviews the severity call and runs the PIR

6.Prerequisites, Materials & Equipment

Access to monitoring, logs, and the deploy/rollback tooling
On-call schedule current and reachable
Status-page and incident-channel access
Runbooks for the top failure modes linked in the wiki

7.Safety & Compliance

Protect customer data throughout: do not paste secrets or personal data into the incident channel, and follow the data-handling policy. If the incident may involve a security breach or personal-data exposure, stop and invoke the IR-Security playbook and notify the DPO.