This IT automation checklist gives nine checks for an automation that already runs. Each check has a pass test, a record to open and a person who looks. Then count the passes out of nine.
Last reviewed 2026-11-05 by Manish Sharma.
The checks cover IT operations work, such as health checks, patching, restarts, clean-ups and certificate renewals. Software test automation is not part of them. Building new environments from files also stays out, which is a different job.
IT Automation Checklist Gate: Is One Task Ready to Automate?
A task is ready when you can answer yes to five questions about it. When you ask them, take one task at a time. If you are weighing several tasks, that is a different exercise, and it belongs to how to build the automation.
- Does the task run the same way each time, with a known right result?
- Is it written down well enough that another person could do it by hand?
- Does one named person answer for it?
- Is there a way back if a run goes wrong?
- Would a failed run reach a person?
If any answer is no, you have two choices. Fix that gap first, or leave the task manual until it is fixed. If nobody can describe the task, the automation becomes a second thing that only one person understands.
Five yes answers say only that the task is ready to start, while the rest of this page is for automations that are already running, and it asks for proof.
The IT Automation Checklist for Running Automations: Nine Checks and Proof
Mark each check pass or fail, and nothing in between. A pass needs a dated record that you can open today. If all you have is someone’s word, it is a fail. Each pass earns one point, so the top total is nine.
Mark one automation at a time. The person who wrote it may mark first, and then a second person opens the record behind every pass. In the tables, “the window” means the last six months.
Before you start, paste these tables into a spreadsheet and add owner, date and result columns. This checklist is a self-check, while an audit or a certificate is a separate job.
Who Answers for It?
Checks 1 to 3 cover the people. Without them, no one can approve a change or step in when a run fails.
| No. | Check | Pass if | Evidence to open | Who looks |
|---|---|---|---|---|
| 1 | Owner | One named person answers for the automation and confirmed it inside the window. | The owner entry and the dated confirmation. | A second person opens the entry. |
| 2 | Approver | A named person, who is not its author, approves changes and any run on live systems. | The approval record for the latest change. | The owner reads the record. |
| 3 | Runbook current | The written steps match what runs today, and a reader who did not write them can follow them. | The runbook, set beside the live version. | A colleague tries the steps on paper. |
Check 2 is about approving changes to the automation. Requests that users raise are a different job, so this list does not cover them. A runbook here is the written set of steps for a task.
What Can It Reach, and Who Hears When It Fails?
Checks 4 to 6 cover reach and silence. An automation that can touch too much, or fail without a sound, needs a check of its own.
| No. | Check | Pass if | Evidence to open | Who looks |
|---|---|---|---|---|
| 4 | Access | It uses its own account, holds only the rights the task needs, and can be switched off alone. | The account’s rights list and the switch-off step. | Someone from security or the owner of the systems it touches. |
| 5 | Secrets | Passwords, keys and tokens sit in a store built for them, not in script text, and a rotation date lies ahead. | The store entry with its rotation date, and a search of the script. | A second person searches the script. |
| 6 | Logs and alerts | Each run leaves a record, and a failed or skipped run reaches a named person. | The latest run record and one alert that reached its person. | The owner opens both. |
For check 5, guidance on keeping secrets out of code sets out why they belong in one managed store with planned rotation.
If a failed run would reach nobody, the automation fails with nobody told. For example, a renewal job that skips a certificate and sends no alert leaves the gap open until someone looks. Check 6 closes that gap.
Can You Change It, Stop It and Go Back?
Checks 7 to 9 cover change and exit. Each one needs a date, because a way back that nobody has tried is a guess.
| No. | Check | Pass if | Evidence to open | Who looks |
|---|---|---|---|---|
| 7 | Change record | Every change since go-live is on record with date, person and reason, and the record matches the version running. | The change log and the running version. | The approver from check 2. |
| 8 | Way back last tried | The way back was tried inside the window and worked. | A dated test record. | The owner and the approver. |
| 9 | Exit plan | A written plan says how to stop the automation, do the work by hand and who may call it. | The plan, with a date and a named caller. | A second person reads it through. |
Check 8 fails when the record says only that a way back exists. It needs a dated run that shows the way back worked.
Key Takeaway A pass needs a dated record that you can open today, and someone’s word is a fail.
Turn Your IT Automation Checklist Result into Action
Count your passes out of nine, then work through the fails in the order below. The marks, the window and the order are Signisys suggestions that you can adjust.
What a Fail Means for Each Check
Each fail points to a different repair. Start with the checks that leave nobody in charge.
- Fail on check 1 or 2: nobody can answer or approve. Fix this first, and hold unattended runs until it is fixed.
- Fail on check 4, 5 or 8: the automation reaches too far, or has no tested way back. Tighten its reach, or put each run behind a person’s approval until the fix is done.
- Fail on check 3, 6, 7 or 9: give each one a named person and a date in the next change window.
Write it down with the approver, the date and the reason. It still counts as a fail.
The total then shows what is true today, and the note shows who accepted it.
Take an invented case, with no real data behind it. A certificate-renewal job passes seven of nine. It fails check 5, because a key sits in the script, and check 8, because the way back was last tried 14 months ago. The count is 9 minus 2, which gives 7. The fix is to move the key into a store then run the way back once.
Treat the total as an automation health check at one moment. A total of nine is a snapshot of the proof you hold, while it does not promise that the next run will succeed.
When to Check Again
We suggest marking all nine checks every six months, while a shorter gap suits sensitive systems. Mark again sooner when one of four triggers appears.
The four triggers are a change to the automation, a new owner or approver, a change to a system it touches, and a failed run. If a trigger appears, you can mark just the checks it touches. For instance, a new owner means checks 1, 2 and 3, and a failed run means checks 6 and 8.
Key Takeaway Mark all nine checks every six months, and mark again sooner after any of the four triggers.
Limits of This Self-Check, and When to Bring in Help
This IT automation checklist shows what proof exists today. It does not judge how well the automation is designed, so a person has to judge that. If a fail shows that a task needs a different kind of approach, see how scripts, tools and AIOps-style options compare.
Bring in a specialist when no one can say who owns an automation, when a secret sits in plain text, when nobody has tried the way back, or when an auditor asks for proof. The checks also apply if AI-driven fixes run unattended, and the same nine questions fit AIOps as they fit a script. For the cost side, see where manual work costs a firm.
Signisys provides the services linked below and gains if you contact us. The nine checks work without us, so you can run them on your own.
For help while you mark, see routine IT operations work with a specialist. Our operations automation solution and IT consulting and managed services cover the follow-up.
IT Automation Checklist FAQ: Common Questions
Do these checks apply to software test automation?
Can you use the checks on a script one person wrote years ago?
How does the IT automation checklist apply to an automation a supplier runs for us?
Who may accept a failed check instead of fixing it?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.