End-of-Life Software Policy Template for Open Source Infrastructure

The short answer

An end-of-life software policy says four things: every component's support status is tracked, end of life is spotted well before it arrives, each end-of-life component gets one of a small set of approved responses, and anything that stays past end of life does so under a time-boxed exception signed by a named approver. The template below covers those rules plus definitions, roles, evidence retention and review. Copy it, replace the values in square brackets with your own, and have it approved the same way as your other security policies.

This is a narrow policy. It covers unsupported and end-of-life software only. Licence policy, approved-component lists and policy as code belong in a broader open source governance framework, which we cover in building an open source governance framework engineers will use. This article is general information, not legal or audit advice. Your auditor or assessor makes the final call on whether a policy meets a given clause.

How to use the template

• Values in [square brackets] are yours to set. Where a framework sets a ceiling, the framework note under the section says so.
• Each section ends with a short note on which clauses it helps you evidence. Delete the notes before publishing the policy internally, or keep them in a separate mapping table for auditors.
• The policy relies on two records it does not contain: the end-of-life risk register and the exceptions register. Our guide to documenting end-of-life software risk lists the fields for both.

The policy

1. Purpose

This policy makes sure that software used by [Organisation] continues to receive security fixes, and that any software which no longer receives them from its original developer is identified early, replaced, retired or given another documented source of fixes, with the remaining risk accepted at the right level.

Framework note: NIST SP 800-53A lists the procedures addressing the replacement or continued use of unsupported system components among the evidence an assessor examines for SA-22. This policy, with the procedures under it, is that evidence.

2. Scope

This policy applies to all software that runs in [production and any environment in scope for an external audit or certification], including:

• open source runtimes, databases, message brokers, coordination services and web servers;
• application frameworks and libraries, including transitive dependencies;
• container base images and operating system packages;
• commercial software and appliances, where not covered by [other policy].

It applies to software operated by [Organisation] and by third parties on its behalf.

Framework note: Cyber Essentials v3.3 applies its update requirements to all software on in-scope devices, including servers and cloud services. PCI DSS 12.5.1 requires an inventory of in-scope system components. Keep the scope wording consistent with the scope statements of the audits you face.

3. Definitions

• Supported software: software that [Organisation] has a legal right to use and for which a named provider has committed to supply regular security fixes and has stated the date that commitment ends. The provider need not be the original developer, but must be able to modify the software to create fixes.
• End of life (EOL): the date after which the original developer, vendor or open source project stops publishing security fixes for a version line.
• Alternative source of support: in-house support, or support from an external provider under contract, that supplies security fixes for a version line after its end of life.
• Component owner: the named person accountable for a component's version, upgrades and register entry.
• Exception: a documented, approved and time-limited decision to run software that does not meet this policy.

Framework note: the definition of supported software follows Cyber Essentials v3.3, which defines licensed and supported software as software you have a legal right to use and that a vendor has committed to support with regular vulnerability fixes, with a stated end date, and says the vendor need not have created the software if it can modify it to create fixes. The alternative-source definition follows SA-22 part b, whose discussion says external providers "can include open-source software value-added vendors". DORA Article 3(3) defines a legacy ICT system as one that has reached end of life or is no longer supported by its supplier or an ICT third-party service provider; financial entities may want to cross-reference that term here.

4. Inventory and support status

1. Each build pipeline produces a software bill of materials for every release deployed in scope.
2. [Security team] maintains a support-status record that joins the SBOM to, for each component and version: the upstream end-of-life date, the source of that date, and the current source of security fixes.
3. The support-status record is reconciled against what is actually running at least [monthly], and any component with no known support status is treated as unsupported until confirmed otherwise.

Framework note: NIST CM-8 (system component inventory). PCI DSS 12.5.1 (inventory of system components) and 6.3.2 (inventory of bespoke and custom software and its third-party components). ENISA maps asset inventory to ISO/IEC 27001:2022 Annex A 5.9, the inventory control. An SBOM alone does not record support status, which is why item 2 exists; see SBOMs and end-of-life components.

