Who's in charge of an incident when IT and security disagree?

One named incident lead runs the response and has authority over containment, including the authority to take systems offline over IT's objection. A named business executive, above both IT and security, owns the risk decisions: when to accept downtime, when to notify, whether to pay. The lead escalates to the executive; the executive doesn't run the bridge. When IT and security disagree, the lead decides on technical matters and the executive decides on business ones, and both decisions are logged. If your plan doesn't name these two people, the disagreement will be settled by whoever is loudest, and that's usually the wrong way round.

Why the disagreement happens, and why it's legitimate

IT is measured on availability. Security is measured on containment. In an incident those goals collide: security wants the server off the network now, IT knows that server runs payroll and it's the 28th. Both are right about their own concern. The failure isn't that they disagree; it's that nobody has been given the authority to resolve it quickly, so it gets escalated to a conference call of twelve people, two of whom will decide, forty minutes later, after the attacker has moved.

NIST's guidance is explicit that organisations should establish roles, responsibilities and authorities for incident response in advance, including who can make what decision, and that leadership's job is to make sure those authorities exist and are respected (Nelson et al., 2025). The federal playbooks CISA wrote for government agencies go further and define a lead for each phase, with the expectation that the lead directs and others support (Cybersecurity and Infrastructure Security Agency, 2021). The model isn't complicated. It's just rarely written down.

The structure that works

Incident lead. One person. Usually from security, sometimes from IT in smaller organisations, occasionally an outside responder. Has authority to isolate systems, disable accounts, and direct both IT and security staff for the duration. Reports to the executive owner. Is not expected to ask permission for containment, only to inform.

Executive owner. A COO, CFO, general counsel, or CEO, depending on the organisation. Owns decisions with business consequences: accepting an outage, authorising spend, approving notifications, engaging law enforcement, deciding on a ransom. Receives updates on a fixed cadence and makes decisions when asked. Doesn't direct the technical work.

Everyone else supports. IT executes containment and restoration under the lead's direction and tells the lead what the operational consequences will be. Legal advises. Communications drafts. HR handles people. None of them hold a veto over containment. They hold the right to be heard, quickly, and to escalate to the executive owner if they think the lead is wrong.

CSF 2.0 puts this under its Govern function for a reason: roles, responsibilities and authorities are an organisational decision, made before the incident, not a technical one made during it (Pascoe et al., 2024). The point of the split is that it separates "what is technically necessary" from "what the business will accept." The lead answers the first. The executive answers the second. Mixing them in one person, or spreading them across a committee, is how incidents stall.

The objection I hear most

"Security can't just take down production." Correct, in normal operations. In a declared incident, the alternative is that an attacker decides when production comes down, and they'll choose a worse time. The way to make this acceptable is to pre-agree the conditions under which the lead may act without consulting the executive (active encryption, confirmed exfiltration in progress, a compromised domain controller) and the conditions under which they must consult first (anything that stops a safety system, a regulated process, or revenue above a stated threshold). Write both lists. Then the 2 a.m. call is about facts.

Where the structure breaks

It breaks when the lead is too junior to be obeyed, when the executive owner is unreachable, when IT and security report to different executives who each back their own team, or when nobody has ever rehearsed it. The last one is the commonest and the cheapest to fix. A sixty-minute tabletop that forces a real disagreement, say, security wants the ERP offline on the last day of the quarter, will show you in an hour whether your decision rights are real or theoretical (I've written about what a tabletop should do).

What I'd do next

Write three lines into your incident response plan: who the incident lead is (by role, with a named deputy), who the executive owner is, and what the lead may do without asking. Get both executives to sign it. If you want an outside view on whether your decision rights would hold under pressure, request a briefing. More on this cluster is in Incident response.