Does the CRA require us to have a formal PSIRT?

The CRA does not mandate the term 'PSIRT', but Article 13 requires manufacturers to have a policy for handling vulnerability disclosures, a single point of contact, and documented processes for receiving, assessing, and responding to reports. A formal PSIRT charter is the best way to demonstrate you have these capabilities in place.

How large does a PSIRT need to be?

Size depends on your product portfolio and vulnerability volume. Small organisations often have a virtual PSIRT of 2–3 people with defined roles. What matters is that every role has a named person and backup, and that the escalation path is clear. A lean, well-documented PSIRT is more effective than a large, undefined one.

What is the difference between a PSIRT and a CSIRT?

A PSIRT (Product Security Incident Response Team) focuses on vulnerabilities in the products your organisation makes. A CSIRT (Computer Security Incident Response Team) typically focuses on incidents affecting your own infrastructure. Many organisations have both. The CRA primarily creates PSIRT obligations - you must handle vulnerabilities in what you sell.

Should the PSIRT charter be public?

The charter is typically an internal governance document. Your public-facing CVD policy is what researchers and customers see. However, referencing the existence of your PSIRT in your public policy and on your security page builds credibility.

What standards should our PSIRT align to?

The primary standards are ISO/IEC 30111 (vulnerability handling processes) and ISO/IEC 29147 (vulnerability disclosure). FIRST (Forum of Incident Response and Security Teams) also publishes PSIRT services framework documentation. The CRA references these standards implicitly through its Article 13 requirements.

← All templates

Free Template

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 13 · Article 14 · Annex I

ForCISOs, security managers, and engineering leaders at organisations that manufacture products with digital elements and need to formally establish a PSIRT function

CRA Articles

Article 13Article 14Annex I

Charter Purpose and Authority

Article 13(1)

This charter establishes the [COMPANY NAME] Product Security Incident Response Team (PSIRT) and defines its mandate, authority, scope, and operating procedures.

The [COMPANY NAME] PSIRT is formally authorised by [CISO / CTO / BOARD] to act as the central function responsible for managing security vulnerabilities and incidents affecting [COMPANY NAME] products. The PSIRT operates under the authority of the [CISO / EXECUTIVE SPONSOR] and has the authority to escalate to any business unit necessary to protect [COMPANY NAME] customers.

This charter is effective as of [DATE] and supersedes any prior informal arrangements for vulnerability management.

Note

A PSIRT without explicit executive authority is ineffective. The charter must name the executive sponsor and make clear that the PSIRT can compel action from engineering, legal, and communications. Board or C-suite sign-off signals that security is taken seriously.

Scope

Article 13

The [COMPANY NAME] PSIRT is responsible for security vulnerabilities and incidents affecting:

All [COMPANY NAME] products with digital elements placed on the EU market
All [COMPANY NAME] cloud services, APIs, and associated infrastructure
Open-source components maintained by [COMPANY NAME]

Out of scope:

Physical security incidents (handled by [FACILITIES / CORPORATE SECURITY])
Data breaches not involving product vulnerabilities (handled by [PRIVACY / LEGAL TEAM])
Vulnerabilities in third-party products not distributed by [COMPANY NAME]

The PSIRT coordinates with adjacent teams for overlapping incidents.

Note

A clear scope prevents both gaps and conflicts. Where scope overlaps with other teams (e.g. data breach response, physical security), define the handoff explicitly. Unclear scope leads to incidents falling through the cracks.

PSIRT Membership and Roles

Article 13(1), Article 14

Core PSIRT Members

| Role | Name | Contact | Backup | |---|---|---|---| | PSIRT Lead | [NAME] | [EMAIL / PHONE] | [BACKUP NAME] | | Security Engineer | [NAME] | [EMAIL] | [BACKUP NAME] | | Engineering Liaison | [NAME] | [EMAIL] | [BACKUP NAME] | | Legal Counsel (advisory) | [NAME] | [EMAIL] | [BACKUP NAME] | | Communications Lead | [NAME] | [EMAIL] | [BACKUP NAME] |

