Key takeaways
- The framework organizes everything into four nested levels: SERVICE AREAS -> SERVICES -> FUNCTIONS -> SUB-FUNCTIONS.
- Use the five Service Areas as a gap-analysis checklist, not a certification target.
FIRST's CSIRT Services Framework is a free, 65-page reference document — currently Version 2.1.0, dated November 2019 and marked TLP:WHITE (shareable without restriction) — that describes the services a Computer Security Incident Response Team (CSIRT) can provide. Published by FIRST (the Forum of Incident Response and Security Teams) with support from the TF-CSIRT Community and the International Telecommunications Union (ITU), it is a planning and common-vocabulary document, not a certifiable standard: per its own Notice, it describes what FIRST "believes are best practices," offered "for informational purposes only," with FIRST disclaiming liability for its use.
What the framework is for
The framework's stated mission is "to facilitate the establishment and improvement of CSIRT operations, especially in supporting teams that are in the process of choosing, expanding, or improving their service portfolio." It is explicit about its own limits: "this document does not explain how to build or improve a CSIRT or corresponding team" — that guidance lives in other resources it lists in its own Annex 3. An initial version of the framework was published in 2017; this edition, v2.1.0, is described as "an improved version of the second version of the CSIRT Services Framework," restructured to remove purely internal administrative work ("Support Services" such as hiring or travel reimbursement) from the catalogue, since those activities "do not constitute service offerings to constituents."
The four-level structure
The framework organizes everything into four nested levels: SERVICE AREAS -> SERVICES -> FUNCTIONS -> SUB-FUNCTIONS.
| Level | Definition, per the framework | Role |
|---|---|---|
| Service Area | "Group[s] services related to a common aspect" to "facilitate understanding and communication" | Top-level category |
| Service | "A set of recognizable, coherent functions oriented towards a specific result," specified with Description, Purpose and Outcome fields | The unit most teams plan around |
| Function | "An activity or set of activities aimed at fulfilling the purp[ose]" of a service | Reusable building block |
| Sub-function | A lower-level activity performed within a function, used where appropriate | Implementation detail |
The five Service Areas
| Service Area | Services it groups (per the framework's own table of contents) |
|---|---|
| 1 — Information Security Event Management | Monitoring and Detection (log/sensor management, detection use cases, contextual data); Event Analysis (correlation, qualification) |
| 2 — Information Security Incident Management | Incident Report Acceptance; Incident Analysis; Artifact and Forensic Evidence Analysis; Mitigation and Recovery; Incident Coordination; Crisis Management Support |
| 3 — Vulnerability Management | Vulnerability Discovery/Research; Vulnerability Report Intake; Vulnerability Analysis; Vulnerability Coordination; Vulnerability Disclosure; Vulnerability Response |
| 4 — Situational Awareness | Data Acquisition (policy aggregation, asset mapping, collection, data processing); Analysis and Synthesis (projection/inference, event detection, decision support, situational impact); Communication |
| 5 — Knowledge Transfer | Awareness Building; Training and Education; Exercises; Technical and Policy Advisory (risk management support, business continuity/disaster recovery planning support, policy support, technical advice) |
Service Area 3, Vulnerability Management, is the area that overlaps most directly with a PSIRT's own work: it covers the same discovery-intake-analysis-coordination-disclosure-response chain that SoftWSP's CVD process guide for ISO/IEC 29147 and 30111 and the vulnerability disclosure policy template describe in operational detail, and that the CRA's 24h/72h reporting duty now attaches legal deadlines to in the EU.
CSIRT vs. PSIRT: the framework's own distinction
FIRST's text draws the line directly: "The focus on constituents as well as the services offered are the key differentiators between the CSIRT of an organization and other security teams represented in the same organization, such as a PSIRT. Generally, the focus on products is the key differentiator between the PSIRT and any other security team, including but not limited to CSIRTs inside an organization." A CSIRT's job is defending a defined constituency's infrastructure; a PSIRT's job is handling vulnerabilities in a manufacturer's own products, wherever those products run. FIRST is also careful to note the two are not independent: "many CSIRTs warn constituents about security vulnerabilities. Such warnings are almost always based on information provided by vendor PSIRTs." A hardware or firmware maker's PSIRT, in other words, is frequently the upstream source feeding downstream CSIRTs' own advisories. See the FIRST PSIRT Services Framework explained and setting up a PSIRT for a hardware company for the product-side counterpart.
Three types of CSIRT
The framework builds its constituency model around three recognizable CSIRT types:
- Enterprise CSIRT — "focused on the security of computer systems and networks that make up the infrastructure of an organization."
- Coordinating CSIRT — where a large organization runs multiple internal security teams, one "might serve as coordinator and single point of contact to the external parties." Coordinating CSIRTs are also established as independent entities serving "a specific set of individuals and/or organizations known as a constituency" who share some common characteristic, such as belonging to the same research network or country.
- National CSIRT — "a distinctive type of Coordinating CSIRT" that facilitates, and often coordinates, the activities of CSIRTs located in a particular nation, or offers limited services to that nation's citizens or critical-infrastructure sectors.
A workable starting point
Use the five Service Areas as a gap-analysis checklist, not a certification targetThe framework itself states no team is expected to run every service — pick the ones that match your mandate and constituency. Treat Vulnerability Management (Area 3) as the bridge to your PSIRT work, since it is the one Service Area whose discovery-to-disclosure chain lines up directly with product vulnerability handling — pair it with ISO/IEC 29147 and 30111 or the CRA's own Annex I Part II text for anything that needs to withstand an audit. Scope your team type (Enterprise, Coordinating or National) before picking services— a Coordinating CSIRT's external single-point-of-contact role implies different Communication and Incident Coordination functions than an Enterprise CSIRT defending its own infrastructure only. Remember this is guidance, not a standard: FIRST's own notice disclaims liability and offers the document "for informational purposes only" — pair it with a standard your compliance team can actually cite where regulatory weight matters.
SoftWSP's PSIRT service can run the vulnerability intake, triage and stakeholder coordination that sits at the CSIRT/PSIRT boundary, so product vulnerabilities reach your own and your downstream CSIRTs' advisories on time: see PSIRT service.
This guide summarizes FIRST's freely published CSIRT Services Framework v2.1.0 (TLP:WHITE); it is general information, not legal advice.
Sources
- FIRST: Computer Security Incident Response Team (CSIRT) Services Framework, Version 2.1.0 (PDF, November 2019, TLP:WHITE) — full text: Purpose, CSIRT/PSIRT distinction, Framework Structure, 5 Service Areas with Services/Functions/Sub-functions, Annexes
- FIRST: CSIRT Services Framework v2.1 — standards landing page (version history, translations)
- FIRST: Services Framework overview (CSIRT and PSIRT frameworks index)
Frequently asked questions
What is the FIRST CSIRT Services Framework, and who publishes it?
It is a free, 65-page reference document from FIRST (the Forum of Incident Response and Security Teams), currently Version 2.1.0, dated November 2019 and marked TLP:WHITE (shareable without restriction). Per its own Purpose section, it is "a high-level document describing in a structured way a collection of cyber security services and associated functions that Computer Security Incident Response Teams and other teams providing incident management related services may provide." FIRST states the document "is developed by recognized experts from the FIRST community with strong support from the Task Force CSIRT (TF-CSIRT) Community, and the International Telecommunications Union (ITU)." An initial version of the framework was published in 2017; version 2.1.0 is, per the document's own text, "an improved version of the second version of the CSIRT Services Framework," restructured after community feedback to remove purely internal administrative activities ("Support Services") from the service catalogue.
How is the framework structured, and what are its five Service Areas?
The framework defines four nested levels: "SERVICE AREAS -> SERVICES -> FUNCTIONS -> SUB-FUNCTIONS." A Service Area "groups services related to a common aspect" to aid understanding and communication; a Service is "a set of recognizable, coherent functions oriented towards a specific result"; a Function is "an activity or set of activities aimed at fulfilling the purpose" of a service. The five numbered Service Areas, per the document's own table of contents, are: (1) Information Security Event Management, (2) Information Security Incident Management, (3) Vulnerability Management, (4) Situational Awareness, and (5) Knowledge Transfer. No single CSIRT is expected to run every service in every area — the framework's own Purpose section states "the services described are those potential services a CSIRT could provide. No CSIRT is expected to provide all described services. Each team will need to choose services that support their mission and constituents, as described by their mandate."
What is the difference between a CSIRT and a PSIRT, per FIRST's own text?
FIRST's framework states it directly: "The focus on constituents as well as the services offered are the key differentiators between the CSIRT of an organization and other security teams represented in the same organization, such as a PSIRT. Generally, the focus on products is the key differentiator between the PSIRT and any other security team, including but not limited to CSIRTs inside an organization." The two are not independent of each other: "many CSIRTs warn constituents about security vulnerabilities. Such warnings are almost always based on information provided by vendor PSIRTs." FIRST maintains a separate, parallel PSIRT Services Framework for product-security teams — see [the FIRST PSIRT Services Framework explained](/guides/first-psirt-services-framework/) for that document's own service areas.
What types of CSIRT does the framework describe?
Three, built on the constituency concept. An Enterprise CSIRT "is focused on the security of computer systems and networks that make up the infrastructure of an organization." Where a large organization runs multiple internal security teams, one "might serve as coordinator and single point of contact to the external parties" — this is called a Coordinating CSIRT, which can also exist as "independent entities serving a specific set of individuals and/or organizations known as a constituency" who "share some common characteristics (like being part of a national research network or belonging to a specific country)." A National CSIRT is described as "a distinctive type of Coordinating CSIRT" that facilitates and often coordinates CSIRT activity for a particular nation, or offers limited services to that nation's citizens or critical-infrastructure sectors.
In this cluster
