A one page leadership summary of a supply chain incident should open with current status and severity, then state what is known, what is not, customer and data impact, actions taken, decisions needed and the time of the next update. Leaders need a decision basis, not a technical narrative.
What leaders actually need
Executives ask the same questions: are customers affected, are we exposed legally, what do you need from me and when will I hear again. Answer those first, and put technical detail on a second page for those who want it.
The layout
| Section | Content | Length |
|---|---|---|
| Status | Severity level, open or contained, time of last update | One line |
| What happened | Plain description, no jargon | Two sentences |
| Exposure | Where the bad version was found, whether it ran | Three lines |
| Impact | Customer data, systems, secrets exposed | Three lines |
| Done so far | Containment and rotation actions with times | Bullets |
| Not yet known | Open questions, stated honestly | Bullets |
| Decisions needed | Notification, spend, public statement | Numbered |
| Next update | Time | One line |
Writing rules
- Separate facts from assumptions. Label each.
- Use times with time zone.
- Say unknown where it is unknown. Leaders react worse to a reversed claim than to an honest gap.
- Avoid attribution and blame.
- Keep notification questions visible. Under GDPR Article 33, for example, a controller must notify the authority without undue delay and where feasible within 72 hours of becoming aware of a personal data breach, unless a risk to people is unlikely. Flag the clock start time if a notification duty may apply, and involve counsel.
- Keep the same format at each update so changes stand out.
What to leave out
Tool names, stack traces, raw logs and speculation about the attacker. Offer them on request.
After the incident
Send a final version with a closing summary and the review date. See the closure checklist.
Update rhythm
Agree the schedule in the first message and keep it. A first update within the first hours, then at set intervals, builds trust even when little has changed. Mark what changed since the last version at the top, so a reader who skims the page still sees movement. When the incident closes, replace the page with a final version that states the cause if known, the impact, the actions taken, and the follow up work with owners and dates.
Quick check
How often should leadership get updates?
On a fixed schedule agreed at the start, such as every few hours at first, then daily.
Should the summary name the maintainer or attacker?
No. Stay with facts about your own exposure and actions.
Safeguard's compliance and evidence automation can help keep records of decisions and controls. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
