Legal needs dated, specific facts: what is affected, which customers or data may be exposed, what has been confirmed versus assumed, and what actions have been taken. A one-page fact sheet that engineering fills in beats a long chat thread, and it keeps opinions separate from evidence.
This post is about communication, not legal advice. What legal does with the facts, including any notification question, is their decision.
Why a fact sheet helps
Lawyers read precisely. A message such as "we think it is probably fine" is hard to use. A message such as "as of 14:00 on 19 October, the vulnerable library is present in service A, and exploitation has not been observed in logs for the past seven days; logs older than that are not retained" is something they can work with, including the gap.
Separating facts from unknowns also protects engineers, who are not asked to commit to conclusions they cannot support.
The fact sheet template
Copy this into a shared document and fill in every line, writing "unknown" where it is true.
| Field | What to write |
|---|---|
| Vulnerability | Name, identifier, link to the public advisory |
| Date and time of this version | A timestamp, with a version number |
| Affected products and versions | Which of ours, and which are confirmed not affected |
| How we confirmed | Scan, code review, test, vendor statement |
| Exposure | Internet-facing or internal, number of instances |
| Data involved | Types of data the affected systems handle |
| Evidence of exploitation | What was checked, what time range, what the logs can and cannot show |
| Actions taken | Patches, mitigations, with timestamps |
| Open questions | What we do not know yet and who is finding out |
| Contacts | Engineering owner, security owner |
Confirmed, assumed, unknown
Mark every statement with one of these three labels. Confirmed means someone checked it and can say how. Assumed means it is a working belief. Unknown means nobody has checked. Legal can then decide what is safe to repeat externally.
Keep the record clean
- Version the sheet rather than overwriting it, so the history of what was known when is intact.
- Do not delete earlier versions.
- Avoid adjectives such as "minor" or "serious" in the facts section. Put severity opinions in a separate field and say who holds them.
- Quote scores with their source and date. A CVSS base score describes intrinsic severity. FIRST says it should not be used alone to assess risk (FIRST CVSS v4.0 guide).
What to attach
An SBOM or dependency list for the affected service helps legal see what is actually inside the product. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components (CISA). A dated dependency list shows what was present at the time.
After the event
Hold a short review. What did legal ask that the template did not cover? Add it. Over a few incidents the template becomes the standard intake, and legal stops needing to ask the same ten questions.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies, which gives the fact sheet its inventory section with a timestamp. The free scan at gold.safeguard.sh/scan is a quick way to see what a project contains.
Quick check
Should engineers write conclusions for legal?
They should write facts and labelled unknowns. Conclusions about obligations belong to legal.
Can the sheet be shared outside the company?
Not by default. Ask legal which parts, if any, can be used externally.
Sources
Last reviewed: 19 October 2026.
