ISO 27001 Patch Management Policy: Ultimate Guide

Introduction

In this ultimate guide I show you everything you need to know about the ISO 27001 Patch Management Policy and exactly what you need to do to satisfy it to gain ISO 27001 certification.

We will get to grips with what patch management is, understand why organisations need a Patch Management Policy, show you how to write one, and let you in on trade secret’s that’ll save you hours of time and effort, simply by using this template.

I am Stuart Barker: founder of High Table, Information Security expert and ISO 27001 Ninja, and this is the ISO 27001 Patch Management Policy.

What is an ISO 27001 Patch Management Policy?

The ISO 27001 Patch Management Policy sets out the guidelines and framework for how you identify, prioritise, test, deploy and monitor patches.

The patch management policy addresses known vulnerabilities by ensuring that systems are up to date.

It is a first line of defence and a basic step in information security.

ISO 27001 Patch Management Policy Template

The ISO 27001 Patch Management Policy is pre written and ready to go. It is designed to save you over 8 hours of work. ISO 27001 templates are an absolute time and life saver.

What is the Purpose of the ISO 27001 Patch Management Policy?

The purpose of the ISO 27001 Patch Management Policy is to ensure operating systems, application software and firmware is updated to address known security vulnerabilities in a timely manner.

What it the ISO 27001 Patch Management Policy Principle?

All software and hardware assets are updated to the latest versions in line with vendor provided guidance and industry best practice.

Why is the ISO 27001 Patch Management Policy Important?

The software that we use is constantly being improved by those that sell us that software. As problems are found in the software or security vulnerabilities are identified the software vendors will address the issue and release a patch. A patch is an update. This software update fixes the problems that have been identified.

If we apply the patch, we update our software and address the security issues and problems. If we do not apply the patch then our software and systems remain vulnerable.

Hackers and cyber criminals not only find the weakness and exploit them, once they are identified they actively seek them out. By not applying the patch and the update you are an easy target. They will exploit what they know and compromise the confidentiality, integrity, availability of your data.

The ISO 27001 Patch Management Policy is important as it sets out clearly and in written form what you expect to happen. If you don’t tell people what you expect of them then how can you expect them to do it? Communicating what is expected is a key step in any HR disciplinary process with many not being enforceable or actionable if you have not told people what to do and got them to accept that they understand what is being asked. The ISO 27001 standard wants you to have the patch management policy in place, communicated, and accepted by staff as part of your ISO 27001 certification. It actually forms part of a wider set of required information security policies that are all included in the ISO 27001 Toolkit.

Patch Management Lifecycle

The life cycle of patch management is

A vulnerability is identified

Vulnerabilities are identified in a number of ways. They can be identified by the software vendor conducting its own testing, by users reporting problems, by professional bug bounty hunters identifying the issue for profit and by researchers finding the exploit on the dark web.

The vulnerability is addressed

Once identified the software vendor will use its resources to tackle and address the vulnerability.

A patch is created

Once the code has been updated the software vendor will create a patch. A patch is just a software update that includes the changes need to address the known problem.

The patch is released

The software vendor will make the patch available and with the patch they will provide release notes that set out what the patch does and what problems it addresses.

You apply the patch

Once the patched is released it is up to you, and your ISO 27001 Patch Management Policy to decide when and how to apply the patch. The things to consider at this stage include whether or not to automatically apply the patch or to apply the patch manually. You will have a Patch Severity and Timeframe to deploy approach that is documented in your policy.

What should ISO 27001 Patch Management Policy Contain?

The ISO 27001 Patch Management Policy is required to be presented in a certain way. What we mean by that is that the policy is expected to have certain document markup. Document mark up is just a fancy words for having certain information on the policy. It will need version control, a version number, an owner, an information security classification. An example ISO 27001 Patch Management Policy table of contents would look something like this:

1      Document Version Control
2      Document Contents Page
3      Patch Management Policy
3.1      Purpose
3.2      Scope
3.3      Principle
3.4      Patching Controls – End Point Devices
3.5      Patching Controls – Production Systems
3.6      Patching Exceptions
3.7      Patching Schedule
3.8      Patch Severity Rating and Timeframes to Deploy
4      Policy Compliance
4.1      Compliance Measurement
4.2      Exceptions
4.3      Non-Compliance
4.4      Continual Improvement
5      Areas of the ISO 27001 Standard Addressed

How to write an ISO 27001 Patch Management Policy

It can be straight forward to write an ISO 27001 Patch Management Policy. These are the steps that you would take.

1. Identify your company assets

Identify what assets your company has. This will be both software and hardware. What are the assets that your business uses to conduct its business. Once we know what assets we have we know what we need to manage and what will potentially require patching.

