IT SOPs are what keep technology operations consistent, secure and compliant. With Trupeer, you can save hours on writing IT SOPs by starting with a free IT SOP template, customizing it with your brand guidelines, and using our AI SOP creator to turn each procedure into a clear video walkthrough.

What an IT SOP is, and what sits either side of it

A standard operating procedure is the written sequence for a task that recurs, aimed at someone competent but not expert, specific enough that two people following it produce the same result.

Two documents sit either side of it and get confused with it constantly.

A policy states a rule and a boundary. It says purchases above a threshold need approval. It does not say which button raises a purchase order. Policies change rarely and are approved by governance. If you find yourself writing "must" and "may not", you are writing policy, and it belongs in a policy document instead.

A runbook or method of procedure is a single execution of a single change, often with timings, written for one night. It is consumed and then archived. An SOP is the reusable thing the runbook borrows from. When the work is a one time cutover with a rollback window, you want a method of procedure, not an SOP.

The SOP sits between them: the rule is elsewhere, the calendar is elsewhere, and what remains is how the work is actually done, this week, on the systems you actually have.

If you want the general purpose version of this document that applies to any team, our SOP template covers the standard structure. This page covers what changes when the procedure is an IT one.

What makes an IT SOP different from every other kind

Restaurant SOPs, HR SOPs and warehouse SOPs describe work that a person will still be doing in five years. Somebody will always greet the customer and check the stock.

IT procedures are not like that. Most of them describe work that a person should stop doing. Provisioning an account, rotating a key, restoring a file, resizing a volume, clearing a queue, granting access to a shared drive: each of these is a task that begins its life as a human procedure and, if the team is any good, ends its life as a script, a self-service action, or a setting in the platform that makes the question impossible to ask.

Which means an IT SOP library is two things at once. It is a set of instructions, and it is an inventory of everything the team is doing by hand. The second use is the more valuable one and almost nobody exploits it, because the template does not ask for it.

So this template adds a field that other SOP templates do not have. Every procedure carries a verdict on its own future, and the library gets reviewed against those verdicts rather than only for accuracy. A team that writes forty SOPs in a year and deletes twelve of them is doing better than a team that writes forty and keeps all forty, and the template should make that visible.

How to customize this template in Trupeer

Step 1: Open the Templates Section

Go to the Templates section from the main navigation.

Step 2: Select and Open a Template

Click on any template you want to work with to open it.

Step 3: Expand the Template View

If needed, expand the template view to see the full layout and details clearly.

Step 4: Edit the Template

Click on Edit to start modifying the selected template.

Within the editor, you can:

• Add new sections

• Define or update formatting rules

• Add a logo and adjust its position and related settings

Step 5: Save Your Customized Template

After making all necessary changes, click Save to store the updated template as your own.

Step 6: Preview and Fine-Tune the Template

When you want to see how your customized template looks, open the Preview.

From the preview screen, you can continue to make adjustments directly if needed, ensuring the template appears exactly as you want.

With an IT SOP template you can:

• Save hours on writing: Skip the blank page with a structure built for IT procedures.

• Stay audit-ready: Built-in sections support SOC 2, ISO 27001 and similar audits.

• Stay on-brand: Apply your logo, fonts and colors using Trupeer's brand kit.

• Train IT teams: Pair SOPs with IT training videos.

• Standardize procedures: Use the same template for every IT SOP.

• Reach global teams: Translate IT SOPs into 65+ languages with one click.

The disposition field

Three verdicts, recorded in the header, reviewed quarterly.

Automate. The procedure is deterministic, has no judgement in it, and is run often enough to be worth the engineering. Key rotation, account provisioning from an approved request, certificate renewal, backup verification, log rotation, standard resize operations. Give it a target quarter, not a vague intention. The SOP stays live until the automation ships, and then the SOP is deleted rather than left to rot alongside it, which is the mistake that produces two competing sources of truth.

Hand to the requester. The procedure is deterministic but somebody outside the team wants it done, and the only reason IT is involved is that the button is behind a permission. Password self-service, group membership requests, licence assignment, common software installs. The work here is not a script, it is a self-service path plus a job aid that makes it obvious. The SOP becomes the specification for that path.

Keep human. Genuine judgement, rare enough that automation would cost more than it saves, or consequential enough that a person should be accountable for the decision. Incident triage, capacity decisions, anything involving negotiating with a vendor, anything where the correct action depends on the state of the business rather than the state of the system.

To decide, multiply run frequency by average duration to get hours per year, then ask whether any step requires a judgement that a rule could not encode. Sixty hours a year with no judgement is an automation candidate on the arithmetic alone. Four hours a year with three judgement calls in it stays human no matter how tedious it feels.

