You can declare a supply chain incident closed when five things are true: the exposure is scoped with evidence, every affected secret is rotated, affected artifacts are rebuilt and redeployed, no new indicators have appeared for an agreed period, and a review is on the calendar. Closing on a feeling leaves loose ends.
Why a formal close
Incidents drift. Without a closure rule, work trails off, the timeline stays unfinished and the same gap reopens next quarter. NIST SP 800-61 Rev. 3 places incident response inside cybersecurity risk management, with recovery and improvement as part of the cycle, so a close is a decision with conditions, not the moment people stop talking.
Closure checklist
| Condition | Evidence |
|---|---|
| Scope is known | List of affected repos, builds, images, machines |
| Bad versions removed | Lockfiles, mirrors and caches clean |
| Secrets rotated | Rotation log with times |
| Artifacts rebuilt | Digests of new builds, old digests retired |
| Persistence checked | Workflow files, hooks, keys reviewed |
| Quiet period passed | No new indicators for the agreed days |
| Communications done | Internal, customer and regulator steps recorded |
| Review scheduled | Date and owner set |
Steps
- The incident lead reads the table aloud with the team and marks each row.
- Anything unchecked gets an owner and a date, or a written risk acceptance.
- Agree the quiet period at the start, based on how long the malicious version was live and how long your logs are kept.
- Close in the incident channel with a short summary: what happened, impact, what changed.
- Hold the review within two weeks while memory is fresh. A blameless format works best, see the blameless postmortem template.
What to carry forward
Turn findings into tracked work with owners. Common items include shorter lived tokens, pinned actions, a dependency cooldown, SBOM storage for each release and better log retention.
Avoid the quiet fade
It is common for an incident to end with a slow decline in messages and no decision. Prevent this by putting the closure meeting in the calendar on day one, with the checklist attached. If open items remain, close the incident and keep the items as tracked work, so the response team can rest and the work still gets done. Review the checklist wording after each event and tighten it where a gap appeared.
Quick check
How long should the quiet period be?
There is no standard. Base it on exposure window, log retention and risk, and write it down at the start.
Can we close with an open item?
Yes, if it has an owner, a date and, where needed, a written risk acceptance.
Safeguard's continuous monitoring can keep watching for new advisories on packages you use after the incident closes. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
