Many incident response teams cannot say precisely which services they provide, to whom, and to what standard, so they are asked to do everything and are measured on nothing. The FIRST CSIRT Services Framework gives teams a shared vocabulary: five service areas, the services inside each, and the functions that deliver them. Used well, it turns a vague mandate into a service catalogue that leadership can fund, constituents can understand and auditors can test. This guide explains the framework's structure, how to use it to define and scope a team, how it relates to RFC 2350, SIM3 and NIST SP 800-61 Rev. 3, and where teams go wrong. It is written for CSIRT and SOC managers, CISOs designing or reviewing an incident capability, and coordinators in sector or national teams. The broader incident lifecycle is in the Incident Response Guide; this page is about the service model.
Key takeaways
- It is a catalogue, not a maturity model. FIRST states that the framework makes no recommendations about capability, capacity, maturity or quality; use SIM3 or a maturity model for that.
- No team should offer every service. The framework says services should follow from the team's mandate and constituency, so selection is the main design decision.
- Five service areas cover the field: information security event management, incident management, vulnerability management, situational awareness and knowledge transfer.
- Each service is defined by purpose and outcome. Writing those two lines for each service you offer is the quickest way to expose unfunded or overlapping commitments.
- Publish the result. An RFC 2350 profile tells constituents and peer teams what you do, how to reach you and what you will not do.
What the framework is and where it came from
The CSIRT Services Framework is published by FIRST (the Forum of Incident Response and Security Teams). The first version appeared in 2017; Version 2.1 replaces all previous versions, and its PDF edition (Version 2.1.0, TLP:WHITE) is dated November 2019. FIRST developed it with strong support from the TF-CSIRT community and the International Telecommunication Union. It describes, at a high level, the cyber security services that CSIRTs and similar incident management teams may provide, so that teams can choose, expand or improve their portfolio and talk to each other in common terms.
The framework is explicit about what it does not do. It does not explain how to build a CSIRT, it treats internal support activities such as staffing as out of scope, and it does not prescribe maturity or quality. It also separates CSIRTs, which serve a constituency, from PSIRTs, which serve a product portfolio; FIRST publishes a companion PSIRT Services Framework for the latter. See the PSIRT Guide.
The building blocks
| Element | Framework definition (paraphrased) | What you write for it |
|---|---|---|
| Service area | A group of services related to a common aspect | Whether the area is in scope at all |
| Service | A set of coherent functions aimed at a specific result, described by description, purpose and outcome | Purpose, outcome, constituents served, hours, service level |
| Function | An activity or set of activities that fulfils a service's purpose; can be shared across services | Owner, procedure, tooling |
| Sub-function | An activity that fulfils a function's purpose; optional or required | Runbook steps where needed |
The five service areas and their services
The framework numbers its service areas as sections 5 to 9. The table lists every service and a selection of the functions under it.
| Service area | Services | Example functions |
|---|---|---|
| 5. Information security event management | 5.1 Monitoring and detection; 5.2 Event analysis | Log and sensor management; detection use case management; contextual data management; correlation; qualification |
| 6. Information security incident management | 6.1 Incident report acceptance; 6.2 Incident analysis; 6.3 Artifact and forensic evidence analysis; 6.4 Mitigation and recovery; 6.5 Incident coordination; 6.6 Crisis management support | Triage (prioritisation and categorisation); root cause analysis; cross-incident correlation; reverse engineering; ad hoc measures and containment; system restoration; notification distribution; media communication |
| 7. Vulnerability management | 7.1 Vulnerability discovery and research; 7.2 Vulnerability report intake; 7.3 Vulnerability analysis; 7.4 Vulnerability coordination; 7.5 Vulnerability disclosure; 7.6 Vulnerability response | Public source vulnerability discovery; triage (validation and categorisation); remediation development; stakeholder coordination; disclosure policy and infrastructure maintenance; detection and scanning; remediation |
| 8. Situational awareness | 8.1 Data acquisition; 8.2 Analysis and synthesis; 8.3 Communication | Asset mapping to functions, roles and key risks; collection; projection and inference; event detection through alerting or hunting; decision support; information sharing management |
| 9. Knowledge transfer | 9.1 Awareness building; 9.2 Training and education; 9.3 Exercises; 9.4 Technical and policy advisory | Outreach; CSIRT staff professional development; scenario development; exercise outcome review; risk management support; business continuity planning support; policy support |
Reading the areas in practice
- Event management (5): this is where most enterprise SOCs live. Detection use case management is a named function, which supports treating detections as maintained assets. See the SOC Guide and the Detection-as-Code Guide.
- Incident management (6): the core of any CSIRT. Note that coordination (6.5) and crisis management support (6.6) are separate services: a team can be strong at technical analysis and still fail an incident because nobody distributes notifications or supports executive decisions.
- Vulnerability management (7): for an enterprise team this usually means 7.1, 7.2 and 7.6 (finding, receiving and remediating), while coordinating CSIRTs and PSIRTs add 7.4 and 7.5. See the Vulnerability Management Guide.
- Situational awareness (8): broader than threat intelligence. It includes mapping assets to business functions and key risks, and decision support for incident management. See the Threat Intelligence Guide.
- Knowledge transfer (9): often unfunded but expected. Exercises (9.3) has its own functions from requirements analysis to outcome review, which fits tabletop and simulation programmes.
Choosing services: mandate, constituency and team type
The framework describes a properly deployed CSIRT as having a clear mandate, a governance model, a tailored services framework and processes to measure and improve services. It describes three main CSIRT types, and the right service selection differs sharply between them.
| Team type | Typical constituency | Usually core | Usually limited or out of scope |
|---|---|---|---|
| Enterprise CSIRT | The organisation's own systems, networks and staff | 5.1, 5.2, 6.1 to 6.4, 7.6, 9.3 | 7.4 and 7.5 (beyond its own products), 9.1 for external audiences |
| Coordinating CSIRT (sector, research network, group) | A set of organisations sharing a characteristic | 6.1, 6.5, 6.6, 7.2, 7.4, 8.3, 9.1 | Hands-on 6.4 recovery inside members' systems, unless contracted |
| National CSIRT | A nation's CSIRTs, critical sectors, sometimes citizens | 6.5, 6.6, 7.4, 7.5, 8.1 to 8.3, 9.1, 9.4 | Deep 6.3 analysis for individual organisations, except in major incidents |
| PSIRT (separate framework) | Products and their users | Vulnerability intake, analysis, remediation, disclosure | Constituency incident handling |
Decision guidance
- Offer, partner or exclude: for each service decide whether the team delivers it, a partner delivers it (retainer firm, MSSP, national CSIRT), or it is explicitly not provided. "Not provided" is a valid and useful answer. See the Incident Response Retainer Buyer's Guide.
- Small organisations often run 5.1 and 5.2 through a managed SOC and keep 6.1, 6.5 and 6.6 in house, because coordination and decisions cannot be outsourced. See the Co-Managed SOC and SOC-as-a-Service Guide.
- Large organisations tend to split event management (SOC) and incident management (CSIRT) into separate teams; the framework's areas give a clean boundary for the hand-off between 5.2 and 6.1.
- Sharing functions: because a function can serve several services, map shared functions (for example triage) once and reuse them, rather than writing parallel procedures for incidents and vulnerability reports.
How to build a service catalogue from the framework
- Write the mandate and constituency in three or four sentences: who you serve, under what authority, and what you can require of constituents (for example, isolating a host). Get it signed by the sponsor.
- Walk all 21 services in a workshop with the team and two or three constituent representatives. Mark each offer, partner or exclude, and record why.
- For every offered service, write purpose and outcome in the framework's style, then add: who can request it, hours of coverage, target response time, the inputs you need, and what the constituent receives.
- Map functions to owners and procedures: each function in an offered service needs a named owner and a runbook or a reason why none is needed. See the SOC Runbook Template.
- Find the gaps: offered services with no owner, no tooling or no budget are the real findings. Fix them or move the service to "partner" or "exclude".
- Publish: create an RFC 2350 description document (contact information, charter, policies, services, reporting forms, disclaimers) and an internal catalogue page. Review both at least annually and after major reorganisations.
- Test the catalogue: run an exercise where constituents request services as described and measure whether the outcome matches the stated service level.
Example service entry
| Field | Example for 6.1 Information security incident report acceptance |
|---|---|
| Purpose | Receive reports of suspected incidents from staff, partners and automated systems and decide whether they need handling |
| Outcome | Every report acknowledged, triaged and either closed with feedback or opened as an incident |
| Channels | [Email address], [phone], [portal], SOC escalation queue; encrypted reporting key published in the RFC 2350 profile |
| Coverage and target | 24x7 acknowledgement within [30] minutes; triage within [2] hours |
| Functions | 6.1.1 report receipt; 6.1.2 triage and processing |
| Not included | Reports about third-party products, which go to the vendor's PSIRT or the national CSIRT |
Relation to RFC 2350, SIM3 and NIST SP 800-61 Rev. 3
The framework sits alongside several other references. Each answers a different question.
| Reference | Question it answers | How it fits with the services framework |
|---|---|---|
| RFC 2350 (BCP 21, 1998) | How do we describe our team to the outside world? | Its "Services" section is where the selected framework services are published, with policies and contact details |
| SIM3 (Open CSIRT Foundation) | How mature is the team? | Assesses organisation, human, tools and process parameters on levels 0 to 4; Trusted Introducer certification uses its 44 parameters |
| NIST SP 800-61 Rev. 3 (April 2025) | How should incident response fit into risk management? | A CSF 2.0 community profile; use it for the lifecycle and governance, and the framework for the service boundaries |
| FIRST PSIRT Services Framework | What does a product security team provide? | Companion framework for vendors; coordinating CSIRTs rely on PSIRT information to warn constituents |
| Incident response maturity models | Where should we invest next? | Score each offered service; see the Incident Response Maturity Model |
SIM3 is moving: the Open CSIRT Foundation published SIM3 v2 interim on 1 January 2023, adding parameter O-6, with the full version 2 expected in 2026 and intended to cover CSIRTs, ISACs, SOCs and PSIRTs. Check the current version before an assessment.
Framework mapping
The table shows where each service area lands in common control frameworks, which helps when an auditor asks how the catalogue supports a control.
| Service area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| 5 Event management | DE.CM-01, DE.AE-02 | SI-4, IR-5 | A.8.15, A.8.16 |
| 6 Incident management | RS.MA-01, RS.MA-02, RS.AN-03, RS.CO-02 | IR-4, IR-6, IR-7, IR-8 | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28 |
| 7 Vulnerability management | ID.RA-01, ID.RA-08 | RA-5, SI-2 | A.8.8 |
| 8 Situational awareness | ID.RA-02, RS.CO-03 | SI-5, PM-16, PM-15 | A.5.7 |
| 9 Knowledge transfer | ID.IM-02 | AT-2, IR-2, IR-3 | A.6.3 |
| Mandate and governance | GV.RR-02 | IR-8 | A.5.2, A.5.24 |
Measuring the services
Because the framework deliberately omits quality measures, each team has to define its own. Tie each metric to an offered service so the catalogue and the dashboard stay aligned.
- 6.1 acknowledgement and triage time: median minutes from report to acknowledgement, and to triage decision, against the published target.
- 5.1 detection coverage: percentage of priority use cases with a working, tested detection. See the Detection Validation and Testing Guide.
- 6.4 time to contain: median time from incident declaration to containment for high-severity incidents.
- 6.5 notification timeliness: percentage of required internal and external notifications sent within their deadlines.
- 9.3 exercise follow-through: percentage of exercise actions closed by their due date.
- Catalogue health: number of offered services without an owner, procedure or tested tool. The target is zero.
Where identity fits
Several services depend on identity data that CSIRTs often lack. Contextual data management (5.1) and asset mapping (8.1.2) need to know which accounts, service accounts, API keys and OAuth applications belong to which business function, and incident analysis (6.2) needs to trace what a compromised credential could reach. Teams that add machine identities to their contextual data can scope incidents involving tokens and keys far faster. See the Identity Incident Response Playbook.
Common failure patterns
- Claiming every service: a catalogue that lists all 21 services with no exclusions is a wish list. Constituents then expect forensic analysis or crisis support that the team cannot deliver at 3 a.m.
- Treating the framework as a maturity score: counting how many services are "offered" says nothing about quality, and FIRST says so. Pair it with SIM3 or a maturity model.
- Ignoring coordination and crisis support: teams invest in analysis tooling (6.2, 6.3) and leave 6.5 and 6.6 informal, so notifications, legal and executive decisions lag the technical work. See Top 10 Incident Response Mistakes.
- Unclear SOC and CSIRT boundary: without an agreed hand-off between event analysis (5.2) and report acceptance (6.1), alerts are closed by one team that the other would have treated as incidents.
- A stale public profile: an RFC 2350 document with old contacts or keys breaks the channel peer teams use to warn you.
- Partner services not tested: services delegated to a retainer firm or MSSP are listed but never exercised, so activation takes days.
Practitioner checklist
- Write and sign off a mandate and constituency statement for the team.
- Walk all five service areas and 21 services; mark each offer, partner or exclude with a reason.
- For each offered service, record purpose, outcome, coverage hours and target response time.
- Assign an owner and procedure to every function in an offered service.
- Agree the hand-off between event management (5) and incident management (6) in writing.
- Publish an RFC 2350 description document and review it at least annually.
- Include machine identities and their owners in contextual and asset data.
- Define 4 to 6 service metrics and report them quarterly to the sponsor.
- Exercise at least one partner-delivered service each year.
- Assess maturity separately with SIM3 or an incident response maturity model.
Standards and references
- FIRST: CSIRT Services Framework Version 2.1
- FIRST: CSIRT Services Framework Version 2.1.0 (PDF)
- IETF: RFC 2350 Expectations for Computer Security Incident Response
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- Open CSIRT Foundation: SIM3 and references
- Trusted Introducer: Certification process
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Incident Response Guide · PSIRT Guide · Building a SOC from Scratch Guide · Incident Response Maturity Model