PSIRT
PSIRT vs CSIRT: product vulnerabilities and incidents in your own IT
A CSIRT responds when your own systems are attacked. A PSIRT responds when the products you sell have a vulnerability your customers are exposed to. Both are incident response teams, both follow FIRST frameworks, and in a real incident they often need each other.
Updated
What is a CSIRT?
A CSIRT (Computer Security Incident Response Team) is the team that handles security incidents for a defined group of people or organizations, called its constituency. FIRST's CSIRT Services Framework defines it as an organizational unit, which may be virtual, or a capability that provides services to that constituency "for preventing, detecting, handling, and responding to computer security incidents".
The constituency decides what kind of CSIRT it is:
- Enterprise CSIRT: one company's own networks, systems, accounts and data.
- Sector CSIRT: a group of organizations in one industry, such as finance or energy.
- National CSIRT: a whole country, often with a role in cross-border coordination.
- Vendor team: a company's customers, for problems in its products. This is the PSIRT.
The CSIRT Services Framework (version 2.1) groups CSIRT services into five areas: information security event management, information security incident management, vulnerability management, situational awareness, and knowledge transfer.
What is a PSIRT?
A PSIRT (Product Security Incident Response Team) is, in FIRST's words, the entity within an organization that focuses on "the identification, assessment and disposition of the risks associated with security vulnerabilities within the products" the organization makes or sells. It takes in vulnerability reports, works out which products and versions are affected, gets a fix built and shipped, and tells customers through advisories.
Its framework, the PSIRT Services Framework (version 1.1), has six service areas: stakeholder ecosystem management, vulnerability discovery, vulnerability triage and analysis, remediation, vulnerability disclosure, and training and education.
The key difference
The difference is whose systems are at risk. A CSIRT protects the organization: the incident is in your environment, and you contain it. A PSIRT protects your customers: the vulnerability is in your product, running in their environments, and you cannot patch it for them. You ship a fix and tell them to install it.
FIRST puts it plainly: "the focus on products is the key differentiator" between a PSIRT and other incident response teams in the same organization, and an enterprise CSIRT is generally focused on the systems and networks that make up the organization's own infrastructure.
PSIRT vs CSIRT compared
| Enterprise CSIRT | PSIRT | |
|---|---|---|
| Scope | Incidents in the organization's own networks, systems and data | Vulnerabilities in the products the organization ships |
| Constituency | Employees and internal systems | Customers and users of the products |
| Typical inputs | Alerts, logs, user reports, threat intelligence | Researcher reports, advisories for third-party components, internal testing, coordinators |
| Typical outputs | Contained incidents, recovered systems, post-incident reviews | Fixed releases, security advisories, CVE records, customer notifications |
| Clock starts | When an incident is detected | When a vulnerability is reported or published |
| Typical owner | The CISO or IT security | Product security or engineering |
| FIRST framework | CSIRT Services Framework 2.1 | PSIRT Services Framework 1.1 |
| Standards | ISO/IEC 27035 (incident management) | ISO/IEC 29147 (vulnerability disclosure), ISO/IEC 30111 (vulnerability handling) |
Both frameworks stress that the teams do not work in isolation. The PSIRT framework describes CSIRTs, national ones included, as stakeholders a PSIRT should build relationships with, because they are often how a vendor hears about a vulnerability early.
CERT vs CSIRT
The first team of this kind was the CERT Coordination Center, which, according to the SEI, emerged from the response to the Morris worm in 1988, with DARPA funding, at Carnegie Mellon's Software Engineering Institute. CERT is a mark registered in the United States by Carnegie Mellon University, and the SEI authorizes US teams to use it in their names. It no longer licenses the mark outside the United States.
So "CERT" and "CSIRT" describe the same kind of team. CSIRT is the neutral term, used by FIRST and in EU law; many teams, national ones especially, still carry CERT in their name.
National CSIRTs and coordinators
A few organizations matter to a product team because they sit between finders, vendors and users:
- CERT/CC has coordinated the disclosure of software vulnerabilities since 1988, and publishes a guide to coordinated vulnerability disclosure for organizations building their own process.
- CISA coordinates disclosure between reporters, manufacturers and users in the United States, and may publish as early as 45 days after first trying to contact an unresponsive vendor, whether or not a fix exists.
- EU national CSIRTs. NIS2 requires every member state to designate or establish one or more CSIRTs, and they cooperate in the CSIRTs Network together with CERT-EU. ENISA, the EU cybersecurity agency, provides its secretariat.
National CSIRTs also have a formal role in vulnerability reporting. Under NIS2 Article 12, each member state designates one CSIRT as coordinator for coordinated vulnerability disclosure: a trusted intermediary between the person reporting a vulnerability and the manufacturer, which can identify the vendors concerned, help the reporter and negotiate disclosure timelines. The Cyber Resilience Act builds on the same role: manufacturers notify actively exploited vulnerabilities in their products to the CSIRT designated as coordinator and to ENISA at the same time.
How a PSIRT and a CSIRT work together
Take a vulnerable open-source component that is being exploited, used both in your product and in your internal systems. Both teams get the same advisory, and each has its own job:
- CSIRT: finds the component on internal servers and laptops, checks logs for exploitation, patches or isolates, and runs an incident if anything was compromised.
- PSIRT: works out which products, versions and builds include the component, assesses whether the product is affected, ships a fixed release and publishes an advisory, with a VEX statement for the versions that are not affected.
- Both: share indicators and timelines. If the CSIRT finds the attack reached the build system, the PSIRT has to check whether any shipped release was tampered with, which turns an internal incident into a product one. A supply chain attack usually crosses this line.
The step that slows the PSIRT down is the second one. A CSIRT can scan its own estate. A PSIRT has to answer for software already in customers' hands, which means knowing what went into every release it shipped. The vulnerability management lifecycle and coordinated vulnerability disclosure pages cover the rest of the PSIRT's path to a fix.
CSIRT vs SOC
A Security Operations Center (SOC) watches: it monitors alerts and logs around the clock, filters out noise and escalates what looks real. A CSIRT responds: it takes the confirmed incident, contains it, investigates, coordinates with legal and communications, and leads recovery. In smaller organizations the SOC and the CSIRT are often the same people, and the SEI points out that whether a team is called a CSIRT, a SOC or something else matters less than which functions it performs.
Neither replaces a PSIRT. A SOC monitors your environment; it cannot see a vulnerability in a device a customer runs.
Do you need both?
If you make software or devices and also run your own IT, you need both functions. You do not need two departments. Small vendors often start with one security lead who runs incident response for the company and a written PSIRT process for the products, with engineering on call for fixes. What has to be separate is the process: an internal incident and a product vulnerability have different owners, different deadlines and different people to tell.
Where CRACI fits
CRACI supports the PSIRT side: knowing what is in the software you ship. It runs your GitHub Actions builds on its own runners and records the packages each job actually fetched, including transitive dependencies and packages restored from caches, and exports SBOMs as CycloneDX or SPDX.
Monitored SBOMs are re-evaluated continuously, and build history shows which past builds contained a vulnerable dependency. The inventory view shows which versions are deployed to which products, and security teams triage findings and route them to the teams that own the fix. See vulnerability tracking and CRACI for PSIRTs.
PSIRT vs CSIRT: frequently asked questions
What is a CSIRT?
A Computer Security Incident Response Team. FIRST defines it as an organizational unit, which may be virtual, or a capability that provides services and support to a defined constituency for preventing, detecting, handling and responding to computer security incidents. The constituency can be one company, a sector or a whole country.
What is the difference between a PSIRT and a CSIRT?
A PSIRT handles vulnerabilities in the products a company sells, which its customers are exposed to. An enterprise CSIRT handles security incidents in the company's own systems and networks. FIRST calls the focus on products the key differentiator between the two.
Is a CERT the same as a CSIRT?
Functionally, yes. CERT is a mark registered in the United States by Carnegie Mellon University, whose CERT Coordination Center was the first such team, set up in 1988 after the Morris worm. CSIRT is the generic term. Many national teams use CERT in their name, and the EU uses CSIRT in its legislation.
What is the difference between a SOC and a CSIRT?
A SOC monitors and detects around the clock: it watches alerts and logs and escalates what looks real. A CSIRT owns the response to confirmed incidents: containment, investigation, coordination and recovery. In many organizations the two overlap or share people, and the SEI notes that what matters is which functions a team performs, not what it is called.
Do we need both a PSIRT and a CSIRT?
If you sell software or devices and also run your own IT, you need both functions, though not necessarily two departments. In a small company the same few people often cover both, with separate processes: one for incidents in your environment, one for vulnerabilities in what you ship.
What does a national CSIRT do?
It handles incidents for a national constituency, shares warnings and coordinates across borders. Under NIS2, every EU member state designates at least one CSIRT, and one of them acts as coordinator for coordinated vulnerability disclosure: a trusted intermediary between the person who reports a vulnerability and the manufacturer.
Know which builds carry a vulnerable component
When an advisory lands, your PSIRT needs to know where the component ships. Book a demo to see it from a record of what each build fetched.
Book a demo