The template structure

Copy from here. The header block carries the fields most SOP templates omit.

Header. SOP number and title, written verb first, for example "Restore a deleted mailbox" rather than "Mailbox restoration process". Owner. Reviewer. Created date. Last verified date, which means the date somebody last ran this procedure and confirmed the steps still match reality, not the date somebody edited the wording. Disposition and target quarter. Run frequency and average duration. Access required, named as the actual role or group. Systems touched. Reversible yes or no.

Trigger. The event or request that starts this procedure, stated so precisely that a person can tell whether they are in scope.

Do not run this if. The conditions under which the procedure is wrong. This section prevents more incidents than the steps do.

Prerequisites. Access, approvals, information, and anything that must be confirmed before step one. Include the consumer check: which other systems, jobs or integrations depend on the thing you are about to change. If you cannot answer that, the answer is not none, it is unknown.

Steps. Numbered, one action each, with the expected result beside each action. If a step has no observable result, it is either not a step or you have not decided what success looks like.

Verification. Not a repeat of the last step. Verification answers whether the outcome happened, and it must cover the longest cycle the change touches. Overnight batch, replication lag, cache expiry, cron schedule, downstream sync. A procedure verified only by a synchronous test has been verified for the first ten seconds of its life.

Rollback. How to undo it, and the point after which you cannot.

Escalation. Who, by what route, and what to tell them.

Change record. Date, who, what changed and why. Three lines is enough.

A worked example, and what it cost

Brightmoor Insurance ran a procedure called "Rotate the payment gateway signing key" every ninety days. Six steps. It had been written in 2023 and executed fourteen times without incident.

On a Tuesday in March an engineer worked through it at 14:20. Generate the new key in the gateway portal, add it to the config store, deploy the config, restart the payment service, confirm a test payment succeeds in the sandbox, revoke the old key. Every step completed. The sandbox payment succeeded. The ticket was closed at 14:35 with a note saying rotation complete.

At 02:10 the nightly premium collection batch failed at authentication. It used the same signing key, held in a separate configuration file on a server that had never been migrated to the config store, because that server predated the migration and nobody who did the migration knew it existed.

Four thousand one hundred direct debit collections did not go out. The failure was found at 06:40 when finance ran the morning reconciliation. Collections were reprocessed by 11:00, but the overnight letter run had already generated failed collection notices to every affected customer, and the contact centre took three hundred and eighty calls over the following two days. Four people spent two days on it, plus an apology mailing.

The SOP was not wrong. Every one of its six steps was accurate and every one was followed. It failed for two reasons that were both structural rather than clerical. It had no prerequisite asking which systems consume this key, so a second consumer stayed invisible for three years. And its verification was a sandbox call, which proved the payment service was healthy at 14:32 and proved nothing about the batch job that would not run for another twelve hours.

The interesting part is what they did next. The instinct was to add a seventh step. What they actually did was build the consumer inventory the incident had forced them to compile, and once that inventory existed, rotation became automatable. The procedure shipped as a scheduled job the following quarter and the SOP was deleted.

The document's most valuable output was never the instructions. It was the inventory the instructions turned out to need, and the disposition field is what makes a team look for that on purpose rather than after an outage.

Formats, and which to use for IT work

Most guides list four SOP formats and leave you to choose. For IT work the choice is narrower than it looks.

Step-by-step is right for linear operational tasks with a known start and finish. Restores, provisioning, rotations, deployments. This is the majority of IT SOPs and the format the structure above assumes.

Flowchart or decision tree is right for diagnosis, where the next action depends on what you just found. Incident triage, connectivity faults, performance investigation. Do not force these into a numbered list, because the numbering implies a sequence that does not exist and people follow it anyway.

Checklist is right for pre-flight and post-change confirmation, where the order matters less than the completeness. Pair it with a step-by-step procedure rather than replacing one.

Hierarchical is right only when a procedure genuinely branches by environment or tier, and it is usually a sign that you have two procedures wearing one title.

Writing one in ninety minutes

Screen record yourself doing the task, at normal speed, on a real system, talking through what you are checking as you go. That recording is the draft.

Write the steps from the recording, then delete every step where you were only navigating. Add the expected result to each remaining step. Write the trigger and the do not run this if section last, because you will only know what belongs there once the steps exist.

Then hand it to someone who has not done the task and watch them follow it without helping. Every place they pause is a missing step or an assumed piece of knowledge. Fix those, set the last verified date to today, and publish.

