Answer with the truth in three parts: what you track, what exceptions currently exist, and what happens to them. Do not answer a flat "no" unless you can show the inventory behind it. Reviewers care more about a managed process with dated exceptions than about a claim of zero.
What the reviewer is asking
The question behind the question is whether you know what you run and whether you act before support ends. A buyer cannot audit your code, so they read your process. A good answer shows an inventory, a lifecycle field, a review cadence and a way to handle exceptions.
A three part answer
Part one, the process. State that you keep an inventory of runtimes, frameworks and base images, record support status and end dates from the maintainers' own pages, and review them on a stated schedule.
Part two, the current state. State plainly whether exceptions exist today. If they do, give the count and say that each has an owner, a documented reason, compensating steps and a revisit date. If you do not know, say you are completing the inventory and give a date.
Part three, the escalation. Say what triggers action: for example, an end date inside a stated window, or a component past support on an internet-facing system.
Sample wording
"We maintain an inventory of runtimes, frameworks and base images in production. Each entry records the support status and end date taken from the maintainer's published policy, with the date we last checked. We review the list monthly for items ending within 90 days. Where a component is past support, we record a time-limited exception with an owner, compensating controls and a target retirement date. We can share the current exception count on request."
Adjust every sentence to match what you really do. If you review quarterly, say quarterly.
Words to avoid
| Avoid | Why | Use instead |
|---|---|---|
| "We have no unsupported software" | Hard to prove, easily disproved | "We track and manage support status" |
| "All software is fully patched" | Absolute claim | "We apply updates on a stated cadence" |
| "Extended support covers us" | Only true with evidence | Name the coverage and end date |
| "Certified" or "compliant" | A questionnaire answer is not an attestation | Describe the control |
Never describe a control you have not implemented. If something is in progress, label it in progress, with a date.
Evidence to offer
- A dated export of the inventory, with sensitive details removed.
- Your exception register template and the count of open entries.
- The policy that sets the review cadence.
- A sample of source links for lifecycle dates.
Share a summary rather than raw scan output unless the buyer asks for more. What to send instead of raw scan results covers how to scope it, and support period and end-of-life dates buyers expect shows the buyer's side.
If you do have a problem
Say so. A named gap with a dated plan reads as mature. A hidden gap that the buyer finds later reads as a trust problem. Use a vulnerability exception for end-of-life software as the model for the record you reference. This is operational guidance, not legal advice. Have your own counsel review any contractual language.
Try it yourself
Click through it at your own pace, or open it full screen. See how a control maps to framework requirements, then map your lifecycle process to the questions you receive.
Where Safeguard fits
Safeguard's compliance and evidence automation helps you keep control records and evidence together, and SBOM and dependency scanning supplies the inventory behind them. A free scan is at gold.safeguard.sh/scan.
Quick check
Is it acceptable to say we have exceptions?
Yes, if they are managed: owner, reason, compensating steps and a revisit date.
Should I attach the full inventory?
Usually a dated summary is enough. Share more only when asked and under suitable terms.
Last reviewed: 19 October 2026.
