ISO 27001 Patch Management Policy Beginner’s Guide

Time needed: 1 hour and 30 minutes

How to write an ISO 27001 Patch Management Policy

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. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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’.

10. 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.

11. 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’.

12. 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.

13. 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.