The Mandate of Timeliness: Patch Management Across Major Compliance Standards

Patch management – the process of identifying, acquiring, testing and installing updates and patches to software and firmware – is universally recognised as a critical pillar of cyber security. Unpatched vulnerabilities are a primary gateway for cyberattacks, making a timely and systematic patching process a core requirement for nearly all major regulatory and security frameworks.

The compliance requirements, however, can differ significantly in their level of prescription, particularly concerning mandatory time frames. When developing your patch management policy, it is essential to align with the most stringent requirements of the relevant standards. Also, please remember that patch deployment feeds into other policies such as your ‘Risk Assessment & Treatment Policy’, which is mandatory under ISO27001.

Cyber Essentials (CE)

The UK government’s Cyber Essentials (CE) scheme provides a clear, baseline approach, making its patch management requirements exceptionally explicit and time-bound. CE certification requires an organisation to ensure all software is:

  • Licensed and Supported: If an asset is no longer supported by the vendor, it must be removed.
  • Patched within 14 days: This critical timeline applies to an update being released if it fixes a vulnerability the vendor describes as ‘critical’ or ‘high risk’, or has a CVSS v3 score of 7 or higher. This specific and tight deadline aims to close the window of opportunity for attackers who rapidly exploit newly published vulnerabilities.
visual timeline above hands typing on keyboard

Payment Card Industry Data Security Standard (PCI DSS)

The PCI DSS, which governs organisations that process, store, or transmit cardholder data, places a high emphasis on proactive vulnerability management, including patching. PCI DSS Requirement 6.2 mandates that organisations:

  • Ensure all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches within one month of release.
  • For critical or high-severity patches, the timeframe is often interpreted by QSAs (Qualified Security Assessors) and industry guidance to be much shorter, but the 30-day window is the explicit baseline for all security patches.

The standard also requires a formal patch management process to identify, rank, and install patches promptly based on the organisation’s risk ranking of the vulnerability.

NIST Special Publication 800-40, Rev. 4: Guide to Enterprise Patch Management Planning

The National Institute of Standards and Technology (NIST) approach, detailed in SP 800-40, is less prescriptive on specific timeframes and more focused on providing a comprehensive framework for planning and operationalising enterprise-wide patch management.

  • Strategic Focus: NIST frames patching as a “critical component of preventive maintenance” and a cost of doing business.
  • Risk-Based Prioritisation: The guidance stresses the need for organisations to develop their own risk-based prioritisation framework that considers factors like vulnerability severity (using CVSS scores), asset criticality, and the existence of active exploits.

Process, not Dates: The focus is on the lifecycle – identifying, acquiring, testing, installing, and verifying – of patches and developing an effective, repeatable enterprise strategy to reduce risk, rather than mandating a one-size-fits-all timeline.

CIS Control 7: Continuous Vulnerability Management

Possibly one of the best-known standards and the basis of many other standards throughout the world, including the UK’s Security Policy Framework, originally called 20CSC or 20 Critical Security Controls.

Objective: Continuously acquire, assess, and take action on information regarding vulnerabilities to minimise risk.

Key Patching Requirements

  • Asset Coverage: Ensure all enterprise assets (servers, endpoints, mobile devices, cloud workloads) are included in vulnerability scans and patching workflows.
  • Vulnerability Identification: Use automated tools to scan for known vulnerabilities using CVE, CVSS, and SCAP standards.
  • Threat Intelligence Integration: Monitor public and private sources for emerging vulnerabilities and threat advisories.
  • Prioritisation: Rank vulnerabilities based on severity, exploitability, and asset criticality using frameworks like CVSS.
  • Remediation Timelines: Establish SLAs for patch deployment based on risk level (e.g., critical patches within 24–72 hours).
  • Verification: Validate patch application through rescan or automated confirmation mechanisms.
  • Exception Handling: Document and approve patch deferrals with compensating controls (e.g., network segmentation, monitoring).
  • Reporting: Maintain audit logs and dashboards to track patch status, coverage, and compliance.

MoJ Security Guidance (UK Ministry of Justice)

The UK Ministry of Justice (MoJ) Security Guidance provides mandatory requirements for MoJ systems. Its patch management guide blends the process-oriented approach with specific deadlines:

  • General Rule: Operating systems and applications must be patched as soon as possible.
  • Specific Deadline: Similar to Cyber Essentials, the MoJ mandates that systems must be patched within no more than 14 days of an update being released, specifically where the fix is for a ‘critical’ or ‘high risk’ vulnerability.

Policy Requirement: It explicitly requires a clear, documented process for how to patch or mitigate systems, demonstrating a strong policy and procedural control.

Standards That Require a Policy but Do Not Mandate a Specific Timeframe

While many modern, threat-focused standards like Cyber Essentials and MoJ Guidance have migrated toward strict, short-term patch deadlines, several foundational and overarching security standards emphasise the existence of a formal policy and process over a specific, universal number of days. These frameworks require organisations to define their own timely and risk-based process, rather than adhering to an external, fixed calendar date.

ISO/IEC 27001 (Information Security Management)

ISO 27001, the international standard for Information Security Management Systems (ISMS), is highly influential globally but remains non-prescriptive regarding specific patch timelines.

  • Control A.12.6.1 (Management of Technical Vulnerabilities): This control requires an organisation to establish a defined process for identifying and managing vulnerabilities (including patching) in a “timely manner.”
  • Focus on Policy: The core requirement is to have a documented policy and procedures that govern how an organisation monitors, assesses, and responds to the release of patches. The organisation itself is responsible for defining what constitutes “timely” based on its risk appetite, business needs, and regulatory obligations, which must then be documented within the ISMS. The audit focuses on the existence, documentation, and effectiveness of the policy and process, not adherence to a 14-day rule.

