Vulnerability Reporting Process (Internal SOP)

Document Title: Vulnerability Reporting Process — Standard Operating Procedure Document Owner: [HEAD OF PRODUCT SECURITY / CISO] Version: [1.0] Effective Date: [DATE] Review Cycle: Annual, or upon material change to CRA implementing acts

Purpose

This SOP defines the standard process by which [COMPANY NAME]'s product security team receives, triages, remediates, and publishes information about security vulnerabilities affecting [COMPANY NAME] products. It operationalises the commitments made in [COMPANY NAME]'s public CVD Policy ([PUBLIC POLICY URL]).

Scope

This SOP applies to:

• All inbound vulnerability reports received via [PORTAL URL], [SECURITY EMAIL], or escalated from customer support or sales
• Vulnerabilities discovered internally by [COMPANY NAME] security teams or in third-party security assessments
• Vulnerabilities in upstream open-source or commercial components that affect [COMPANY NAME] products
• Any security incident that may constitute an Article 14 reportable event

Out of Scope: Vulnerabilities in infrastructure operated by third-party cloud providers where [COMPANY NAME] has no remediation authority.

Step 1 — Receipt and Logging (Owner: [SECURITY OPERATIONS / PSIRT TIER 1])

Upon receipt of a vulnerability report:

1. Log the report in [TRACKING SYSTEM, e.g. Jira / Linear / CVD Portal] within 2 hours of receipt during business hours, or by 09:00 on the next business day for off-hours reports
2. Assign a tracking ID using the format [VULN-YYYY-NNNN]
3. Send acknowledgment to reporter within 48 hours of receipt (use acknowledgment template [LINK])
4. Tag the report with initial classification: [RESEARCHER / CUSTOMER / INTERNAL / AUTOMATED SCAN / BUG BOUNTY]

Step 2 — Eligibility Check (Owner: [PSIRT TIER 1])

Within 1 business day of logging, assess:

• Is the reported product within scope of the public CVD policy?
• Is the reported version still supported?
• Does the report describe a security vulnerability (vs. a bug or feature request)?

If out of scope or not a security issue: close with explanation, use closure template [LINK]. If in scope: proceed to Step 3.

Step 3 — Technical Triage (Owner: [PSIRT TIER 2 / PRODUCT SECURITY ENGINEER])

Within 5 business days of acknowledgment:

1. Attempt to reproduce the reported behaviour in a test environment
2. Confirm the vulnerability exists and identify the affected component(s)
3. Assign preliminary CVSS 4.0 base score (see Section 3)
4. Identify whether the vulnerability is already publicly known (search NVD, vendor advisories, GitHub security advisories)
5. Route to the responsible product engineering team via [ROUTING PROCESS]

Scoring Standard: [COMPANY NAME] uses CVSS 4.0 as its primary severity scoring system. CVSS 3.1 scores may be provided for backward compatibility.

Scoring Responsibility: The assigned PSIRT Tier 2 engineer performs initial scoring. For Critical (9.0+) vulnerabilities, a second engineer must independently review and agree the score before it is finalised.

Severity Bands and SLA:

| CVSS Score | Rating | Patch SLA | Escalation | |------------|--------|-----------|------------| | 9.0–10.0 | Critical | [15] calendar days | CISO + VP Engineering same day | | 7.0–8.9 | High | [30] calendar days | Head of Product Security | | 4.0–6.9 | Medium | [60] calendar days | Assigned engineer | | 0.1–3.9 | Low | [90] calendar days | Backlog |

Scoring Adjustments:

The PSIRT may adjust the effective priority (not the CVSS base score) upward based on:

• Active exploitation confirmed in the wild → treat as Critical regardless of CVSS
• Vulnerability affects a safety-critical function → treat as Critical regardless of CVSS
• Vulnerability is in a product with very large installed base → increase urgency by one band
• Proof of concept publicly available → increase urgency by one band

EPSS: Where available, consult the Exploit Prediction Scoring System (EPSS) score alongside CVSS to assess exploitation likelihood.

Step 4 — Remediation Assignment (Owner: [HEAD OF PRODUCT SECURITY])

For confirmed vulnerabilities, create a remediation ticket in [ENGINEERING TRACKING SYSTEM] and assign to the responsible product engineering team. The ticket must include:

• PSIRT tracking ID and link
• CVSS score and severity band
• Patch SLA deadline
• Reporter coordination status (embargo, public policy, etc.)
• Draft CVE details (see Section 6)

Step 5 — Fix Development (Owner: [PRODUCT ENGINEERING TEAM])

1. Develop a fix that addresses root cause, not just the reported symptom
2. Conduct security code review of the fix prior to merge
3. Write regression test to prevent re-introduction
4. For Critical/High: conduct fuzzing or targeted penetration test on the fixed component before release
5. Communicate fix-ready status to PSIRT at least [5] business days before planned release to allow advisory preparation

Step 6 — Release Coordination (Owner: [PSIRT + PRODUCT ENGINEERING])

1. Coordinate release date with reporter (offer advance notification of patch under embargo)
2. Prepare customer-facing advisory (see Section 6)
3. Confirm update delivery mechanism (OTA, download portal, package repository)
4. For Critical vulnerabilities: notify major enterprise customers of upcoming patch under embargo [X] days prior to release

