Team Types Within the Context of FIRST Services Frameworks

Version 1.0
Also available in PDF

1. Purpose

As of October 2023, specific Forum of Incident Response and Security Teams (FIRST) Services Frameworks have been developed for two team types: Computer Security Incident Response Teams (CSIRTs) and Product Security Incident Response Teams (PSIRTs). While there are established definitions of CSIRT and PSIRT, in practice and within some communities or contexts, they have slightly different meanings. Rather than simply building on these established definitions, volunteers from the global community in the CSIRT Framework Development Special Interest Group (CSIRT SIG) are working diligently to develop an informal shared understanding of these and other relevant terms.

Other types of teams (e.g., Security Operations Centers [SOCs] and Information Sharing and Analysis Centers [ISACs]) are becoming increasingly vital for addressing urgent cyber insecurity. Therefore, it is necessary to establish standard definitions for at least some of these teams as well. In 2022, experts in the global community discussed this need, which resulted in a CSIRT SIG project to define standard types (and terms) for teams that provide information security incident management capabilities: CSIRTs, ISACs, PSIRTs, and SOCs. (In this report, we, the members of the CSIRT SIG, discuss these four team types in greater detail in Section 3.)

When discussing these team types and the terms that describe them, the CSIRT SIG team did not address national or sectorial variants; however, it plans to address them in the future. The CSIRT Services Framework explains current and well-established terms, such as coordinating CSIRT and enterprise CSIRT, and there is nothing wrong with using those terms. However, until definitions of the four basic team types are widely accepted, it might not be beneficial to provide additional details, and it might even hinder discussions.

Future versions of this document will include definitions for team sub-types based on a wider discussion and the adoption of the above four basic team types. The terms describing these team types that we outline in this report are the first ones the global community is considering.

2. Background

Over time, various entities (e.g., organizations, governments) in the CSIRT community have developed their own service lists and/or frameworks. However, as technology, tools, and processes have evolved, the community has realized that these lists and frameworks do not address certain topics and activities.

FIRST is interested in enabling the global development and maturation of CSIRTs and other security incident management entities. We launched a community-driven approach to developing an improved CSIRT Services Framework as part of the CSIRT SIG, and an initial version was published in 2017. As illustrated in Figure 1, the current version (v2.1) contains five distinct service areas and 21 associated services.

Five Service Areas and Their Associated Services
Figure 1: The CSIRT Services Framework’s (v2.1) Five Service Areas and Their Associated Services

After the initial release of the CSIRT Services Framework, a similar approach was taken to develop a PSIRT Services Framework that recognizes the many operational aspects of PSIRTs that require a different set of services and corresponding activities. The first PSIRT Services Framework was published in 2018.

Interdependencies of Service Areas
Figure 2: The PSIRT Services Framework’s (v1.1) Interdependencies of Service Areas

The current versions of both the CSIRT Services Framework and the PSIRT Services Framework are available on the FIRST website.

The primary goal of these frameworks is to help establish and improve team operations. Other goals include helping teams identify and define their core categories of services and providing a standard set of terms and definitions that the community can use. The services described in these frameworks are those that a team could provide; in other words, no team is expected to provide all of the described services but can select the ones that support its mission and constituents as described by its mandate.

FIRST also recognizes that defining team types is a vital step in developing a common language for describing incident management entities and their capabilities. Therefore, in this report, we focus on team types.

3. Team Types: Capabilities that Handle Security Incidents, Threats, and Vulnerabilities

Different types of teams have various roles within the realm of information security to prevent, detect, analyze, resolve, and/or mitigate information security incidents, threats, and/or vulnerabilities. These roles are evident not only because FIRST and other communities serve as forums for CSIRTs, but because these forums also bring together incident management and security teams, which have similar capabilities, to gather, discuss, and share information and develop resources.

In Section 1, we discussed the need to define four team types that provide information security and incident management capabilities: CSIRTs, ISACs, PSIRTs, and SOCs. In this section, we define each of these team types and provide profiles that show where some team types might be integrated.

CSIRTs, ISACs, PSIRTs, and SOCs can coexist. For example, a large, broadly scoped SOC might include a CSIRT as one of its divisions or departments; a CSIRT might include a SOC; and an ISAC may include a SOC or a CSIRT.

The hierarchy of these teams is not the most important aspect of the profiles we provide. What is most important are the following descriptions:

  1. the responsibilities and activities that each team or capability provides1:
  2. how to help members of the global community understand the differences2:

Both types of information will ultimately enable members of the global community categorize their own team or capability in a commonly accepted manner.

