We all know that patching is important, we all champion efficient management around updates, and we all know the risks from a data breach if something goes wrong. So why is the physical process for updating systems across the enterprise still so difficult? What can we do to improve this?

Why are we still here?

To start with, let's look at where we are with patching. According to the Ponemon Institute, almost half of all companies had one or more data breaches during the previous two years. Of those breaches, 60 per cent could have occurred due to known vulnerabilities where patches were available but not applied.

According to Gartner, despite spending on security worldwide growing to more than $150 billion during 2021, these known problems are still difficult to deal with.

While patching an individual asset for a particular vulnerability might not be hard, IT - security teams have not been able to keep up with the pace due to current siloed processes that require manual effort. Alongside this, IT teams face problems when their IT estates are not fully visible, and they have problems keeping up with their current workflows and responsibilities.

To improve patching and vulnerability management, it's important to start with asset control and creating an accurate inventory. Without this list of assets, it is impossible to know that everything is being managed effectively and that all necessary patches are applied.

Once you have that accurate list of assets, you can audit how well you are currently doing with patch deployment and compliance and see any areas that are falling behind. This exercise can show you where the most effort is needed to prevent issues, particularly if there are serious threats in the wild that can be used against those vulnerabilities.

Putting theory into practice

These steps are standard for all IT security teams. The vast majority of enterprises have services and technologies to help them manage vulnerabilities, so why is this still problematic?

The first reason is that the team responsible for flagging vulnerabilities will not be the one that applies the patches. Vulnerability management typically sits with the IT security team, but patching desktops will be the responsibility of the desktop team, IT operations or the IT service management department.

Change management can be involved whether you have a full internal team or multiple companies. For example, a colleague of mine who previously worked for a manufacturing company once had to go through a change process with 42 different approvers, all of whom had to sign off on the change before it could go live.

When you have a critical patch that must be deployed, this level of bureaucracy can delay the process and lead to more risk than it prevents.

Who is responsible?

It's also worth looking at your security team's metrics and the goals that other teams must meet. This can unveil surprising facts that were holding you back from improving patching and help you find new ways to improve performance as well.

For example, your IT operations team may be responsible for the patch deployment process alongside maintaining uptime and service availability for the business. In these circumstances, rolling out a patch may affect those other service levels, which can delay something being implemented while approval is sought.

Similarly, the team may want to arrange deployment for multiple patches in one go rather than prioritising a patch for a serious risk on its own. Solving this problem involves looking at how things are categorised and carried out so that both teams win.

Making this a business issue, rather than a technology problem, can make it easier to get support for more efficient patch deployment and faster updating.

For instance, getting business unit leaders to look at patch levels and updates may be difficult on its own. However, if your company sets a KPI around update status for those leaders, they will want to improve their performance and keep everything up to date as much as possible.

Improving patch management - and by extension, how we approach vulnerabilities - involves looking at processes, collaboration and goals. By thinking about the wider impact that patching has, we can improve how this gets delivered to the business.

Using automation in the patching process can also help. The manual load required to patch all operating systems and third-party applications can be overwhelming - automation can be the solution to reduce some manual work and any updates or mistakes.

When empirical data is used to underpin decisions around where to implement automation, work becomes more efficient. Creating predefined rules based on internally agreed operating procedures can remove a lot of the manual lifting and get things done faster.