Complete Guide to CSIRT: How to Build an Incident Response Team

The Complete Guide to CSIRT Organization: How to Build an Incident Response Team

July 19, 2018

Tim Matthews

Learn the latest best practices for organizing and managing a Computer Security Incident Response Team (CSIRT).

A computer security incident response team (CSIRT) can help mitigate the impact of security threats to any organization. As cyber threats grow in number and sophistication, building a security team dedicated to incident response (IR) is a necessary reality.

In this blog we discuss how to organize and manage a CSIRT and offer tips to make your incident response team more effective. First, let’s define the role and scope of your CSIRT team, consider beginning by following a four-step process to help organize and manage your team.

Figure 1: This four-step process helps to organize and manage a computer security incident response team (CSIRT).

What is a CSIRT?

A CSIRT is a group that responds to security incidents when they occur. Key responsibilities of a CSIRT include:

  • Creating and maintaining an incident response plan (IRP)
  • Investigating and analyzing incidents
  • Managing internal communications and updates during or immediately after incidents
  • Communicating with employees, shareholders, customers, and the press about incidents as needed
  • Remediating incidents
  • Recommending technology, policy, governance, and training changes after security incidents

Overall, a CSIRT analyzes incident data, discusses observations, and shares information across the company. Some of these responsibilities may be shared with other organizations, which we will discuss below.

How CSIRTS differ from CERTs and SOCs

There are overlapping responsibilities between a community emergency response team (CERT), computer security incident response team (CSIRT), and security operations center (SOC). Adding to the confusion, frequently the terms CERT and CSIRT are used interchangeably, despite the important differences. To add clarity, let’s start by defining the role of each team with background on where the teams originate.

A security operations center (SOC) is a facility where an organization’s network, applications, and endpoints are monitored and defended. The term was adapted from network operations centers (NOC), where large telecommunication or corporate networks are monitored. When network security became more of a concern, security teams were formed within the NOCs and eventually were spun off into larger organizations as the responsibilities of security teams became more complex and specialized. The security staff working in a security operations center are often called the SOC team.

Figure 2: Understand the primary roles and characteristics of a CERT, CSIRT, and SOC.

The term “Computer Emergency Response Team” was coined in 1988. In response to the Morris worm attack that impacted thousands of servers on the Internet, DARPA funded the formation of the Computer Emergency Response Team Coordination Center (CERT-CC) at Carnegie Mellon University. The goal of CERT-CC was to help protect the Internet by collecting and disseminating information on critical security vulnerabilities. Several other countries formed similar centers using the same acronym (despite threats of legal action by Carnegie Mellon for trademark infringement). Now the term CERT applies to any emergency response team dealing with cyber threats. Many people use CERT-CC interchangeably with CSIRT, though the charter of a CERT is information sharing to help other response teams respond to threats against their own infrastructure.

A CSIRT is responsible for responding to security incidents. A comprehensive response includes both technical actions taken to remediate the incident and recommended changes to systems to protect against future incidents. There are several nontechnical aspects to a response, including employee communications, responding to press inquiries, dealing with legal issues, and any personnel issues in the event of insider action. (Other names for CSIRT include computer incident response team (CIRT) and incident response team (IRT).)

To sum up, using strict definitions, a CERT collects and disseminates security information, typically for the benefit of a country or industry. A CSIRT is a cross-functional team that responds to incidents on behalf of a country or organization. A SOC is where a country or organization monitors and defends its network, servers, applications, and endpoint computers.

Selecting an organization type: Deciding on either a CSIRT, CERT, or SOC

Using the strict definitions above, the choice between a CSIRT and CERT is straightforward. Unless your goal is to collect and disseminate information on security vulnerabilities on behalf of a country (which probably is already covered) or industry (which likely already exists), then your choice is narrowed down to either a CSIRT or SOC.

