Unsupported Software Findernotice of vendor support

9. Unsupported with no exception recorded

The line is past vendor security support (or on extended support only) and the exception column is blank on it. CIS Safeguard 2.2 lets unsupported software stay only with a recorded exception that sets out the compensating controls and the acceptance of the remaining risk; the other schemes you ticked ask for removal, segregation or an approved plan.

When it is raised
past support or extended only, and the exception column blank (only when the list has an exception column)
The question
If this line has to stay, is an exception recorded with the compensating controls and the acceptance of the remaining risk, and when is it next reviewed?
For
your IT operations lead

The clauses it can cite

Cyber Essentials SU.4Remove Out-of-Support Software

Remove Out-of-Support Software. Remove software that is no longer receiving security updates from in-scope devices, or fully segregate it from the rest of the network.

What an assessor asks to see: EOL removal log; Segregated VLAN evidence; Compensating control documentation
Where software lists usually fall short: EOL kept on production network; No plan to retire
Source: Cyber Essentials (NCSC and IASME), read 30 Sep 2026
Cyber Essentials Plus PM-02Unsupported Software Removal

Unsupported Software Removal. Software and operating systems that are no longer supported by the vendor must be removed from in scope devices or isolated with compensating controls.

What an assessor asks to see: Software inventory with vendor support status; EOL remediation plan; Isolation network diagrams
Where software lists usually fall short: Windows 7 or unsupported Server still in scope; EOL Java runtimes on user devices; No inventory accuracy check
Source: Cyber Essentials Plus (NCSC and IASME), read 30 Sep 2026
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
CIS Controls v8 2.3Address Unauthorized Software

Address Unauthorized Software. Make sure any unauthorised software on enterprise assets is either taken out of use or covered by a recorded exception, with a review at least monthly.

What an assessor asks to see: Monthly unauthorised software reports and the removal tickets raised; Exception records for any retained unauthorised software, with approval; Endpoint scan comparing installed software with the authorised list, with each unauthorised hit dispositioned; Exception approvals for retained unauthorised software naming the approver and review date; Before and after inventory snapshots confirming unauthorised titles were actually uninstalled
Where software lists usually fall short: Removal tickets closed without verifying the software was uninstalled from every affected device; Unauthorised browser extensions and portable executables never included in the monthly review; Exceptions granted informally by email and absent from any register
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 runCheck your own list