Safeguard
Compliance•

How do you document a vulnerability exception you forgot to file?

If a finding went unfixed with no approval on record, file a late exception dated today, state the gap plainly and never backdate. Steps inside.

Safeguard Security Team
3 min read

File a late exception with today's date, say plainly that the deviation began earlier, record who approves it now, and add a note on how you will stop it happening again. Never backdate. An honest late record is a weaker control than a timely one, but a fabricated one is a far bigger problem.

This comes up in nearly every audit prep: someone finds a ticket-less suppression and wonders whether to quietly "fix the paperwork".

Why backdating hurts

Auditors compare timestamps across systems. An approval dated March in a system that was configured in June, or a ticket created in October with an effective date of last spring, is easy to spot. Once one record looks edited, the rest of the register loses credibility.

The honest backfill, step by step

  1. Find the real start. Use scanner history or git blame to learn when the finding appeared and when it should have been handled.
  2. Open a new exception record today. Fill in the usual fields: finding, asset, reason, other controls, expiry.
  3. Add a gap statement. One or two sentences: "This finding was first detected on 4 June and was not recorded as an exception until 19 October."
  4. Get approval now. The approver confirms the risk is acceptable going forward, or declines and a fix is scheduled.
  5. Set a short expiry. Late records deserve a shorter first term, such as 30 days.
  6. Record the cause. Why was it missed? Missing template, unclear owner, tool allowed silent dismissal?
  7. Fix the cause. One concrete change, such as disabling silent dismissal or adding a weekly check for unrecorded suppressions.

Sample wording

"Retroactive record. Finding present since 4 June. No approval was recorded at the time. Approved today by the engineering lead for 30 days, pending a fix in the next release. Process change: dismissals in the scanner now require a linked ticket."

What the auditor sees

A dated, honest gap with a corrective action reads as a control that detected its own failure. That is what a working process does. Many auditors treat a self-identified, corrected deviation more kindly than one they discover.

Prevent the next one

Run a monthly diff between scanner suppressions and the register. Anything in the first and not in the second is a candidate for backfill. Keep the diff output as evidence that you check.

NIST SP 800-40 Rev. 4 frames patching as planned preventive maintenance. A late exception record is part of keeping that plan honest, so it should follow your normal process, not bypass it.

Where Safeguard fits

Safeguard's continuous monitoring can surface findings that have been open longer than your policy allows, which is a reasonable trigger for the monthly diff.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how long-open findings surface, then ask which of them would need a late record.

Quick check

Can I change the effective date on an old record?

Do not. Add a dated note or a new record. The original timestamps are part of the audit trail.

Do I have to tell the auditor?

Disclosing a self-found gap with its fix is usually better than letting them find it. Ask your auditor how they want it presented.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.