Yes, if your freeze policy says how. Define in advance which security fixes qualify for a freeze exception, who approves, and what testing is minimum. Without that, teams either break the freeze informally or leave an exploited flaw open, and both are hard to explain later.
Why freezes exist
Many regulated organizations freeze production changes around quarter end, major reporting dates, peak trading or holiday periods. The idea is sound: fewer changes, fewer surprises while the business is most sensitive to outages.
But a freeze is a risk decision, not a law of nature. NIST's patch management guide treats emergency patching as a planned scenario for a severe or actively exploited vulnerability, handled as efficiently as possible, with an accelerated schedule. A freeze policy that ignores that scenario conflicts with it.
Write the exception criteria
Decide in calm conditions which events justify a change during a freeze. A short list works:
- Evidence of active exploitation of a flaw in software you run.
- A vulnerability in an internet-facing system with a public exploit.
- A fix needed to contain an incident already underway.
- A flaw whose exposure would breach a contractual or regulatory commitment.
Everything else waits for the freeze to end, and lands in the backlog with a note.
Reduce the blast radius of freeze-time changes
| Control | Purpose |
|---|---|
| Smallest possible change | Patch only the flaw, no bundled upgrades |
| Canary first | Confirm the patch works on a few instances |
| Named approver | A senior owner accepts the freeze-time risk |
| Rollback ready | Tested, with a decision rule for using it |
| Extra monitoring | Watch errors and latency after the change |
NIST suggests that even in emergencies, deploying to a small number of canary assets can confirm the patch is not corrupted and does not break the software, for anywhere from minutes to hours.
What if the fix is too risky during the freeze
Then use a mitigation. NIST describes emergency mitigation as temporary measures before or instead of a patch, such as deactivating a function or isolating an asset, with a plan to replace the mitigation by a permanent fix. Record the mitigation, the evidence that it works, and the date to remove it.
Keep the paper trail
Each freeze exception should have a change record containing the trigger, the approval, the test results and the verification. After the freeze, review all exceptions together. If you granted many, the freeze policy or the routine patch cycle needs adjusting. NIST also notes that postponing routine patching makes emergency patching harder, because earlier patches may need to be installed first, so a freeze that follows months of skipped updates raises risk.
Plan before the freeze begins
A pre-freeze sweep helps. Two weeks before, list known open high-risk findings and fix what can be fixed. Entering a freeze with a clean queue means fewer exception requests.
Where tooling helps
Safeguard tracks which findings are reachable and which have a fix available, so a pre-freeze review can focus on the findings that matter. Fix pull requests from autonomous remediation are off by default and stay under human approval.
Quick check
Is a freeze exception a policy violation?
Not if the policy defines it. An exception that follows the written criteria and approvals is the policy working as designed.
Who should approve a freeze exception?
A named senior owner for the affected system, with the security lead consulted. Write the roles into the policy.
Sources
Last reviewed: 19 October 2026.
