Cyber Incident Response Roles: Who Does What During a Breach?

Despite thoughts to the contrary, a cyber incident rarely remains within the security team. A suspicious login, compromised endpoint or unusual network activity can quickly spread like wildfire to become a business-wide crisis. At that point it tends to involve customer communications, legal obligations, operational disruption, financial decisions, executive scrutiny and more.

Yet organisations often only make preparations for the technical aspects of incident response without giving equal attention to something more fundamental: Who is actually in charge when an incident happens?

A single team doesn’t have the access or authority to handle the entire crisis on their own or appropriately. For example, the security team can investigate the incident, but it cannot decide whether a critical business service should be taken offline because they do not have insight into operational consequences. Legal teams can notify the right regulators or customers but they don’t necessarily know the technical facts required to make that initial judgement.

The challenge is therefore not simply having the right people available. It is giving people clearly defined responsibilities, decision rights and lines of communication before a crisis forces the issue.

The SP 800-61 incident-response recommendation by NIST (National Institute of Standards and Technology) reflects this eagle-eye-view approach of integrating any breach across all organisational operations.

Cyber Incident Response As a Coordinated Effort

Cybersecurity teams are often the frontline of security breach detection. They may detect malicious activity, investigate compromised systems, isolate affected devices and determine how an attacker gained access. But the consequences of a serious breach rarely stop at the technical boundary of the affected system.

Consider a ransomware attack that disrupts a critical customer-facing platform. The security team may recommend isolating the environment. IT may need to determine what can safely be taken offline. Legal needs to assess contractual and regulatory obligations. Finance may need to consider financial exposure and insurance requirements.

Senior leadership may ultimately have to decide whether restoring a service quickly is more important than preserving forensic evidence or whether a particular business operation should remain offline. None of these decisions clearly belong exclusively to cybersecurity.

Similarly NIST's Cybersecurity Framework 2.0 treats incident management as something that should be a coordinated organisational activity, including escalation, stakeholder communication, mitigation and recovery. This is why a mature incident response structure needs to know a) who is doing the work and b) who has the authority to decide what happens next.

The Roles Behind an Effective Cyber Response

1. The Incident Commander: Coordinating the Response

At the centre of a major incident should be someone responsible for overseeing and coordinating the cyber incident response plan. This person’s role is often described as an incident commander or incident manager.

The incident commander does not necessarily need to be the most senior person in the organisation, nor do they need to personally understand every technical detail. Their primary responsibility is to maintain a coherent response across multiple teams. That can include:

• Establishing the current situation.
• Setting response priorities.
• Coordinating different teams.
• Resolving conflicts between competing priorities.
• Escalating decisions that exceed their authority.
• Maintaining situational awareness.
• Ensuring key decisions are recorded.
• Making sure the response does not fragment into disconnected activities.

Without a central coordinating person, incident response can become a collection of conversations that merely occur parallel to one another. Security may be investigating one issue while IT is making changes elsewhere that can interfere with their investigation. Or communications is preparing a statement based on outdated information.

The incident commander is the nexus and connects all activities so they flow through a central hub. They are responsible for finding out what we know, what we’re trying to achieve, what needs to happen next and who has the authority to make it happen. And then make it happen by delegating activities.

2. Leadership: Making the Decisions Security Cannot Make Alone

Senior leadership has a different role from the incident response team. Executives should not be directing individual forensic investigations or deciding which firewall rule to change. Their responsibility is to make decisions related to business risk, resources and organisational priorities.

NIST's SP 800-61 Rev. 3 explicitly states that leadership should be responsible for overseeing incident response, allocating funding and potentially making high-impact decisions such as shutting down or rebuilding critical services.

Depending on the incident, leadership may need to decide:

• Whether a critical service should remain operational.
• Whether the organisation can accept a particular level of risk.
• Whether additional external resources should be brought in.
• Whether customers or partners should be informed.
• Whether the incident requires escalation to the board.
• Whether business operations need to be suspended.
• How competing business priorities should be balanced.

