A vulnerability triage checklist that records the decision

A finding needs more than a severity label. Someone must establish whether it applies, understand what an attacker could do, decide what happens next, and define the evidence needed to close it.

This checklist records that decision. Its completed example assumes a cross-tenant invoice disclosure in a fictional SaaS application. All observations are invented for the exercise; they do not describe a real assessment, incident, or employer system.

Get the checklist

The UTF-8 text format can be copied into an issue or assessment record. Store real evidence and credentials in the appropriate private workspace rather than a public copy of the template.

Establish what the finding means here

Begin with the affected product, version, environment, endpoint, or dependency. Record the source, received date, reviewer, authorized reproduction steps, expected behavior, observed behavior, and evidence location.

Then ask whether the affected component is present and reachable. What account, privilege, interaction, or other prerequisite does an attacker need? Which data, tenants, and business operations could be affected? Which controls have evidence behind them?

Keep uncertainty visible. “Not reproduced yet” is not the same as “not affected.” Record the next validation action and its owner. A scanner label or a proposed control does not resolve applicability by itself.

Separate severity from remediation priority

FIRST’s CVSS guidance distinguishes Base severity from a complete risk assessment. If you record a CVSS score, retain the version, vector, source, and assessment date. Use the relevant threat and environmental context rather than turning a Base score into an automatic deadline.

Useful additional inputs can include exposure, affected data, the number of tenants at risk, observed exploitation, and controls whose effectiveness has been checked. Record those inputs separately so another reviewer can follow the decision.

For findings with a published CVE, external intelligence can add context:

CISA’s KEV data provides catalog records to check and date. Absence from the catalog does not prove that exploitation is absent.
FIRST’s EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It is not the probability that your particular application or organization will be compromised.

Keep the score date and source. Do not multiply a severity score by an exploitation estimate and present the result as a validated risk calculation. Application findings without a CVE can leave CVE, KEV, and EPSS fields not applicable; that does not make the finding less worthy of attention.

Record an actionable disposition

Use these four dispositions as a starting point, adapting them to your team’s policy:

Escalate now: Route urgent evidence to the people who can contain the issue and make immediate decisions. Suspected active exploitation belongs in the organization’s incident-response process.
Remediate: Assign corrective work, an owner, a target date, and explicit retest criteria.
Investigate: Identify the missing evidence and assign the next validation step and review date.
Accept or defer: Record the authorized decision-maker, rationale, residual risk, review date, and triggers that reopen the decision.

These are workflow labels, not a universal scoring standard. Set deadlines under your organization’s policy and the finding’s actual context.

Walk through the fictional finding

The companion application’s members can read all invoices in their own tenant; administrators can also mutate and export them. Neither role has cross-tenant access. The example requires an inaccessible object under an authorized tenant context to return a generic 404.

For FINDING-001, assume a Beta member supplies an Alpha invoice ID and receives 200 with Alpha invoice content. This is the hypothetical failure of AUTHZ-003, linked to threat TM-001. The API authorization matrix itself remains unexecuted.

The completed checklist chooses remediation and immediate owner attention because the assumed symptom breaks tenant confidentiality from an ordinary account. It does not claim to know the full affected population or exploitation history. Those remain investigation work. Its example target date is illustrative, not an SLA for readers to adopt.

Define closure before closing the issue

For this finding, retest the foreign-object request and related access paths. Verify that ordinary own-tenant member and administrator reads still work. Check lists, searches, mutations, and exports where the same boundary could fail.

Record the retest environment, version, date, reviewer, responses, and state checks. A code change or a newly returned 404 alone is not enough. The fictional record remains open with no retest evidence and no closure date.

The threat-model worksheet can preserve the original boundary and decision context so that future design changes trigger another review.