10. Evergreen product behind the current release
Browsers and other auto-updating clients are supported on the current release only, so an older version is not past support in the way a retired product is: it is behind. The question is how far behind the fleet is allowed to run, which is what the patch-window clauses set.
- When it is raised
- an evergreen product on a release older than the newest one released on or before the as-at date
- The question
- How far behind the current release is this fleet allowed to run, and are automatic updates on where the option exists?
- For
- your desktop support lead
The clauses it can cite
Cyber Essentials SU.2Automatic Updates Enabled Where Possible
Automatic Updates Enabled Where Possible. Automatic updates must be enabled on devices and software where the option exists, to ensure security updates are applied without delay.
What an assessor asks to see: Windows Update for Business policy; MacOS auto-update screenshot; WSUS/Intune config
Where software lists usually fall short: Auto-update deferred indefinitely; Users can opt out
Cyber Essentials SU.3Critical and High Updates within 14 Days
Critical and High Updates within 14 Days. All high or critical security updates (CVSS 7.0+ or vendor critical/high rating) must be applied within 14 days of release.
What an assessor asks to see: Patch compliance dashboard (Defender/Tenable/Qualys); 14-day SLA report; Exception register
Where software lists usually fall short: Patch backlog beyond 14 days; No CVSS-based tracking
Cyber Essentials Plus PM-01High and Critical Vulnerability Patching
High and Critical Vulnerability Patching. Security updates rated high or critical must be applied within 14 days of release for operating systems and supported applications, or vulnerable software removed.
What an assessor asks to see: Patch deployment reports; Internal authenticated scan results; Exception register with risk owner sign off
Where software lists usually fall short: Scan shows 14+ day breaches; No scan of servers; Patches deferred without documented risk acceptance
CIS Controls v8 7.4Perform Automated Application Patch Management
Perform Automated Application Patch Management. Keep applications on enterprise assets updated by automated patch management, running at least once a month.
What an assessor asks to see: Application patch management configuration with automated monthly deployment; Application patch compliance reports; Patch standard covering third-party applications, not only operating system updates; Third-party patching tool catalogue showing which applications are auto-updated; Monthly application version compliance report for browsers, runtimes, PDF readers and office suites
Where software lists usually fall short: Only Microsoft products patched automatically while Java, Adobe and browsers lag behind; Server-side applications and databases patched only during annual upgrades; Software installed outside the software distribution tool never updated
PCI DSS 4.0 6.3.3Timely installation of security patches
6.3.3 Timely installation of security patches. All system components must be shielded from known vulnerabilities by applying relevant security patches or updates such that: patches or updates addressing critical vulnerabilities, as ranked under Requirement 6.3.1, must go in within one month of their release; and every other relevant security patch or update is installed within a suitable time frame set by the entity's own assessment of how critical the risk is to its environment, using the Requirement 6.3.1 ranking process. It applies to all entities and all system components. Customized approach objective: exploitation of a known vulnerability cannot be used to compromise system components.
What an assessor asks to see: Patch management procedure stating the one-month deadline for critical patches and time frames for others; Patch compliance reports per system component showing install dates against vendor release dates; Risk-based rationale or targeted risk analysis for non-critical patch time frames; Exception register for patches that could not be applied, with compensating measures; Sample of critical advisories traced to installation evidence
Where software lists usually fall short: Critical patches applied more than one month after release because of change freeze windows; Network devices, hypervisors or appliances excluded from patch reporting; No defined time frame for non-critical patches, so they accumulate indefinitely
NIST SP 800-53 SI-2Flaw Remediation
SI-2 Flaw Remediation. a. Identify, report, and correct system flaws; b. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation; c. Install security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates; and d. Incorporate flaw remediation into the organizational configuration management process.
What an assessor asks to see: System and information integrity policy; System and information integrity procedures; Procedures addressing flaw remediation; Procedures addressing configuration management; List of flaws and vulnerabilities potentially affecting the system; List of recent security flaw remediation actions performed on the system (e.g., list of installed patches, service packs, hot fixes, and other software updates to correct system flaws); Test results from the installation of software and firmware updates to correct system flaws; Installation/change control records for security-relevant software and firmware updates; System security plan; Test of Organizational processes for identifying, reporting, and correcting system flaws; organizational process for installing software and firmware updates; mechanisms supporting and/or implementing the reporting and correcting of system flaws; mechanisms supporting and/or implementing testing software an
Where software lists usually fall short: Security-relevant updates installed outside the organization-defined time period with no recorded exception or risk acceptance; Updates deployed to production without the testing for effectiveness and side effects that SI-2 b requires
ISO/IEC 27001 A.8.8Management of technical vulnerabilities
Management of technical vulnerabilities. The organization is to gather information about technical vulnerabilities in the information systems it uses, assess how exposed it is, and take suitable action. Purpose (stated in ISO/IEC 27002:2022): prevents exploitation of technical vulnerabilities. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.8.
What an assessor asks to see: Statement of Applicability entry for control A.8.8, showing inclusion or justified exclusion, implementation status and the risks it treats; A software asset inventory with vendor, product, version, deployment location and responsible owner; Defined vulnerability management roles and a list of monitored vulnerability information sources; Authenticated scan results and penetration test reports by authorized testers, with verification scans after patching; Remediation timelines by severity with measured performance, and risk records weighing the vulnerability against update risk
Where software lists usually fall short: The asset inventory is incomplete, so unknown software is never scanned or patched; Remediation timelines are routinely missed with no risk acceptance; Third-party libraries in in-house code are not tracked for vulnerabilities; There is no way for external researchers to report vulnerabilities
Essential Eight Patch applications ML1Patch Applications
Patch Applications (ML1). An automated method of asset discovery is used at least fortnightly to support detection of assets for subsequent vulnerability scanning. A vulnerability scanner with an up-to-date vulnerability database is used. The scanner runs at least daily for online services and at least weekly for office productivity suites, web browsers and their extensions, email clients, PDF software and security products. Patches or vendor mitigations for online services are applied within 48 hours when critical or working exploits exist, otherwise within two weeks. Patches for office productivity suites, web browsers and their extensions, email clients, PDF software and security products are applied within two weeks of release. Online services that are no longer supported by vendors are removed. Office productivity suites, web browsers and their extensions, email clients, PDF software, Adobe Flash Player, and security products that are no longer supported by vendors are removed.
What an assessor asks to see: Asset discovery tool configuration (Tenable Nessus, Qualys, Rapid7 InsightVM, Microsoft Defender for Endpoint) showing fortnightly scheduled discovery scans; Vulnerability scanner plugin/feed last-updated timestamp evidence; Daily scan schedule and result history for online services (web apps, externally exposed APIs, internet-facing portals); Weekly scan schedule and result history for the in-scope application classes; Patch deployment evidence: tickets, change records or SCCM / Intune / Jamf reports correlating CVE publication date to patch deployment date for each in-scope class; List of online services with EOL/EOS status and decommissioning evidence; Endpoint software inventory showing no Adobe Flash, no unsupported browser versions, no out-of-support PDF readers; Vendor support lifecycle policy with explicit deadlines for replacement
Where software lists usually fall short: Asset discovery cadence longer than fortnightly or run only when changes are requested; Scanner credentialed scanning not configured, only unauthenticated scans, missing internal patch state; Patching SLA met for Microsoft updates but missed for third-party apps (Chrome, Firefox, Adobe, Java, Zoom); Adobe Flash Player still installed on legacy systems; Online services classed differently to ACSC definition, missing daily scan obligation; Critical CVE patched but evidence of decision (critical vs non-critical) not retained
Essential Eight Patch applications ML3Patch Applications
Patch Applications (ML3). All ML2 requirements plus: Patches or vendor mitigations for office productivity suites, web browsers and their extensions, email clients, PDF software and security products are applied within 48 hours of release when vulnerabilities are critical or working exploits exist. Applications other than the priority classes that are no longer supported by vendors are also removed.
What an assessor asks to see: Threat intelligence feed configuration (CISA KEV, MSRC, vendor advisories) integrated with patching workflow; Sample emergency patch tickets showing CVE publication, criticality decision, deployment to fleet within 48 hours; Vendor mitigation register where a patch was not available but mitigation was applied (registry change, configuration change, firewall rule); Asset inventory showing no unsupported applications across the entire application estate; Decommissioning evidence (change tickets, audit logs) for removed legacy applications; Out-of-cycle change board records authorising emergency deployments; Coverage report showing every workstation, server and mobile device received the patch within SLA; Quarterly executive report showing 48-hour SLA compliance percentage
Where software lists usually fall short: 48-hour SLA tracked but not met for remote or roaming workstations; Browser extension patches missed because of dependency on user-driven updates; Vendor mitigation applied but no record kept of when patch supersedes it; Unsupported in-house apps tolerated indefinitely under risk acceptance; Threat intelligence not linked to patch prioritisation; Coverage report incomplete because mobile devices use separate patching tool
See the specimen list runCheck your own list