When to Apply Article 14 Assessment

At the point of triage (Step 3), and again upon any material change in understanding of the vulnerability, the PSIRT must assess whether Article 14 mandatory notification applies.

Article 14 Triggers (assess ALL of the following):

[ ] Is the vulnerability actively being exploited in the wild? (confirmed or credibly reported) [ ] Does the vulnerability constitute a 'severe security incident' as defined in Article 14? — Severe security incident indicators: significant service disruption, unauthorised access to sensitive data, potential for significant financial harm, or impact on critical infrastructure

If ANY trigger is checked YES:

1. Escalate immediately to [HEAD OF PRODUCT SECURITY] and [CISO]
2. Complete Early Warning notification to ENISA (or national CSIRT) within 24 hours of awareness — Use the Article 14 Early Warning template [LINK] — Submit via ENISA Single Reporting Platform (SRP): [ENISA SRP URL]
3. Complete Full Notification to ENISA within 72 hours of awareness — Use the Article 14 Full Notification template [LINK]
4. Submit Final Report to ENISA within 14 days (or extended period agreed with ENISA) — Include root cause analysis and permanent mitigation measures

If NO triggers apply: Continue standard CVD process. Document the Article 14 assessment in the tracking ticket with timestamp (required for CRA audit).

Uncertainty: If you are unsure whether Article 14 applies, treat it as applying and escalate. It is easier to withdraw a precautionary early warning than to explain a missed notification.

Step 7 — Advisory Preparation (Owner: [PSIRT])

For all Medium severity and above vulnerabilities, prepare a security advisory prior to patch release.

Advisory Contents:

| Field | Requirement | |-------|-------------| | CVE ID | Required (request from [CNA / MITRE] at triage stage) | | CVSS score | Required (4.0 base score; 3.1 optional) | | CWE category | Required | | Affected products | Required (product name, model, firmware/software version range) | | Fixed version | Required | | Vulnerability description | Required (do not include reproduction steps or PoC) | | Workaround | Required if patch is not yet available | | Reporter credit | Required if reporter consented | | CSAF advisory | Strongly recommended |

CSAF Publication:

Publish the advisory in CSAF 2.0 format at [CSAF FEED URL]. Update the CSAF provider-metadata.json file to include the new advisory. Notify [CSAF AGGREGATORS / BSIFEED] upon publication if applicable.

Advisory Review:

All advisories must be reviewed by:

• [PSIRT LEAD] for technical accuracy
• [LEGAL / COMMUNICATIONS] for language and liability review
• For Critical advisories: [CISO] sign-off required

Publication Timing: Advisories are published simultaneously with or after the patch release. They must never be published before the patch is available to all customers.

Step 8 — Closure (Owner: [PSIRT])

Close a vulnerability ticket only when ALL of the following are complete:

[ ] Patch released to all affected customers [ ] Advisory published [ ] CVE published in NVD (or submission confirmed) [ ] Reporter notified of closure and invited to verify fix [ ] Any Article 14 notifications completed (if applicable) [ ] Ticket updated with all final details and closure date

Reporter Final Communication:

Send reporter a closure communication including: advisory URL, CVE ID, and credit text (if applicable). Invite the reporter to confirm the fix resolves the issue within [14] days.

Post-Mortem (Critical and High vulnerabilities):

For Critical and High severity vulnerabilities, conduct a post-mortem within [30] days of closure:

1. What was the root cause of the vulnerability?
2. How long was the vulnerability present in the codebase (vulnerability age)?
3. Why was it not caught by existing security controls (SAST, code review, penetration testing)?
4. What control improvements are needed?
5. Were SLAs met? If not, why?

Document post-mortem findings in [POST-MORTEM SYSTEM] and assign any resulting action items to the appropriate team with owners and deadlines.

Retention Policy

[COMPANY NAME] retains all vulnerability-related records for a minimum of [5] years from the date of closure, or for the supported lifetime of the affected product, whichever is longer.

Records to Retain:

• Original reporter communication (including timestamps)
• All internal and external communications during the vulnerability lifecycle
• Triage notes and severity assessments (including CVSS scoring rationale)
• Article 14 assessment decisions and supporting evidence
• Article 14 notifications submitted to ENISA (copies)
• Remediation tickets and commit references
• Advisory publication records and CSAF files
• Post-mortem reports

Audit-Ready Evidence Package:

For each closed vulnerability of Medium severity or higher, maintain an evidence package containing:

1. Timeline from report receipt to closure
2. CVSS score and rationale
3. Article 14 assessment outcome and basis
4. Advisory publication URL and date
5. CVE ID

Data Handling: Vulnerability records containing personally identifiable information about reporters must be handled in accordance with [COMPANY NAME]'s Privacy Policy ([LINK]) and applicable GDPR obligations. Reporter identity should be separated from technical vulnerability records where possible.

Access Control: Vulnerability records are classified [CONFIDENTIAL / RESTRICTED] and accessible only to [PSIRT TEAM MEMBERS, CISO, LEGAL]. Access logs are retained.