We based our definitions on the descriptions of services in CSIRT Services Framework, Version 2.1 since it provides a unique and consistent namespace. We recognize that the PSIRT Services Framework uses a different namespace, so we plan to map both namespaces in the future.

In subsequent reports, we will also describe other team types (e.g., national CSIRTs, sectorial CSIRTs) that are considered sub-types of the four team types listed above.

3.1 Computer Security Incident Response Teams (CSIRTs)

CSIRTs provide services and support to a defined constituency. They manage information security incidents by preventing, handling (i.e., detecting, analyzing, responding), and/or coordinating information security incidents.

A CSIRT is often referred to as a CERT (Computer Emergency Response Team), CIRT (Computer Incident Response Team), CIRC (Computer Incident Response Center), CSIRC (Computer Security Incident Response Capability), or other name or abbreviation based on the objectives of the organization selecting its name. In the context of incidents, sometimes the word computer is used interchangeably with cybersecurity, cyber, or information.

Regardless of the name used, this type of team specializes in information security incident management services. CSIRTs in other settings can specialize in information technology (IT) security, operational technology (OT) security, or specific subsets of information security. Some teams have an even narrower focus and provide services related only to incidents related to data protection or malware.

A properly deployed CSIRT has a clear mandate, a governance model, a tailored services framework, technologies, and processes to provide, measure, and continuously improve defined services to raise its maturity. It might be established as a single unit, an independent organization, or a part of a larger cybersecurity organization like in many national cybersecurity centers (NCSCs).

National CSIRTs (nCSIRTs) and sectorial CSIRTs (including government CSIRTs) are special types of CSIRTs that focus on coordinating the response to information security incidents, threats, and vulnerabilities. Therefore, they provide all the services that are mandatory for any CSIRT. We will describe these and other CSIRT sub-types in future versions of this documents (release planned for mid of 2025).

Table 1 illustrates the services that a CSIRT can and must offer. The services that CSIRTs must offer are labeled MUST.

Computer Security Incident Response Teams (CSIRTs)

Service Area Associated Services Offering
Information Security Event Management Monitoring and Detection  
Event Analysis  
Information Security Incident Management Information Security Incident Report Acceptance MUST
Information Security Incident Analysis MUST
Artifact and Forensic Evidence Analysis  
Mitigation and Recovery MUST
Information Security Incident Coordination MUST
Crisis Management Support  
Vulnerability Management Vulnerability Discovery/Research  
Vulnerability Report Intake  
Vulnerability Analysis  
Vulnerability Coordination  
Vulnerability Disclosure  
Vulnerability Response  
Situational Awareness Data Acquisition  
Analysis and Synthesis  
Service Communication  
Knowledge Transfer Awareness Building  
Training and Education  
Exercises  
Technical and Policy Advisory  

Table 1: CSIRT Service Offerings: Information Security Incident Management Service Area

Two service offerings, although important, are not mandated for all CSIRTs: Artifacts and Forensic Evidence Analysis and Crisis Management Support. Because of their unique nature, we describe them in more detail:

Artifact and Forensic Evidence Analysis

This is an important service for managing information security incidents and enabling a meaningful response. However, this service requires a significant level of expertise and relies on costly resources, which may not always be readily available or cost effective in an organizational setting, especially for small teams. While it might pose challenges, it is likely more cost effective for an internal CSIRT to outsource this service and pay only for instances that require such detailed analysis. For these reasons, we do not consider Artifact and Forensic Evidence Analysis a MUST for all CSIRTs to offer.

Crisis Management Support

This service is not considered a MUST for all CSIRTs to offer. During large critical incidents, significant resources are required for coordination, communication, and overall management. If a CSIRT is not appropriately staffed, these activities may compete with other activities, such as technical investigations, incident analysis, incident response, and incident mitigation. The result can be mismanaged or poorly handled information security incidents.

Crisis Management Support typically involves a broad scope of the organization and might not even be caused by an information security incident but rather a disaster or significant outage of equipment not related to malicious cyber activity. Since Crisis Management Support often requires multiple teams and departments of an organization to collaborate, a CSIRT is clearly one of the units that could be involved. However, in most cases, even in a cyber or information security incident, the CSIRT might not take the lead in managing the crisis. While a CSIRT may not be equipped to manage all types of crises, its support might be crucial, especially if a crisis affects the information infrastructure or critical information system assets.

3.2 Information Sharing and Analysis Centers (ISACs)

ISACs are industry-specific organizations or capabilities that gather, analyze, share, and coordinate information about cyber threats and incidents among critical infrastructures or industry sector entities (e.g., the finance sector). ISACs can also facilitate data sharing among public and private sector groups in accordance with government policies or national laws and might even be organized as public-private partnerships.

