# Vulnerability Investigation Brief Template

*[Use this template to create a brief on a security vulnerability for leaders and decision-makers who need to be informed about it and decide how to act on it. It also fits a malicious or compromised dependency you need to assess and remove, such as a backdoored open-source package or a supply-chain compromise, where the call is the same exposure-and-remediation decision even without a CVE. Base the brief on vendor advisories, government bulletins, such as CISA Known Exploited Vulnerabilities, the CVE database entry, public reporting, a malware analysis report when the exposure is a malicious package, and your internal analysis.*

*Add your organization's context for scope, significance, and prioritization to explain the risk exposure. For more on context-driven prioritization, see [Escape the Vulnerability Management Hamster Wheel](https://zeltser.com/vulnerability-management-hamster-wheel).*

*The text in square brackets is meant to guide you; remove it before finalizing the brief. The title above is generic; rename to match your specific brief.*

*This template was [created by Lenny Zeltser](https://zeltser.com/cyber-threat-intel-report-template) and distributed under the [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/) (CC BY 4.0). The license covers the template; any brief you produce with it is yours.]*

*[Date · Classification · Significance]*

## Bottom Line

*[One paragraph (3-5 sentences) stating what the vulnerability is and how the organization is affected, if at all. Explain what decisions must be made, if any, and what defensive actions are being planned (e.g., patch, mitigate, or monitor). If requesting a decision from the reader, name the specific question or tradeoff explicitly, so they know whether they're being informed or being asked to weigh a choice.]*

## Quick Facts

|  |  |
|---|---|
| **Vulnerability** | *[Name or identifier, such as a CVE (e.g., CVE-2026-12345), a vendor bug ID, or a common nickname such as Heartbleed. Include multiple identifiers when useful.]* |
| **Significance** | *[Your context-adjusted significance rating for this vulnerability in your environment. Vendors base their CVSS scores on worst-case assumptions, so adjust for exposure, compensating controls, data sensitivity, and asset criticality to accurately describe the risk.]* |
| **Timeline** | *[Disclosed <date>. Patched <date> (or "Not yet available"). Exploited <date> (or "Not observed in the wild"). Add the CISA KEV addition date if applicable.]* |
| **Affected Resources** | *[Specific products, versions, and configurations the vendor identifies as affected. Carry the bridge to your environment in the Are We Affected? section.]* |
| **Exploitation** | *[In the wild, proof-of-concept available, theoretical, or unknown. Name the basis for the claim (such as CISA KEV, vendor confirmation, or a researcher report) and give the date you checked. Note any active campaigns leveraging it.]* |
| **Remediation** | *[State the kind of fix and whether it's available. The fix might be a vendor patch, a rollback to a known-good version, a firmware update, a workaround, a configuration change, etc. Note "not yet available" if none exists. Flag when a patch alone isn't enough (pre-patch tokens may stay valid) or has a trade-off such as a performance cost. The action plan goes in Defensive Actions.]* |
| **Attack Vector** | *[How the vulnerability is exploited, such as remote network with no authentication, or local with privileges.]* |

## Are We Affected?

*[One or two sentences explaining your organization's exposure to this vulnerability. Take your organization's context into account to accurately represent the risk.*

*If the vulnerability is in a third-party product, state whether you run the affected software and how exposed you are. If the issue is in your own software, summarize the remediation plan and capture what your legal, compliance, or communications team has decided about customer notifications and coordinated disclosure. If the affected code is a component embedded across other products (a library, a protocol, a CPU feature), state which of your products contain it and which of those run a vulnerable version or configuration.]*

## Defensive Actions

*[Top three to five defensive actions ordered by priority. Common actions for vulnerabilities include patch, apply vendor mitigation or workaround, restrict network exposure, and deploy detection signatures. Why, When, and Who are organization-specific fields the source material generally doesn't address. For actions that require decision-maker approval, name the decision in the When column (e.g., "Pending CFO approval by Jan 22").]*

| What | Why | When | Who |
|---|---|---|---|
| *[Lead with an action verb, such as Patch, Mitigate, Block, or Monitor.]* | *[Why this matters for the reader's organization.]* | *[Such as Immediate, Within 30 days, etc.]* | *[The internal owner.]* |
|  |  |  |  |
|  |  |  |  |

## What We Don't Know

*[One or two sentences naming the key uncertainties that would change the assessment. Examples include exact affected versions, patch coverage for older releases, exploitation prevalence, and whether published mitigations fully address the vulnerability. Be explicit about what evidence would tip your read of the situation.]*

## More Information

|  |  |
|---|---|
| **Primary Source** | *[Link to the principal vendor advisory, government bulletin, or CVE database entry you're synthesizing from.]* |
| **Additional Details** | *[Researcher write-ups, exploitation reports, vendor blogs, and other sources you drew from.]* |
| **Follow-Up Contact** | *[Name and channel for follow-up questions on this brief.]* |