Avoid turning executive involvement into operational interference. Leadership provides authority and strategic direction while the incident commander coordinates the response within that direction.

This proverbial separation of church and state allows technical specialists to do their jobs while ensuring decisions with enterprise-wide consequences remain at the appropriate level.

3. Security and Incident Response: Establishing What Actually Happened

The technical response team is responsible for finding out what happened and also limiting the technical impact. Depending on the organisation, this could include a security operations centre, incident response team, security engineers, digital forensics specialists or an external incident response provider.

Their responsibilities may include:

• Validating that an incident has occurred.
• Investigating the attack.
• Identifying affected systems and accounts.
• Determining the scope of compromise.
• Analysing evidence.
• Identifying attack techniques and potential root causes.
• Containing malicious activity.
• Supporting eradication.
• Advising on technical recovery.

NIST describes incident handlers as responsible for verifying incidents, collecting and analysing evidence, prioritising response activities, limiting damage and helping identify root causes.

But technical teams should not operate in isolation. Their findings need to be translated into real-life business consequences. For example, from the security team’s perspective it’s meaningful to say that the database cluster has been compromised, but leadership needs to know what this means for operations. Managing that translation from team to team is one of the most important functions of the wider response.

4. Business and Service Owners: Understanding the Impact

Every significant security incident inevitably becomes a business question. A technical team can identify an affected application. The person responsible for that service can explain what consequences there are if it becomes unavailable.

Therefore, business or service owners provide context that security teams may not have. They can help determine:

• Which services are business-critical.
• Which dependencies can be temporarily disrupted.
• What level of degradation is acceptable.
• Which customers or internal teams will be affected.
• Which systems need to be restored first.
• What operational consequences a containment decision could create.

This context is especially important when containing the problem that ends up creating the most disruption. Disconnecting a compromised system might reduce risk from a cybersecurity standpoint but it can have the domino effect of stopping an essential business process.

5. Legal: Turning Technical Facts Into Obligations

Legal teams have the distinct responsibility in this scenario of determining what the incident means from a legal and regulatory perspective. This can include assessing:

• Whether a data breach has occurred.
• Whether notification obligations have been triggered.
• Which domains are involved.
• Whether contractual obligations apply.
• Whether law enforcement should be engaged.
• How communications should be handled.
• What evidence and documentation need to be preserved.

The legal function should not be expected to determine the technical facts itself. Instead, it should use the flow of information it receives from security and business teams to make decisions around legality. This makes information quality and timing critical.

A legal decision based on an incomplete understanding of the incident can be just as problematic as a technical decision based around incorrect data.

6. Communications: Circulate the Message Without Controlling the Facts

Not only do cyber incidents create a technical problem but also an informational one. Employees want to know what is happening. Customers may want reassurance. Partners may ask whether they are affected. Regulators may require information.

Communications teams need to manage how each piece of information is shared according to each audience’s unique needs. Their role can include:

• Preparing internal communications.
• Drafting customer and partner communications.
• Managing media enquiries.
• Coordinating executive messaging.
• Ensuring communications are consistent.
• Translating technical developments into understandable language.

But communications should not operate independently of the incident command structure. The communications team shapes HOW the message is communicated, but the security and legal teams need to establish WHAT can accurately and safely be communicated. That distinction becomes particularly important when the facts are still developing.

7. IT and Operations: Keeping the Business Running

The cybersecurity team often spearheads the investigation, but IT and operational teams may determine how the business continues to function during the incident. Their role can include isolating infrastructure from the threat, managing system changes, supporting restoration, protecting unaffected environments, and working with third-party providers.

Their priorities can sometimes conflict with those of incident responders. Security may want to isolate a system immediately out of panic but operations may know that doing so will take down a critical service and disrupt operations. Neither perspective is inherently wrong.

The incident response structure exists to bring those two perspectives together so that independent teams can join in making an informed decision that benefits the business rather than competing about who’s right.

8. The Board: Oversight Rather Than Operational Command

Not every incident requires board involvement. However, major security incidents can create significant financial, regulatory, operational and reputational consequences, making them a governance issue as well as a security issue.

