Patching without testing: Risky or Rational?

: @orinthomas Earlier this year I was teaching a Configuration Manager class and we were discussing software update testing before deployment. I asked members of the class how much time they spent testing software updates before deploying them given that the average time between the release of an update and a publicly available exploit was around 6 days. I got a variety of answers. Some of the organizations that students worked for had a lengthy update testing process which could mean it was several weeks between when an update was released and went into productions. Others had a more cursory testing scheme, deploying updates to a small number of production servers before redeploying the updates across their organization. The answer that interested me the most was a student who told me that they simply deployed updates without testing them. His reasoning was as follows: Testing rarely found updates that broke something to the point where the update would not be deployed. Thorough update testing each month took a substantial amount of time. Time equals money. On a yearly basis, the cost of testing updates rigorously each month exceeded the cost of rolling back the occasional update that broke things. He made sure that he took a full backup of each system prior to deploying an update so that he could perform a complete rollback if he couldn’t uninstall the update gracefully He deployed updates in a staggered manner, so that any immediate problems would become apparent before the update was rolled out to all production systems. This approach seems to be an attempt to balance the risk of an update ganking systems with the not insubstantial cost of thoroughly testing updates before deployment. It relies on software vendors being reasonably thorough about testing updates prior to deployment. If your organization is finding few actual problems when testing updates prior to deployment, perhaps you are allocating more resources than necessary to mitigate a