An urgent hotfix should still have a second reviewer, a small diff, a regression test and a passing pipeline. What you can shorten is the waiting, not the checking. Pair the author and reviewer live, and record the approval so the speed is defensible later.
What you can speed up and what you cannot
| Keep | Speed up |
|---|---|
| A second person reads the diff | Review happens by video call, not by queue |
| Tests run, including the new regression test | Run only the pipeline stages that matter, never zero |
| Scan for new vulnerable components | Auto-approve nothing, but make the scan fast |
| A record of who approved | Fill it in as you go, not after |
An unreviewed emergency change is one of the most common ways to introduce the next incident. A typo in a hotfix can turn one problem into two.
Rules that work
- The diff must be small enough to read in one sitting. If it is large, split the urgent part from the cleanup.
- The author cannot be the only approver. A second person checks the change line by line.
- The regression test must exist and must have failed before the fix.
- No unrelated changes. Formatting, renaming and other tidy work go in a later change.
- The pipeline must pass. If a stage is flaky, rerun it and note the rerun, do not bypass it.
- Check for new dependencies. A hotfix that adds a package needs a look at that package.
- Check what the change touches around the fix: error handling, logging that might expose data, and configuration defaults.
A short reviewer checklist
- Does the change fix the reported behavior and nothing else?
- Is the failure mode safe? If the new code errors, does it fail closed?
- Does a test prove both the block and the valid case?
- Is anything secret or personal now written to logs?
- Is the rollback step clear?
When only one person is available
Sometimes at three in the morning there is no second reviewer. Write down why, have the sole author do a self review with the checklist, and schedule a review by another person within a day. Record the exception. If this happens often, your on call rotation needs a second name.
Evidence afterward
Keep the approval record, the pipeline run, the scan result and the test output together. Frameworks that ask for secure change management generally expect to see this kind of record, and it is easy to keep if you capture it during the event. Do not describe any of it as a certification, since evidence only shows the control operated.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which checks must pass before merge, the minimum a hotfix should keep.
Safeguard policies and gates can enforce those checks on every pull request, including urgent ones, and its compliance and evidence automation helps you keep the records. A free scan is at gold.safeguard.sh/scan.
Quick check
Can a hotfix skip code review?
It should not. Shorten the wait with a live review, but keep a second person reading the change.
What if the pipeline is slow?
Run the stages that cover the changed code and the security checks, and record any stage you deferred and why.
Last reviewed: 19 October 2026.
