Add a short section that lists what you have confirmed, what you believe but have not confirmed, and what you do not know, with an owner and a date against every open item. It stops guesses becoming facts and shows readers where your confidence ends.
Why uncertainty belongs in writing
Supply chain incidents rarely end with a full picture. Logs expire, maintainers go quiet and the package itself may be deleted. If the postmortem pretends to certainty, the first new fact makes the whole document look wrong. If it states its limits, new facts read as expected updates.
It also protects the team. Statements like "no data was accessed" become a liability when later found false. "We found no evidence of data access in these logs, which cover these dates" stays true.
A three column structure
| Confirmed | Believed | Unknown |
|---|---|---|
| Bad version resolved in build jobs A and B, per lockfile and build log | Code ran only in CI, since no developer lockfiles show the version | Whether the code reached the artifact cache |
| Credentials for job A rotated on the date shown | Job B held no cloud credentials | Why the first alert did not fire |
Each item in the first column needs evidence you can point to. Each item in the second needs the reasoning. Each in the third needs an owner.
How to word each kind
- Confirmed: "We confirmed from the build log that..."
- Believed: "We believe X because Y. We have not verified Z."
- Unknown: "We do not yet know X. [Name] will check by [date]."
Avoid soft words such as "appears" or "seems" without saying what is missing. They hide whether you checked.
Absence of evidence
The hardest line to write is "no evidence of misuse". Make it specific. State which logs you reviewed, the dates they cover, what a malicious action would have looked like in them, and what you could not see. A reader can then judge for themselves whether your check was strong or thin.
If logs were missing, retention was too short, or a system had no logging at all, write that down. It is a finding, and probably an action.
Keep the list alive
Unknowns need a home after publication. Add an "open questions" list at the end of the postmortem, review it at a fixed interval, and move each item to confirmed, ruled out or accepted. When the list is empty, add a dated note saying so. If something stays unknown for good, mark it "will not be known" and say why.
Say it in external messages too
If you write to customers, reuse the same structure in plain words. Say what you know, what you are still checking and when you will update. Have your communications owner and legal adviser review it. Nothing here is legal advice.
Quick check
Does listing unknowns make us look unprepared?
Usually the opposite. Clear limits with owners and dates read as control. Vague confidence reads as risk.
What if an unknown can never be answered?
Mark it as will not be known, say why, for example missing logs, and add an action to avoid that gap next time.
Last reviewed: 19 October 2026.
