An incident status board for a component advisory needs one row per product and release, with columns for verdict, evidence, owner, fix state, customer notice and last update. Everyone reads the same board, so questions get answered from one place instead of in side chats.
The columns
| Column | Content | Why it is there |
|---|---|---|
| Product and release | Name and version | The unit of the answer |
| SBOM source | Where the match came from and its date | Shows how fresh the evidence is |
| Component version | Version found, direct or transitive | Supports the range check |
| Verdict | Not affected, affected, fixed or under investigation | Matches the VEX vocabulary |
| Basis | Justification, impact note or action statement | The verdict needs a reason |
| Owner | One named person | Removes ambiguity |
| Fix state | Not started, in progress, released, deployed | Separates a fix existing from a fix running |
| Customer notice | Not needed, drafted, sent, with time | Tracks communication |
| Last updated | Timestamp | Shows staleness at a glance |
The four verdict values come from the CISA minimum requirements for VEX. Using them on the board means your VEX statements can be generated straight from the rows.
Rules that keep it honest
- Under investigation is the default for every product with a hit or a gap. Nothing is marked clean by silence.
- A product with no SBOM gets its own row, marked under investigation, with the work to find out.
- Changing a verdict requires a basis in the same edit.
- Fix state has separate values for released and deployed. Customers care about the second.
- The board has one editor per row. Others comment.
- A summary line at the top shows counts by verdict and the time of the last update.
Build it simply
A shared spreadsheet or ticket board is enough for most incidents. Create the rows from the SBOM hit list (see the first 24 hours timeline), add rows for products with no SBOM, and assign owners before the first update meeting. For repeated use, automate row creation from your inventory so the board does not depend on someone's memory.
Reading the board
Three questions summarise it. How many rows are still under investigation? How many affected rows have no owner or no date? Which rows have not changed since the last update time you promised customers? Review these at each check-in.
Closing
Close the board when every row is fixed, not affected with a basis, or accepted by a named owner with a review date. Archive it with the incident file so it can feed metrics and the review (see SBOM incident readiness metrics).
Try it yourself
Click through it at your own pace, or open it full screen. See how status changes appear over time.
Quick check
Should the board be visible to the whole company?
Share a read-only view with those who need it. Keep sensitive notes in a restricted section.
Do we need a board for a small incident?
A short list with the same columns still helps. Scale the tool, not the discipline.
Safeguard's vulnerability management tracks findings per product with owners and status, which can serve as the board.
Sources
Last reviewed: 19 October 2026.
