Toil in vulnerability management is repetitive manual work that scales with your estate and adds no lasting value, such as copying findings into tickets or chasing owners. Automate that first. Keep judgement tasks, like deciding risk acceptance, with people. Cutting toil is how a fixed team gains capacity.
A working definition
Google's SRE book defines toil as work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. It adds that not every toil task has all of these traits, and that toil is not simply work someone dislikes.
It also records an advertised goal of keeping toil below half of each engineer's time, because toil tends to expand and can fill every hour. That idea transfers well. If your security engineers spend most of the week on mechanical handling, they have no time to improve anything.
Where toil hides in vulnerability work
| Task | Toil? | Better approach |
|---|---|---|
| Copying scanner output into tickets by hand | Yes | Automatic ticket creation with deduplication |
| Chasing owners for status | Yes | Assigned owners and an aging view |
| Re-triaging the same unreachable finding each scan | Yes | Recorded decisions that persist |
| Bumping a patch version and opening a pull request | Often | Automated fix pull request, human review |
| Building the monthly report in a spreadsheet | Yes | A live view from the same data |
| Collecting evidence for an auditor | Often | Evidence captured as work happens |
| Deciding whether to accept a risk | No | Needs human judgement |
| Planning a major framework upgrade | No | Engineering work with lasting value |
How to find your own toil
- For two weeks, ask each person to note tasks that repeat.
- Mark each with how often, how long, and whether it needs judgement.
- Multiply frequency by time to see the cost.
- Rank by cost and by how easy it is to automate.
- Pick the top item, automate it, and measure the hours returned.
Do not start with the most exciting task. Start with the most repetitive.
Automation has its own costs
Automation that you cannot trust adds a new kind of toil: checking its output. Keep each automation observable, with a clear way to see what it did and to turn it off. The ladder in which fixes to automate first covers how to build trust step by step.
Protect the freed time
Time saved vanishes if nobody decides where it goes. Name the next target for freed hours, such as a major upgrade or a test gap that blocks automation. Otherwise the saving just disappears into the next surge.
Judgement is not toil
Some work looks repetitive but needs a person: risk acceptance, exception review and customer communication. Automating those without oversight swaps a slow decision for an unaccountable one. Automate the preparation, such as gathering context, and leave the decision with a named owner.
Where Safeguard fits
Safeguard automates several repeating tasks: continuous scanning, ownership tracking, evidence collection for compliance, and optional fix pull requests, which are off by default. It is a way to shift hours from mechanical tasks to decisions. A free first look is available through the free scan.
Quick check
Is all manual work toil?
No. Work that needs judgement and creates lasting value is not toil. Toil is manual, repetitive, automatable work that grows with scale.
What should I automate first?
The most frequent mechanical task that needs no judgement, such as ticket creation and owner assignment.
Sources
Last reviewed: 19 October 2026.
