Before a holiday or long weekend, patch what is pending, renew anything expiring in the window, confirm who is on call for security and how they are reached, test alert routing, and write down the rule for emergency changes. Attackers like quiet periods because fewer people are watching.
Reduce what can go wrong
- Finish pending patches for internet facing systems before the freeze starts. Do not leave known exploited issues open over a break.
- List expiring items in the freeze window plus a week: certificates, API keys, domain registrations, licences and service account passwords. Renew them now.
- Freeze risky changes, not all changes. Defer migrations, permission redesigns and new vendor connections until people are back.
- Check backups. The latest backup completed and the restore path works.
Make sure someone is watching
- Name the on call person and a backup, with phone numbers that are tested. A page that goes to an unmonitored mailbox helps nobody.
- Test alert routing end to end. Send a test alert for a security event and confirm it wakes the right person.
- Check the decision chain. Who can approve taking a system offline, rotating keys or contacting customers at night?
- Keep contact details for key vendors and hosting providers reachable offline.
- Share a short runbook: how to disable an account, block an address, isolate a host and revoke a token.
Write the emergency change rule
A freeze fails if people do not know when to break it. Define:
- What counts as an emergency, such as active exploitation, data exposure or a critical vulnerability in an exposed system.
- Who approves an emergency change.
- The minimum checks, such as a second person reading the change.
- How the change is recorded, so it can be reviewed afterwards.
Reduce the human exposure
Remind staff that phishing and payment fraud spike around holidays. Tell them how to confirm unusual requests. Check that out of office messages do not reveal too much, such as travel dates and who is covering.
After the break
Review logs for the period. Check for sign ins at odd hours, new accounts, new keys, and disabled logging. Review alerts that fired and how fast they were handled. Lift the freeze gradually.
Safeguard can alert on newly disclosed vulnerabilities in your dependencies, which helps when the news breaks while the team is away.
Keep the plan proportionate. A small team does not need a command centre, only a clear name, a working phone and a short runbook. Pick a person who has done on call before and give them a backup. Tell the rest of the team that they should not be heroes: if something looks wrong, they call the on call person and do not start improvising changes.
Quick check
Should we freeze security patches too?
Usually not for critical ones on exposed systems. Freeze large or risky changes instead.
What is the one thing to test?
That an alert actually reaches a person who can act on it.
Last reviewed: 19 October 2026.
