Buying an Incident Response Retainer: What Actually Matters

Direct answer: An incident response retainer buys you a relationship, an access path and a defined process before you need them. The response time in the agreement matters less than what happens inside it: who picks up, what they are authorised to do, whether they already have access to your environment, and whether the scope covers your actual failure modes. Ask what an engagement looks like in hour one, not what the acknowledgement target is.

What you are actually buying

During an incident, the expensive delay is almost never finding somebody technical. It is contracting, scoping and access. A firm you have never worked with needs an agreement signed, an NDA, a scope, a rate, and read access into systems you are currently unsure about. That process takes hours to days, and it happens while your team is trying to contain something.

A retainer front-loads all of it. The contract exists, the access paths exist, the runbook exists, and somebody on the other end already knows what your stack looks like. That is the product. The response time in the SLA is a promise about how fast the relationship activates, not about how fast the problem gets solved.

Questions worth asking

Who picks up, and what is their background? A rotation staffed by tier-one analysts reading a script is a different product from a named responder who has run breaches. Ask specifically who answers at 2am on a Saturday.

What are they authorised to do? Some retainers are advisory: they tell your team what to do. Some are hands-on within an agreed boundary. Both are legitimate and the difference matters enormously at the moment you need it. Get it in the scope in writing.

What access exists in advance? Read-only into cloud, identity provider and observability, established during onboarding, is the difference between working the problem in hour one and negotiating credentials in hour one.

What is out of scope? Deep forensics for litigation, malware reverse engineering, negotiating with a ransomware operator, and legal disclosure drafting are commonly excluded or subcontracted. Knowing which of those your retainer covers is not something to discover during an incident.

What happens between incidents? A retainer that only earns its money during a breach is poor value in the years you do not have one. Tabletops, runbook maintenance, escalation tree upkeep and post-incident improvements are what makes the quiet months worth paying for.

How do hours work? Included hours, rollover, and the rate once they are exhausted. An incident that runs a week will exhaust any included allowance, so the post-allowance rate is the number that actually matters for a bad month.

What the SLA does and does not promise

Acknowledgement time is when someone confirms they have your escalation. Time to hands-on is when work starts. These are different numbers and vendors are not always careful about which one they quote. Ask for both, and ask what the coverage actually is, because 24/7 for acknowledgement with business-hours engineering is a common shape.

Also worth checking: whether the SLA is contractual with a remedy, or a target. Most are targets. That is not scandalous, but it changes what the number means.

The compliance and insurance angle

Two audiences care about this beyond your own risk. Enterprise security questionnaires routinely ask whether you have a retained incident response capability, and answering yes with a documented SLA closes the row cleanly. Cyber insurers increasingly ask the same question at underwriting, and some require you to use a panel firm during a claim, which is worth checking against your retainer before you buy either.

SOC 2 and ISO 27001 do not require a retainer. They require an incident response plan that has been tested, which a tabletop satisfies and a retainer usually includes. If your primary motivation is the audit rather than the risk, a tested plan is the cheaper and more direct purchase.

When a tabletop is the better buy

If you have never run an exercise, start there. A one-day facilitated tabletop against a realistic scenario for your stack tells you whether your plan works, produces the test record your framework asks for, and gives you a much clearer view of what you would actually need on retainer. Most teams change their mind about the tier they need after one.

The pattern that works well is a tabletop first, then a retainer sized to what the exercise exposed, rather than a tier chosen from a table before anyone has tested anything.

What we do differently

We stopped selling incident response as a standalone retainer with SLA tiers, because the companies buying it were buying the rest as well: someone to keep the compliance programme true, answer questionnaires and own the security roadmap. Splitting that into separate agreements was tidy on an invoice and wrong in practice, since the same people do all of it and the context transfers.

It runs through one retainer now, scoped and priced per client, with the response commitment written into the agreement where the work needs one. A one-day tabletop is still a fixed-scope engagement with a published price, and it remains the right first step for most teams.