Incident Response Accountability: Who Owns What

"IT will handle it" is the most common answer to "what happens if we get hit," and it is also the most incomplete one. IT can isolate a compromised device in minutes. IT cannot decide whether to notify a regulator, whether to engage with a ransom demand, or who speaks to the client base while the situation is still unfolding. Those decisions belong to someone, but in most businesses, nobody has actually said who.

Incident response accountability is not a technical problem. It is an organisational one, and it tends to surface at the worst possible moment: partway through an actual incident, when three people are giving different instructions and nobody is sure who has the authority to overrule the others.

What "accountability" actually means during an incident

A cyber incident is not a single event with a single owner. It moves through phases, and different people are best placed to own different parts of it. Confusion usually happens because businesses assume "IT will handle it" covers the whole thing, when in reality an incident touches at least four separate areas of responsibility.

Detection and technical containment. Someone needs to confirm what is actually happening, isolate affected systems, and stop the spread. This is usually the most straightforward part to assign, because it sits clearly with whoever manages endpoint detection and response, whether that is an internal IT team or a managed provider. Our piece on MDR versus EDR covers this distinction in more detail, but the short version is that detection tooling only matters if someone is actually watching it and empowered to act on what they see.

The decision to declare an incident. This sounds like a formality. It is not. Declaring an incident often triggers insurance notification clocks, regulatory reporting timeframes, and client communication obligations. Waiting too long to declare, hoping it turns out to be nothing, is one of the more common ways a manageable event becomes a much larger one. This decision needs a named owner inside the business, not just "whoever notices first."

Vendor and insurer coordination. A ransomware event, a compromised mailbox, or a data exposure rarely involves only one system. It might touch the email security platform, the cyber insurer's incident response panel, a software vendor whose product was the entry point, and sometimes law enforcement. Someone has to be the single point of contact coordinating all of that, because a business trying to talk to four vendors simultaneously during a live incident usually ends up with four different versions of what is happening. This is one of the more overlooked benefits of a provider that manages vendor relationships directly rather than leaving a client to chase each one individually.

The decision to pay, or not pay, a ransom. This should never sit with a single person acting alone, and it should never sit with IT alone. It involves legal advice, the cyber insurer if one is in place, and often law enforcement guidance, because paying can carry its own legal and financial consequences depending on who the demand is linked to.

Why this usually only gets noticed after an incident

Most businesses discover their incident response plan has ownership gaps the same way they discover an untested backup does not restore properly: during the incident itself, not before it. Our recent piece on what a cybersecurity contract should actually say covers a related gap, that many agreements never state clearly whether incident response labour is included in the standard fee or billed separately once something goes wrong. Accountability and cost are usually tangled together for exactly this reason. If nobody has agreed in advance who does what, nobody has agreed in advance what it costs either.

The businesses that handle incidents well are not necessarily the ones with the most sophisticated security tools. They are the ones that had an uncomfortable conversation in advance about who is allowed to make which call, and wrote it down somewhere more durable than a slide from a training session two years ago.

What a workable accountability structure looks like

It does not need to be a fifty-page document. It needs to answer a short list of questions clearly enough that nobody is guessing under pressure:

• Who has the authority to declare an incident, and who do they need to tell within the first hour?
• Who is the single point of contact for vendors, insurers, and any external responders, so instructions do not come from four directions at once?
• What decisions require sign-off from someone outside IT, such as legal counsel or a director, before action is taken?
• Who communicates with staff, clients, and, if required, regulators, and in what order?
• Who is responsible after the incident is contained, for the post-incident review that decides what changes so it does not happen the same way twice?

None of this requires predicting every possible scenario. It requires deciding, while everyone is calm, who is holding each piece of the response before anyone actually needs to.

Where Affinity MSP Fits In

Where we have seen this go well, incident response ownership is agreed before there is an incident to respond to, not improvised during one. As part of how we manage security for clients, we take on the vendor liaison role directly, meaning our team coordinates with the endpoint security, email security and insurance parties on a client's behalf during an incident, rather than leaving the business to manage four separate relationships while also trying to run day-to-day operations under pressure.

If your current arrangement has never actually named who owns which decision, a free AffinityScan assessment is a reasonable place to start the conversation, since it gives a factual starting point on where your current setup stands before you need to test it under real conditions.

FAQ

Who is responsible for incident response in a business, IT or leadership?

Both, for different parts of it. IT, whether internal or an outsourced provider, typically owns detection, technical containment, and system recovery. Leadership, often alongside legal counsel and the cyber insurer, should own the decision to declare an incident, external communications, and any decision involving legal or financial risk, such as whether to engage with a ransom demand.

What is the first thing a business should do when a cyber incident is suspected?

Confirm the scope with whoever manages security monitoring, and declare the incident formally rather than waiting to see if it resolves on its own. Early declaration protects insurance notification timeframes and regulatory reporting windows, both of which are often time-limited from the moment an incident is confirmed.

Should a business ever decide to pay a ransomware demand on its own?

No. This decision should involve legal advice and, where a policy exists, the cyber insurer, because payment can carry legal consequences depending on who the demand is connected to, and insurers often have specific requirements about how a ransom situation is handled under the policy.

How does Affinity MSP help with incident response accountability?

We take on direct coordination with security vendors and, where relevant, cyber insurers during an incident, acting as a single point of contact rather than leaving a client to manage multiple external parties at once, and we work with clients in advance to document who owns each part of the response before it is needed.