Say what you know, say what you do not, name who is finding out, and give a time. "We do not know yet" is a complete and credible statement when it comes with an owner and a deadline. It becomes a problem only when it is vague or never updated.
Why people avoid the phrase
Engineers fear sounding unprepared. Managers fear that an unknown will be read as a failure. The result is updates that either say too little or guess. Guesses are worse: a wrong "not affected" costs more trust than ten honest "still checking" messages.
The four-part unknown
Each unknown in an update should carry four parts.
| Part | Example |
|---|---|
| The question | Is the legacy billing service running the affected library version? |
| Why it is open | The service has no current dependency list |
| Who is finding out | Billing team lead |
| By when | 15:00 today |
If an unknown lacks one of these, it is not ready to publish. Add the missing part first, even if it is "owner to be assigned by 12:00".
Phrases that work
- "Confirmed: the web application uses the library. Not yet confirmed: whether the vulnerable function is called. Checking: platform team, update at 14:00."
- "We have not seen signs of exploitation in the logs we hold, which cover the last seven days. We cannot speak to earlier activity."
- "Our current status is under investigation. This will change to affected or not affected by 17:00."
Phrases to avoid
- "We believe we are fine." Beliefs without a stated basis read as hope.
- "No impact." It is rarely true that nothing at all is affected, and it is hard to retract.
- "As far as we know." If this is the whole answer, it hides how far that is.
Keep status values consistent
VEX documents use a small, fixed set of statuses: not_affected, affected, fixed and under_investigation (OpenVEX specification). Borrowing that set for human updates keeps language consistent. The specification also notes that a statement of under investigation can later be replaced by one stating the product is affected or not affected, so an unknown is understood as a temporary state.
Close the loop
Every unknown you publish creates a promise. Track them in the same document, strike through the resolved ones with the outcome, and never remove an unknown silently. If a deadline passes, update anyway: "Still checking. New time 17:00. Reason: the log export is taking longer than expected."
A short template
Known: [list]. Not yet known: [list, each with owner and time]. Next update: [time]. What you can do now: [action or none].
Try it yourself
Click through it at your own pace, or open it full screen. Watch how items start in an early state and move as evidence arrives. Notice how clearly each state is labelled.
Where Safeguard fits
Safeguard's asset discovery and dependency scanning can turn "do we run it?" from an unknown into a quick check. See the free scan at gold.safeguard.sh/scan.
Quick check
Is it better to wait until everything is known?
No. Waiting leaves stakeholders guessing. Publish what is confirmed, label the rest, and set a time.
What if a deadline for an unknown is missed?
Publish a short update anyway with the reason and a new time.
Sources
Last reviewed: 19 October 2026.