In the United States, ISACs are required in specific industry sectors. In other regions or countries, ISAC activities are driven by the industry they belong to, but they cover more sectors. For example, in Europe, an effort was made to collect information about various ISACs3. An information sharing and analysis organization (ISAO) is an alternative name for an ISAC and ISAC-type organizations.

ISACs focus on analyzing information security attacks, incidents, and threats based on the insights gained through situational awareness. They focus on collecting threat information, analyzing it, and creating intelligence. Synthesizing and disseminating this information is designed to help organizations that experience incidents to become more cyber resilient and capable of taking proactive steps when new trends are identified or when developments occur.

Table 2 illustrates the services that an ISAC can and must offer. The services that ISACs must offer are labeled MUST. ISACs focus on situational awareness services, but they might also handle some aspects of information security incident management and/or vulnerability management, usually with an emphasis on incident or vulnerability coordination and especially supporting dissemination and communication.

Service Area Associated Services Offering
Information Security Event Management Monitoring and Detection  
Event Analysis  
Information Security Incident Management Information Security Incident Report Acceptance  
Information Security Incident Analysis  
Artifact and Forensic Evidence Analysis  
Mitigation and Recovery  
Information Security Incident Coordination  
Crisis Management Support  
Vulnerability Management Vulnerability Discovery/Research  
Vulnerability Report Intake  
Vulnerability Analysis  
Vulnerability Coordination  
Vulnerability Disclosure  
Vulnerability Response  
Situational Awareness Data Acquisition MUST
Analysis and Synthesis MUST
Service Communication MUST
Knowledge Transfer Awareness Building  
Training and Education  
Exercises  
Technical and Policy Advisory  

Table 2: ISAC Service Offerings: Situational Awareness Service Area

3.3 Product Security Incident Response Teams (PSIRTs)

PSIRTs focus on vulnerability management in products and services. They are specialized teams or capabilities that respond within vendor organizations or service providers to handle and resolve vulnerabilities in products or services. Many vendors or service providers, including open source communities, have already established PSIRTs to provide the following services:

  1. Track, mitigate, and fix vulnerabilities in their own products.
  2. Disseminate information about product security updates.

PSIRTs might also provide information security incident management services and situational awareness by supporting incident response coordination, communication, and the mitigation of actively exploited vulnerabilities or the discovery of new threats within their customer base or the broader community.

Table 3 illustrates the services that a PSIRT can and must offer. The services that PSIRTs must offer are labeled MUST.

Service Area Associated Services Offering
Information Security Event Management Monitoring and Detection  
Event Analysis  
Information Security Incident Management Information Security Incident Report Acceptance  
Information Security Incident Analysis  
Artifact and Forensic Evidence Analysis  
Mitigation and Recovery  
Information Security Incident Coordination  
Crisis Management Support  
Vulnerability Management Vulnerability Discovery/Research  
Vulnerability Report Intake MUST
Vulnerability Analysis MUST
Vulnerability Coordination MUST
Vulnerability Disclosure MUST
Vulnerability Response MUST
Situational Awareness Data Acquisition  
Analysis and Synthesis  
Service Communication  
Knowledge Transfer Awareness Building  
Training and Education  
Exercises  
Technical and Policy Advisory  

Table 3: PSIRT Service Offerings: Vulnerability Management Service Area

A service offering, although important, is not mandated for all PSIRTs: Vulnerability Discovery/Research. Because of its unique nature, we describe it in more detail below:

Vulnerability Discovery/Research is a service that identifies new vulnerabilities. Identifying vulnerabilities enables a meaningful response by the PSIRT. However, to handle known vulnerabilities, these services require significant resources, which are not always available. As other sources of knowledge about new (i.e., yet unknown) vulnerabilities become available, it is reasonable to exclude Vulnerability Discovery/Research from a PSIRT’s portfolio. Therefore, we do not consider Vulnerability Discovery/Research in the mandatory services that a PSIRT offers.

The following definition of PSIRT is from the latest version of the PSIRT Services Framework4:

A Product Security Incident Response Team (PSIRT) is an entity within an organization which, at its core, focuses on the identification, assessment and disposition of the risks associated with security vulnerabilities within the products, including offerings, solutions, components and/or services which an organization produces and/or sells.

While there are important differences between any CSIRT and PSIRT, it is crucial to recognize that there is also synergy between these two team types. The key takeaway is that CSIRTs and PSIRTs do not operate independently; they often work together. For example, many CSIRTs warn constituents about security vulnerabilities; these warnings are almost always based on information that vendor PSIRTs provide.

