Triaging a Vulnerability Report
Audience. Whoever works the submissions inbox day to day.
Outcome. Every report acknowledged inside the SLA, scored, assigned, decided on, and closed with an evidence trail that stands up to inspection.
Why it matters. SOP-01 gets reports arriving. This is what happens next, and it is where the CRA vulnerability-handling requirements in Annex I Part II are actually met or missed. Several panels here carry their clause reference on screen, so the trail assembles itself if you use them.
Time required. Acknowledgment takes under a minute and should never wait. The rest follows the vulnerability.
The flow at a glance
The diagram shows the seven stages on one page, from a new report to a closed report. The same stage bar is on each report page, in the classic and the new dashboard. The steps below explain each part. Select the diagram to open it at full size. The example product is fictional.
Step 1. Work the inbox by SLA, not by arrival
Open Submissions.
Every report shows product, type, reporter contact, status, age and SLA state. The Article 14 column needs the Reporting plan or higher. Anything past the acknowledgment target is called out at the top of the page and flagged in the SLA column. The time left shows only for a NEW report.
Sort your attention by the SLA column, not the date. A breached acknowledgment is the one thing on this screen that is visible evidence of a process not working.
Step 2. Acknowledge first, investigate second
Open the report and acknowledge it. The Acknowledge button sits inside the acknowledgment alert at the top of the report, beside the time the acknowledgment is due. The alert stays until the report is acknowledged, also when the report has already moved to In progress. Acknowledging such a report keeps it In progress.
To list every report past its acknowledgement window, click the Ack Overdue tile on the Overview, or Show only these reports in the alert above the Submissions list. Both use the window your disclosure policy commits to, 48 hours unless you changed it.
The acknowledgment clock is what the SLA measures. It is not a claim that you understand or agree with the report, only that a human has it. Acknowledging in sixty seconds and investigating for a week is a working process. Investigating for a week and then acknowledging is a breach.
Step 3. Score it
Use the CVSS Calculator panel. Both 3.1 and 4.0 are available.
Set the vector, then Apply to Submission. The score is saved to the submission record as audit evidence, labelled VRF-2. Apply also sets the severity from the score, and it replaces a severity that you set by hand.
Score from the reporter's evidence, not from your first instinct about severity. For a security incident, a HIGH or CRITICAL severity triggers Article 14 while the Article 14(5) tests are open. A vulnerability triggers Article 14 only when it is actively exploited, whatever its score.
Assess is done when the severity is not UNRATED. On the Compliance plan and higher, the report must also be linked to a CRA product, see Step 6b.
Step 4. Assign a coordinator
In the Coordinator panel, assign the person who owns this report through to closure. Only an admin can assign. The list shows the users of your workspace and the partner users who have a seat on it, for example your authorised representative. A partner user is in the list only while partner access is on, your workspace still links that partner, and the partner account is active. Auditors are not in the list. The coordinator gets an email and follows the report from then on.
Supports RCP-5-RC-01, coordinator formally assigned and notified. An unassigned report has no route to resolution and no one to chase.
Step 5. Request more information, where needed
Use Request more info to send a structured request to the reporter.
Supports VRF-1-RQ-01. The exchange is recorded, which matters more than the convenience. The request needs a reporter email address. It does not change the status of the report.
Step 6. Establish which components are affected
Open Impacted components.
Add components manually, or use Scan SBOM for CVEs to cross-reference against your uploaded SBOM. The scan needs the Reporting plan or higher. Mark each as affected or not affected with a reason. Labelled RCP-3/4.
Two limits worth knowing. The scan matches each component by vendor and product name (CPE) through GCVE. If GCVE is not available, it uses an NVD keyword search. It does not match on the package version, so it over-reports and every hit needs review. It also caps how many components it checks in one run and tells you when it did, so a partial scan is never presented as a clean result. For version-accurate matching, use SBOM Exposure on the Supply Chain Intelligence page, which is covered in SOP-06.
Step 6b. Confirm the CRA product link
Check the CRA product panel. A report whose product name matched exactly one active product was linked at intake, and anything ambiguous arrived unlinked. When no product carries the reported name, the panel says so and offers to create that product with the name already filled in.
Correct it now rather than later. If this report ever escalates to Article 14, the link is what fills the ENISA SRP product type and Annex III/IV category from the classification you already made, instead of asking someone to recall the tier while a 24-hour clock runs. Only admins can change it. See SOP-04.
Step 7. Coordinate upstream where the flaw is not yours
If the vulnerability is in a component you integrate rather than code you wrote, use Upstream coordination.
This satisfies CRA Article 13(6), which requires you to report a vulnerability in an integrated component to the person or entity maintaining it. Record the component, the maintainer contact, and any patch reference.
This obligation is easy to overlook because the flaw is not yours. The obligation to report it upstream still is.
Step 8. Keep the communication log current
Log every substantive exchange with the reporter in the Communication log.
Labelled PRE-4, evidence of researcher communications. Some automatic steps write a line here, for example the acknowledgment, the resolution, an information request and a fix verification. Other emails do not, for example the receipt that the reporter gets at intake, the upstream email and the coordinator email. Anything you send out of band, a call or a direct email, has to be logged by hand or the trail has a hole in it.
You cannot delete an entry. To correct one, log a new entry.
Step 9. Record the remediation decision
Open Remediation decision and pick one.
| Decision | Meaning |
|---|---|
| Fix | Produce and release a security patch |
| Workaround | Publish mitigation until a fix is ready |
| Accept | Risk formally accepted, no immediate action |
| Transfer | Upstream component owner to remediate |
| Defer | Action planned but postponed with rationale |
Add the rationale, target date and owner. The portal requires only the decision type, so these fields depend on you. Supports RMD-1-RQ-01, a documented decision, and RMD-1-RQ-02, a plan with a timeline. The panel needs the Reporting plan or higher.
Fix, Accept and Transfer complete the Fix stage. Workaround and Defer keep it open until you verify the fix or resolve the report. You can verify it before you close the report.
Accept and Defer are legitimate outcomes, and both are only defensible with a written rationale. The field exists for that reason. Use it properly, because an unexplained Accept is the entry an auditor will stop on.
Step 10. Escalate to Article 14 if it qualifies
If the vulnerability is actively exploited, or the incident is severe, stop here and follow SOP-04, Filing an Article 14 Report. The clock started when you became aware, not when you finished triage.
Only an admin can record the Article 14 decision. If it does not apply, click Record: not actively exploited. The Report to CSIRT stage is then skipped.
Step 11. Consider AI triage for volume
AI triage is an Enterprise feature and is off by default. Enable it under Settings, then AI Triage.
It runs on each report that arrives through the portal or a batch upload. It suggests a summary, a severity, a type, a CVSS score, an Article 14 risk and possible duplicates. A person applies each suggestion. It does not assign the report, it does not make the remediation decision, and it does not acknowledge on your behalf.
Step 12. Publish the advisory, then close the report
When the Fix stage is done, an admin clicks Draft public advisory in Public Advisory. You do not have to close the report first. The draft is a template, and the panel warns that the summary is a copy of the report text. Edit the summary before you click Publish, so that the public page does not show reproduction detail. An Accept decision needs no advisory.
Only an admin can close a report. In Close Report, enter the reason in 10 to 500 characters. Click Mark resolved when the vulnerability is fixed. Click Dismiss when the report is out of scope or not a vulnerability. For a duplicate, use Mark as duplicate, see Duplicate Reports. A dismissed or duplicate report needs no advisory.
Completion checklist
Per report.
- Acknowledged inside the SLA target
- CVSS scored and applied to the submission
- Coordinator assigned
- Further information requested if the report was incomplete
- Affected components established and marked
- Upstream maintainer notified where the component is third-party, per Article 13(6)
- Communication log reflects every substantive exchange
- Remediation decision recorded with rationale, target date and owner
- Article 14 assessed, and SOP-04 followed if triggered
- Advisory published where the fix is public
- Report resolved or dismissed with a reason
Where this connects
- SOP-04 takes over the moment a report is classified as actively exploited or a severe incident.
- SOP-06 covers version-accurate component matching, which is the reliable way to answer "are we affected".
- SOP-01 covers the SLA targets that the first two steps here are measured against.