The FIRST PSIRT Services Framework, explained

FIRST's PSIRT Services Framework is a free, 91-page reference document — currently Version 1.1, dated Spring 2020 and marked TLP:WHITE (shareable without restriction) — that describes the services a Product Security Incident Response Team (PSIRT) can provide. Published by FIRST (the Forum of Incident Response and Security Teams), it is not a certifiable standard: it is a planning and training catalogue that most device makers draw on when they design, not audit, their vulnerability-handling team.

What the framework actually is

FIRST describes its Services Frameworks (PSIRT and the parallel CSIRT one) as "high level documents detailing possible services that computer incident response teams (CSIRTs) and product incident response teams (PSIRTs) may provide," developed "by recognized experts from the FIRST community" and driven by FIRST's Education Advisory Board. Its stated purpose is to "provide a foundation for the development of new training material," though FIRST notes it is "used in a much wider scope, for example when defining an initial service catalogue for new teams." A notice on page 2 is explicit about its status: the document describes what FIRST "believes are best practices," offered "for informational purposes only," with FIRST disclaiming liability for its use. That framing matters — unlike ISO/IEC 29147 or 30111, there is no certification or conformity scheme attached to it.

The four-level structure

The framework organises everything into four nested levels:

Level	Definition, per the framework	Role
Service Area	Groups "services related to a common aspect," to "facilitate understanding"	Top-level category
Service	"A set of recognizable, coherent actions towards a specific result on behalf of or for the constituency of an incident response team"	The unit most teams plan around
Function	"An activity or set of activities aimed at fulfilling the purpose of a particular service"; a function "might be shared and used in the context of several services"	Reusable building block
Sub-function	A lower-level activity performed as part of a function	Implementation detail

Each Service and Function is specified with a "Description" field and a "Purpose and Outcome" field — a consistent template throughout the document, which is one reason it gets reused as an audit or gap-analysis checklist even though it was written as training material.

Before the services: Strategic, Tactical and Operational foundations

Ahead of the six numbered Service Areas, the framework sets out foundational components an organisation needs "to plan, establish, and effectively operate a PSIRT," grouped as Strategic (for example Executive Sponsorship — obtaining buy-in and ongoing funding from the organisation's leadership — plus Charter, Organizational Model and Budget), Tactical, and Operational building blocks, with a closing step on Evaluation and Improvement: identifying metrics to assess how well the PSIRT is performing and where it should improve. The framework is explicit that the organisation's PSIRT reports to an executive who can confirm its authority, and that a PSIRT "report to an executive of the company" so that its findings carry weight.

The six Service Areas

Service Area	What it covers (per the framework's own section text)
1 — Stakeholder Ecosystem Management (named directly in the body text)	Engaging internal teams, the finder community, peer PSIRTs/coordinators and downstream customers; includes Internal Stakeholder Management, Finder Community Engagement, Incident Communications Coordination, Reward Finders with Recognition & Acknowledgement, and Stakeholder Metrics
2 — Vulnerability Discovery (named directly in the body text)	Intake of vulnerability reporting, identifying unreported vulnerabilities, monitoring for product-component vulnerabilities, and discovery metrics
3 — Vulnerability Triage and Analysis (named directly in the table of contents)	Vulnerability qualification, working with established finders, and vulnerability reproduction
4 (no extractable headline name; purpose quoted from its own section)	"Highlight the processes and mechanisms required to release and announce a remedy to stakeholders and downstream vendors," via Remedy Release Management Plan (4.1), Remediation (4.2), Incident Handling (4.3), and Vulnerability Release Metrics (4.4)
5 (no extractable headline name; purpose quoted from its own section)	"Provide transparency to stakeholders and partners through collaboration with finders, coordinators and downstream vendors to responsibly disclose vulnerabilities and fixes," via Notification (5.1), Coordination (5.2), Disclosure (5.3), and Vulnerability Metrics (5.4)
6 (no extractable headline name; summarised from its own intro)	Training needs for product security roles, which "can vary significantly across a corporation," via Training the PSIRT (6.1), Training the Development Team (6.2), Training the Validation Team (6.3), Continuing Education for all Stakeholders (6.4), and Provide Feedback Mechanisms (6.5)

The published table of contents confirms every numbered Service listed above; Service Areas 1-3 also have a name directly stated in the document's own text, while 4-6 render their section-opening titles as graphics rather than extractable text in the copy reviewed for this guide — so this table describes 4-6 by their quoted purpose statement and numbered services rather than a single headline label. Treat any one-phrase name you see elsewhere for Areas 4-6 as to be confirmed against the source PDF.

Key definitions worth knowing

The framework's glossary fixes a few terms that are easy to use loosely in a vulnerability-handling policy:

• Remediation (or Remedy) — "a change made to a product or online service to remove or mitigate a vulnerability," typically a binary replacement, configuration change, or source patch and recompile; "mitigations are also called workarounds or countermeasures."
• Coordinator — an "optional participant that can assist vendors and finders in handling and disclosing vulnerability information."
• Bug Bar — "criteria that define the types of bugs that qualify as a security vulnerability," used so reports that meet the bar are processed through the PSIRT's standard operating procedure.
• Advisory — an "announcement or bulletin that serves to inform, advise, and warn about a vulnerability of a product."

Framework vs. standard: how to use each

	FIRST PSIRT Services Framework	ISO/IEC 29147 / 30111
Nature	Voluntary best-practice/training document, TLP:WHITE, free	Internationally standardised processes (ISO/IEC, paywalled full text)
Certifiable	No	No formal certification scheme either, but widely cited as the reference process standard
Best used for	Designing the team, its stakeholder relationships, and its full service catalogue	Defining the specific vulnerability-disclosure and handling process steps a policy commits to
Legal standing	None cited; FIRST disclaims liability for use	Referenced informally by regulators and buyers as good practice, but not itself an EU harmonised standard either

Most hardware and firmware makers use both together: ISO/IEC 29147/30111 (or the Cyber Resilience Act's own Annex I Part II text) to write the disclosure policy commitments, and the FIRST framework to design the team, stakeholder engagement and metrics around it. See how to set up a PSIRT for a hardware company and the CVD process under ISO/IEC 29147 and 30111 for the operational detail; see CRA 24h/72h vulnerability reporting for the legal deadlines the EU now attaches on top of all of this.

A workable starting point

1. Read the foundations section first (Strategic/Tactical/Operational) before picking services — the framework assumes executive sponsorship and a charter exist before Service Area 1 starts.
2. Use the six Service Areas as a gap-analysis checklist, not a certification target: for each, ask which services your team already runs, informally or not.
3. Pair it with a standard your legal or compliance team can cite, since the framework itself carries no regulatory weight — ISO/IEC 29147/30111 or the CRA's Annex I Part II text for anything that needs to withstand an audit.
4. Track metrics from day one (Stakeholder Metrics in Service Area 1, Vulnerability Discovery Metrics in Service Area 2, Vulnerability Release Metrics in Service Area 4) — the framework treats measurement as core to maturing the team, not an afterthought.

SoftWSP's PSIRT service can run intake, triage and stakeholder coordination against this framework's service areas while keeping decision authority with the manufacturer: see PSIRT service.

This guide summarises FIRST's freely published PSIRT Services Framework v1.1 (TLP:WHITE); it is general information, not legal advice.