Tell the story in five artifacts: the reason the system cannot be upgraded, the compensating controls, dated evidence that they work, a named owner with a review record, and a retirement plan. Bring them in that order and keep each to a page.
What the auditor is trying to decide
An auditor is not usually asking whether you have an old system. Most organizations do. They are asking whether you know about it, decided deliberately, and kept the decision current. NIST's text on unsupported components accepts exceptions where systems provide critical mission or business capabilities and newer technology is not available, or where systems are so isolated that replacement is not an option. The exception is legitimate. What an auditor tests is the rigor around it.
This post is operational guidance, not legal advice, and what a particular auditor needs depends on the framework and scope you are being assessed against.
Artifact 1: the reason
One paragraph. What the system does, who depends on it, why it cannot be upgraded now (vendor ended support, application incompatible, downtime not allowed), and the cost or impact of changing it. Avoid vague language like "legacy constraints".
Artifact 2: the compensating controls
A table linking each gap to the control that addresses it.
| Gap | Control | Enforced by |
|---|---|---|
| No security patches | Isolated segment, deny by default | Firewall rules |
| No modern authentication | Access through jump host with multi-factor authentication | Access broker |
| No agent | Network and log monitoring | Collector and alerts |
Artifact 3: dated evidence
Screenshots and exports with dates: firewall rule export, the failed test of a direct connection, a log sample showing a denied attempt, the restore test record. Evidence older than your review cycle invites questions.
Artifact 4: ownership and review
Name the business owner and technical owner. Show the approval, who approved it and when, and the review history. NIST's plan of action and milestones control describes updating plans based on assessment findings, independent audits and monitoring, which is the behaviour you want to show: the record changes when facts change.
Artifact 5: the exit
The retirement plan with dated milestones and the current status. If dates have slipped, show the recorded reason and the sponsor's decision. A slipped date with a reason is far easier to defend than a plan that silently expired.
How to present it
- Lead with the risk, not the technology.
- Offer the artifacts as a pack, one folder per system.
- Be honest about residual risk. State what the controls do not cover.
- Show the review trigger list, such as new exploited vulnerabilities in the system.
- Do not claim a certification or attestation you do not hold. Say what you do and give the evidence.
Try it yourself
Click through it at your own pace, or open it full screen. Step through it to see how one control can be mapped to several frameworks.
Where Safeguard fits
Safeguard's compliance and evidence automation helps keep control evidence collected and dated in one place, which makes a pack like this easier to refresh. The free scan is at gold.safeguard.sh/scan.
Quick check
Will an auditor accept an exception without a retirement date?
Practices vary, but an open ended exception is much harder to defend. Even a rough dated plan shows the risk is being managed.
Who should present the exception?
The system owner, with security in support. Owners can explain the business need that security cannot.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (SA-22 Unsupported System Components and CA-5 Plan of Action and Milestones)
Last reviewed: 19 October 2026.