A well-deployed PSIRT is not an isolated group; it remains closely connected to the development of the organization’s products and is part of the organization’s broader secure engineering initiative. This organizational structure ensures that security assurance activities are integrated into the secure development lifecycle (SDL).

Product security incident response is often associated with the maintenance phase of the SDL since most product security vulnerabilities are reported as quality escapes5 after the product’s release to the market. However, PSIRTs can have a significant impact in early requirements gathering during architecture, design, planning, and risk modeling phases. PSIRTs can also add value by providing guidance and oversight for handling security issues found internally (e.g., during development).

3.4 Security Operations Centers (SOCs)

SOCs typically handle many different facets of security operations and focus on information security event management (i.e., event monitoring and detection).

A SOC monitors the networks and systems of its parent organization or constituency for unusual, anomalous, or suspicious activity using some type of software or hardware (e.g., network taps, endpoint detection, sensors, or other similar products).

Some SOCs may also perform response activities using automated or predefined use cases or playbooks; they escalate any issues that do not align with those cases/playbooks to established contacts, or they promptly alert victim organizations.

SOCs may provide information security incident management services and vulnerability management services independently or rely on other teams for support.

Table 4 illustrates the services that a SOC can and must offer. The services that SOCs must offer are labeled MUST.

Service Area Associated Services Offering
Information Security Event Management Monitoring and Detection MUST
Event Analysis MUST
Information Security Incident Management Information Security Incident Report Acceptance  
Information Security Incident Analysis  
Artifact and Forensic Evidence Analysis  
Mitigation and Recovery  
Information Security Incident Coordination  
Crisis Management Support  
Vulnerability Management Vulnerability Discovery/Research  
Vulnerability Report Intake  
Vulnerability Analysis  
Vulnerability Coordination  
Vulnerability Disclosure  
Vulnerability Response  
Situational Awareness Data Acquisition  
Analysis and Synthesis  
Service Communication  
Knowledge Transfer Awareness Building  
Training and Education  
Exercises  
Technical and Policy Advisory  

Table 4: SOC Service Offerings: Information Security Event Management Service Area

4. Overview and Considerations

We studied the mandatory services that characterize each of the four basic team types (i.e., CSIRTs, ISACs, PSIRTs, and SOCs) that provide information security incident management capabilities. In this section, we summarize our findings and address specific questions about these team types. This section is a comprehensive record of our work in the CSIRT SIG to develop an informal shared understanding of these team types and their capabilities.

4.1 Defining Four Basic Team Types

Table 5 is an aggregation of the four tables introduced in earlier sections. It illustrates that four of the five service areas each provide the foundation for a defined basic team type.

Service Area SOC CSIRT PSIRT ISAC
Information Security Event Management
Monitoring and Detection MUST - - -
Event Analysis MUST - - -
Information Security Incident Management
Information Security Incident Report Acceptance - MUST - -
Information Security Incident Analysis - MUST - -
Artifact and Forensic Evidence Analysis - - - -
Mitigation and Recovery - MUST - -
Information Security Incident Coordination - MUST - -
Crisis Management Support - - - -
Vulnerability Management
Vulnerability Discovery/Research - - - -
Vulnerability Report Intake - - MUST -
Vulnerability Analysis - - MUST -
Vulnerability Coordination - - MUST -
Vulnerability Disclosure - - MUST -
Vulnerability Response - - MUST -
Situational Awareness
Data Acquisition - - - MUST
Analysis and Synthesis - - - MUST
Communication - - - MUST
Knowledge Transfer
Awareness Building - - - -
Training and Education - - - -
Exercises - - - -
Technical and Policy Advisory - - - -

Table 5: Mapping of Service Areas to Team Types

4.2 Why Knowledge Transfer Is Not a Must for Any Team Type

All four team types (i.e., CSIRT, ISAC, PSIRT, SOC) likely perform some services of the Knowledge Transfer service area. This service area is crucial for each type of incident management or security capability because these capabilities collect relevant data; perform detailed analysis; identify threats, trends, and risks; and create best current operational practices to help organizations detect, prevent, and respond to information security incidents. Transferring this knowledge to their constituents is crucial to improving overall information security at organizational and community levels.

The Training and Awareness service is important to all incident management capabilities and their constituencies. It may be more prevalent in CSIRTs and ISACs, but for defined communities of interest, PSIRTs and SOCs can also conduct this service. Training exercises are suitable for all four team types and technical or policy advisory roles.

However, it is resource intensive for any incident management capability to develop and deliver training materials; therefore, it is not always possible to provide the Training and Awareness service. It is often more effectively handled by specialized units of a team’s parent organization (e.g., a training group or an external third-party contractor with expertise in knowledge transfer). When specialized units provide this service, the ideal approach involves these units gathering input from the incident management team and subsequently producing content based on this input, which is then delivered in training and distributed in materials.

