Why do you test manufacturer patches before releasing them? So you don’t disrupt the Business when you apply them.

What if the exposure to a Business Disrupting Security Event is greater because you haven’t patched?
What is the balance of the two risks?

Security Patches, issued by a large software company are a nicely package guide to where Security Vulnerabilities can be found. These are rapidly reverse engineered by the malware and criminal hacking community – and they work very quickly since their window of opportunity is small, but their rewards are great. This is why critical Vulnerabilities, such as Heartbleed, are announced after the major affected systems have patches available or implemented.

So, should you test Security Patches before deployment? Why not just deploy patches before an attacker uses their vulnerabilities against you?

But know you are doing it. Have an approved Patching Policy, and have a routine for it – a Patching Procedure: Backup or Snapshot systems beforehand (one of the big benefits of virtualisation) then if there is an issue you can quickly revert and start to investigate the cause of the issues.
After all, you have a business continuity plan to handle minor disruptions don’t you? Better to have a test of that than a real use of your Security Incident Plan.

(And you do have a Security Incident Plan don’t you?)