How do you write a legacy system audit finding without overstating it?

Write the finding around evidence, not fear. A good finding acknowledges controls that exist and identifies the specific gap that remains.

A useful structure is:

• Condition: critical application runs on unsupported technology.
• Criteria: policy, risk appetite, patch-management standard, vendor lifecycle requirement, or cybersecurity framework.
• Cause: application dependency, unavailable upgrade path, funding delay, or unclear ownership.
• Risk: security exposure, operational outage, compliance issue, recovery failure, or unsupported vendor response.
• Evidence: asset record, support status, access rules, missing risk acceptance, missing restore test, or no migration date.
• Recommendation: document risk acceptance, strengthen compensating controls, assign owner, set review cadence, and approve a remediation roadmap.

For example, the finding might say that management has not documented residual risk acceptance or a funded remediation path for a critical application running on unsupported technology. That is more defensible than claiming a breach is inevitable.

The strongest report language ties the issue to governance and control effectiveness, not to an auditor's personal discomfort with old software.