2. Prioritise your company assets

Once you identify what assets you rely on to conduct business priorities them based on the importance to the business, the classification of the data that is stored, processed or transmitted through them and the risk they pose to you. Prioritising assets allows us to focus our efforts on the protection of the things that are most important to us. Consider the split between production systems and end point devices.

3. Create your patching schedule

Based on the asset and its priority create a patching schedule. The patching schedule should set out when patches are applied. A common approach is to define it as the catch all of ‘patches are applied in line with vendor provided guidance’.

4. Create your Patch Severity Rating and Timeframes to Deploy

This is the guidance that sets out what the various patch severities are and the timelines to deploy the detaches. Patch Severity can be defined by the vendors but a good framework for the patch severity would be:

Patch Severity Example

Critical: A vulnerability whose exploitation could allow code execution without user interaction. These scenarios include self-propagating malware (e.g., network worms), or unavoidable common use scenarios where code execution occurs without warnings or prompts. This could mean browsing to a web page or opening email.
Microsoft recommends that customers apply Critical updates immediately.

Important: A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of user data, or of the integrity or availability of processing resources. These scenarios include common use scenarios where client is compromised with warnings or prompts regardless of the prompt’s provenance, quality, or usability. Sequences of user actions that do not generate prompts or warnings are also covered.
Microsoft recommends that customers apply Important updates at the earliest opportunity.

Moderate: Impact of the vulnerability is mitigated to a significant degree by factors such as authentication requirements or applicability only to non-default configurations.
Microsoft recommends that customers consider applying the security update.

Low: Impact of the vulnerability is comprehensively mitigated by the characteristics of the affected component. Microsoft recommends that customers evaluate whether to apply the security update to the affected systems.

For reference the Microsoft Guide is located here.

5. Communicate the patch management policy to appropriate staff

Consider as part of your required communication plan the different ways and timings that are appropriate to you to communicate the patch management policy. Make sure it is stored somewhere that people can easily access it at any time and that they can, indeed, access it.

6. Get evidence that the staff have accepted the patch management policy

Using your acceptance methodology get staff to accept that they have read and understand the policy and accept its terms. Maintain evidence of this for future audit and potential disciplinary process.

7. Manage Exceptions

There may be systems that cannot be patched for business or technical reasons. These should be identified, recorded, agreed and managed via risk management with effective compensating controls in place.

ISO 27001 Patch Management Policy Example

An ISO 27001 Patch Management Policy example would look like this extract:

What are the benefits of ISO 27001 Patch Management Policy?

Other that your ISO 27001 certification requiring the following are benefits of having the ISO 27001 Patch Management Policy:

1. Improved security: Your systems will be up to date and protected from all known vulnerabilities reducing the likelihood and impact of an attack
2. Reduced risk: Having up to date systems reduces the risk of attack and exploit
3. Improved compliance: Standards and regulations require systems to be patched and maintained
4. Reputation Protection: In the event of a breach having effective patch management will reduce the potential for fines and reduce the PR impact of an event

Who is responsible for the ISO 27001 Patch Management Policy?

Patch management is the responsibility of the IT team and specifically of the IT infrastructure teams.

What are examples of a violation of ISO 27001 Patch Management Policy?

Examples of where the policy can fail or violations of the patch management policy can include:

1. Not having a full list of assets. Not knowing what you are assets are means you cannot protect them
2. Not identifying and assessing vulnerabilities. Having systems that are unpatched and not knowing about it. Or having and systems that are unpatched and knowing about it but doing nothing to manage it.
3. Not prioritising patching based on risk.
4. Not testing patches before deployment. This can lead to creating further problems if the patch introduces new features or removes features you rely on.
5. Not managing exceptions. There maybe systems that cannot be patched and this will require special management and compensating controls.

What are the consequences of violating the ISO 27001 Patch Management Policy?

Not patching systems can have severe consequences. This is the simplest, most effective protection against cyber attack. Like leaving your door unlocked and wide open, you are inviting attackers into your systems. The consequences could be legal and regulatory fines and / or enforcement, loss of data, loss of revenue and in the most extreme cases risk to life and closure of your organisation.

How do you monitor the effectiveness of the ISO 27001 Patch Management Policy?

The approaches to monitoring the effectives of patch management include:

1. Reporting on the status of devices and current patch levels
2. Internal audit of the patching process
3. External audit of the patching process
4. Review of system logs and alerts for anomalies in operation

ISO 27001 and the ISO 27001 Patch Management Policy

The ISO 27001 Patch Management Policy satisfies the following classes in ISO 27001:

ISO 27001 Patch Management Policy FAQ