7. Not in the lifecycle record

The product, or this version of it, is not in the lifecycle record held here (endoflife.date, read on the date shown). That says nothing about its support: it is unknown, never supported. The clauses you ticked ask you to know the answer, so the answer comes from the vendor.

When it is raised: no record matches the product name, or the record does not list the version, or the version is not given or is shared by several releases
The question: Check with the vendor: is this version still receiving security updates, and until when? Record the answer and its source beside the line.
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

Source: Cyber Essentials (NCSC and IASME), read 30 Sep 2026

CIS Controls v8 2.1Establish and Maintain a Software Inventory

Establish and Maintain a Software Inventory. Keep a detailed register of all licensed software installed across enterprise assets. Each entry has to capture the title, the publisher, the date of first installation or use, and the business reason for it; where it makes sense, also capture the URL, the app store or stores, the version or versions, how it is deployed, and the date it was retired. Revisit and refresh the register at least twice a year.

What an assessor asks to see: Software inventory export showing title, publisher, first install date and business purpose for each licensed title; Record of the twice-yearly inventory review; Software asset management standard naming the mandatory inventory fields and the register owner; Sample of software titles traced from endpoints to the register showing publisher and business purpose recorded; Retired software entries showing a decommission date rather than being deleted from the register

Where software lists usually fall short: Register covers workstations but omits servers, cloud workloads or SaaS subscriptions; Business purpose field left blank or filled with a generic value for most titles; Twice-yearly review not held, so the register still lists software removed long ago

Source: CIS Controls v8 (Center for Internet Security), 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

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 CM-8System Component Inventory

CM-8 System Component Inventory. a. Develop and document an inventory of system components that: 1. Accurately reflects the system; 2. Includes all components within the system; 3. Does not include duplicate accounting of components or components assigned to any other system; 4. Is at the level of granularity deemed necessary for tracking and reporting; and 5. Includes the following information to achieve system component accountability: [Assignment: organization-defined information deemed necessary to achieve effective system component accountability]; and b. Review and update the system component inventory [Assignment: organization-defined frequency].

What an assessor asks to see: Configuration management policy; Procedures addressing system component inventory; Configuration management plan; System security plan; System design documentation; System component inventory; Inventory reviews and update records; Test of Organizational processes for managing the system component inventory; mechanisms supporting and/or implementing system component inventory

Where software lists usually fall short: The component inventory omits components found on the network, or double-counts components assigned to other systems; The inventory lacks the defined accountability information and is not reviewed and updated at the defined frequency

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

ISO/IEC 27001 A.5.9Inventory of information and other associated assets

Inventory of information and other associated assets. The organization is to build and keep current an inventory of its information and other associated assets, with their owners recorded. Purpose (stated in ISO/IEC 27002:2022): identifies the organization's information and associated assets so they can be protected and properly owned. 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 5.9.

What an assessor asks to see: Statement of Applicability entry for control A.5.9, showing inclusion or justified exclusion, implementation status and the risks it treats; The asset inventories (information, hardware, software, virtual, facilities and others) with owner, classification and location fields populated; Reconciliation records between inventories and discovery tooling, or evidence that installs, changes and removals update the inventory automatically; A procedure for assigning ownership on creation or acquisition and reassigning it when owners leave or change role; Records of periodic classification and access restriction reviews carried out by asset owners

Where software lists usually fall short: The inventory covers hardware only and omits information assets, cloud services and software components; Owners listed are people who have left or generic team names with no accountable individual; The inventory drifts from reality because no reconciliation or automated update exists; Disposed assets remain in the inventory, or live assets never entered it

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

See the specimen list run Check your own list