Health Insurance Portability and Accountability Act (HIPAA)

HIPAA in the United States, which protects sensitive patient health information (PHI), mandates robust security controls under its Security Rule. While it doesn’t offer a consolidated “patching” control, the requirements are dispersed across several safeguards:

  • Focus on Risk Analysis: HIPAA requires covered entities to conduct a risk analysis to identify and assess potential threats and vulnerabilities.
  • Implementation Specification (Technical Safeguard): The rules generally require implementing security measures that reduce risks and vulnerabilities to a reasonable and appropriate level.
  • Absence of a Fixed Period: HIPAA does not specify that patches must be applied in 7 days, 14 days, or 30 days. Instead, it mandates that an organisation’s security policy must detail a process for protecting against and correcting vulnerabilities as part of its overall risk management strategy. Compliance is achieved by demonstrating that the documented process is reasonable and effectively manages identified risks to PHI.

COBIT (Control Objectives for Information and Related Technologies)

COBIT is an IT governance and management framework that provides a comprehensive set of processes and control objectives.

  • Process APO12.04 (Manage Security Vulnerabilities): This control objective focuses on establishing and maintaining a process for identifying, managing, and mitigating vulnerabilities.
  • Policy-Driven Approach: COBIT requires the organisation to define a policy for security vulnerability management. While it guides organisations toward prioritising fixes based on risk and impact, the framework does not specify time limits for patch deployment. It instructs the organisation to determine what constitutes “timely” as a part of their own defined service level agreements (SLAs) or operational procedures, making the existence and documentation of the policy the primary compliance requirement.

The distinction between these standards highlights a shift in cyber security compliance. Standards like ISO 27001 and COBIT focus on the strategic governance of security – requiring a policy and process that addresses patching “in a timely manner.” In contrast, standards driven by an immediate, real-world cyber threat profile, such as Cyber Essentials, MoJ Guidance, and increasingly prescriptive versions of PCI DSS, mandate a more tactical and urgent timeline (e.g., 14 days) to enforce minimum security maturity and dramatically shrink the exploitation window. Organisations must tailor their patch management strategy to satisfy both the high-level policy mandates and the specific time-bound requirements applicable to their industry and data types.

The Importance of cadence in Patch Management Compliance

Patching cadence is the established frequency and regularity with which an organisation systematically reviews, tests, and deploys updates to its systems. It is arguably more important than adhering to a single deadline, as a defined cadence transforms patching from a reactive scramble into a proactive, predictable security practice.

Minimising the “Window of Vulnerability”

The most critical function of a consistent cadence is minimising the window of vulnerability – the time between a security patch’s release and its application. Attackers actively monitor vendor patch releases to identify the underlying vulnerability, quickly reverse-engineer a working exploit, and deploy it before organisations have patched. This period, sometimes measured in hours or days, is when an organisation is most at risk. A tight, predictable cadence, reinforced by automation, shrinks this window dramatically.

vulnerability in annual scans
vulnerability inmonthly scans

Operational stability and compliance

A consistent patching cadence supports compliance by:

  1. Predictability and Testing: A regular schedule allows for dedicated maintenance windows, thorough testing in sandboxed environments, and proper coordination, which prevents new patches from breaking critical business operations. This stability is an indirect but essential part of compliance.
  2. Measurable Performance: Cadence provides the crucial metrics for security governance. Organisations can track and report on metrics like “Average Time to Patch,” “Percentage of Patches Deployed by Deadline,” and “Patch Compliance Rate” to senior leadership and auditors. These metrics are the proof of compliance required by standards like NIST and ISO 27001.
  3. Prioritisation: A cadence structure allows an organisation to classify vulnerabilities by severity (CVSS score) and system criticality. Patches for high-risk, internet-facing systems can be deployed in an emergency cadence (e.g., within 48 hours), while less critical patches can be applied during a standard monthly or bi-weekly maintenance cadence.

In essence, compliance standards may set the minimum bar (e.g., “patch critical flaws in 14 days”), but a well-defined cadence is what organisations need to execute the process reliably, demonstrating a truly mature and defensible security posture.

Recommendations

  • When dealing with multiple standards, base patch cadence, etc, on the most stringent  mandatory requirement
  • Automate patch deployment using centralised tools (e.g., SCCM, WSUS, or third-party platforms).
  • Segment patching by asset type and risk profile to avoid operational disruptions.
  • Integrate patching with change management to ensure traceability and rollback options.
  • Use CIS Benchmarks to validate secure configurations post-patching.

Some Statistics from Verizon’s DBIR

Some Statistics from Verizon's DBIR

Patch Management Statistics From Other Sources

Average Time to Patch Critical Vulnerabilities

  • Median time to remediate Known Exploited Vulnerabilities (KEVs): 174 days
  • Median time for non-KEV vulnerabilities: 621 days
  • Zero-day vulnerabilities: 80% are exploited before a patch is released
  • 28.3% of vulnerabilities are exploited within 24 hours of public disclosure

Acceleration Factors

  • Organisations patch CVE-listed bugs 3.5x faster than non-CVE ones
  • Vulnerabilities known to be targeted by ransomware actors are patched 2.5x faster than other KEVs
  • Automated patch management can cut response times in half

Risk Implications

  • 80% of cyberattacks are linked to unpatched software
  • Over two-thirds of breaches stem from outdated software

12% of Java apps still run vulnerable Log4Shell versions, nearly 3 years post-disclosure