After shipping a fix, ask the reporter to confirm it works, publish an advisory that matches the release, credit the finder as they prefer, tell customers how to deploy, and run a short review of the case. The CERT guide lists confirming the fix as a finder step and deployment support as a vendor step.
Why the loop matters
The CERT Guide describes disclosure as a process, not an event. Its tutorial lists, for finders, discovering, reporting, confirming that the remediation works, and optionally publishing an advisory. For vendors it lists receiving, validating, prioritizing, remediating, publishing an advisory, and supporting deployment with information and patches while taking deployers' feedback.
Most teams stop at the release. The steps after it are where trust is built or lost.
The checklist
| Step | Owner | Done when |
|---|---|---|
| Ask the reporter to retest | Vendor | They confirm, or report a gap |
| Publish the advisory | Vendor | It names versions, fix, workaround |
| Credit the finder | Vendor | Name matches what they asked for |
| Notify customers | Vendor | Direct message sent to those who should hear |
| Update tracking | Vendor | Ticket closed with advisory link |
| Hold a short review | Vendor | Five line note filed |
Asking for a retest
Send the reporter the fixed version and the date it will be public. Ask them to retest and say that you will wait a few days for an answer. Retests sometimes find a bypass, and it is far better to learn that before publishing. If they find one, treat it as a new report on the same case and reset the timeline with them.
Telling customers how to deploy
A fixed version helps nobody until it runs. Say which versions are fixed, how to upgrade, whether a restart or migration is needed, and what to do if they cannot upgrade yet. See how to notify downstream users.
The short review
Write five lines: what came in, how long each stage took, what almost leaked, what the reporter said, and one change to make. File it where the next responder will find it. The principle of process improvement in the guide exists for exactly this.
Handling the awkward cases
If the reporter does not reply to your retest request, publish on your agreed date anyway and note that the fix was not independently confirmed. If they publish first, see what to do when a researcher goes public before your fix.
Quick check
Should I wait for the reporter to confirm before publishing?
Wait a reasonable, stated period. If they do not answer, publish on the agreed date and say the fix was not independently confirmed.
What if the retest finds a bypass?
Treat it as a new report on the same case, fix it, and agree a new date with the reporter.
Safeguard's policies and compliance evidence automation can keep the record of each disclosure step. A free scan covers the dependency side.
Sources
Last reviewed: 19 October 2026.
