Is it more secure to apply updates as soon as they are released, or wait to make sure the updates are not causing problems to the system. It might sound stupid but in the last few years I heard about more than one incident when vendors release updates that suppose to add features (not to fix security issues) which cause security problems or even break the system.

Is there a general rule or a common practice among system administrators/security professionals?


The general rule of thumb is to apply the updates in a test or parallel environment, run tests, then approve for general release.

In some cases, people will apply patches to live environments but on lower priority servers and be willing to suffer outages on the less critical systems.

BUT, because of the criticality of a lot of patches, it is also advised to design a policy of applying all patches to all servers as soon as possible and have a procedure by which you can quickly recover from an issue. You trade patch-based 'availability' issues for security-based issues and you need to determine which trade-off is the best fit for your environment.

  • 4
    When a patch causes downtime, it's the IT group's "fault". When a hacker exploits a unpatched security hole, it's the hacker's "fault". No one wants to blame themselves, so the blame is shifted to a nameless threat instead of Jim down the hall. I think that a lot of organizations think they are doing "risk management" when they are really performing "blame management". – schroeder Oct 8 '14 at 18:39
  • "Risk management" is not trusting the company releasing the patch, blame goes on them. Given the wide array of system configurations, especially in the corporate environment, you have no idea what will and won't break your systems without testing. In these cases, it's the IT group's fault if they don't properly test the patches before install. If they slack around and don't provide proper testing and get hit by a hacker, then it's again their fault for providing inadequate security when a fix is available. As someone who works in the IT world, expect to get blamed a lot. – user41341 Oct 8 '14 at 23:06

Updates should be applied as soon as they can safely be applied. A balance of functionality/availability and security needs to be found. Updates should never be immediately applied without testing. Appropriate testing needs to be performed to verify that the updates work and don’t break any existing functionality.

This is where policy comes in. The decision of when to update shouldn’t be made by one person. The process for how updates are applied should be defined in a policy. It’s the only way to ensure all of the rest of the organization’s concerns are addressed. The rest of the organization can be affected when the update process goes wrong. Appropriate testing needs to be performed, and once updates are approved systems will need to be restarted to apply updates. Testing should be an agreed upon process to ensure that existing functionality can be verified. Applying updates needs to be an agreed upon process as critical infrastructure will need to be updated and that needs to planned.

Updates are rolled out in phases after testing is complete. This is to prevent any unseen issues from affecting the entire organization at once. I personally like 3 tiered rollouts if available. That means updates are first rolled out to a smaller group of tech savy people in the organization. If there are problems they are the most likely to find them, they’re least likely to have complaints when issues arise, and they are the best people to be able to use work arounds. Then the general population when the tech savy group hasn’t identified any additional issues. Then the higher risk and/or least tech savy people last. These are the ones that have the most problems. What is rolled out to them should be good or else they’ll have the biggest complaints.

The best turn around I’ve heard of from a large organization is 3 weeks with some leeway of less for critical or more for minor issues. That means when I update is released, it will be applied to the entire organization within 3 weeks.


Depends highly on the update, you always stand the chance that a new update will be itself a security risk, or expose one while addressing another, but you also can assume it will be widespread,, and that by adopting it early you enter a large pool of recent known attack targets.

I agree with sschroeder, it depends on the environment, for the average home user, I would say yes, because most are safer at least trying. In corporate environments I say no because if not insecurity brought with new patches, may come instability, and deploy nothing large scale until well tested. Exceptions being those cases where you just have to because the internet is on fire and your dongle is exposed.

This is especially true of service packs, where an individual update is generally highly tested and highly specific, service packs could make thousands of changes to a billion different system configuration possibilities, I have seen entire companies brought down my automated install everything automatically strategies of admin who favored ease of false security over diligence, competence, and stability.

As far as security goes... A good approach to all secure environments is system hardening... so if an exploit is found, what can a remote user do with it? Proper firewall rules, allowed traffic, protocol analysis, at the borders. Disabling unneeded protocols, services, and utilities on the machines themselves. I mean ultimately in the hands of a gifted attacker, there is almost always a way, however those types are in general rare, more often it is the passerby looking for vulnerable systems, and you can do a LOT to make yourself a less worthwhile target.

Those things give you the ability to carefully plan update strategies instead of install and pray.

Not the answer you're looking for? Browse other questions tagged or ask your own question.