What is an incident response retainer?

The short definition

An incident response retainer is an agreement, signed in advance, under which a specialist team will help you handle a cyber incident on pre-agreed terms. It is not a product with a specification. Providers assemble it from a common set of parts, and the parts they include and exclude vary more than the price does.

Three components are present in essentially every retainer. There is a contract that already exists when the incident starts. There is a stated response target. And there is a queue position: retained customers are served before walk-in work. Most retainers add prepaid hours or funds, and better ones add onboarding and at least one exercise.

That is the whole idea. Everything else in this guide is a consequence of it.

Why the contract is the first component, not the fine print

Ask any responder what actually delays the start of an engagement and you will not hear about analyst availability. You will hear about paperwork. Without a retainer, the first day of a serious incident is spent negotiating a master services agreement, a data processing agreement, a liability cap, an indemnity position and an hourly rate, between two sets of lawyers, while systems are encrypted and the executive team is asking for an update every twenty minutes.

Providers say this openly. Palo Alto Networks describes its retainer as giving “priority access to experienced responders with pre-defined SLA’s before a crisis occurs”, and says it “removes the delays of finding a provider and negotiating terms during an attack”. Mandiant lists the same component as a headline bullet: “pre-negotiated terms and pre-paid funds for proactive services, training, and incident response”.

Procurement latency is the hidden cost of not having a retainer, and it is the one component you are guaranteed to receive even if nothing else in the agreement is ever used.

The six components

1. The pre-negotiated contract

Master terms, liability position, data processing agreement, rate card, notice periods and termination rights, all agreed while nobody is under pressure. This is also where the parts nobody reads until they matter live: what the provider may do without asking you, where your data will be processed, and who the sub-processors are.

2. The response-time target

A stated commitment, almost always sold in tiers. Published figures run from one hour to one business day. Unit 42 states it plainly: its “response SLAs range from 24 hours to two hours, based on your selected retainer and service level”. Mandiant publishes a two-hour response time. Arctic Wolf publishes one hour. CrowdStrike publishes 24/7/365 availability and global deployment “within hours” without attaching a numeric target.

What none of those pages says is what has to have happened by the target. That single omission is why we gave the SLA its own guide.

3. Prepaid hours or funds

A block bought up front and drawn down against work. The block is worth having if, and only if, it can be spent on something in a year without an incident. Mandiant’s published description of prepaid funds covering “proactive services, training, and incident response” is the model to ask for. A block that expires unused is a straightforward transfer of your money for nothing.

4. Onboarding before the first call

The work that makes the provider useful on day one: network and identity context, confirmation of what is logged and for how long, an access method agreed and tested, a severity and categorisation scheme, and the escalation chart. Arctic Wolf bundles “IR planning and a tabletop exercise” into its retainer explicitly. Where a provider does not bundle it, buy it separately.

NIST treats this as an outcome in its own right rather than a nicety. Subcategory GV.SC-08 of the CSF 2.0 profile in SP 800-61r3 is “relevant suppliers and other third parties are included in incident planning, response, and recovery activities”, and ID.IM-02 covers improvements identified from tests and exercises “including those done in coordination with suppliers and relevant third parties”.

5. Named contacts and an escalation path

A declaration channel that starts your contractual clock, an out-of-band fallback for the case where your own email and telephony are the thing that is down, and named people with real authority on both sides. The UK NCSC asks even a basic incident response plan to carry key contacts covering the IR team or provider, IT, senior management, legal, PR, HR and insurance, escalation criteria with a process for critical decisions, and “at least one conference number” that is always available for urgent calls.

6. A written scope of work

The FIRST CSIRT Services Framework enumerates the services inside incident management: report acceptance, incident analysis, artifact and forensic evidence analysis, mitigation and recovery, incident coordination, and crisis management support. Read that list as a checklist. A retainer covering analysis but not mitigation and recovery is a different product from one covering both, and the price difference is real and defensible.

The three commercial models

Retainers are sold in three shapes. They transfer different risks, and the right one depends far more on your own capability than on your size.

How the three retainer models differ