5. End-of-life notification window

1. [Security team] monitors upstream lifecycle announcements for every component in the inventory.
2. When a component in use is within [12] months of its end-of-life date, the component owner is notified and a register entry is opened.
3. No later than [6] months before end of life, the component owner records a chosen response under section 6, with a target date.
4. On the end-of-life date, every instance still running must be covered by an approved response: an alternative source of support already in place, or an approved exception.
5. Where a project announces end of life with less notice than the window above, the steps run immediately and the shortened timeline is recorded.

Framework note: PCI DSS 12.3.4 asks entities to review their technologies at least every 12 months, document vendor announcements such as "end of life" plans, and keep a senior-management-approved plan to remediate outdated technologies. Our end-of-life dates and EOL tracker list upstream dates for common runtimes, and our comparison of EOL tracking tools covers automating item 1.

6. Approved responses

Each end-of-life component must have exactly one of the following responses recorded in its register entry.

1. Upgrade to a version line that receives security fixes from its developer.
2. Replace with a different product that is supported software under section 3.
3. Extended support from an alternative source. An external provider must be under a contract that names the components and version lines covered, commits to delivery times for security fixes that meet section 7, and supplies signed builds that [Organisation] verifies before deployment. In-house support must have a named team and a written procedure for monitoring advisories and backporting fixes.
4. Retire the component and remove it from all hosts, images and recovery copies.

Extended support is a response, not an end state. A component under extended support keeps its register entry, and its owner records a target date for upgrade, replacement or retirement, reviewed under section 10.

Framework note: SA-22 part a (replace) and part b (in-house support or support from external providers) map to these four responses. SOC 2 CC9.2 asks the entity to assess and manage "risks associated with vendors and business partners", which covers the external provider. Cyber Essentials requires unsupported software to be removed, or removed from scope in a sub-set that prevents all traffic to or from the internet; on the scheme's definition, software kept supported by a provider that meets section 3 is supported software. Confirm that reading with your certification body.

7. Security updates for end-of-life components

1. Security fixes for components under extended support follow the same patch timelines as any other software under [Patch Management Policy].
2. At a minimum: fixes for critical vulnerabilities within [14] days of release; high within [14] days; others within [a time frame set by risk ranking].
3. Every fix is deployed through normal change control, and the SBOM records the patched build as its own version.

Framework note: set these values to the strictest framework you are assessed against. Cyber Essentials v3.3 requires updates fixing vulnerabilities the vendor rates critical or high risk, or with a CVSS v3 base score of 7 or above, within 14 days of release. Under PCI DSS v4.0.1, Requirement 6.3.3 requires patches for critical vulnerabilities, ranked under 6.3.1, within one month of release, and all other applicable patches within a time frame the entity sets from its risk ranking. NIST SI-2 and RA-5 leave the period to the organisation. ENISA maps vulnerability handling to ISO/IEC 27001:2022 Annex A 8.8, the control on managing technical vulnerabilities, and SOC 2 CC7.1 asks for procedures to identify "susceptibilities to newly discovered vulnerabilities".

8. Exception process

1. Where none of the section 6 responses can be in place by the end-of-life date, the component owner requests an exception from [Security team].
2. The request states: the component, version and environments; the constraint preventing compliance; the risk, including exposure and known vulnerabilities; the compensating controls and the date and result of their last test; the source of security fixes, if any; and the plan and date that end the exception.
3. Approver: exceptions are approved by [CISO or delegate]. Exceptions for components that are internet-facing, process [regulated data], or have a known exploited vulnerability are approved by [senior management risk owner].
4. Maximum duration: [6] months per exception, renewable no more than [once]. A renewal requires fresh justification and evidence that the exit plan has progressed.
5. An exception lapses early if a vulnerability affecting the component is added to CISA's Known Exploited Vulnerabilities catalog, if the component's exposure increases, or if the source of security fixes ends.
6. Expired or lapsed exceptions are reported as open findings to [risk committee] until closed.