Extended PSIRT Members (engaged as needed)

Product managers for affected product lines
Customer success and support leads
External security advisors or researchers

PSIRT Lead responsibilities: Day-to-day PSIRT operations, Article 14 escalation authority, external communications with ENISA and national CSIRTs, final decision on disclosure timing.

Note

Every role needs a named backup. PSIRT incidents do not wait for holiday returns. Review membership annually and whenever there is a staff change. The PSIRT Lead must have explicit Article 14 authority - this is a compliance requirement, not a preference.

Operating Procedures

Article 13, Article 14

The PSIRT operates according to the following lifecycle:

Intake - All vulnerability reports are received via the official disclosure portal or security alias and logged within 48 hours.
Triage - Severity is assessed using CVSS 3.1 or 4.0 within 5 business days. Article 14 triggers are assessed at this stage.
Remediation - Engineering is engaged with a target patch date based on severity SLAs.
Article 14 notification - If triggered, ENISA early warning within 24 hours, full notification within 72 hours.
Advisory publication - CSAF 2.0 advisory published at patch release.
Post-incident review - Conducted for all Critical and High severity vulnerabilities within 30 days of closure.

Full operational procedures are documented in the [VULNERABILITY REPORTING PROCESS DOCUMENT LOCATION].

Note

The charter should reference the full process document rather than repeat it in detail. Keep the charter strategic; keep the process document operational. This makes both easier to maintain.

Severity Classification and SLAs

Article 13, Article 14

The PSIRT classifies vulnerabilities using CVSS base scores:

| Severity | CVSS Range | Patch SLA | Escalation | |---|---|---|---| | Critical | 9.0–10.0 | 7 days | CISO + Engineering VP immediately | | High | 7.0–8.9 | 30 days | PSIRT Lead within 24 hours | | Medium | 4.0–6.9 | 90 days | Standard sprint planning | | Low | 0.1–3.9 | Next minor release | Scheduled |

Article 14 notification is triggered when a vulnerability is actively exploited in the wild, or constitutes a severe security incident, regardless of CVSS score.

Note

SLAs must be achievable. If Critical issues cannot realistically be patched in 7 days, adjust - but document your reasoning. Regulators will expect you to justify SLAs that are significantly longer than industry norms.

External Coordination

Article 14

[COMPANY NAME] PSIRT coordinates with the following external parties as required:

ENISA - Mandatory notification under CRA Article 14 via the Single Reporting Platform (SRP)
National CSIRT ([COUNTRY CSIRT NAME and URL]) - Coordination on vulnerabilities affecting critical infrastructure or national security
Upstream component vendors - For vulnerabilities originating in third-party components
CVE Programme / MITRE - For CVE identifier assignment
Security researchers - Via our public CVD policy at [PUBLIC POLICY URL]
Sector-specific authorities - [ENISA / NCB / SECTOR REGULATOR] as applicable

The PSIRT Lead is the sole authorised spokesperson for external communications regarding product vulnerabilities.

Note

Naming the external coordination contacts in the charter prevents delays when an incident occurs. Knowing which CSIRT to contact and having the ENISA SRP credentials ready are table-stakes for CRA compliance.

Charter Review and Maintenance

Article 13

This charter will be reviewed:

Annually by the PSIRT Lead and CISO
Following any Critical severity incident
Following material changes to [COMPANY NAME] product portfolio
Following regulatory updates to the EU Cyber Resilience Act implementing acts

All revisions will be version-controlled and approved by [CISO / EXECUTIVE SPONSOR]. The current version of this charter is maintained at [INTERNAL LOCATION].

Version: [1.0] Effective date: [DATE] Next review: [DATE + 12 months]

Note

An unreviewed charter becomes stale and unusable. Make review a standing agenda item in your annual security governance calendar. Post-incident reviews often surface charter gaps - capture them immediately.

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

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.

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.

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.