For an urgent hotfix, keep the checks that stop you making things worse: a second reviewer, secret detection, a tested rollback and a basic test of the fix. You can defer slow or broad checks, such as full regression and deep scans, if you run them right after release and record the debt.
Why not skip everything
Speed is the reason hotfixes are risky. A rushed change is more likely to contain a mistake, and a mistake in production under pressure is costly. The Scrum Guide says an item that does not meet the definition of done cannot be released. Many teams define a shorter "hotfix path" in advance so urgency does not mean improvisation.
Decide the path now, while nobody is panicking. During an incident, people reach for whatever is written down.
Keep, defer, or drop
| Check | Hotfix decision | Reason |
|---|---|---|
| Second person review | Keep | The cheapest defence against a rushed mistake |
| Secret detection | Keep | Fast, and a leaked secret in a rush is common |
| Test of the fix itself | Keep | Proves the change does what you meant |
| Rollback plan | Keep | You must be able to undo a bad hotfix |
| Dependency scan on changed files | Keep if fast | Skip only if it takes long, then run after |
| Full regression suite | Defer, run right after | Slow, but must be completed |
| Deep static analysis | Defer, run right after | Same |
| Design review | Defer unless the fix adds a trust boundary | Do a short review later |
| Documentation updates | Defer, with a date | Must not be forgotten |
The catch-up rule
Anything deferred gets a ticket, an owner and a date, normally within a few working days. Tell the product owner what was deferred and why. Close the ticket only when the check has run and any finding is handled.
NIST's Secure Software Development Framework asks teams to record security check approvals, rejections and exception requests in the workflow and tracking system. A hotfix exception is exactly that, so record it there.
Steps for a hotfix
- Declare it a hotfix and name the incident or risk.
- Make the smallest change that fixes the problem.
- Get a second person to review the diff.
- Run secret detection and the test for the fix.
- Confirm the rollback and how to trigger it.
- Release, then watch monitoring closely for a set time.
- Open catch-up tickets for everything deferred.
- Run the deferred checks and close the tickets.
- Hold a short review. What made the hotfix necessary, and what would have prevented it?
When the hotfix is a security fix
If the hotfix closes a vulnerability, speed matters more. Still keep the second review and the rollback. Check that the fix covers the issue, and consider whether similar code exists elsewhere. NIST SSDF practice RV.3.3 asks teams to review the software for similar vulnerabilities and fix a class of issue proactively.
Who can approve the shortened path
Decide in advance. Common choices are the tech lead and the product owner together, or an on-call lead. Avoid a single person who can approve their own hotfix with no second view.
Watch for abuse
If every release becomes a hotfix, the path is a loophole. Count hotfixes each quarter. A rising number points to problems earlier in the process, such as late testing or unclear priorities.
Roll back first when unsure
If you are not sure a hotfix is safe, rolling back to the last good version is often faster and safer. Know in advance which version that is and how to deploy it.
Safeguard can run quick dependency checks and keep gate decisions with the build for later review. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a hotfix allowed to skip code review?
It should not. A second reviewer is the cheapest protection against a rushed mistake. Keep the review short, but keep it.
What happens to the checks we deferred?
They get a ticket, an owner and a date, usually within days. The hotfix is not fully done until they have run and findings are handled.
Sources
Last reviewed: 19 October 2026.