Model	How you pay	What it suits	Where it hurts
Prepaid block	Hours or funds bought up front and drawn down at an agreed rate	Complex or regulated estates where a cold start would cost a day, and readiness work needs its own budget line	A quiet year is a write-off unless the balance can be spent on proactive work or rolls over
Standby agreement	A low or nominal annual fee; response billed at pre-agreed rates when used	Teams that can hold the first hours themselves and want procurement latency removed cheaply	Nothing is prepaid, so nothing was spent on the provider learning your estate
Subscription	A fixed recurring fee for a defined scope, often bundled with monitoring	Organisations with no out-of-hours capability at all, where the real gap is detection	Simple to budget, hard to compare; the scope boundary is where the argument happens

The cost guide works through what moves the number inside each model, and why the gap between the retained rate and the walk-in emergency rate is the figure worth extracting.

What a retainer is not

• It is not insurance. A retainer pays for nothing and covers no loss. A cyber policy may pay the responder; the retainer decides who that responder is and how quickly they arrive. The two are complements and the comparison on the home page sets out how they interact.
• It is not monitoring. Every response target measures from the moment you declare. If nothing is watching the estate at three in the morning, the delay that hurts you occurred before the clock started. DORA Article 10(2) makes the dependency explicit: detection mechanisms must “define alert thresholds and criteria to trigger and initiate ICT-related incident response processes”.
• It is not a compliance certificate. No EU instrument names a retainer. A supervisor will ask for the incident handling policy, the roles, the escalation chart and the test records, not the invoice.
• It does not transfer decisions. Taking a production line offline, notifying customers or forming a position on a ransom demand are your decisions. NIST is specific that the contract should record “restrictions on what the service provider can do, such as sharing sanitized incident information with other customers or making and implementing operational decisions”.
• It is not automatically portable to your insurer. If your policy runs through a panel, your retained provider may not be on it.

Who actually needs one

Retainers are usually justified with a threat argument. A capability argument is more honest, because it can be answered with facts about your own organisation rather than assertions about attackers.

You need one when the first four hours of a serious incident would otherwise be spent finding someone. That is the case when you have no dedicated security staff; when you have competent generalists for whom incident response is not the day job; when you have a security team that goes home at six; or when you have a capable team that has never done a full forensic investigation on a compromised identity provider and would rather not learn during one.

Regulatory position sharpens the same question. If you are an essential or important entity under NIS2, an early warning is due within 24 hours of becoming aware of a significant incident, and it has to state whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have cross-border impact. That statement is a triage output, and somebody competent has to produce it inside the first day. If you are a financial entity under DORA, the initial notification is due within four hours of classifying an incident as major, and no later than 24 hours from becoming aware of it.

You probably do not need one, yet, when nobody would notice an intrusion for a fortnight. In that case the money buys a faster answer to a question nobody has asked. Detection comes first, and the scoping tool says so directly when the answers point that way.

What a good retainer looks like on the day it is used

You declare on a channel that both sides agreed and both sides have tested. Your declaration starts the clock, not the provider’s acceptance of it. Within the target, a named lead is assigned, and that person has already seen a diagram of your network and knows which identity provider you use.

They do not ask for a VPN account, because one exists and was tested in March. They do not ask what your severity levels mean, because the scheme is in the folder. They do not ask who can authorise isolating a host, because the escalation chart names that person and their deputy. And when your legal team asks whether the memory images are leaving the EU, someone can answer from the contract rather than from memory.

None of that is exotic. All of it is onboarding, and all of it is cheaper to do in advance than to improvise. Implementing Regulation (EU) 2024/2690, which sets out the technical requirements behind the NIS2 incident handling duty for the entity types it covers, effectively lists the same artefacts: a categorisation system, effective communication plans including for escalation and reporting, assignment of roles to competent employees, and “documents to be used in the course of incident detection and response such as incident response manuals, escalation charts, contact lists and templates”.

Before you sign

• Get the response target in writing with the verb attached: acknowledgement, named lead, responder on a bridge, or containment under way.
• Fix the clock to your declaration and name the channel that starts it.
• List the six FIRST services and mark each one in or out of scope.
• Ask for the retained rate and the walk-in emergency rate, and compare the gap.
• Establish whether unused hours roll over and whether they can be spent on readiness.
• Settle where responders sit, where forensic data is processed and stored, and who the sub-processors are.
• Ask what happens when a widespread event fills the provider’s queue, and whether your tier holds a position.
• Confirm with your broker, in writing, that using this provider will not prejudice a claim.

Then run one exercise with the provider in the room before the renewal date, so that the first time you use the agreement is not the first time you use the agreement.