ISO 27001 Patch Management Policy
In this guide, you will learn what an ISO 27001 Patch Management Policy is, how to write it yourself and I give you a template you can download and use right away.
Table of contents
- ISO 27001 Patch Management Policy
- What is an ISO 27001 Patch Management Policy?
- How to write an ISO 27001 Patch Management Policy
- ISO 27001 Patch Management Policy Template
- ISO 27001 Patch Management Policy Example
- Patch Management Lifecycle
- Why is the ISO 27001 Patch Management Policy Important?
- ISO 27001 Patch Management Policy FAQ
- Further Reading
What is an 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.
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.
All software and hardware assets are updated to the latest versions in line with vendor provided guidance and industry best practice.
It is a first line of defence and a basic step in information security.
It is one of the ISO 27001 policies required by the ISO 27001 standard for ISO 27001 certification.
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.
Time needed: 1 hour and 30 minutes
How to write an ISO 27001 Patch Management Policy
- 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.
- 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.
- Write the ISO 27001 Patch Management Policy purpose
The purpose of this policy is to ensure operating systems, application software and firmware is updated to address known security vulnerabilities in a timely manner.
- Write 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.
- Write the ISO 27001 Patch Management Policy scope
All employees and third-party users.
All company software, hardware, and virtual services in scope of the ISO 27001 implementation as recorded in the company asset registers. - Describe your patching controls for end point devices
The use of automated patching where available and appropriate is used.
The patching status of end point devices is checked every 30 days.
Where appropriate and available automatic tracking of end point patching is deployed with automatic alerting and reporting of devices that are non-compliant.
Where a device or asset is found to be non-compliant remedial action is taken. - Describe your patching controls for production systems
Patching of production systems follows the standard change management process.
The patching status of end point devices is checked every 30 days.
Where appropriate and available automatic tracking of end point patching is deployed with automatic alerting and reporting of devices that are non-compliant.
Where a device or asset is found to be non-compliant remedial action is taken. - Explain how you manage patching exceptions
An exception list is maintained, managed, and reported via the Management Review Team.
Where a patch cannot be applied, for whatever reason, including but not limited to operational requirements the device is added to the risk register and managed via the risk management process. This is reported and tracked via the normal management review team meeting process of continual improvement. - Set out 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’.
- Describe your patch severity ratings and timeframes to deploy
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. - 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’.
- 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.
- 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.
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.
ISO 27001 Patch Management Policy Example
An ISO 27001 Patch Management Policy example would look like this extract:
Patch Management Lifecycle
The life cycle of patch management is
1. 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.
2. The vulnerability is addressed
Once identified the software vendor will use its resources to tackle and address the vulnerability.
3. 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.
4. 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.
5. 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.
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.
ISO 27001 Patch Management Policy FAQ
The ISO 27001 Patch Management Policy Template can be downloaded here.
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. The ISO 27001 Patch Management Policy should include:
Document Version Control
Document Contents Page
Purpose
Scope
Principle
Patching Controls – End Point Devices
Patching Controls – Production Systems
Patching Exceptions
Patching Schedule
Patch Severity Rating and Timeframes to Deploy
Policy Compliance
Compliance Measurement
Exceptions
Non-Compliance
Continual Improvement
Areas of the ISO 27001 Standard Addressed
1. The patch management lifecycle is:
2. A vulnerability is identified
3. The vulnerability is addressed
4. A patch is created
5. The patch is released
6. You apply the patch
1. Identify your company assets
2. Prioritise your company assets
3. Create your patching schedule
4. Create your Patch Severity Rating and Timeframes to Deploy
5. Communicate the patch management policy to appropriate staff
6. Get evidence that the staff have accepted the patch management policy
7. Manage Exceptions
An example free ISO 27001 Patch Management Policy PDF is here.
You can learn about ISO 27001 Patch Management in the ISO 27001 Patch Management Policy Ultimate Guide
The benefits of an ISO 27001 Patch Management Policy are:
Improved security: Your systems will be up to date and protected from all known vulnerabilities reducing the likelihood and impact of an attack
Reduced risk: Having up to date systems reduces the risk of attack and exploit
Improved compliance: Standards and regulations require systems to be patched and maintained
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
Patch management is the responsibility of the IT team and specifically of the IT infrastructure teams.
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
Examples of where the policy can fail or violations of the patch management policy can include:
Not having a full list of assets. Not knowing what you are assets are means you cannot protect them
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.
Not prioritising patching based on risk.
Not testing patches before deployment. This can lead to creating further problems if the patch introduces new features or removes features you rely on.
Not managing exceptions. There maybe systems that cannot be patched and this will require special management and compensating controls.
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.
ISO 27001:2022 Clause 5 Leadership
ISO 27001:2022 Clause 5.1 Leadership and commitment
ISO 27001:2022 Clause 5.2 Policy
ISO 27001:2022 Clause 6.2 Information security objectives and planning to achieve them
ISO 27001:2022 Clause 7.3 Awareness
ISO 27002:2022 Clause 8 Technological Controls
ISO 27002:2022 Clause 8.1 User endpoint devices
ISO 27002:2022 Clause 8.8 Management of technical vulnerabilities
Further Reading
The ISO 27001 Patch Management Policy satisfies the following classes in ISO 27001:
ISO 27001 Annex A 8.1 User endpoint devices
ISO 27001 Annex A 8.8 Management of technical vulnerabilities