When Your IT Provider Is Part of the Incident

If your firm had a serious cyber incident tomorrow, who would investigate it, who would pay for that, and who would they report to?

In most mid-sized firms the honest answer is that the IT provider would handle it, the cost would be argued about afterwards, and the report would go to whoever asked loudest. That is not a plan. It is a set of assumptions that have never been tested against each other.

This article covers what to check in your managed services agreement and your cyber policy, four questions to put to your provider, and a sensible split of responsibility for a firm without a security team.

Where most firms sit

Most firms of 50 to 200 people do not have a security team. They have an IT provider, a cyber insurance policy and a managing partner who expects the two to sort it out between them if something goes wrong.

That is not a criticism. It is how the market works. A firm that size cannot justify a full security function, and a good provider does a lot of what that function would do: patching, backups, endpoint protection, account management. On a normal day the arrangement is sensible.

The typical setup looks like this:

• A managed services agreement covering support, maintenance and restoring service.
• A cyber policy arranged through a broker and renewed once a year on the strength of a questionnaire.
• An incident response plan, if there is one, whose first step is "call the IT provider".

Each piece makes sense on its own. The problem is that almost nobody has laid them side by side and asked how they behave together at 9pm on a Friday.

The independence problem

When something serious happens, someone has to establish what happened. How the attacker got in, what they touched, what left the environment and how long they were there. That answer drives everything else: whether you notify clients, whether the matter is reportable under the Notifiable Data Breaches scheme, what you tell your insurer, and what you can stand behind if a client later takes action.

In most firms the organisation best placed to answer that question is the one that runs the environment. It has the access, the logs and the knowledge. It is also the organisation whose configuration, patching and monitoring are part of what is being examined.

This is not a suggestion that providers act in bad faith. Most do not. The issue is structural, and it costs the firm even when everyone behaves well.

• Investigation and restoration compete for the same people. In the first hours, restoration usually wins because that is what the firm is asking for. Evidence gets overwritten along the way. Reimaging a laptop fixes the laptop and destroys the record of what happened on it.
• The findings are harder to rely on. If the report matters later, to an insurer, a regulator or a court, the first question about it will be who wrote it and what interest they had in the answer.
• Awkward findings arrive slowly. If the root cause was a missed patch or a misconfigured rule, the people best placed to find it are the people least comfortable reporting it. That is human, not dishonest.

The cost is rarely dramatic. It looks like an investigation that cannot answer the question the insurer asks, a notification decision made on incomplete facts, or a dispute about who pays for the rebuild.

The contract gap

Get out two documents: the managed services agreement and the cyber policy wording. Read them together, not one after the other.

In the managed services agreement, check:

• Whether "security incident" is defined at all, and whether responding to one is in scope or billed as a separate project.
• Response times, and whether they apply after hours and on weekends.
• Whether the provider is required to preserve logs and evidence, or only to restore service.
• Who owns the logs, how long they are kept, and whether you can get them if the relationship ends.
• Any limitation of liability, and how it applies to security failures.

In the cyber policy, check:

• Whether you must use the insurer's panel for forensic and legal support, and what happens if you engage someone before the insurer does.
• How quickly you must notify the insurer, and through which channel.
• Whether costs incurred before notification or before the insurer's consent are covered.
• Any conditions about security controls, such as MFA or backups, that your provider is actually responsible for maintaining.

Then look at what sits between them.

The agreement usually covers getting systems back. The policy usually covers investigating and notifying once the insurer is engaged. Neither one tends to cover the first two hours: the point where something has been noticed, the insurer has not yet appointed anyone, and the provider is already working on the fix.

That window is where logs roll over, machines get rebuilt and early decisions are made without anyone owning them. It is also where most of the eventual cost gets decided.

Every policy is different and this is not advice on any particular wording. Check yours with your broker. Most firms find the gap within about fifteen minutes of reading the two documents side by side.

Four questions to put to your provider

These are not a test. A good provider will have answers, and the ones they do not have are the ones worth knowing about now.

1. If we have a serious incident, what do you do first: preserve or restore? A good answer separates the two. They isolate rather than wipe, capture what they can before rebuilding, and stop to get a decision from the firm when the two conflict.
2. What logs do you hold for us, for how long, and how quickly can you hand them to a third party? A good answer comes in days, not adjectives, for email, sign-ins, endpoints and firewalls. It also tells you where the logs live, and whether someone with stolen admin access could delete them.
3. If our insurer appoints an investigator, how will you work with them? A good answer is that they have done it before, they will provide access and logs promptly, and they do not see it as a threat.
4. Where would your own systems or access form part of the investigation? A good answer acknowledges that their remote access tools, admin accounts and shared management platforms are in scope, and that they will accept someone else looking at them.

A sensible split of responsibility

For a firm without a security team, the split that works is simple. The provider fixes, someone independent investigates, and the firm decides.

The column that matters most is the last one. The investigator reports to the firm, not to the provider, and not through the provider.

Agreeing it in advance without damaging the relationship

Most providers are relieved to have this conversation. Being both the person fixing the problem and the person investigating it is an uncomfortable position for them too.

The framing that works is about governance, not trust. Something like:

"Our insurer and our own governance mean that if we have a serious incident, the investigation needs to be independent of whoever runs the environment. That is not about you. It protects both of us. We would like to agree now how you would work alongside an investigator, what you would preserve before restoring, and what logs we would have available."

Then write it down. One page is enough: who does what in the first two hours, who has authority to pause restoration, which investigator you would call, and how to reach your broker. Attach it to your incident response plan, give a copy to your provider, and send one to your broker.

Test it once a year. A one-hour tabletop exercise with the provider in the room will tell you more than any report.

The conversation to have before the call

None of this is complicated. It is one meeting and one page. Held on a quiet day, it removes an argument you cannot win in the middle of an incident.

If it would help, I am happy to read your managed services agreement and cyber policy side by side and tell you where the gaps are. No pitch, just a second set of eyes from someone who has sat on both sides of this conversation.