3. Ends before your next assessment
The security end date falls after the as-at date and on or before the next assessment date you set, so on the day of the assessment this version sits past vendor support unless it has moved. The clauses shown are the ones that apply from that date, and the ones that ask for a plan now.
- When it is raised
- security end date after the as-at date and on or before the next assessment date (inclusive)
- The question
- Is the upgrade for this version planned and dated before the assessment, and will the assessor see it done or see the approved plan?
- For
- your IT operations lead
The clauses it can cite
Cyber Essentials SU.1Software Licensed and Supported
Software Licensed and Supported. All software on in-scope devices must be licensed and supported by the vendor (i.e. receiving security updates). Unsupported software must be removed or segregated.
What an assessor asks to see: SCCM/Intune software inventory; EOL/EOSL register; Segregation evidence for unsupported
Where software lists usually fall short: Windows 7/Server 2012 still in use; EOL Java runtimes
CIS Controls v8 2.2Ensure Authorized Software is Currently Supported
Ensure Authorized Software is Currently Supported. Only software that still receives vendor support may be marked as authorised in the enterprise software register. Where unsupported software is still needed for the mission, record an exception that sets out the compensating controls and the acceptance of remaining risk. Unsupported software with no recorded exception is to be marked unauthorised. Check the list for support status no less often than monthly.
What an assessor asks to see: Authorised software list compared with vendor support status, showing only supported software authorised; Exception register for unsupported software with mitigating controls and residual risk acceptance; Monthly support status check record comparing each authorised title with vendor end-of-life announcements; Software register entries for end-of-support titles marked unauthorised where no exception exists; Risk acceptance sign-offs by a named business owner for each unsupported title kept for the mission
Where software lists usually fall short: End-of-life operating systems or Java runtimes still listed as authorised after vendor support ended; Exceptions recorded without compensating controls or an expiry and review date; Support status checked only at annual audit time instead of monthly
PCI DSS 4.0 12.3.4Annual review of hardware and software technologies
12.3.4 Annual review of hardware and software technologies. Hardware and software in use must undergo a check at least every 12 months, covering at minimum: analysis that vendors still supply timely security fixes; analysis that the technologies still support, and do not obstruct, PCI DSS compliance; documentation of industry announcements or trends about a technology, for instance a vendor's end-of-life notice; and a remediation plan for outdated technologies, including those with announced end-of-life, approved by senior management. Objective under the customized approach: hardware and software stay current and vendor supported, and plans to retire or replace unsupported components are reviewed periodically. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.
What an assessor asks to see: Technology review report covering support status and patch availability; End-of-life tracking register with vendor announcements; Senior management approved remediation plan for outdated technologies; Firmware and version inventory
Where software lists usually fall short: Review omits network device firmware or embedded systems; End-of-life systems identified but no approved remediation plan; Plan exists but lacks senior management approval
NIST SP 800-53 SA-22Unsupported System Components
SA-22 Unsupported System Components. a. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or b. Provide the following options for alternative sources for continued support for unsupported components [Selection (one or more): in-house support; [Assignment: organization-defined support from external providers]].
What an assessor asks to see: System and services acquisition policy; Procedures addressing the replacement or continued use of unsupported system components; Documented evidence of replacing unsupported system components; Documented approvals (including justification) for the continued use of unsupported system components; System security plan; Supply chain risk management plan; Test of Organizational processes for replacing unsupported system components; mechanisms supporting and/or implementing the replacement of unsupported system components
Where software lists usually fall short: Components past developer or vendor end of support remain in service without a replacement plan; No in-house or external alternative support arrangement is documented for unsupported components still in use
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 operating systems ML1Patch Operating Systems
Patch Operating Systems (ML1). An automated method of asset discovery is used at least fortnightly. A vulnerability scanner with an up-to-date vulnerability database is used. The scanner runs at least daily for operating systems of internet-facing servers and internet-facing network devices, and at least fortnightly for operating systems of workstations, non-internet-facing servers and non-internet-facing network devices. Patches for internet-facing OS and network device vulnerabilities are applied within 48 hours when critical or working exploits exist, otherwise within two weeks. Patches for workstation, non-internet-facing server and network device OS are applied within one month of release. Operating systems that are no longer supported by vendors are replaced.
What an assessor asks to see: Asset discovery configuration and reports showing fortnightly cadence covering servers, workstations and network devices; Authenticated OS vulnerability scan results (Nessus, Qualys, Defender for Endpoint TVM) with last-update timestamp; Daily scan schedule and report for internet-facing servers and network devices (perimeter firewalls, load balancers, VPN concentrators); Fortnightly scan schedule and report for workstations and non-internet-facing infrastructure; Patch deployment evidence (WSUS, SCCM, Intune, Jamf, vendor portals for network devices) with CVE-to-patch timestamps; Network device firmware management evidence (Cisco PSIRT subscription, deployment tickets); Asset register showing no out-of-support OS (e.g. no Windows 7, no Server 2012 R2 past EOL); EOL replacement plan for any in-progress migrations with compensating controls
Where software lists usually fall short: Network devices not in vulnerability scan scope; Internet-facing servers patched in 48 hours but cloud-managed appliances (load balancer firmware) miss SLA; Workstations patched via WSUS but roaming or remote machines miss the one-month window; Non-internet-facing servers patched on quarterly cycle, breaching one-month SLA; Out-of-support OS retained for legacy app without compensating control documented; Asset discovery misses cloud VMs spun up outside the central inventory
Essential Eight Patch operating systems ML3Patch Operating Systems
Patch Operating Systems (ML3). All ML2 requirements plus: A vulnerability scanner is used at least fortnightly to identify missing patches in drivers and in firmware. Patches for drivers and firmware are applied within 48 hours of release when critical or working exploits exist, otherwise within one month. Patches for workstations, non-internet-facing servers and non-internet-facing network device operating systems are applied within 48 hours when critical or working exploits exist (rather than one month). The latest release, or the previous release, of operating systems are used. Operating systems that are no longer supported by vendors are replaced.
What an assessor asks to see: Fortnightly driver and firmware scan results from vendor tools (Dell Command Update, HP Image Assistant, Lenovo Vantage, server iLO/iDRAC, network device vendor advisories); Driver and firmware patch deployment evidence with CVE-to-deployment timestamps within SLA; Emergency patching evidence for non-internet-facing servers and workstations within 48 hours for critical CVEs; OS version inventory confirming all hosts are on the latest or N-1 OS release; Replacement evidence (decommissioning tickets, migration plans) for any out-of-support OS; Threat intelligence to patch workflow link (CISA KEV subscription, vendor PSIRT, ASD alerts); Coverage report for drivers across all hardware models and firmware across UEFI, BIOS, BMC, network device OS; Quarterly executive report showing N or N-1 OS adherence percentage
Where software lists usually fall short: Driver and firmware patching done opportunistically at hardware refresh only; 48-hour SLA met for internet-facing but not internal critical workloads; OS version drift (e.g. Windows 10 22H2 retained alongside Windows 11) with no clear N-1 boundary; Network device firmware lagging due to maintenance window scarcity; Driver vulnerability scanning depends on vendor agent not installed across fleet; EOL OS replacement plan slipped without re-baselining
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