Incident response · Retained
An incident response retainer is mostly a procurement decision made early. During a live incident the technical problem is rarely what delays the response — what delays it is agreeing scope, signing a contract, arranging access and establishing who is authorised to say yes, all while the thing is still spreading.
Agreed scope · named responders · access arranged in advance · contract already signed
Before the call
What a retainer buys before anything happens
Nearly all of the value is banked in advance. That is the point.
A signed contract
Commercial terms, liability and scope agreed while everyone is calm. Negotiating a statement of work at midnight during an active compromise produces bad terms and slow starts.
Access that already exists
Knowing how responders will reach your environment, with what credentials and through whose approval, decided in advance. This is routinely the single largest source of delay.
Somebody who has seen your estate
A responder walking in cold spends the first hours learning your architecture. A retained one already has a diagram, a contact list and an understanding of what matters.
A defined authority chain
Who can authorise disconnection, rebuild, payment discussions and notification. Established in advance, and worth rehearsing in a tabletop exercise.
During
What we do during an incident
Containment comes before understanding. Understanding comes before rebuild.
Containment is deliberately ahead of full diagnosis in that order. Organisations frequently want to know exactly what happened before acting; the spread does not wait for the analysis, and a complete understanding of an incident you failed to contain is an expensive thing to own.
On ransomware specifically: recovery is decided by the state of your backups and the integrity of your identity system, and both of those are determined long before the incident. We would rather examine them now, under a retainer, than discover them during a recovery. See backup and disaster recovery.
An honest note
What we will not put in a proposal
We do not publish a headline response time. A number without a definition of what starts the clock, what stops it, and what is actually delivered when it stops is a marketing figure rather than a commitment, and response commitments are agreed per contract against your environment and coverage window.
We will tell you plainly, in writing, what we commit to before you sign. If a competing proposal leads with a striking number, the useful question is what precisely happens when that clock expires.
Preparation
What to have ready, retainer or not
Most of what determines how an incident goes is decided months earlier. None of the following requires a contract with us.
An offline copy of the plan
Printed, or on a device that does not depend on the network you are trying to recover. A plan stored only on the file share is unavailable exactly when it is needed.
Contact details that work out of hours
Your own people, your provider, your insurer, your counsel. Verified, not assumed — and stored with the plan.
Backups you have restored from
Not backups that report success. Backups from which somebody has actually restored something recently and written down how long it took.
A named decision-maker per decision
Disconnect, rebuild, notify, engage counsel. Each needs a person and a deputy, agreed in advance.
An asset picture
What you run, where it runs, and which systems the business genuinely cannot operate without for a day.
Identity system hygiene
Ransomware recovery is largely an identity problem. Privileged account separation and a clean recovery path for the directory matter more than any single security product.
Related
Related work
These sit alongside this engagement more often than not:
Managed security services
Day-to-day security operations run on your behalf, which is what leadership and compliance work both depend on.
Backup and disaster recovery
Tested recovery, which decides how a ransomware incident actually ends.
Questions
Incident Response Retainer & Ransomware Recovery India, answered
What is an incident response retainer?
A contract arranged before an incident that fixes scope, commercial terms, access arrangements and escalation paths in advance, so that when something happens the response starts with technical work rather than with procurement.
What is your response time?
Agreed per contract, in writing, against your environment and coverage window. We do not publish a single headline figure because a response time without a definition of what starts and stops the clock, and what is delivered when it does, is not a commitment worth relying on.
Do you handle ransomware recovery?
Yes — containment, eradication, recovery and the post-incident report. The realistic outcome is largely determined by your backups and the integrity of your identity systems, which is why a retainer includes looking at both before anything happens.
Do you advise on paying a ransom?
That is a legal and commercial decision for your board with its counsel and insurer, not a technical one for a service provider. What we do is make sure the decision is informed — what is actually encrypted, what can be restored, and how long recovery would take without paying.
What if we already have a SOC?
A retainer complements it. Detection and response during business as usual is a different capability from crisis response at scale, and most in-house and managed SOC arrangements are scoped for the former. See SOC as a Service.
Does unused retainer time carry over?
That depends on how the retainer is structured, and it is worth settling before signing rather than discovering at renewal. Many organisations use unspent hours for tabletop exercises, readiness reviews or plan updates, which is a considerably better outcome than losing them.
Next step
Talk to someone who has done this before
Tell us where you are and we will tell you what the work actually involves. If you do not need us, we will say so.