Send a first holding update within the first hour or two, then a fixed cadence, such as every two to four hours while the situation is moving, and daily once it stabilises. Always state the time of the next update. The commitment to a schedule matters more than the exact interval.
Why cadence matters
Silence is read as a problem. Stakeholders who hear nothing for six hours start asking, and every individual question pulls an engineer away from the work. A predictable update lets people stop asking. Teams that publish on a schedule spend less time answering one-off messages.
A cadence you can adopt
| Phase | Interval | What it covers |
|---|---|---|
| Hour 0 to 2 | First update inside this window | We are aware. Status: under investigation. Next update time |
| Active response | Every 2 to 4 hours | Confirmed facts, new unknowns, actions taken |
| Stabilised | Daily | Remaining work, any customer action needed |
| Closing | Once | Final status and what changes next time |
Adjust the intervals to your size and the severity. The point is that each update ends with the next time.
What each update must contain
Use the same short structure every time so readers can scan for what changed:
- Status line: under investigation, affected, mitigated, or fixed.
- What changed since the last update.
- What is still unknown, each with an owner.
- What you need from readers, if anything.
- Next update time.
Different audiences, different channels
- Engineers need technical detail and a working channel.
- Executives need the one-page brief (see the template).
- Support and sales need an approved line they can quote.
- Customers need a public notice only when the status requires one, and wording from legal.
Keep one source of truth and let each audience read a different view of it.
Do not let the update stall
The most common failure is an update skipped because "nothing changed." Send it anyway. "No change since 14:00; the log review is 60 percent done; next update 18:00" tells people the work is alive.
Finding out quickly whether you are affected
The speed of the first real update depends on how fast you can answer "do we run it?" A current inventory answers that in minutes. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components (CISA), which is exactly the lookup you need.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new issue enters the list and moves through states. Each state change is a reason to send an update.
Where Safeguard fits
Safeguard offers zero-day discovery, dependency scanning and SBOMs, so the first status check does not start from nothing. The free scan is at gold.safeguard.sh/scan.
Quick check
What if the first update has little to say?
Send it anyway. Acknowledge awareness, say the status is under investigation, and give the next update time.
When can updates stop?
When the status is final and no customer action remains. Send one closing note.
Sources
Last reviewed: 19 October 2026.
