In our last post we introduced some of the key principles of incident response. Today we will focus on the major roles and organizational structure.

Organizational Structure

As we return to our IT security focus, the incident response organization consists of two major kinds of resources: those dedicated completely to response, and those with other primary functions who get pulled into incidents as needed depending on the scope or nature. For example, the legal team isn’t necessarily involved in every incident, but clearly plays an important role in anything with legal or regulatory consequences.

Also, a smaller organization might have no dedicated resources, while a larger one may have a full time team with defined roles, which deals with multiple overlapping incidents. That’s okay because the structure and system can expand and contract as needed if you follow the ICS principles.


These individuals and roles may not spend all their time on incident response, but are the key roles to fill when an incident occurs. One person can fill multiple roles, especially for a smaller incident or organization, but only if they have the right skill set.

  • Team Lead/Incident Commander: The person with overall responsibility and accountability for the direct management of incidents. Typically reports to the CISO, CIO, or even CEO, but following unity of command, should definitely only be accountable to a single manager. When an incident triggers, the first person to respond is the incident lead until they hand off responsibility to someone of equal or higher authority. That way someone is always in charge, even if only for the first few minutes. Command is then handed off to higher and higher levels as needed. When you have a full-time team, the team lead/manager is also responsible for ongoing training, program development, and so on.
  • Network Analysts: Experts in analyzing network packets/traffic, including forensic captures. Analysis includes ongoing monitoring, as well as deeper investigation during incidents.
  • Systems Analysts: Experts in analyzing endpoints and servers.
  • Forensics Analysts: Often a subspecialty of systems analyst, these individuals have deeper training in forensic investigation – which includes both the technical skills for the forensics examination of a system, and the legal training to properly handle evidence if there may be legal considerations (keep in mind that merely firing someone may lead to civil legal action).
  • SIEM/Log Management Analysts: Individuals experienced in monitoring SIEM output and log analysis.
  • Network, Systems, Database, and Application Administrators: Those individuals responsible for the maintenance of systems and networks. It is their responsibility to implement defensive mitigations during and after an incident, and to clean up affected systems. A firewall/IPS administrator might be responsible for closing the entry or egress points being used by the attacker. Systems administrators might roll out patches or configuration changes to host firewalls. A DBA might change account permissions or close out connection methods. This is a rather large bucket, and in most organizations these people operate at the direction of dedicated incident responders or other members of the security team.
  • Legal, Human Resources, and Risk: Any time an incident might involve legal action, employees, or a material costs, you should involve any required combination of these business units.
  • Communications/PR: If an incident has public impact, such as breach notifications, it’s critical to involve those responsible for organizational communications.
  • Accounting/Finance: Incident response costs money. It’s important to include the bean counters early, even if only to pay for the pizza and Red Bull. They can also take responsibility for tracking ongoing incident costs so those of you responsible for stopping and cleaning the problem don’t have to spend your time spinning accounting spreadsheets.
  • Logistics: This role can be a bit nebulous, but includes those responsible for getting the things you need during an incident. It may be someone from finance, the purchasing team, or the security team. Basically it’s someone with a credit card and the authority to use it. They keep people fed, purchase needed hardware and software, and hire outside experts.
  • Communications: Those responsible for making sure responders (and management) can communicate. You might only need this role in a big incident, but make sure you identify people ahead of time who can keep you talking – via cell phones, landlines, email, IM, or whatever other mechanism isn’t totally pwned.
  • Executive Management: We list them last, but they are ultimately responsible for everything in the organization – including incidents. Except in the organization’s very largest incidents, they probably won’t be involved directly.

Yes, that is a large number of potential roles, but remember that not all are needed for every incident, and the same person might fill multiple roles based on organization and incident size. For example, in a small or mid-sized organization it isn’t unusual to have the team lead also be the network and systems analyst, and possibly also responsible for cleaning systems or reconfiguring the firewall.

In terms of structure, here is one approach:


Finally, don’t forget our key concepts for the organizational structure:

  • People should only report to a single manager.
  • Any manager should only command 3 to 7 other people, ideally 5.
  • The organizational structure fills in resources as needed. You don’t need everything, and what you do need you don’t need all the time. This is a scaffold to build on, not a permanent building.