PSIRT Charter Template
A PSIRT charter template that defines team mandate, authority, responsibilities, escalation paths, and interaction with Article 13/14 obligations. Based on the FIRST PSIRT Services Framework and CRA requirements, this charter is designed to be a formal governance document ratified at executive level.
Mission Statement
Article 13PSIRT Charter [COMPANY NAME] Product Security Incident Response Team
Version: [1.0] Ratified by: [CISO / CTO / BOARD SECURITY COMMITTEE] Effective Date: [DATE] Review Cycle: Annual
Mission
The [COMPANY NAME] Product Security Incident Response Team (PSIRT) exists to protect the security and integrity of [COMPANY NAME] products and the users and organisations that depend on them.
The PSIRT's mission is to:
- Receive, triage, and coordinate the remediation of security vulnerabilities affecting [COMPANY NAME] products with digital elements
- Ensure that [COMPANY NAME] meets its obligations under the EU Cyber Resilience Act (CRA), including Articles 13 and 14
- Communicate transparently with the security research community, customers, and regulators
- Drive continuous improvement in [COMPANY NAME]'s product security posture
The PSIRT operates in accordance with the FIRST PSIRT Services Framework and ISO/IEC 29147 (Vulnerability disclosure) and ISO/IEC 30111 (Vulnerability handling processes).
Executive ratification of the charter gives the PSIRT formal authority to direct engineering teams and engage with legal, communications, and external parties. Without this authority, PSIRTs often lack the organisational standing to enforce SLAs. Reference FIRST PSIRT Services Framework to anchor the charter in an internationally recognised standard.
Scope & Constituency
Article 13, Article 152.1 Products in Scope
The PSIRT's authority and responsibility extends to all [COMPANY NAME] products with digital elements placed or made available on the EU market, including:
- [PRODUCT LINE 1] (all active versions)
- [PRODUCT LINE 2] (all active versions)
- Associated cloud services, APIs, and mobile applications
- Third-party and open-source components integrated into [COMPANY NAME] products
Products at end-of-life are subject to a transition period as defined in the [SUPPORT LIFECYCLE POLICY URL].
2.2 Constituency
The PSIRT serves the following stakeholders:
- External security researchers and bug bounty participants
- [COMPANY NAME] customers and partners reporting vulnerabilities
- Internal engineering teams requiring security guidance during remediation
- [COMPANY NAME] leadership requiring timely awareness of significant security incidents
- Regulators and national CSIRTs receiving Article 14 notifications
2.3 Relationship to the Corporate Security Team
The PSIRT is a function within [REPORTING STRUCTURE, e.g. the Office of the CISO / Product Engineering]. It operates independently from the Corporate Security (IT/infrastructure) team but coordinates closely with it on matters involving both product and infrastructure (e.g. a vulnerability in a product that also affects internal systems).
Explicitly scoping the PSIRT to all EU-market products is important for CRA compliance — regulators will look at whether your security team has coverage of all in-scope products. The distinction between Product Security (PSIRT) and Corporate Security (IT) is a common source of confusion; resolving it in the charter prevents scope disputes.
Team Structure & Roles
Article 13, Article 143.1 PSIRT Composition
| Role | Headcount | Responsibilities | |------|-----------|------------------| | PSIRT Lead | [1] | Charter owner; final escalation authority; regulatory engagement | | PSIRT Engineer (Tier 2) | [N] | Technical triage; CVSS scoring; remediation coordination | | PSIRT Analyst (Tier 1) | [N] | Report intake; acknowledgment; eligibility triage | | PSIRT Programme Manager | [1] | SLA tracking; metrics; reporter communications |
3.2 On-Call Coverage
The PSIRT operates business-hours coverage as standard. On-call coverage for Critical severity vulnerabilities and Article 14-reportable incidents is provided by [ON-CALL ROTA SYSTEM / PAGERDUTY]. The on-call engineer has authority to initiate emergency escalation outside business hours.
3.3 Extended Team
The PSIRT works with the following extended team members who are not full-time PSIRT staff but are called upon for specific functions:
- Product Engineering Leads — one nominated security contact per product line ([LIST CONTACTS])
- Legal Counsel — [CONTACT] — for safe harbour disputes, legal threats, and regulatory correspondence
- Communications / PR — [CONTACT] — for customer-facing advisory language and media inquiries
- Privacy / Data Protection Officer — [CONTACT] — for vulnerabilities involving personal data
3.4 Deputy
In the absence of the PSIRT Lead, authority and responsibilities pass to [DEPUTY PSIRT LEAD]. This applies to Article 14 notification authority.
Defining a deputy for the PSIRT Lead is not optional — CRA obligations do not pause for holidays or illness. The extended team model avoids the PSIRT becoming a bottleneck by embedding security contacts in product engineering teams who handle first-line product questions.
Authority & Escalation
Article 14, Article 154.1 PSIRT Authority
The PSIRT Lead has the authority to:
- Declare a Security Incident — formally elevate a vulnerability to incident status, triggering the incident response plan ([IRP LINK])
- Direct engineering teams to prioritise vulnerability remediation in accordance with PSIRT-assigned SLAs, overriding routine sprint planning if necessary
- Embargo information — place internal and external communication under embargo pending coordinated disclosure
- Engage directly with ENISA or national CSIRT for Article 14 notifications without requiring separate executive approval for each notification
- Authorise security advisories for publication
- Engage external parties — legal, PR, or specialist incident response firms — up to [€X / £X] without separate procurement approval in emergency situations
4.2 Escalation Paths
| Situation | Escalation Target | Escalation Timeline | |-----------|-------------------|---------------------| | Critical vulnerability | Head of Engineering + CISO | Same business day | | Article 14 trigger confirmed | CISO + Legal Counsel | Within 2 hours | | Active exploitation in the wild | CEO + CISO + Legal | Within 1 hour | | Reporter threatening legal action | Legal Counsel + CISO | Immediately | | Media inquiry about a vulnerability | Communications + CISO | Immediately | | Disagreement with engineering on SLA | Head of Engineering → CISO | Within 24 hours |
4.3 Non-Escalation Principle
The PSIRT is empowered to make routine decisions — acknowledgment, severity scoring, advisory publication, Article 14 assessment for standard cases — without escalation. Over-escalation dilutes the effectiveness of escalation paths for genuine emergencies.
Granting the PSIRT Lead direct authority to file Article 14 notifications without per-instance executive approval is essential for meeting the 24-hour early warning deadline. The non-escalation principle prevents the common failure mode where nothing can happen without a senior approval chain.
CVD Programme Responsibilities
Article 135.1 Public CVD Policy
The PSIRT owns and maintains [COMPANY NAME]'s public CVD Policy at [POLICY URL]. The policy must be reviewed annually and updated within [30] days of any material change to products in scope or CRA implementing acts.
5.2 Reporting Channels
The PSIRT owns:
- The vulnerability disclosure portal at [PORTAL URL]
- The [[email protected]] email address
- The security.txt file at https://[DOMAIN]/.well-known/security.txt
- The public CSAF advisory feed at [CSAF FEED URL]
5.3 CVE Programme
[COMPANY NAME] is [a CVE Numbering Authority (CNA) / participates in the CVE programme via [CNA NAME]]. The PSIRT Lead is the designated CNA coordinator. The PSIRT is responsible for:
- Requesting CVE IDs for confirmed vulnerabilities in [COMPANY NAME] products
- Publishing CVE records to the NVD within [X] days of advisory publication
- Maintaining the accuracy of published CVE records
5.4 Bug Bounty Programme
The PSIRT coordinates with [COMPANY NAME]'s bug bounty programme on [PLATFORM, e.g. HackerOne / Intigriti]. The PSIRT Lead sets and reviews bounty scope and reward structures [QUARTERLY / ANNUALLY]. All bug bounty reports are processed through the standard CVD SOP.
Assigning ownership of each reporting channel to the PSIRT prevents the common situation where a security.txt file goes stale or a disclosure portal becomes unmaintained. CNA status is a meaningful signal of product security maturity and is increasingly expected by enterprise procurement.
Article 14 Reporting Ownership
Article 146.1 Designated Reporting Authority
The PSIRT Lead is the designated authority for Article 14 notifications to ENISA. In the PSIRT Lead's absence, the Deputy PSIRT Lead holds this authority.
6.2 Article 14 Assessment
The PSIRT is responsible for conducting an Article 14 assessment for every confirmed vulnerability of High severity or above, and for every report claiming active exploitation. The assessment must be documented and retained.
6.3 Notification Process
Where an Article 14 trigger is confirmed:
- PSIRT Lead notifies CISO and Legal within 2 hours
- PSIRT Lead or delegate prepares Early Warning using the ENISA notification template within 24 hours of awareness
- PSIRT Lead or delegate submits Early Warning via ENISA Single Reporting Platform (SRP)
- PSIRT prepares Full Notification within 72 hours
- PSIRT prepares Final Report within 14 days (or agreed extension)
6.4 Coordination with National CSIRT
For incidents affecting critical infrastructure or where the national CSIRT has jurisdiction under NIS2, the PSIRT Lead will liaise with [NATIONAL CSIRT, e.g. BSI / ANSSI / NCSC] in addition to ENISA.
6.5 Record Keeping
All Article 14 notifications and supporting documentation are retained by the PSIRT for [5] years and stored in [SECURE STORAGE SYSTEM].
Designating a named individual (not just a team) as the Article 14 reporting authority is essential for accountability. The 24-hour deadline is not achievable without a pre-defined process — this section ensures the process is documented before an incident occurs, not during it.
Interaction with Legal & Communications
Article 13, Article 147.1 Legal Counsel
Legal Counsel is engaged by the PSIRT in the following circumstances:
- Any vulnerability that may constitute an Article 14 reportable event
- Receipt of legal threats from reporters or third parties related to security research
- Requests for information from regulators or law enforcement about a vulnerability
- Vulnerabilities involving potential GDPR-reportable personal data breaches
- Proposed changes to safe harbour language in the public CVD policy
Legal Counsel does not have authority to delay or prevent Article 14 notifications that the PSIRT Lead has determined are required.
7.2 Communications & PR
Communications is engaged in the following circumstances:
- Any vulnerability likely to receive public or media attention (CVSS 9.0+, active exploitation, or significant customer impact)
- Preparation of customer-facing advisories for Critical and High vulnerabilities
- Preparation of responses to media inquiries about vulnerabilities
All externally published advisory language must be approved by Communications and Legal before publication. Target review time: [4 hours] for Critical, [2 business days] for High.
7.3 Non-Interference Principle
Neither Legal nor Communications may direct the PSIRT to (a) delay publication of a security advisory beyond the committed coordinated disclosure timeline, or (b) suppress technical accuracy in a security advisory. Disagreements on these matters escalate to [CISO / CEO].
The non-interference principle is the most important element of this section. Legal and PR teams sometimes pressure PSIRTs to soften advisory language or delay disclosure for reputational reasons. Documenting this boundary in the charter gives the PSIRT explicit backing to resist inappropriate pressure.
Metrics & Review
Article 13, Article 14, Article 158.1 Key Performance Indicators
The PSIRT tracks and reports the following metrics [MONTHLY / QUARTERLY] to [CISO / BOARD SECURITY COMMITTEE]:
| Metric | Target | |--------|--------| | Acknowledgment within 48 hours | ≥ 99% | | Triage completion within 5 business days | ≥ 95% | | Critical patch SLA met | ≥ 90% | | High patch SLA met | ≥ 85% | | Article 14 early warning within 24 hours | 100% | | Article 14 full notification within 72 hours | 100% | | Reporter satisfaction (survey) | ≥ [4.0/5.0] | | Mean time to resolve (MTTR) by severity | [Tracked] |
8.2 Charter Review
This charter is reviewed annually by the PSIRT Lead and ratified by [CISO / BOARD SECURITY COMMITTEE]. The review considers:
- Changes to CRA implementing acts or ENISA guidance
- PSIRT performance against KPIs
- Post-mortem findings and systemic issues
- Benchmarking against FIRST PSIRT maturity model
8.3 External Assessment
[COMPANY NAME] commits to an external assessment of PSIRT capability against the FIRST PSIRT Services Framework every [2] years, or ahead of any significant regulatory audit.
Setting 100% targets for Article 14 timelines is correct — these are legal obligations, not aspirational KPIs. Reporter satisfaction surveys are underused but valuable; researchers who feel respected are more likely to continue reporting to you. External FIRST assessment is a credible signal of maturity for both regulators and enterprise customers.
Use this template automatically in CVD Portal
CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free, forever.
Set up your free portal