What does an incident response team do and who is on it?

An incident response team verifies that an incident has happened, collects and analyzes evidence, limits the damage, finds the root cause and restores operations. It works alongside leadership, technology staff, legal and others. It can be staff, contracted or on call, and many organizations mix all three.

Is an incident response team still a separate group?

NIST SP 800-61 Revision 3, published in April 2025, makes a point that changes how teams are built. In the past, response was done almost exclusively by incident handlers from the organization's own team. Today, success depends on many internal and external parties with a wide range of roles, often spread across the world. Roles differ for each organization and sometimes by incident.

So think of a response capability, not only a team. The handlers are essential, but they cannot approve a shutdown, issue a legal notice or rebuild a database alone.

Who are the roles?

NIST lists examples. Based on its description:

• Leadership oversees response, allocates funding and may decide high-impact actions like shutting down or rebuilding critical services.
• Incident handlers confirm an incident occurred, gather and analyze data and evidence, prioritize activities and act to limit damage, find root causes and restore operations.
• Technology professionals include architects, engineers, administrators and developers who help respond and recover.
• Legal reviews plans and policies against applicable laws, including privacy, and can review supplier contracts that affect response.

The publication also lists public affairs and media relations, human resources, physical security and facilities, and asset owners such as system, data and business process owners. It treats third parties under contract as part of the picture too, under a shared responsibility model that the contract should spell out.

Staff, contract or on call?

Handlers might be on staff, on contract, or available when needed. NIST gives examples: outsourcing a security operations center to a managed security services provider, using a cloud provider's response team for incidents inside that cloud, or drawing on a parent organization, a business partner or law enforcement. Many organizations perform basic response themselves and call in third parties for certain incidents. Larger ones may have several teams, which NIST says should act as one coordinated entity so processes, procedures and training are consistent and information is shared.

What does a gap look like?

A constructed example: a 300-person software firm has two engineers who handle incidents when needed. A customer reports data in the wrong account. The engineers find the bug within hours. Then nobody knows who may tell the customer, whether a contract requires notice within a deadline, or who may approve taking the service offline. The technical fix is ready. The decisions are not.

That is a role gap, not a skill gap. A one-page list of named people and deputies for each role, plus contact details that work when email is down, would have saved the afternoon.

How to check or apply this

1. List the roles above and write one named person and one deputy for each. Include external contacts.
2. Record who can authorize high-impact actions, such as taking a service offline or rebuilding it.
3. Check contracts with managed service or cloud providers. Know what they respond to and how to reach them.
4. Keep contact details and the plan somewhere that works during an outage, such as a printed copy or a separate system.
5. Run a table-top exercise twice a year with leadership and legal present, using a realistic scenario.
6. After every incident or exercise, record what slowed you down and update the plan.
7. Map your plan to the CSF 2.0 functions in the NIST profile so gaps are easy to see.

Quick check

Sources

• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management

Last reviewed: 18 October 2026.