If your incident response team roles include monitoring and defending your organization against cyber attacks, you are looking at building and staffing a SOC. If your organization is too small to afford a SOC, or you have outsourced your SOC (which is common for smaller organizations), then you will want a CSIRT to deal with security incidents as they occur. Again, the response may not be technical, but the response requires legal or PR expertise.

Table 1: How to decide on utilizing a CERT, CSIRT, or SOC team.

How to Organize a CSIRT

Organizing your CSIRT involves determining who will be on the team, their roles and responsibilities, which functions to outsource, and where your team members will be located.


As mentioned, the CSIRT is a cross-functional team that will coordinate during incidents. The CSIRT should also hold quarterly meetings to review past incidents and make recommendations on changes to policy, training, and technology. Lastly, the team should participate in drills at least twice a year. These drills are considered “table-top incidents” where CSIRT members act out what they would do in the case of an incident, so that the team stays sharp and works out any issues.

To build your CSIRT team, here is a list of the talent you will need, along with the different CSIRT roles and responsibilities:

Team Leader or Executive Sponsor: Typically, this is the CISO or a member of the executive staff. The key role of the team leader is to communicate incidents to the executive staff and board and to assure that the CSIRT gets appropriate attention and budget.

Incident Manager: This manager or executive can work across the organization and is responsible for calling meetings and holding team members accountable for their action items. The incident manager also summarizes findings and any impacts to communication throughout the company before escalating issues up to higher levels.

Lead Investigator: This technical resource, such as a security analyst or dedicated incident responder in the SOC, is responsible for investigating the occurrences during a security incident. The lead investigator may work with an extended team of security analysts and forensic investigators.

Communication and Public Relations: Ideally, this is an individual on the marketing team responsible for public relations, fielding any press inquiries or statements, as needed, and drafting communications to be sent to employees, partners, and customers. The monitoring of social media should also be handled by this individual.

Legal: The general council or a deputy member of the legal team, this individual advises on the need to disclose incidents, such as a breach, and deals with any of the fallout resulting from the security incident, such as shareholder or employee lawsuits.

Human Resource Representative: This position is typically filled by the head of HR, who can manage any personnel-related issues that occur, especially if they involve insider theft.
The HR representative also gives suggestions for how incidents are communicated to employees.

An outsourced versus internal CSIRT team

Since the CSIRT roles and responsibilities are cross-functional and involve more than technical staff, it is unlikely to be entirely outsourced, and it probably shouldn’t be given how critical cybersecurity is for protecting business interests. That said, you may be able to outsource parts of the CSIRT team based on your budget and expertise. Here is a quick summary of the pros and cons of outsourcing the incident response team roles.

Table 2: Here are the pros and cons of outsourcing the various functions of your CSIRT.

Where should CSIRT staff be located?

One thing is true of security incidents: They always happen at the most inopportune times—on weekends, after business hours, or on holidays or personal vacations. Hackers have carried out major breaches during holiday shopping season when clerks are rushed and customers can be less diligent about examining their online purchases. Some have theorized that hackers attack on weekends or national holidays, knowing that security staff will not be able to catch them in the act.

For that reason, it’s important that CSIRT staff be dispersed geographically. Ideally, someone would be awake and available 24/7. Also, there should be redundancy for every team member such as having more than one legal expert and PR representative. An easy way to do this is for team members to assign delegates when they are unavailable or unreachable.

If you have a small organization, or one located in a single country but with customers worldwide, you can consider outsourcing CSIRT functions after hours, on weekends, and during holidays in your geographic area.

Developing an incident response plan

Although we are covering this topic at the end of the blog, creating an IR plan is the first thing a CSIRT should do. Organizations that lack experience can hire a consultant to help draft the plan. It is important that the team be fully staffed and participate in the plan creation–even if it’s done with an external consultant—so that the CISRT team has familiarity and a sense of ownership.

Here are the critical steps in developing an incident response plan (IRP). (It really doesn’t matter if these are slides or documents or spreadsheets.) The most important thing is that the plan is easy to find during the panic of a potential crisis, and simple to understand for by someone who is overwhelmed.

