Review an emergency fix fast, not never. Keep a second reviewer focused on one question, whether the change actually closes the hole. Defer style and refactoring comments, then review the change again more thoroughly once the emergency is over. Do not call a deadline an emergency.
What counts as an emergency
Google's public engineering guidance defines an emergency change as a small change that, for example, lets a major launch continue instead of rolling back, fixes a bug significantly affecting users in production, handles a pressing legal issue, or closes a major security hole.
The same page lists what is not an emergency: wanting to launch this week rather than next, a developer who has worked a long time and wants the change in, reviewers being in another time zone, the end of a Friday, and a manager citing a soft deadline. A hard deadline, it says, is one where something disastrous happens if you miss it.
That distinction matters for security because "urgent" is the easiest word to use when you want to skip a step. A real emergency is a live exploit or a confirmed exposure. A scanner finding on a quiet service is not one.
What to keep
Google's guidance says that in an emergency the reviewer should care more about the speed of the review and the correctness of the code, meaning does it actually resolve the emergency, than anything else. Translate that for a security fix:
- Does it close the hole? Read the change against the vulnerable path. Can the same input still reach the bad behaviour another way?
- Does it break anything obvious? One quick check that the main flow still works.
- Does it add new exposure? A hurried patch that adds a debug endpoint, a broad permission or a logged secret creates the next incident.
- Is there a rollback? Know how to undo it before you ship it.
Keep it to a second person. A reviewer who is not under the same pressure as the author catches errors the author cannot see.
What to defer
- Naming, style and structure comments.
- Wider refactors of the surrounding code.
- Documentation updates, as long as a ticket exists to write them.
- Test coverage beyond one test that proves the fix.
Say these out loud in the review: "Deferring style and tests to the follow-up." That keeps the pull request narrow and makes the promise visible.
The follow-up review
Google's guidance says that after the emergency is resolved you should look over the emergency changes again and give them a more thorough review. Make this a ticket with an owner and a date, created while the fix is being reviewed. Without a ticket it will not happen.
The follow-up covers the deferred items, a fuller test, and a short look at why the hole existed. If the cause is a pattern, such as an unchecked object id, the real fix is wider than the patch.
Keep the record
Whatever your compliance regime, write down who reviewed the emergency change, when, and when the follow-up was completed. A short entry in the pull request is enough. An unexplained approval-free merge looks the same in an audit as a control that did not exist.
Watch for repeat emergencies
Google's guidance warns that if developers routinely submit changes that "must get in" with superficial review, the process should change. In security terms, if you declare an emergency every month, you have a planning problem or a backlog problem, not an emergency problem.
Quick check
Can one person approve an emergency fix?
Two people is safer, and it is quick. If a second reviewer truly is not available, record that, and schedule the follow-up review for the next working day.
Does an emergency waive tests?
It waives breadth, not proof. Keep one test or one manual check that shows the fix works, and defer the rest.
Sources
Last reviewed: 19 October 2026.
