What is the difference between this document and our public CVD policy?

Your public CVD policy tells external researchers what to expect when they report a vulnerability. This internal process document tells your team exactly how to handle reports operationally. Both are required - the public policy without internal process leads to disorganised handling; internal process without a public policy means researchers have nowhere to report.

Who should have access to this document?

This document should be accessible to all members of the PSIRT, engineering leads, CISO, and legal counsel. It should be version-controlled and reviewed at least annually.

How do we handle reports that arrive outside business hours?

Define an on-call rotation for your PSIRT lead or security contact. At minimum, ensure the security email alias is monitored and that there is a clear escalation path for Critical issues that arrive outside business hours. The 24-hour Article 14 early warning window does not pause for weekends.

What if we discover a vulnerability internally rather than through a researcher report?

Internally discovered vulnerabilities should follow the same process from Step 2 onwards. Create a ticket, assign a severity, and apply the same remediation and disclosure SLAs. Article 14 obligations apply regardless of how the vulnerability was discovered.

How do we get a CVE identifier?

You can request a CVE through MITRE's CVE Request form, or through a CVE Numbering Authority (CNA) that covers your product domain. If you are a software publisher, consider becoming a CNA yourself to control your own CVE assignment. CVD Portal can assist with CVE request documentation.

← All templates

Free Template

Vulnerability Reporting Process Template

An internal-facing vulnerability reporting process that documents how your security team handles incoming reports from intake through resolution. Complements your public CVD policy with operational procedures aligned to CRA Article 13 and 14.

Article 13 · Article 14

ForSecurity operations teams, PSIRTs, and engineering managers who need a documented internal process for handling vulnerability reports

CRA Articles

Article 13Article 14

Purpose

Article 13

This document describes the internal process by which [COMPANY NAME] receives, triages, remediates, and discloses security vulnerabilities in its products and services. It is an internal operational document that supports our public Coordinated Vulnerability Disclosure Policy.

This process applies to all vulnerability reports received from external researchers, customers, partners, automated scanning tools, and internal discovery.

Note

This is an internal document, not the public-facing policy. Keep it specific and operational. Vague processes are not followed - concrete steps with owners and deadlines are.

Step 1 - Intake and Acknowledgment

Article 13(1)

Owner: [SECURITY CONTACT / PSIRT LEAD] SLA: 48 hours from receipt

All incoming vulnerability reports are received via:

The vulnerability disclosure portal at [PORTAL URL]
The security email alias [[email protected]]
Escalations from customer support (tagged [SECURITY-ESCALATION])

Actions:

Log the report in [ISSUE TRACKER / TICKETING SYSTEM] under the 'Vulnerability Reports' project.
Assign a unique identifier (e.g. VUL-YYYY-NNNN).
Send acknowledgment to the reporter within 48 hours using the acknowledgment template in [TEMPLATE LOCATION].
If the report appears to be spam or not a security issue, close with a polite explanation and log the decision.

Note

Every report must be logged, even invalid ones. This creates an audit trail that demonstrates you have a functioning programme under CRA Article 13. Assign an ID immediately - it prevents duplicate handling and helps cross-reference with CVEs later.

Step 2 - Initial Triage

Article 13, Article 14

Owner: [SECURITY ENGINEER / PSIRT MEMBER] SLA: 5 business days from receipt

Actions:

Attempt to reproduce the vulnerability in a controlled environment.
Assign an initial CVSS 3.1 or 4.0 base score.
Classify the vulnerability:
- Critical (CVSS 9.0–10.0): Escalate immediately to PSIRT lead and engineering VP
- High (CVSS 7.0–8.9): Assign to product security team within 1 business day
- Medium (CVSS 4.0–6.9): Add to current sprint planning cycle
- Low (CVSS 0.1–3.9): Schedule for next minor release
Determine if the vulnerability is actively being exploited in the wild.
If actively exploited or constitutes a severe security incident: trigger Article 14 Escalation (see Step 3a).
Update the ticket with triage outcome and communicate to reporter.

Note

Severity classification drives your remediation SLAs and determines whether Article 14 notification is required. Document your CVSS scoring rationale - auditors will ask.

Step 3a - Article 14 Escalation (if applicable)

Article 14

Trigger: Vulnerability is actively exploited in the wild, OR constitutes a severe security incident as defined under CRA Article 14.

Owner: [PSIRT LEAD / CISO] SLA: Act within 1 hour of determination

Actions:

Notify the PSIRT lead, CISO, and legal counsel immediately.
Submit an early warning to ENISA via the Single Reporting Platform (SRP) within 24 hours of becoming aware.
Submit a full notification to ENISA within 72 hours including: product details, CVSS score, affected user population, and initial mitigation steps.
Coordinate with national CSIRT ([NATIONAL CSIRT NAME]) if required.
Submit a final report to ENISA within 14 days (or agreed extended period) including root cause analysis and remediation steps.
Log all ENISA submissions and reference numbers in the vulnerability ticket.

Note

Article 14 escalation must be documented and rehearsed - it is a compliance obligation, not a best practice. The 24-hour early warning window is extremely tight. Assign a named owner and ensure they know where to find the ENISA SRP credentials.

Step 3b - Remediation

Article 13

Owner: [ENGINEERING LEAD for affected product] SLA: Based on severity

| Severity | Patch SLA | |---|---| | Critical | 7 days | | High | 30 days | | Medium | 90 days | | Low | Next minor release |

Actions:

Create a tracked engineering issue linked to the vulnerability ticket.
Develop and test the fix in a private branch.
Request security review of the patch from [SECURITY TEAM].
Obtain CVE identifier from [CVE Numbering Authority / MITRE] if applicable.
Prepare draft security advisory using the advisory template at [TEMPLATE LOCATION].
Notify reporter of expected patch date and request confirmation of fix.

Note

Remediation SLAs must be realistic and actually enforced. If your team consistently misses them, revise them rather than ignoring them - indefensible SLAs are worse than honest ones.

Step 4 - Disclosure and Advisory Publication

Annex I, Article 13

Owner: [PSIRT LEAD / SECURITY COMMUNICATIONS] SLA: Publish advisory on or before patch release

Actions:

Finalise the security advisory (CVE ID, CVSS score, affected versions, fix version, acknowledgment).
Publish advisory at [ADVISORY URL] in both HTML and CSAF 2.0 format.
Distribute advisory via [EMAIL LIST / RSS / SECURITY MAILING LIST].
Notify the reporter that the issue is resolved and the advisory is published.
Close the vulnerability ticket with reference to the published advisory.
Update the public [ACKNOWLEDGMENTS PAGE] if the reporter has consented to credit.
Conduct a 30-day post-incident review for Critical and High severity issues.

Note

Publish the advisory at the same time as the patch - not before. CSAF 2.0 publication is increasingly expected by enterprise customers and aligns with CRA Annex I. CVD Portal generates CSAF 2.0 automatically.

Roles and Responsibilities

Article 13(1)

| Role | Responsibility | |---|---| | PSIRT Lead | Overall process ownership; Article 14 escalation authority | | Security Engineer | Triage, reproduction, CVSS scoring | | Engineering Lead | Patch development and release | | CISO | Escalation for Critical issues; ENISA communications | | Legal Counsel | Notified for all Critical issues; advises on safe harbour | | Security Communications | Advisory drafting and publication |

PSIRT Contact: [NAME], [EMAIL], [PHONE] Backup contact: [NAME], [EMAIL]

Note

Named owners with backup contacts are essential. When a Critical vulnerability lands, you do not want to be searching for who is responsible. Review this list whenever there is a staff change.

Use this template automatically in CVD Portal

CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free for Article 14 compliance.

Set up your free portal

Frequently asked questions

Ready to go beyond the template?

CVD Portal automates acknowledgments, tracks deadlines, and generates CSAF advisories — free.

Set up your free portal

Related templates

Coordinated Vulnerability Disclosure Policy Template

A complete coordinated vulnerability disclosure policy following ISO/IEC 29147 best practice and CRA Article 13. Covers the full disclosure lifecycle: intake, triage, remediation, and coordinated publication.

CRA-Compliant CVD Policy Template

A comprehensive CVD policy structured specifically for the EU Cyber Resilience Act. Addresses Articles 13 and 14 obligations including 24-hour early warning, 72-hour full notification, and coordinated disclosure timelines.

PSIRT Charter Template

A formal charter for establishing or formalising a Product Security Incident Response Team (PSIRT). Defines the team's mandate, authority, scope, membership, and operating procedures under the EU Cyber Resilience Act and ISO/IEC 30111.

Article 14 Early Warning Notification Template

A structured notification template for the CRA Article 14 24-hour early warning obligation. Designed to be submitted to ENISA (or the relevant national CSIRT) when a manufacturer discovers an actively exploited vulnerability or severe security incident.