Ninety minutes is realistic for a procedure you already know. Doubling that for a procedure you are documenting from someone else's knowledge is normal, and a knowledge transfer SOP helps structure that conversation.

Which IT SOPs to write first

Not the ones that feel important. Write the ones that score high on three things at once: run often, hurt when done wrong, and currently live in one person's head.

That rule usually surfaces the same starting set. Access and identity procedures, meaning joiners, leavers, privilege escalation and shared account handling. Backup and restore, which almost every team has documented for backup and not for restore. Incident declaration and escalation, including who is allowed to call it. Change and release steps for your most frequently touched system. Certificate and key rotation. Endpoint rebuild and asset handover.

Leavers and restore are the two that most reliably turn out to be undocumented, and they are the two where the cost of improvising is highest.

Anything you write here should point at your systems inventory rather than describing it. The application and credentials register is the right home for that, and the wider system description belongs in your IT documentation.

Reviewing the library

Once a quarter, sit with the list and ask three questions of each entry.

Has it been verified in the last six months, meaning has anybody actually run it. Unverified procedures are worse than absent ones, because people trust them.

Has its disposition changed. A procedure that was rare last year and is now weekly has moved into automation territory.

Did anything ship. Count the SOPs deleted this quarter because the work behind them was automated or handed over. If that number is zero for three quarters running, the library has become a filing exercise rather than a working set.

What to leave out

Screenshots of things that change, meaning any interface your vendor updates on their schedule. They date the document faster than the words do and they are the main reason people stop trusting a procedure. Describe the target by name rather than by position on screen.

Explanations of why the system works the way it does. Genuine curiosity is fine but it belongs in documentation, not in a procedure somebody is reading while a queue backs up.

Approval rules and thresholds. Those are policy, and duplicating them into procedures means updating fourteen documents when one number changes.

Recording the procedure instead of writing it

The slowest part of building an SOP library is not deciding what to write, it is the typing. And a procedure written from memory is always missing the two clicks the author stopped noticing years ago.

Trupeer AI turns a screen recording into a documented procedure, so the ninety minute method above collapses into a single pass. Record the task once and you get a step by step guide with the steps already written, a video for the people who would rather watch it, and a document in your knowledge base, in your own branding.

Record it. Brand it. Translate it. Trupeer it.

The SOP creator is built for exactly this, documentation keeps the procedures and the system descriptions together, and translation means a follow the sun team reads the same procedure in their own language. Setup instructions are in the document template setup guide.

Frequently Asked Questions

Is there a free IT SOP template in Excel?

Excel is the wrong container for the procedure and the right container for the library. Build one sheet listing every SOP with columns for title, owner, last verified date, disposition, run frequency, hours per year and target quarter. That sheet is what makes the quarterly review possible. The procedures themselves belong somewhere with version history and search.

Is there a Word version, or a Word doc free download?

The header block and section headings above are written to be pasted straight into Word or Google Docs and used as your house structure. There is no gated download, which also means no form between you and the template. Save your filled version as the departmental starting point rather than re-copying it each time.

Is there a PDF version?

Export your own once the procedure has been verified. PDF is right for a procedure that has been signed off and is being circulated for audit, and wrong for a working document, because a procedure nobody can edit is a procedure that goes stale in place.

Can I download it for free?

The structure, the disposition field and the worked example are free and unrestricted. Use them, edit them, put them in your own template library under your own name with no attribution.

Is there a free SOP generator?

Yes, and generators are genuinely useful for the first draft. Trupeer AI's SOP creator builds the procedure from a screen recording, which means the steps come from the system rather than from your memory of it. Whatever you use, the parts a generator cannot supply are the disposition, the consumer check and the verification window, so expect to add those by hand.

How do I make an SOP format for my team?

Pick one structure, fill it in for three real procedures, then stop and look at what you had to fight the template to express. Adjust once, then freeze it. Teams that keep refining the format never accumulate procedures, because every new SOP triggers a debate about the shape of the document rather than the content of the work.

What is the best SOP template?

The one your team will keep verified. Structure matters far less than ownership and a review date, and a plain six section procedure that somebody ran last month beats an elaborate one that nobody has opened since it was written.

How long should an IT SOP be?

One screen for the steps in most cases. If the steps run past about fifteen, the procedure is usually two procedures, or it contains navigation that should be cut. The header, prerequisites and verification can be as long as they need to be, because those are the parts that prevent incidents.

How often should IT SOPs be reviewed?

Verify every procedure at least every six months by running it, and review the whole library quarterly against the disposition field. Anything touching access, keys or restores deserves a shorter cycle, and any procedure involved in an incident gets re-verified before the incident is closed.