Send reminders at three points: a first notice early enough to plan the fix or renewal, a second when work should already be underway, and a final one the day before. Scale the lead time to severity, tell both owner and approver, and escalate on expiry day.
What a reminder is for
An exception is a promise to revisit. The reminder is how the tool keeps that promise when people forget. A good one makes the next action obvious: fix it, renew it with fresh evidence, or let it lapse and accept that the gate will block again.
A bad reminder is a bare "exception 4821 expires soon" with no link, no context and no deadline. People mute those within a month.
A starting schedule
These intervals are a starting point to adapt, not a standard. Shorter exceptions need shorter lead times.
| Exception length | First notice | Second notice | Final notice |
|---|---|---|---|
| 30 days or less | 7 days before | 3 days before | 1 day before |
| 31 to 90 days | 21 days before | 7 days before | 1 day before |
| Longer | 30 days before | 14 days before | 1 day before |
Higher severity should get earlier and louder notices. A critical finding waived for 30 days arguably needs the first notice at 14 days, because a fix takes time to schedule.
Who gets told
Notify the owner of the affected service, the approver who signed off, and a shared channel or queue so the message survives someone leaving. If your notices go only to the person who requested the exception, they vanish with that person. Orphaned exceptions are a known failure, covered in orphaned vulnerability exceptions when the owner leaves.
What each message should contain
- The finding, the affected asset and the current severity
- The original reason and who approved it
- Exact expiry date, time and timezone
- A link to renew with evidence, and a link to the fix or fix PR
- What happens on expiry, stated plainly
Re-check the finding at reminder time. If a fix has since shipped, say so, because the cheapest outcome is that the owner upgrades and closes the exception. If exploitation status has changed, say that too. The what happens when a vulnerability exception expires post covers the expiry behaviour itself.
Escalation on and after expiry day
On the day of expiry, the gate should return to its normal verdict. Tell the owner's manager that a block is coming, and tell the approver that their decision has lapsed. Do not extend silently to avoid friction. A quiet auto-renewal turns every exception into a permanent one.
Avoiding alert fatigue
Batch low severity reminders into a weekly digest. Send critical ones individually. Track how many reminders lead to a fix versus a renewal. If nearly all end in renewal, the real problem is upstream: the exceptions are being granted for too long, or the fixes lack an owner.
Safeguard's autonomous remediation can open fix PRs (off by default, with every category set to Manual), which gives a reminder something concrete to link to. Its policies and gates then enforce the verdict once an exception lapses.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for where a fix is already available, which is the news every reminder should lead with.
Quick check
Should reminders stop once the owner replies?
No. A reply does not extend the exception. Keep the schedule until the exception is fixed, renewed or closed.
Is one reminder enough?
Rarely. A single early notice gets forgotten, and a single late one leaves no time to act.
Last reviewed: 19 October 2026.