Gain executive buy-in: Your team leader will be the one to spearhead gaining executive buy-in. If this individual is a member of the executive team such as the CIO or CISO, then this step will be easier. Make sure the CEO, CFO (who may deal with investors), chief counsel, and other key members of the executive team are informed and in agreement on the charter. The CSIRT will be looking at sensitive information and communicating delicate details, so it is essential that the team be trusted and supported at the executive level.

Confirm roles and responsibilities: Based on the staffing guidelines above, confirm what all the role is and ensure that everyone is in agreement. Establish a backup for each role in case someone is on vacation or otherwise unreachable. Importantly, get agreement from your CEO or other executives when executive approval is needed, and decide on what situations the CSIRT can act on its charter.

Document critical assets: Map out your critical systems and intellectual property. Understand the value of source code or web properties. Know the financial impact of a network going down. You want to know the impact to the business when something goes down or goes missing such as critical data. One critical asset is your customer database. There may be breach notification requirements and even penalties. Examining reports from past audits may also be useful in this step.

Establish a communications plan and protocol: Establish how the team will communicate. For example, we had a crisis where half the incident response team was waiting on a conference bridge and the other half was waiting on Slack. In such a case, who would initiate the call? Who would initiate it if that person was not around? How often should you provide updates to the executive team? When would you need to get permission from an executive who was not on the team? Ideally, consider all scenarios and work out approvals in advance.

Draft core communications in advance: List all your potential incidents in advance, such as theft of customer data, critical system compromise, network or site down, cyber bullying by an employee, and so on. Then draft potential tweets for social media, short statements for the press, and even a press release for a serious incident that requires legal disclosure. Previously, these were called “drawer statements” as they were kept in the desk drawer for emergencies. Once drafted, have them vetted and approved by your legal team– that way you don’t need approvals in the middle of a fire drill.

Prepare by conducting drills: Like the communications issues we mentioned above, there are many things that can go wrong or fall through the cracks during a crisis. Have your team leader organize periodic drills and walk through your process. It will not only highlight potential issues, but drills also give the team more confidence.

Socialize the CSIRT charter to the company: First, have your CEO and executive team review and approve the CSIRT’s charter and draft plan. Once you have approval, let your company know about the CSIRT and its charter. Also, let the company know how you will be communicating with during a public security incident. The last thing you want is every salesperson in the company emailing your PR person (or worse, your CEO) asking about what is happening. Lastly, make it clear that only members of the CSIRT will be writing and disseminating communications to customers and partners.

Ultimately, you will learn from experience. so it’s important that you continually collect feedback and refine your process. This may involve making a number of adjustments such as adding or changing team members and changing how you communicate.

Security incidents will happen that are outside of your control. How you build a CSIRT team dedicated to dealing with these incidents will depend on you.

Editor’s Note: Tim Matthews was previously a CSIRT member at a public company, responsible for communications and public relations during incidents.

Want to learn more about Incident Response?
Have a look at these articles:

Recent Incident Response Articles

Turnkey Playbooks Now Available for Exabeam Customers

Read More

EDR vs EPP: What is the Difference?

Read More

Securing Your Remote Workforce, Part 3: How to Detect Malware in the Guise of Productivity Tools

Read More

Beat Cyber Threats with Security Automation

Read More

National Cybersecurity Awareness Month: Incident Response

Read More

Recent Information Security Articles

Exabeam Fusion XDR and Exabeam Fusion SIEM now available in Google Cloud Marketplace

Read More

SOC Analyst: Job Description, Skills, and 5 Key Responsibilities

Read More

Cybersecurity Awareness Month: Time to Recalibrate and Prioritize Security

Read More

SOC Processes and Best Practices in a DevSecOps World

Read More

Cloud SIEM: Features, Capabilities, and Advantages

Read More

Ransomware: Prevent, Detect and Respond

Read More