Holiday periods are something every organisation has to deal with. Whether it's the summer holidays or another period where large numbers of people are taking leave, the reality is that many businesses will operate for a period of time with reduced staffing.
For IT and security teams, this can present a particular challenge.
Project work may slow down or even come to a halt. There may be fewer people available across IT support, networks, applications, and security, as well as across the wider business. Third-party suppliers may also be operating with reduced resources.
So should our approach to change remain the same?
Does reduced staffing change the risk?
One of the first things I think organisations need to consider is whether operating with reduced resources changes their risk profile or even their risk appetite.
A change that we would be comfortable making during normal operations may look very different when key people are away.
Can we carry out the same level of testing? Can we communicate the change effectively to the business? Do we have the right people available to monitor what happens afterwards? More importantly, if something does go wrong, do we have the people, knowledge, and authority available to deal with it?
The technical risk associated with a change may not have changed, but our ability to deal with the consequences might have.
That is an important distinction.
Change freeze or controlled change?
A common response is to introduce a change freeze during holiday periods. In some circumstances that makes perfect sense, but I don't think a blanket freeze should necessarily be the only answer.
There is an opportunity to plan before entering a period of reduced staffing.
What changes are scheduled? Which are genuinely necessary? Which can wait? What are the dependencies? What could the impact be if something goes wrong, and do the people who will actually be available have the capability to manage those consequences?
There is also another side to this from a security perspective.
A critical vulnerability doesn't care that half of the security or IT team is on holiday. If a vulnerability significantly changes the organisation's attack surface and there is a high probability of exploitation, doing nothing may introduce more risk than making the change.
The question therefore, isn't always simply whether we should make a change. Sometimes it is about understanding the risk of making the change versus the risk of not making it.
Do we still have the operational capability?
Reduced staffing shouldn't just be looked at in terms of numbers.
We need to understand what capabilities remain available.
The organisation may normally have a large IT or security team, but what happens if the people with detailed knowledge of a particular system, application or network are away? Do those remaining have the necessary access? Do they know how to recover the service? Can they engage the right third party if specialist support is required?
The same applies to decision-making.
If something goes wrong, are the people working during that period actually empowered to make the decisions that may be required?
And this isn't just an IT decision. An incident could require business, operational, financial or security decisions. The normal decision-makers may not be available, so the organisation needs to understand who has that authority in their absence.
What happens if there is an incident?
Incident response is another area worth thinking about.
Many organisations have incident response plans describing who needs to be involved when a significant incident occurs. But how well does that plan work when a large proportion of those people are on holiday?
An incident response plan that assumes a full team, full technical capability, and a full house of decision-makers may look very different when it has to be enacted by a skeleton team.
Internal and external escalation paths matter here as well.
Do the people working know who to contact? Are emergency and out-of-hours details available? Can they reach the organisation's SOC, IT support provider, application vendor, or other critical suppliers? And are those suppliers themselves able to provide the level of support the organisation expects during the holiday period?
These questions bring change management, incident response, business continuity, and operational resilience much closer together.
Prepare your team to act
If you are a Huntress partner or customer how can you ensure the Huntress agentic platform is optimally configured to contain and respond to incidents? We call this Huntress Managed Response.
For Huntress partners and customers, enabling Managed Response creates a more resilient first line of defence. It gives the Huntress Security Operations Center (SOC) permission to take predefined, targeted actions on the partner's behalf when a confirmed threat is published as an Incident Report. Instead of waiting for someone to review an alert, decide what to do, and press another button, the SOC can begin containment and remediation immediately.
There are several outcomes that the Huntress Managed Response delivers.
Isolating threats in minutes rather than hours
The first outcome is speed. Managed Response is designed to begin remediation as soon as the SOC confirms a threat and publishes the Incident Report, with the objective of containing incidents in minutes rather than hours.
Shortening the gap between detection and containment can help limit an incident's potential impact, while giving security teams more time to focus on business priorities and recovery.
Expert response is available when your team needs it
Even highly capable teams cannot be available every minute of every day. Managed Response extends the reach of both partners and customers by enabling Huntress experts to take initial, time-sensitive actions when they matter most.
Dependable handling when your resources are strained
Incidents can create uncertainty, even for experienced teams. Managed Response turns proven remediation procedures into repeatable action.
For partners supporting multiple environments, and for customers seeking a dependable response process, this consistency makes incident handling easier to operationalise, measure, and improve.
Empowering teams to transition swiftly from containment to recovery
Managed Response handles the immediate work of disrupting attacker activity and evicting the threat. The partner and customer teams can then focus on securing the environment, fully resetting affected passwords, identifying the root cause, such as a phishing email, applying required patches, and restoring normal operations.
For organisations and the partners that support them, enabling Managed Response is a practical way to strengthen operational resilience. It reduces reliance on perfect timing, perfect staffing, and manual reaction while preserving oversight, recovery ownership, and the opportunity to learn from every incident.
Figure 1: Huntress Managed Response containment and remediation options and automations.
Questions worth asking about operational resilience
Before entering a period of reduced staffing, there are some simple questions I think organisations should be asking:
Does reduced staffing change our current risk profile or risk appetite?
Do we need a change freeze, or can we operate a controlled approach to necessary changes?
Do we understand the dependencies and potential consequences of the changes that are allowed to proceed?
What minimum IT, security, and business capabilities need to remain available?
Do we have the right knowledge and access available, not simply enough people?
Are the people working empowered to make the necessary technical, security, operational, financial, and business decisions?
Would our incident response plan still work effectively with reduced resources?
Are our internal, external, emergency, and out-of-hours escalation paths clear?
Have we confirmed what support is actually available from our critical third parties?
How would we respond if a critical security vulnerability required an urgent change?
Do we understand the risk of not making a particular change?
What is our plan for returning to normal operations?
That last question is easily overlooked.
Once people return, there may be a backlog of project work, patches, upgrades, and other changes waiting to happen. Simply releasing everything at once could create another period of increased risk.
There needs to be some thought about how that demand is communicated, prioritised, and brought back into the normal change process.
The question isn't just whether the change is approved
None of this means organisations should stop making changes every time people go on holiday.
It means the circumstances in which we are making those changes need to form part of the risk decision.
A change may have been tested. It may have been through the normal change process. It may even have an approved rollback plan.
But if something goes wrong, who is there to recognise it, make the decision, execute that rollback, communicate with the business, and manage the consequences?
The technical risk of the change may be exactly the same.
The organisation's capacity to deal with failure may not be.
So perhaps during periods of reduced staffing, alongside asking whether a change has been tested and approved, there is another question we should be asking: Do we have the operational resilience to make this change safely right now?