For these reasons, no Knowledge Transfer activities should be considered a MUST for any of the four team types. However, this does not mean that these team types would not provide these services, but these services are not mandatory for CSIRTs, ISACs, PSIRTs, or SOCs.

4.3 Why We Did Not Define Managed Security Service Providers

Managed security service providers offer a variety of security incident management related services, which would be considered a CSIRT or SOC offering in most other contexts. It is entirely acceptable to provide a range of services, especially when customers are paying for them.

Therefore, we believe that it is acceptable to offer CSIRT services to customers, but when they are offered, they should be compatible with our definition of services offered by a CSIRT. That means that additional services might be offered, but no service considered mandatory (i.e., labeled MUST) should be omitted.

For marketing reasons, service providers may call themselves whatever they want. Ultimately, it is the responsibility of the customer to confirm whether the services offered fulfill their requirements.

Global or national cybersecurity communities may consider investigating “false flag” operations that deliberately use marketing terms without providing the services typically associated with the team’s name.

4.4 Why We Did Not Define a SOC as Part of a CSIRT or Vice Versa

As we described earlier, a SOC and a CSIRT can be implemented independently since they each can provide distinct services. However, if both teams exist within the same organization, it is imperative to establish suitable interfaces between them.

In many contexts, only one team exists—either a SOC or a CSIRT. However, whichever team it is must be careful about the services it offers. A name that includes only CSIRT or SOC might not represent the entire set of services it provides. The name only reflects the focus of the team and the emphasis of the parent organization. This is especially obvious when we analyze the requirements further:

This framework does not address how two team types that collaborate to respond to information security incidents are structured inside the organization and which is the principal team that is ultimately responsible for the services provided. As part of its governance structure, the organization must define the roles and responsibilities and the authority of both team types. In practice, some organizations form these combined teams and call them a SOC; other organizations use CSIRT as part of the name. Both approaches are acceptable; there are no rules about how to name an internal team.

4.5 Why We Did Not Define a New Name for a Combined CSIRT and PSIRT

In some organizations that are typically categorized as vendors, various incident management capabilities coexist. Originally, mostly CSIRTs and PSIRTs coexisted; however, a SOC (at least) will now also likely coexist with the CSIRT and PSIRT in these settings. Since CSIRTs and PSIRTs share some common needs and are built on similar internal support services (e.g., a hotline for their constituents), some vendors decided to include both services in the same organizational unit.

Sometimes, those units find it difficult to communicate that they are both a CSIRT and PSIRT. Instead of using naming including the team type, like “NAME CSIRT and PSIRT” they prefer to use a unique name like “NAME XYZ.” To date, no naming conventions have been developed; however, most vendors seem to prefer establishing internal CSIRTs that manage their own information assets and infrastructures independently from customer-focused PSIRTs because of the very distinctive needs of the constituencies each of them serves.

4.6 Why We Did Not Define CDC or NCSC

Some organizations started as a CSIRT and added more services and personal resources, only to find that over time, they were doing much more than a typical CSIRT. Therefore, they chose to use other team names, such as CDC (Cyber Defense Center) or CSC (Cyber Security Center), to convey that the combined team is more than just a CSIRT, ISAC, or SOC.

Interestingly, both abbreviations are used in different communities. To date, CDC is used in companies, government or sector organizations where other security services are combined with CSIRT services but also ensure an appropriate level of information security through proactive measures. Sometimes CSC is used for these teams, but CSC is more often used within a national context for National Cybersecurity Centers (i.e., NCSC).

Although CDCs, CSC, or NCSCs are recognized for their combined capabilities, the specific security incident management services they provide are not distinct from those provided by the four basic team types defined in this framework and are therefore already covered

ANNEX 1: Acknowledgments

The following volunteers from the global community contributed significantly to the initial release of this report. They are listed in alphabetical order by their last name, without a title but with their affiliation and/or country::

ANNEX 2: Supporting Resources

  1. Information security can always be replaced with cybersecurity without affecting our discussion or definitions. ^
  2. In computing, a namespace is a set of names used to identify and refer to objects to ensure that all of a given set of objects have unique names and can be easily identified. In this report, we use namespace to refer to the names given to team types and the services they provide. ^
  3. For more information about European Union ISACs, see their website: https://www.isacs.eu/european-isacs ^
  4. For more information about PSIRTs, see the PSIRT Services Framework, Version 1.1 ^
  5. A quality escape is when development and testing fail to identify/resolve a vulnerability, allowing it to reach the customer. ^