Most organisations discover they do not have a computer security incident response team (CSIRT) at the moment they need one: a serious incident arrives and nobody has the authority, the contacts or the agreed process to lead it. A CSIRT is not the same as a security operations centre. The SOC watches and triages; the CSIRT owns the response, coordinates across IT, legal, communications and suppliers, and represents the organisation to peers, regulators and national teams. This guide covers how to set one up: the mandate and constituency, which services to offer using the FIRST CSIRT Services Framework, organisational models, staffing, the RFC 2350 team description, trust and community membership, and how to measure maturity with SIM3 and the ENISA approach. It is written for CISOs, incident response leads and those building enterprise, sector or national teams. For the monitoring side, see the Building a SOC from Scratch Guide.
Key takeaways
- Start with the charter, not the tools. RFC 2350 puts mission, constituency, sponsorship and authority first; a team without written authority cannot isolate a system at 2am.
- Choose services deliberately. The FIRST CSIRT Services Framework lists five service areas and states that no CSIRT is expected to provide all of them.
- Pick an organisational model that matches your size. A small organisation runs a virtual team plus a retainer; a large or regulated one needs a dedicated, centrally led team with distributed contacts.
- Trust is a capability. Published contact details, a PGP key, TLP use and membership of FIRST or Trusted Introducer let other teams share information with you.
- Measure maturity with a recognised model. SIM3, which ENISA and FIRST have adopted, gives a structured view of organisation, people, tools and processes.
What a CSIRT is and how it differs from a SOC and PSIRT
FIRST defines a CSIRT as an organisational unit, which may be virtual, or a capability that provides services and support to a defined constituency to prevent, detect, handle and respond to computer security incidents, in line with its mission. Three features follow from that definition: a constituency (who the team serves), a mandate (what it may do) and a service catalogue.
| Function | Primary focus | Typical outputs | Relationship to the CSIRT |
|---|---|---|---|
| SOC | Continuous monitoring, alert triage, first response | Triage decisions, escalations, detection content | Feeds incidents to the CSIRT; in small organisations the same people |
| CSIRT | Incident handling and coordination for a constituency | Incident management, coordination, advisories, lessons learned | Owns the incident from declaration to closure |
| PSIRT | Vulnerabilities in the organisation's own products | Vulnerability intake, fixes, security advisories | Shares coordination methods; separate constituency (product users). See the PSIRT Guide |
| National or sector CSIRT | A country or sector as constituency | Alerts, coordination across organisations, national reporting | An enterprise CSIRT's main external peer |
Under the EU NIS2 Directive, each Member State must designate CSIRTs responsible for incident handling for the entities in scope, and these teams form the EU CSIRTs Network. For enterprise teams in scope of NIS2, the national CSIRT or competent authority is the recipient of incident reports. See the NIS2 Directive Guide.
Mandate: charter, constituency and authority
RFC 2350 (Best Current Practice 21, June 1998) sets out what a CSIRT should publish about itself. Its charter section has four parts, and these are the right starting point for any internal mandate document as well:
- Mission statement: the team's core activities, stated clearly and without ambiguity. Example: "To coordinate the response to information security incidents affecting [Organisation], limit their impact and restore normal operations."
- Constituency: who the team serves: all subsidiaries, specific business units, customers of a managed service, or a sector. Ambiguity here causes the most arguments during incidents involving joint ventures, acquisitions and suppliers.
- Sponsorship and affiliation: the body that authorises the team, usually the board or executive committee, with the CISO as sponsor.
- Authority: what the team may do, which can differ from the constituency perimeter. RFC 2350 recommends legal advice on this section. Write down explicitly whether the CSIRT can isolate hosts, disable accounts, take a service offline, preserve evidence from personal devices and engage external parties without further approval.
Authority is usually expressed in three levels: full authority (the team acts and informs the owner), shared authority (the team recommends and the system owner acts within a set time), and advisory (common for national and sector CSIRTs, which coordinate but cannot direct). Most enterprise teams need full authority for containment of severity 1 and 2 incidents, with a named executive who can override it.
Choosing services with the FIRST CSIRT Services Framework
The FIRST CSIRT Services Framework 2.1 groups services into five areas. It makes no recommendation on capability or maturity and says some services may be performed by others, such as vendors, PSIRTs or third-party specialists.
| Service area | Services in the framework | Typical enterprise choice at launch |
|---|---|---|
| Information Security Event Management | Monitoring and detection; event analysis | Provided by the SOC or managed detection provider; CSIRT consumes escalations |
| Information Security Incident Management | Incident report acceptance; incident analysis; artefact and forensic evidence analysis; mitigation and recovery; incident coordination; crisis management support | Core of the CSIRT. Forensics often by retainer at first |
| Vulnerability Management | Vulnerability discovery and research; report intake; analysis; coordination; disclosure; response | Report intake and response; coordination with the PSIRT if the organisation ships products |
| Situational Awareness | Data acquisition; analysis and synthesis; communication | Threat intelligence relevant to the constituency, often shared with the CTI team |
| Knowledge Transfer | Awareness, training, exercises and advice to the constituency | Playbooks, exercises and lessons-learned briefings |
Decision guidance: launch with incident report acceptance, analysis, coordination and mitigation and recovery done well, plus one external contact point. Add forensic analysis in-house only when incident volume justifies the tooling and skills; until then, use an incident response retainer with agreed response times. See the Incident Response Retainer Buyer's Guide.
Organisational models and staffing
| Model | How it works | Fits | Main risk |
|---|---|---|---|
| Virtual (ad hoc) team | Named people from security, IT and legal convene when an incident is declared | Small organisations, low incident volume | Day jobs win; skills fade between incidents |
| Centralised team | Dedicated staff handle all incidents for the constituency | Mid to large organisations, one main jurisdiction | Distance from local systems and business units |
| Distributed team | Handlers sit in regions or business units under common procedures | Global groups, decentralised IT | Inconsistent handling and evidence standards |
| Combined (hub and spoke) | Central team leads, with trained local responders and contacts | Large and regulated organisations | Needs strong coordination and training |
| Coordinating CSIRT | Coordinates other teams, rarely handles directly | Group-level, sector and national teams | Limited authority over members |
Core roles for any model: CSIRT manager (owns the mandate and the service catalogue); incident manager or incident commander on rota (runs each incident); incident handlers or analysts; forensic analyst (in-house or retained); threat intelligence liaison; and named contacts in legal, privacy, communications, HR, IT operations, cloud and identity teams. Out-of-hours cover needs a minimum rota of [four to five] people for a weekly on-call pattern without burnout; smaller organisations rely on the retainer for overnight analysis and keep only the incident manager role on call.
Identity is part of the team. Many incidents are decided in the identity platform: revoking sessions, disabling service accounts, rotating API keys and certificates. Give the CSIRT a named identity administrator on the rota and pre-approved break-glass access. See the Identity Incident Response Playbook.
Policies, processes and the RFC 2350 description
RFC 2350's template is a practical checklist of what the team must decide and publish:
- Document information: last update date, distribution list for change notices, where the document is published.
- Contact information: team name, address, time zone, telephone, email, public keys and encryption information, team members, points of customer contact and hours.
- Charter: mission, constituency, sponsorship and affiliation, authority.
- Policies: types of incidents and level of support; co-operation, interaction and disclosure of information; communication and authentication.
- Services: incident response (triage, coordination, resolution) and proactive activities.
- Incident reporting forms.
- Disclaimers.
Behind the public description, the internal process set is: an incident response policy and plan, a severity classification matrix, playbooks for the most likely incident types, an evidence handling procedure, an out-of-band communications plan and a contact tree. NIST SP 800-61 Rev. 3 (April 2025), now a CSF 2.0 Community Profile, frames these as part of cybersecurity risk management rather than a stand-alone function. See the Incident Response Plan Template, the Incident Severity Classification Matrix Template and the NIST SP 800-61 Incident Response Guide.
Trust, sharing and community membership
Peers share sensitive information with teams they can verify. The three common steps are:
- Publish: an RFC 2350 description, a security contact (for example through a security.txt file), and a PGP key for encrypted reports. Use FIRST TLP markings for everything shared. See the Traffic Light Protocol Guide.
- Trusted Introducer: the European CSIRT community directory runs a Listed, Accredited, Certified path. Accreditation requires an already listed team, a published RFC 2350 description and use of TLP; the process takes one to four months and carries a one-time fee of EUR 800 and an annual fee of EUR 1,200 (as published at the time of writing). Certification is open to accredited teams.
- FIRST membership: full members need two sponsors, the primary being a full member outside the applicant's parent organisation, and sponsors conduct a site visit. FIRST lists an annual full membership fee of US$2,800 for 2024 to 2026 and a one-time US$1,000 application fee.
Sector information sharing and analysis centres (ISACs) and the national CSIRT complete the external network. Agree in advance what the team may share and at what TLP level, and who approves sharing during an incident.
Measuring maturity: SIM3 and ENISA
The Security Incident Management Maturity Model (SIM3), owned by the Open CSIRT Foundation, measures how well a team governs, documents, performs and measures its function. The current reference is SIM3 v2 interim, published on 1 January 2023, with a full version 2 expected in 2026 covering CSIRTs, ISACs, SOCs and PSIRTs. FIRST, ENISA and the EU CSIRTs Network have adopted it or are moving to it. Internal and not-for-profit use is free; commercial audits need permission from the foundation.
ENISA's CSIRT maturity framework, based on SIM3, evaluates organisational, human, tools and processes parameters and rates each as basic, intermediate or advanced. ENISA offers an online self-assessment and a peer review method.
| Area | What "basic" looks like | What "advanced" looks like |
|---|---|---|
| Organisation | Mandate exists informally; constituency loosely defined | Approved charter, published RFC 2350, service catalogue, defined authority |
| Human | A few people with incident duties on top of other work | Rota, defined roles, training plan, documented skill requirements |
| Tools | Email and spreadsheets | Case management, evidence store, secure communications, forensic tooling |
| Processes | Undocumented, depends on individuals | Documented, exercised and reviewed playbooks with metrics |
For an organisation-wide view of incident response maturity, see the Incident Response Maturity Model.
Implementation roadmap
- Months 0 to 1: mandate. Draft the charter (mission, constituency, sponsorship, authority), get legal review of the authority section and executive approval.
- Months 1 to 2: services and model. Choose the launch services from the FIRST framework, the organisational model and the retainer arrangement. Name the roles and the on-call rota.
- Months 2 to 4: process and tools. Publish the incident response plan, severity matrix, top five playbooks, evidence procedure, case management and an out-of-band channel.
- Month 4: test. Run a tabletop exercise against the most likely scenario, then a functional exercise of the containment steps. Fix the gaps before declaring the team operational. See the Cyber Incident Exercises Beyond Tabletop Guide.
- Months 4 to 6: go live and connect. Publish the RFC 2350 description and contact routes, register with the national CSIRT and sector ISAC, and apply to Trusted Introducer listing or FIRST if appropriate.
- Month 12: assess. Run a SIM3 or ENISA self-assessment and set targets for the next year.
Small versus large: a 300-person company can meet most of this with a two-page charter, a virtual team of five, a retainer with a one-hour response commitment and the national CSIRT's reporting route. A multinational needs the combined model, regional handlers, a 24x7 rota and formal sharing agreements.
Detection and measurement
- Mean time from detection to incident declaration for severity 1 and 2 incidents.
- Mean time to containment by severity.
- Percentage of incidents handled under a documented playbook.
- Percentage of post-incident actions closed by their due date.
- Exercise coverage: share of top scenarios exercised in the last 12 months.
- Maturity score trend from annual SIM3 or ENISA self-assessment.
Framework mapping
| CSIRT element | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Other |
|---|---|---|---|
| Charter, roles and authority | GV.RR-02 | IR-1 Policy and Procedures, IR-8 Incident Response Plan | ISO/IEC 27001:2022 A.5.24 |
| Triage and handling | RS.MA-01, RS.MA-02 | IR-4 Incident Handling | CIS Controls v8.1 Control 17 |
| Reporting and notification | RS.CO-02 | IR-6 Incident Reporting | NIS2 incident reporting |
| Assistance to users and constituency | RC.CO-03 | IR-7 Incident Response Assistance | FIRST Services Framework |
| Exercises and improvement | ID.IM-02, ID.IM-04 | IR-3 Incident Response Testing | SIM3, ENISA maturity framework |
Common failure patterns
- No written authority. The team finds the intruder but must wait for a business owner to approve isolation, losing hours.
- A SOC renamed as a CSIRT. Monitoring staff are given incident ownership without coordination skills, legal and communications contacts, or time.
- Dormant accounts outside scope. Legacy remote access accounts belong to nobody. The Colonial Pipeline ransomware attack began with an unused VPN account without MFA, and the company shut down pipeline operations from 7 to 13 May 2021 while responders worked: the CSIRT's scope must include identity and remote access, and its plan must include how operations continue.
- Retainer never tested. The contract exists but onboarding, log access and contact routes were never exercised.
- No external contact point. Researchers and national CSIRTs cannot reach the team, so warnings arrive late or not at all.
- Stale contact details in the RFC 2350 description and call tree, discovered during the incident.
Practitioner checklist
- Approve a charter with mission, constituency, sponsorship and authority, reviewed by legal.
- Select launch services from the FIRST CSIRT Services Framework and document what is outsourced.
- Choose an organisational model and name every role, including identity, legal and communications contacts.
- Stand up a 24x7 route: on-call rota or retainer with a tested response time.
- Publish the incident response plan, severity matrix, playbooks and evidence handling procedure.
- Publish an RFC 2350 description, security contact and encryption key; use TLP for all sharing.
- Register with the national CSIRT and sector ISAC; consider Trusted Introducer and FIRST.
- Exercise the team before go-live and at least annually.
- Run a SIM3 or ENISA self-assessment every year and track the score.
Standards and references
- FIRST: CSIRT Services Framework Version 2.1
- IETF: RFC 2350 Expectations for Computer Security Incident Response
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- ENISA: CSIRT Maturity Framework
- Open CSIRT Foundation: SIM3 and References
- Trusted Introducer: Accreditation Process
- FIRST: Membership
- Carnegie Mellon SEI: Organizational Models for CSIRTs
Related NHI Mgmt Group resources: Building a SOC from Scratch Guide · Incident Response Guide · PSIRT Guide · Incident Response Maturity Model