The board’s role is to provide oversight rather than direct involvement in incident management decisions. To fulfil this responsibility, it needs to understand the scale and potential impact of the incident, the organisation’s exposure, major decisions being made, regulatory and legal implications, whether management has sufficient resources to respond effectively, and what lessons should be addressed after the incident.

The board should not become another operational layer through which every response decision has to pass. Instead, it should provide governance and challenge whether management is responding in a way that is appropriate to the level of enterprise risk.

9. Third Parties Have a Role Too

Enterprises nowadays rarely control their entire technology environment from within. Cloud providers, managed security providers, software vendors, payment processors, telecommunications companies and other suppliers may all need to become involved in an incident.

This means the response structure needs to account for any people or organisations who are outside the enterprise’s reporting lines but inside its operational dependencies. Third parties may provide assistance in the form of:

• Technical investigation.
• Cloud infrastructure support.
• Threat intelligence.
• Digital forensics.
• Legal expertise.
• Crisis communications.
• Recovery services.

NIST's guidance recognises that incident handlers can be either internal or contracted, while its CSF 2.0 also calls for incident response to be a coordinated effort with relevant third parties. The important point to remember is that outsourcing a function does not necessarily outsource accountability.

An organisation may bring in an external incident response firm, for example, but leadership still needs to understand who is making decisions and who remains ultimately accountable for the outcome.

One Incident, Different Decision Rights

The clearest way to understand all of these roles is to separate responsibility from authority:

The exact structure will vary between organisations. A multinational enterprise might have separate crisis management, cyber response, legal, communications and business continuity teams. But, a smaller organisation might have only five people performing all of these functions.

The titles themselves don’t matter as much as the decision architecture. Everyone should know who coordinates the response, who provides specialist advice, who owns each business decision and who has authority to escalate.

How to Close the Coordination Gap in Cyber Response

Creating an incident response structure is not simply about assigning more people to a crisis but rather assigning the right people. Clear responsibilities, decision rights and coordination are what enable an organisation to respond effectively.

Without them, even well-resourced teams can become stuck in a cycle of assumptions such as security expecting leadership to make the decision on whether a system should be shut down and similarly, leadership is expecting security to have already made that decision.

This is called the coordination gap. Every team is doing something independently, yet the response barely moves because of assumptions and lack of communication.

An effective incident command structure addresses this gap by making it clear who leads, who advises, who decides and who needs to be informed. It doesn’t need to be a rigid hierarchy. Instead, it should provide enough flexibility to adapt to the scale and impact of an incident while still maintaining clear accountability.

Several principles support this approach:

• Central coordination

Someone maintains the overall picture and aligns activities across teams.

• Distinct decision rights

Technical specialists provide expertise, while business leaders retain authority over significant risk decisions.

• Impact-based escalation

Incidents should be escalated according to their potential business consequences, not simply their technical severity.

• Two-way information flow

Security needs business context, while leadership needs clear, timely updates on technical developments.

• Defined external involvement

Suppliers and specialist responders should have clear responsibilities and points of contact.

• Explicit decision ownership

Teams should know who has authority to make critical decisions before an incident unfolds.

NIST's incident response guidance also reflects this broader approach, treating incident response as an integrated organisational capability rather than an isolated cybersecurity function.

The objective is not to create a structure that eliminates uncertainty. It’s to ensure that uncertainty about the incident doesn’t become uncertainty about who is responsible for acting.

Cyber Response Is Everyone's Responsibility

A cyber incident may begin with a technical alert, but a serious breach quickly transforms into an organisational event:

Effective cyber incident response is not simply about having a technically capable security team. It is about creating an organisational structure capable of making decisions under pressure.

Don’t just focus on whether you have an incident response plan but also on whether everyone knows who’s responsible for making each important decision when a security breach occurs and can instantly mobilise. Uncertainty about who is in charge shouldn’t be a concern in a crisis situation.

To understand how organisations prepare for incidents, manage risk and remain operational when critical systems come under pressure, explore EM360Tech's coverage of the evolving realities of cyber resilience and enterprise security.