Skip to main content


Testing Software Patches is Critical

Testing Software Patches is Critical

So, You’ve Been Patching; Now What?

There are numerous, important components of a strong Patch Management Program; including identifying the right patches, establishing a formal patch schedule, deploying patches, and making sure your patching is effective. However, one often-overlooked, yet critical component of a good Patch Management Program is Patch Testing. Testing patches before you implement them is a safer way to determine if a patch will cause an error in your production environment. One of the most frequently asked questions about patch management is “How do I test my patches before I implement them into my production environment, and how long do I need to spend testing?”


Option 1: Create a Test Environment

The best way to test a patch is to establish a nonproduction environment that hosts your critical applications, including business applications and network systems where possible. The idea is to apply patches and updates to the nonproduction environment first, testing the environment for operational acceptance. The test environment may be virtual, it may consist of old systems past their useful production life loaded with business applications, or it may be replacement-level production systems that are segmented off the production network. The goal is to replicate the production environment as much as you can, but there may be limitations (logistical, physical, resource, or monetary) that leave the test environment a little light, but testing most patches is better than testing no patches.


Patches may be available multiple times a week, so testing as soon as possible is very important to maintain your threat protection. The time it takes to test patches may be two days to two weeks, depending on the updates provided and criticality of the system to be patched. You must keep in mind a patch is provided to fix a software vulnerability or to add additional security. It is important to establish a standard testing timeframe in your documented Patch Management Program. Complete the testing as soon as possible in your test environment, then once you're confident the patch won’t cause issues, implement the patch in the production environment.


Option 2: Test on Limited Production Devices

What if creating a separate nonproduction environment is not practical? You can identify a few devices and systems from your production environment, add these devices to a separate operational group, and then use the group as a testing environment. With this testing group, you would apply the patches in the same fashion discussed above, then let the users test the patches for functionality. This test group allows a patch to be limited to only a few devices in the event the patch causes operational issues and time is required to fix the issue. This allows you to limit the risk exposure to the rest of the production environment, and if a patch does cause an issue, you can work to roll-back or find a fix for the patch before implementation into the rest of production.


Don’t Forget About Vendor Patching

Your organization has likely outsourced some, if not most, of your business applications. What should you do about understanding how your outsourced critical systems are patched? The first step is to obtain an external audit report from the outsourced vendor. An external audit report – often an SSAE 18 SOC Report or a standards-based questionnaire – should validate the vendor’s patching process along with the effectiveness of patch testing. You may not have a choice in how the partner tests before implementing patches, but you should be able to determine if it’s effective and adequate. Be sure to include your review of this audit report in your ongoing vendor management processes.


Consider risk exposure in your plan to test patches and determine what method of testing is right for your organization. Test your available patches as soon as possible before implementing into your production environment. Patch testing could save your organization a lot of work and provide a safer environment.


How SBS Can Help

Patch Management should be a part of any strong External IT Audit program. SBS offers External IT Auditing as a service, in addition to other network security testing such as Vulnerability Assessments (testing the effectiveness of your patch management program and vulnerability management). 

Written by: Jeff Spann
Senior Information Security Consultant
SBS CyberSecurity

SBS Resources


Related Certifications

Join our growing community of financial service professionals showing their commitment to strong cybersecurity with a cyber-specific certification through the SBS Institute. Click here to view a full list of certifications.

Hacker Hour webinars are a series of free webinars hosted by SBS CyberSecurity. Unlike paid webinars, Hacker Hours are aimed to meet on a monthly basis to discuss cybersecurity issues and trends in an open format. Attendees are encouraged to join the conversation and get their questions answered. SBS will also offer products and services to help financial institutions with these specific issues.

Posted: Monday, October 30, 2017
Categories: Blog