Incident response retainers: what to look for, and what to have ready

An incident response retainer is bought on a quiet day and used on the worst one. Its value is settled long before anyone calls: by what was agreed in advance, and by what you prepared on your side.

What a retainer settles in advance, and its four limits

A retainer is a standing agreement with a response team. Contract terms, authorisation, contacts and access paths are agreed before anything goes wrong, so the first call starts triage rather than procurement. A good one also includes an onboarding session in which the responders learn your environment, and lets you draw on the agreement for readiness work such as a tabletop exercise or a compromise assessment.

NIST's current guidance, SP 800-61 Revision 3, published in April 2025, maps incident response onto the Cybersecurity Framework 2.0, so preparation sits inside everyday risk management rather than in a plan that waits on a shelf. A retainer is one way to make that true, within four limits:

• It is not monitoring. Nobody is watching your alerts unless you have bought detection and response separately. A retainer starts when you call.
• It is not insurance. It buys speed and expertise, not cover for losses. If you hold a cyber policy, the two have to be made to work together, which is covered below.
• It does not hand over your decisions. Responders run the technical investigation; decisions about customers, regulators, extortion demands and public statements stay with your leadership and counsel.
• It is not a compliance artefact. A retainer that has never been exercised, with contacts nobody has checked since signing, satisfies an auditor and fails an incident.

Questions to ask a provider before you sign

Every provider will say it responds quickly and employs experienced people. The useful questions are the ones whose answers you can check, and the useful answers are specific: names, sequences and limits.

What to agree in advance, so the first call is not a negotiation

Each of the terms below takes an hour or two to settle on a quiet day. During an incident the same conversation takes far longer, because the people who can sign are busy and the lawyers are reading quickly.

1. 1

   Authorisation and its limits

   A signed authorisation that lets responders access systems, collect evidence and take agreed containment actions, with named people on your side who can widen or halt that authority at any hour. List the cloud tenancies, subsidiaries and supplier-hosted systems it covers. Responders can only touch what you are able to authorise, so check now what your hosting provider, managed service provider and key software suppliers will allow.

2. 2

   Contacts and decision rights

   Primary and backup contacts on both sides, with phone numbers held somewhere other than your corporate directory. Decide in advance who can approve isolating production, who calls the insurer, who speaks to customers and who briefs the board. Under pressure, nobody remembers the organisation chart.

3. 3

   Access paths that survive a compromise

   Assume your single sign-on, VPN or email may be part of the incident, and agree how responders get in anyway: break-glass accounts kept offline, a responder account that stays disabled until it is needed, a tested way to deploy collection or endpoint tooling, and read access to your log platform. Try each path during onboarding, not on the night.

4. 4

   Counsel and legal privilege

   Decide with your lawyers whether counsel should engage the responders when an incident occurs, so that the investigation runs at their direction. Whether privilege protects the resulting work depends on the jurisdiction and on how the engagement is set up and used, which is a question for counsel rather than for the responders. The retainer should allow either route without renegotiation.

5. 5

   Data protection for the responders

   Responders will see personal data, credentials and confidential documents. Agree a data processing addendum, where evidence is stored and in which jurisdiction, who can access it, how long it is kept and how it is destroyed.

6. 6

   An out-of-band channel

   A separate messaging workspace or phone bridge, agreed in advance. CISA's ransomware guidance recommends coordinating isolation through out-of-band methods such as phone calls, so that attackers watching internal channels are not tipped off.

Readiness that makes the first hour faster

Without preparation, the first hours of an incident go on finding things: where the logs are, who holds administrator rights, whether the backups exist and who knows the password to the backup console. Each item below gives those hours back to the investigation.

Logging retention

Default retention windows are short, and they expire during investigations. Microsoft Entra ID keeps sign-in and audit logs for seven days on the Free tier and 30 days on P1 and P2, and upgrading later does not bring back data that has already expired. Microsoft Purview Audit (Standard) keeps records for 180 days by default. AWS CloudTrail event history covers the last 90 days of management events and no data events; anything longer needs a trail or an event data store that you create yourself.

An intrusion found today may have begun months earlier, and the records of how it began are the first to age out. If a database falls under Israel's data security regulations at a medium or high security level, Regulation 10 already requires its access-monitoring records to be kept for at least 24 months, so the legal duty and the forensic need point the same way.

• Identity provider sign-in and audit logs exported to storage you control, with at least a year of retention.
• An organisation-wide CloudTrail trail, or your platform's equivalent, delivered to a separate logging account that production administrators cannot alter.
• Endpoint, VPN, firewall, DNS and mail gateway logs kept long enough to look back across a full quarter.
• Clocks synchronised and every log source's time zone recorded; a timeline built from mismatched clocks is wrong in ways that matter.

Identity

Keep a current list of privileged accounts across Active Directory, your identity provider, cloud platforms, hypervisors and the backup system. Know how to revoke sessions and tokens at scale, how to rotate service-account and API credentials, and who is allowed to do both. If you run Active Directory, have the documented procedure for resetting the krbtgt account to hand before you need it.

Backups

Responders ask three questions early: do backups exist, can the attacker reach them, and how long does a restore take? Answer them in advance. Keep at least one copy offline or immutable, protected by credentials that are not part of your production identity system, and time a restore of a critical system so that the recovery plan rests on a measured number.

Knowing your own estate

A current network diagram, a list of internet-facing systems, the systems that matter most to the business with their owners, and the third parties that hold remote access. A penetration test or a cloud configuration review produces much of this as a by-product.

How insurers and counsel fit in

If you carry cyber insurance, the policy shapes the first day as much as the retainer does. Settle these points with your broker or insurer before an incident, and keep the answers with the retainer:

• The notification window and method: who you call, by when, and what counts as notice.
• Whether the policy funds your chosen responder, or requires consent before you engage one.
• Whether the insurer appoints counsel, and how that counsel engages and directs the responders.
• Which response costs are covered, and which need approval before they are incurred.

Counsel's role is separate from the responders'. Notification decisions are legal decisions informed by technical facts: GDPR asks controllers to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, and Israel's data security regulations require the Registrar to be notified immediately of a severe security incident. The responders establish the facts, quickly and in writing; counsel decides what is notified, to whom and when. Our compliance overview lists the main regimes and their clocks.

A readiness checklist for this quarter

• Retainer signed, with authorisation covering every tenancy, subsidiary and supplier-hosted system that matters.
• Named contacts and backups on both sides, checked in the last six months and stored outside corporate systems.
• Decision rights written down: who can isolate production, notify the insurer, brief customers and engage counsel.
• An out-of-band communication channel set up and tested.
• Break-glass and responder access paths tested end to end.
• Identity, cloud, endpoint and network logs retained for at least a year, in storage production administrators cannot alter.
• A current list of privileged accounts, and a rehearsed procedure for revoking sessions and rotating credentials.
• Offline or immutable backups, with a timed restore of at least one critical system.
• A current network diagram, a list of internet-facing assets and a ranked list of critical systems with owners.
• The insurer's notification rules, any approved-firm requirements and the counsel arrangements recorded alongside the retainer.
• A tabletop exercise run against a realistic scenario, with every gap it found assigned to an owner.
• The first-hour checklist printed and kept where the on-call team can reach it without the network.

If you want these tested against your own environment, our incident response service covers readiness assessments and tabletop exercises as well as live response, and the breach archives show how the same gaps played out in public incidents.