Receiving your first vulnerability report

An email arrives. A security researcher you have never heard of says they have found a flaw in your product, and they have attached something that looks like proof. For a small team without a Product Security Incident Response Team (PSIRT), this is the moment that decides whether the researcher becomes a quiet, helpful partner — or a frustrated stranger drafting a public write-up.

The good news: you do not need a different plan for every report. There is one workflow, and it branches at a few well-marked points. Reports arrive in wildly different shapes — a careful researcher with clean proof, an upstream vendor warning that a component you use is affected, a customer asking whether a newly announced flaw touches you. But they all move through the same stages. Knowing the stages lets you read a strange report calmly and put it in the right place instead of improvising.

The clock that matters most: acknowledge within 24 hours

Before anything else, send an acknowledgement. Within 24 hours of a report landing, the reporter should hear back from a human — a receipt, an incident ID, and a date for the next update. That is it. The acknowledgement does not commit you to a severity, a fix, or a timeline. It just confirms a person is on it.

This single habit heads off most of the disclosure fights small teams get into. Researchers who hear nothing within a day are the ones who lose patience and start writing publicly. Mature teams aim for four to six hours; 24 hours is the outer bound people actually measure you against.

The eight stages every report moves through

The wording varies across frameworks — the Forum of Incident Response and Security Teams (FIRST) PSIRT Services Framework and the ISO/IEC 29147 and 30111 standards each phrase it a little differently, and the July 2026 joint guidance from CISA, the NSA, JPCERT/CC, and the Dutch and UK national cyber security centres ("Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers") walks the same chain — but the structure is the same everywhere:

1. Report received. A message reaches someone responsible for responding. Good or terrible, in scope or out, signed or anonymous — none of that matters yet.
2. Acknowledgement. Within 24 hours, the reporter gets a receipt and an incident ID (see above).
3. Triage. Usually within five business days, the first real pass: can we reproduce it, is it actually a security issue, does it affect a shipping product? A few signals — credible signs of active attack, a regulator, a known critical-advisory cycle — compress this to hours.
4. Validation. Engineering reproduces it; you confirm it in writing. This is where a claim becomes a confirmed weakness. Validation means confirming the mechanism the reporter described, in an environment that maps to the shipping product — not running the attack end-to-end in production.
5. Severity and scope. A Common Vulnerability Scoring System (CVSS) score is the starting point, not the answer. Make it defensible — if a customer challenges it later, you want to show your reasoning, not wave at the calculator. The harder half is scope: which products, versions, and setups. Customers read the affected-products list as a yes/no statement of their exposure, so be specific.
6. Coordination decision. Here the path visibly branches: a quiet fix with no advisory, a public advisory when the fix ships, a multi-vendor embargo, a regulator notice, a bug-bounty payout. Most reports land in one of two buckets — public advisory at fix, or quiet fix. The interesting ones are the rest.
7. Fix delivery. Engineering ships the fix and verifies it — against the original proof and the nearby paths a regression might surface. A broken fix is worse than no fix.
8. Disclosure. The advisory publishes, customer mailings go out, the Common Vulnerabilities and Exposures (CVE) record updates, and the reporter gets credit in the wording they asked for. Line the channels up so none publishes hours ahead of the others — a scattered disclosure is a defender's nightmare and an attacker's opening.

A ninth step — the post-incident review — is where the workflow learns. Fifteen honest minutes on what worked, what did not, and one action item for next time beats a polished document nobody reads.

Where the path branches

Four decision points account for most of the variation between reports. Recognising them early is the actual skill:

• Origin. A researcher report begins with a relationship you are responsible for tending. An internal find has no outside party to coordinate with. An upstream notice arrives with a deadline someone else already set. Same stages; different actors and time pressure.
• Coordination posture. Coordinated disclosure means you publish at the same moment as other affected parties — slower, more discipline, stronger shared defence. Uncoordinated means you publish on your own clock — faster, riskier where others are exposed downstream. The choice is usually made between triage and fix delivery, and it shapes everything after.
• Bounty eligibility. If you run a bug-bounty programme, the in-scope, severity, payout, and credit questions run as a side track. It does not change the technical response, but it shapes the reporter conversation.
• Impact breadth. A one-customer or odd-setup issue runs the workflow lightly; a multi-customer issue runs it heavy. Misjudging breadth is a common way to lose credibility late — a customer finds out they were affected and never told.

Three places the standard path needs help

Three patterns come up again and again as the cases where the basic workflow is not enough — and the moment to recognise the situation is non-standard:

• Shared internal services. A flaw in an internal identity service or monitoring agent has no version range to publish and no download path for the fix — the "affected products" list is your own systems. The workflow still runs, but the advisories and notices it produces need adapting. The response often feels half PSIRT and half incident response, because it is.
• Cross-vendor dependency chains. When the bug is in a component you pulled in indirectly, the upstream owns the fix and you own the customer-facing advisory. The failure mode: treating the upstream's silence as a reason to hold your own advisory longer than your customers can stand. Name the dependency and line the timelines up openly.
• Regulatory deadlines. Sometimes a weakness also trips a notification law — the General Data Protection Regulation (GDPR) 72-hour clock, the EU NIS2 Directive, the US Securities and Exchange Commission's four-business-day rule for material incidents. Then the disclosure timing is no longer yours alone. Get legal counsel and your responders talking before this comes up. They speak different languages, and the gap between them is where mature teams get into trouble.

What good looks like on your first report

A team that handles its first report well looks calm from the outside. The reporter hears back within a day. Triage runs on a stated clock. The fix is checked against more than the original proof. Disclosure lines up across channels, and a short review captures one improvement. None of that requires a large team. It requires knowing the stages in advance — so the first report is a process you run, not a panic you survive.

When you want this ready to use

Sylvan Assurance's PSIRT Response toolkit turns this workflow into working documents: the readiness assessment with expert notes, the PSIRT Response Playbook and First-72-Hours Runbook, the stakeholder message templates and regulatory-notice decision tree, the coordinated-disclosure playbook, and worked sample incidents — with higher editions adding tabletop scenario generation, forensics and evidence-preservation guidance, and bug-bounty operations. Editions from $49; the toolkit page has the full breakdown.

The free PSIRT readiness assessment at sylvanassurance.com/free/psirt asks 17 questions and returns a tailored guide. It runs entirely in your browser; your answers are never sent anywhere.

Prefer the long form? The companion Sylvan Press title, PSIRT, covers the same ground in depth.