// guide
How do you choose a cyber incident response provider?
There is no worse moment to choose a provider than in the middle of an incident. You are under pressure, short of information, and negotiating from the weakest position you will ever be in. The good choice is made when nothing is wrong.
Why beforehand rather than during
Three things take time you do not have during an incident: finding an available provider, agreeing scope and terms, and signing. In practice that is days.
And even once signed, a provider meeting your environment for the first time spends the opening hours getting to know it — precisely the hours in which evidence decays and the attacker advances.
That is why the retainer model exists: settle it in advance so the first hour goes into handling the incident rather than into procurement.
Seven questions worth asking
What will you do in the first hour, in order? A general answer is a bad sign. Someone who has done this can describe a sequence.
How do you preserve evidence, and what happens if we need it for legal proceedings or an insurer?
Who will actually handle our case — the person I am speaking to now, or somebody else?
What is defined as out of scope? A provider who says "everything" has not read the question.
What permissions will you need in our environment, and who approves their use?
What do we get at the end — a technical report, or also something we can put in front of management and a regulator?
What should we prepare in advance so that you can work quickly?
Red flags
A promise to prevent every incident. Nobody can, and whoever promises it either does not understand or is selling.
Refusing to define what is out of scope. Unlimited scope in a proposal becomes a dispute during an incident.
"We have advanced technology" as the answer to a question about process. Tools do not replace a method.
Pressure to sign quickly because of an offer. Incident response is not a field bought under manufactured urgency.
Unwillingness to talk about what has gone wrong for them before. Anyone who has handled enough incidents has seen some go badly.
What to settle in writing
Scope: which systems, which kinds of incident, and what is excluded.
Availability: what hours, through what channel — and what happens if the usual channel is the one that was compromised.
Permissions: what the provider gets, when, and who approves it.
Evidence: what is retained, for how long, and who owns it.
Confidentiality: what happens to your data held by the provider once the incident is closed.
A provider who refuses to define what is out of scope is not sparing you a conversation — they are deferring it to the worst possible moment.