Comments on: Best Practices for Patch Management

By: albert

albert — Wed, 05 Jan 2011 04:05:34 +0000

I’d like to think that all IT development companies (at least to my knowledge) test patches to some degree before they are rolled out. Unfortunately, from what I gather from the discussions sparked by this article; companies pressured by time and resources aren’t able to test patches as extensively as they should. However, it seems that untested patches are causing more trouble than they’re worth. Might as well be safe and test them extensively.

By: Vernon

Vernon — Tue, 04 Jan 2011 22:22:02 +0000

@nathan

I’ve actually worked in a company where the lack of an effective disaster recovery plan ended up costing them a fortune. In an effort to make deadline and lower costs, the company gambled to release a patch far sooner than it could be amply tested. The theory behind the decision was that the patch could actually be fixed in future, less sizable, updates. When the patch proved to be more bugged than we first imagined, a recovery plan would’ve been able to minimize areas affected by the patch release. In the end, what was supposedly cheap and risk-free, ended up being costly and damaging.

By: Emmanuel Carabott

Emmanuel Carabott — Tue, 14 Dec 2010 18:50:08 +0000

Hi Nathan, you’re right in that a disaster recover plan is definitely essential. I would still recommend going through the testing cycle however. It’s true that one cannot be completely sure that a patch will not cause issues once deployed in the live environment no matter how attentive one is with the testing; however, even an effective disaster recovery plan will take time to execute and during that time you might be losing precious productivity. I think they’re both important and should both be employed.

I agree however, you’re 100% right that a disaster recovery is an essential part of patch management!

By: timothy

timothy — Tue, 14 Dec 2010 18:19:33 +0000

It’s not that I don’t think companies don’t test their patches before deploying. It’s more that I don’t think companies test them enough. There’s a million possible things that can go wrong with a single patch, and though all of them can’t realistically be pinpointed under most project timetables. These vulnerabilities should at least be minimized. The advantage you gain by sticking to unrealistic deadlines is immediately lost when the system goes down due to bad patch management.

By: nathan t.

nathan t. — Sun, 12 Dec 2010 16:56:23 +0000

I think a disaster recovery plan is not only the best practice to addressing patch management issues, it’s downright essential. You can test the patch in controlled conditions all you want, but who’s to say that it won’t choke up all your systems once the patch goes live? Having fail-safes are a must have with systems reaching a level of complexity far beyond our wildest dreams less than ten years ago.