Vulnerabilities exist in all types of software.

Why? Because software development is not a perfect process. With a constant balancing act between release schedules and quality assurance that results in the release of initial versions of product, problems that do arise, need to be fixed with security updates. These updates are often referred to as patches, because of the way they cover holes.

So what’s the problem? Organisations can be poor at systematically applying those patches, leaving many devices unpatched for months, or years. Leaving well-known vulnerabilities exposed is like leaving your front door open 24/7, allowing hackers entry into your systems.

Here’s what you can do:

Create a patching policy for your organisation that defines:

1) A service level agreement (SLA) for each patch category, such as:

– Critical – 10 days

– High – 30 days

– Medium – 60 days

– Low – 90 days

2) How patches are tested before they are deployed into the live network, to ensure they don’t cause a problem

3) Post patching testing to ensure everything still works and that the patch has actually been applied, many people forget to reboot the device to actually install the patch.

4) Metrics to measure the success of patching against the SLA targets