How to Document End-of-Life Software Risk: Risk Register, Exceptions and Compensating Controls

The short answer

Document end-of-life software risk as one register entry per unsupported component and version, not as a line in a general IT risk log. Each entry records the component, the version you run, the upstream end-of-life date and where that date came from, how exposed the component is, the known CVEs against it, an owner, a decision, the compensating controls in place, a review date and an exit plan. Where the decision is to keep running the component, attach a time-boxed exception approved by someone with the authority to accept the risk. Then review the entry on a fixed cadence and close it only with evidence that the component was upgraded, replaced, retired or put under a documented source of security fixes.

That structure maps onto what the main frameworks ask for. NIST SP 800-53 SA-22 wants replacement or an alternative source of support, and assessors examine "documented approvals, including justification" for continued use. PCI DSS 12.3.4 wants end-of-life plans documented and a remediation plan approved by senior management. This article is general information, not legal or audit advice. Your auditor or assessor makes the final call on whether the evidence is enough.

The fields of an end-of-life risk register entry

Keep one row per component and version line in each environment where it runs. A ZooKeeper 3.6 ensemble in production and another in a payment environment are two rows, because their exposure, owners and controls differ.

The register sits next to your SBOM rather than inside it. NTIA's minimum SBOM elements have no field for support status, which is why our post on SBOMs and end-of-life components argues that an inventory finds the problem without fixing it. Our comparison of end-of-life tracking tools covers how to populate the date and source columns automatically.

A filled-in example: ZooKeeper 3.6

Apache ZooKeeper 3.6 reached end of life on 30 December 2022, with 3.6.4 as its final release, as recorded on our ZooKeeper 3.6 end-of-life page. The deployment details below are illustrative.

Two details make this entry hold up. The CVE field says plainly that upstream has no fix for this line, so nobody reads a clean scan as a clean bill of health. And the decision names where fixes will come from, which is the question an SA-22 assessor asks first. Our SA-22 guide lists the evidence for each route.

What a time-boxed exception should contain

An exception, sometimes called a risk acceptance, is the signed decision to keep running something that policy says should be upgraded. It is separate from the register entry because it has a different lifecycle: it is approved once, expires, and is either closed or renewed with fresh justification. A useful exception contains:

1. Scope. The register entry it covers, the component, version and environments. One exception per entry keeps renewals honest.
2. The constraint. Why the component cannot be upgraded yet: client dependencies, vendor certification of a dependent product, a change freeze. PCI DSS's compensating controls worksheet asks for the legitimate technical or business constraint first.
3. The risk statement. What could go wrong, using the exposure and CVE fields, and what risk remains after controls. The PCI worksheet calls this the additional risk posed by not meeting the original requirement.
4. The source of fixes. In-house team or external provider, and the contract or procedure that defines it. This is SA-22 part b.
5. Compensating controls and their tests. Each control, how it was validated, and how it will be maintained.
6. Approver. Someone with authority to accept the risk at its level, named in your policy. SP 800-53A looks for documented approvals with justification, and PCI DSS 12.3.4 asks for senior-management approval of the remediation plan.
7. Start date, expiry date and maximum duration. Expiry is what makes it time-boxed. Set a maximum duration and a limit on renewals in your policy, so that a long-running exception has to be argued again on its merits.
8. Conditions that void it early. For example, a new CVE on the component listed in CISA's Known Exploited Vulnerabilities catalog, a change that exposes the component to the internet, or a lapse in the support contract.
9. Link to the exit plan. The ticket or plan of action and milestones (NIST CA-5) that ends the need for the exception.

An expired exception should be treated as an open finding, not quietly extended. Our compliance versus security post explains why: an accepted exception closes the audit finding but not the risk.

Compensating controls auditors usually accept, and their limits

Auditors generally accept compensating controls for an end-of-life component when they reduce a specific risk, have been tested, and come with a plan to stop needing them. They are much less comfortable with controls offered as a permanent substitute for support. The common ones:

Whichever controls you use, record for each one the finding it addresses, the test, the result and the date. A firewall rule that was correct before the last network change is the usual reason a compensating control fails sampling.

How often to review

At least annually for every entry, because that is the floor in the frameworks that set one. PCI DSS 12.3.4 requires a review of hardware and software technologies at least once every 12 months. DORA Article 8(7) requires financial entities, other than microenterprises, to run a specific ICT risk assessment on all legacy ICT systems "on a regular basis, and at least yearly", and before and after connecting new technologies, applications or systems. DORA's definition of a legacy ICT system in Article 3(3) includes one that has reached end of life or is no longer supported by its supplier or an ICT third-party service provider.

Annual is the floor, not the target. A quarterly review suits most end-of-life entries, with an immediate review when one of these happens:

• A new CVE names the component's version line, or upstream publishes an advisory without listing older lines.
• A CVE affecting the component is added to the Known Exploited Vulnerabilities catalog.
• The component's exposure changes: a new network path, a new data type, a new framework in scope.
• The exception is within a month of expiry.
• The source of fixes changes, including a contract renewal or a team reorganisation.

How to close the item

Close a register entry only when the risk it records no longer exists, and attach the evidence:

• Upgraded. The change record, the SBOM or inventory showing the supported version, and a scan after the change. Then close the exception.
• Replaced. The same evidence for the replacement product, plus confirmation that the old component no longer runs anywhere, including disaster-recovery copies and base images.
• Retired. The decommissioning record and evidence that the hosts, images and data were removed or archived.

Moving a component onto extended support does not close the entry. It changes the decision to "kept, with an external source of fixes" and the review continues, because new CVEs will keep arriving against an old line. What changes is that each new CVE now has somewhere to go. Our audit evidence checklist shows how the closed entry, the change records and the approvals fit into one package for sampling.

Where OSSeva fits

OSSeva is the external source of fixes that the decision field can name for community end-of-life runtimes. OSSeva Patch delivers drop-in builds with backported security patches quarterly and out of cycle for CVSS 9.0 and above, signed with GPG and attested with Sigstore Cosign. For ZooKeeper that includes patched 3.6.x builds. OSSeva Operate commits to patching Critical CVEs (CVSS 9.0 or higher) within 48 hours and High within 7 days. OSSeva Assure adds architecture review and compliance documentation. Our end-of-life dates and EOL tracker give you the date and source for the register.

Frequently asked questions

What is the best way to document software end of life risk?

Keep one risk register entry per unsupported component and version, with the upstream end-of-life date and its source, exposure, known CVEs, an owner, a decision, compensating controls, a review date and an exit plan. Link a signed, time-boxed exception to any entry where the component stays in service.

How do you manage end of life software compliance?

Track support status alongside your inventory, decide for each end-of-life component whether to upgrade, replace, retire or keep it with a documented source of fixes, and review the decisions on a fixed cadence. Our end-of-life software policy template sets out the rules in a form you can adopt.

How do you prepare for an end of life software audit?

Make sure every end-of-life component in scope has a register entry, a current approval with justification, evidence of where its fixes come from, tested compensating controls and change records for fixes applied in the period. Auditors sample, so assemble the evidence per component rather than per framework.

How do you reduce risk from obsolete software?

Contain it first with isolation and access restrictions, get a source of security fixes for the version you run, and schedule the upgrade or retirement. Controls lower the risk quickly; only a fix or removal takes the vulnerability away.

Is a risk acceptance enough on its own?

Rarely. Frameworks allow documented risk acceptance, but auditors expect it to be time-boxed, approved at the right level, backed by tested controls and linked to a plan that ends it.