Editor's Note: PatchZone welcomes our newest guest blogger - Brien Posey.  Brien, a six-time Microsoft MVP, is a published author of over 4,000 technical articles and papers and three dozen book contributions. He has served as a CIO in the healthcare industry and a network administrator for the United States Department of Defense. Check out his blog here.



Today almost every software vendor routinely releases patches for their wares. Because of the overabundance of available patches, it is critical for organizations to adopt a comprehensive patch management policy. Doing so is the only way to stay organized and to keep track of which patches have been deployed and why. This blog post outlines some important elements that should be included in an organization’s patch management plan.


Patch Testing Period

Probably the most hotly debated aspect of patch management is the testing period. Some organizations go way overboard with patch testing, subjecting each patch to a battery of tests for six months or more. On the other end of the spectrum, there are organizations that do not do patch testing at all.


The reason why patch testing is such a hotly debated topic has to do with the double edged sword that is patch management. It is a well-documented fact that some patches have bugs. If an organization fails to test their patches then they could experience problems related to a buggy patch. On the other hand, most patches are designed to address security vulnerabilities. An organization that spends an excessive amount of time testing patches leaves themselves vulnerable to the exploit that the patch is designed to correct until the day when the patch is eventually applied.


Your patch management policy should define the amount of time that is allowed for patch testing once a patch is released. Some patch management policies define multiple testing schedules based on the patch type. For instance, a patch that addresses a critical vulnerability might be tested over a shorter duration than a more comprehensive patch such as a service pack or a feature pack.


Of course determining an acceptable testing schedule is only one aspect of the patch management policy. Typically the policy will also stipulate how the testing is to be done. For example, some organizations use lab testing, while others prefer to perform pilot patch deployments in the production environment.


Patch Deployment Method

Another aspect of the patch management process that should be outlined in your policy is the patch deployment method. Typically this is a simple statement outlining the technical aspects of installing the patches and verifying the success of the installation process.


Post Deployment Testing

Even with a high degree of patch testing, there is always a chance that a bug could be discovered after a patch has been approved for use in the production environment. As such, some organizations like to do post deployment testing as a way of verifying that the patch is not causing any problems.


If your organization does post deployment testing then your patch management policy should outline the testing methods and the testing schedule.


Patch Rollback
If a patch is determined to be problematic after it has been deployed to the production network then the patch may need to be removed. Your patch management policy should discuss the technique for removing the patch, but also the situations that warrant removing the patch.


Most patch management utilities include a mechanism for removing buggy patches, but it is important to understand that patches are sometimes hierarchical. It may be impossible to remove a patch if subsequent patches have been applied, unless the buggy patch and all subsequent patches are removed. Needless to say this is a somewhat drastic step. That’s why it is so important to outline the circumstances under which it is acceptable to remove a buggy patch.


Patch Reconciliation

Finally, a good patch management policy should address the subject of patch reconciliation. If your organization is performing comprehensive patch testing and only deploying approved patches then it stands to reason that you should have a list of the patches that have been approved for deployment.  Patch reconciliation involves comparing this list against an inventory of each computer’s contents to verify that all approved patches have been applied and that no unapproved patches have slipped through the cracks.


Your patch management policy should state how often a reconciliation report should be created, as well as how to deal with any discrepancies that may be found within the report.



The items that I have outlined in this blog post represent some of the elements that should go into a good patch management policy. However, every organization’s needs are different so it is important to custom tailor your patch management policy to meet your own unique needs.



Sign up for alerts on PatchZone news & tips here.