4. Ends within the window you set

The security end date falls after the as-at date and within the number of days you set (90 by default, a default and not a rule of any scheme). It is the list to start the upgrades from.

When it is raised: security end date after the as-at date and no more than the window of days after it (inclusive); 90 days unless you set another number
The question: Which of these can be upgraded before the date shown, and which need a plan approved now?
For: your IT operations lead

The clauses it can cite

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

Source: CIS Controls v8 (Center for Internet Security), read 30 Sep 2026

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

Source: PCI DSS 4.0 (PCI Security Standards Council), read 30 Sep 2026

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

Source: NIST SP 800-53 Rev 5, read 30 Sep 2026

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

Source: ISO/IEC 27001 (Annex A), read 30 Sep 2026

See the specimen list run Check your own list