Framework note: SP 800-53A looks for "documented approvals, including justification, for the continued use of unsupported system components" under SA-22. NIST CA-5 requires a plan of action and milestones for weaknesses not yet corrected. The PCI DSS compensating controls worksheet asks for the constraint, the objective of the original requirement, the identified risk, and how the control is validated and maintained, so a request in this format can be reused for a QSA.

9. Roles and responsibilities

Framework note: SA-22 assessments include interviews with the people responsible for acquisition, information security and component replacement. Naming the roles here tells the assessor whom to interview.

10. Evidence retention

The following records are retained for [the longest look-back period of any audit, certification or contract that applies, and at least N years]:

• support-status records and SBOMs for each release;
• register entries and their review history;
• requests for exceptions, approvals, renewals and closures;
• contracts and delivery records for external support providers, including the signatures or attestations verified for each build;
• change records and scan results for every security fix applied to an end-of-life component;
• compensating control test results.

Framework note: none of the clauses cited in this template sets a retention period for these records, so set it from your audit cycles and contracts. Our audit evidence checklist shows how these records are sampled.

11. Review

1. This policy is reviewed at least annually by [CISO], and after any significant change to the technology estate or to the frameworks that apply.
2. Every register entry for an end-of-life component is reviewed at least [quarterly], and immediately when a new vulnerability affects it or its exception is within [30] days of expiry.
3. Every component past end of life receives a documented risk assessment at least annually.

Framework note: PCI DSS 12.3.4 sets a 12-month technology review. DORA Article 8(7) requires financial entities, other than microenterprises, to conduct a specific ICT risk assessment on all legacy ICT systems "on a regular basis, and at least yearly", and before and after connecting technologies, applications or systems. NIST RA-3 asks for risk assessments to be updated when significant changes occur.

12. Non-compliance

Software found running past its end-of-life date without an approved response or a current exception is reported to [risk committee] as an open finding and remediated under section 6 or 8 within [30] days.

Framework coverage at a glance

References are to clauses we checked against published text. ISO/IEC 27001:2022 numbers follow ENISA's published mapping, because the standard itself is behind a paywall.

A dash means we found no clause that asks for that section directly, not that an auditor will ignore it. For the framework detail behind each column, see our guides to NIST SA-22, PCI DSS and end-of-life open source and SOC 2 audit findings.

Where OSSeva fits

OSSeva provides the "extended support" response in section 6 for community end-of-life runtimes. OSSeva Patch ships drop-in builds with backported security fixes quarterly and out of cycle for CVSS 9.0 and above, signed with GPG and attested with Sigstore Cosign, so section 6's verification step has something to verify. Where section 7 needs tighter timelines, OSSeva Operate patches Critical CVEs (CVSS 9.0 or higher) within 48 hours and High within 7 days. OSSeva Assure adds architecture review and the compliance documentation for the exception and evidence sections.

Frequently asked questions

What does software retirement governance and compliance involve?

A written policy that tracks support status, sets a notification window before end of life, limits the responses to upgrade, replace, extended support or retire, and requires a time-boxed, approved exception for anything else. Evidence that the policy was followed matters as much as the policy itself.

What should a software end of life compliance checklist include?

An inventory with support status and end-of-life dates, a register entry and owner for each end-of-life component, a recorded response, a source of security fixes, approved exceptions with expiry dates, tested compensating controls, change records for fixes, and a review date.

How do you manage end of life software compliance across several frameworks?

Write one policy and set its values to the strictest framework in scope, such as the 14-day update window in Cyber Essentials, then keep a mapping table like the one above for each auditor.

Does running end-of-life software automatically fail an audit?

Not under SA-22, which accepts an alternative source of continued support. Cyber Essentials is stricter: unsupported software must be removed or isolated from the internet. Its definition of supported software allows a provider other than the original developer, if that provider can modify the software to create fixes, commits to regular fixes and states when they end.

How long should an end-of-life exception last?

None of the clauses cited here sets a number. Pick a maximum duration and a renewal limit in the policy, and require evidence that the exit plan has progressed before any renewal.