Almost every organisation we are called into has chosen its incident-response provider during the incident. That is the one moment when you cannot assess anyone properly: you are compromised, the clock is running, and the first firm that answers the phone gets the engagement. This guide is about the decision you make beforehand — what separates a forensics practice from a pentest vendor with a forensics page, and what to put in writing before anything happens.
If you are mid-incident right now, stop reading this and use the phased playbook instead: AD compromise IR playbook for Indian BFSI covers detection through recovery hour by hour, and ransomware readiness for Indian BFSI covers the containment decisions. Come back to this page when the incident is closed and you are deciding who to retain.
A pentest vendor is not a DFIR responder
The two look adjacent on a capability slide and are different disciplines. A penetration test is a scheduled, scoped exercise where you control the environment and the tester writes findings. An incident response is unscheduled, unscoped, adversarial and evidential: the environment is actively hostile, the scope is whatever the attacker touched, and the output may be read by a regulator, an insurer, a board, or a court. Testing skill transfers. Evidence discipline does not, and it is the part that decides whether your conclusions hold up.
- A tester can re-run a failed check. A responder who contaminates volatile memory has destroyed the artefact permanently.
- A test report argues severity. A forensic report has to survive someone hostile asking how you know.
- Testing runs on your schedule. Response runs on the attacker's, which is usually a Friday night.
- A test is bounded by a scope document. Response scope is discovered, and it usually grows.
What to verify before you sign
Ask for evidence of each of these in writing. A provider who cannot answer the evidence-handling questions specifically is telling you something useful.
| What to check | Why it matters | What a good answer looks like |
|---|---|---|
| CERT-In empanelment, and the category | Regulators and tenders frequently require an empanelled auditor, and empanelment is scoped by category — being on the list does not mean being on it for your kind of work | The provider names its category and points you at the official CERT-In list rather than a logo on its own site |
| Who actually turns up | Sales engineers and delivery engineers are often different people; in IR the named responder matters more than the firm | Named leads, their certifications, and a commitment that the person on the call is on the engagement |
| Evidence handling and chain of custody | This determines whether findings survive a regulator, an insurer or litigation | A written procedure: acquisition order, hashing, storage, custody log, and who signs it |
| Volatile-data capability | Memory, running processes and network state are gone after a reboot; many providers only do disk | Memory acquisition as standard, with tooling named and an order-of-volatility policy |
| Regulatory reporting support | Your obligations run in parallel with the investigation and the deadlines are short | They draft or review the regulator notification with you, and have done it before in your sector |
| Response-time commitment | "Best effort" is not a commitment | A contractual acknowledgement and on-site window, with the escalation path written down |
| Data residency of the evidence | Indian obligations around log retention and storage location apply to your evidence too | Evidence stays in India unless you agree otherwise in writing |
| Conflict position | Your IR provider auditing its own prior work is a conflict | They will say so, and will tell you when to bring in a third party |
Due-diligence checklist for an Indian DFIR provider
Evidence handling is the part nobody asks about
It is also the part that decides whether the engagement was worth paying for. An investigation that reaches a correct conclusion through an undocumented process gives you an answer you cannot use. If the matter becomes an insurance claim, an employment dispute, a regulatory finding or a prosecution, the first question is not what you found — it is how you know, and who could have altered it between acquisition and analysis.
- Acquisition in order of volatility — memory before disk, live network state before shutdown.
- Cryptographic hashes taken at acquisition and verified before and after every analysis step.
- Analysis performed on copies, never on the original media.
- A custody log with names, timestamps and handovers, maintained from acquisition to disposal.
- A repeatable method, so a second examiner can reach the same conclusion from the same evidence.
Retainer or call-when-it-happens?
A retainer is not primarily about a discount. It is about the work that happens before the incident — the provider already knowing your estate, your logging, your escalation contacts and your regulatory position — because all of that is time you do not have later.
| Retainer | Ad-hoc engagement | |
|---|---|---|
| Time to first action | Contract and scope already agreed; work starts on the call | Procurement, scoping and NDA first, while the incident continues |
| Environment knowledge | Pre-built: architecture, logging coverage, crown jewels | Discovered during the incident, from people who are already busy |
| Logging gaps | Found and fixed during onboarding, before they cost you an investigation | Found during the investigation, when they are unfixable retroactively |
| Commercial position | Rates fixed in advance | Negotiated at your weakest moment |
| Unused hours | Typically redirect to readiness work — tabletop exercises, playbook review | Not applicable |
What actually differs
The honest counter-argument: if you have no security team, no central logging and no tested backups, a retainer is not the first thing to buy. Fix detection and recovery first — a responder can only reconstruct what your logs recorded.
Your reporting clock runs during the investigation, not after it
Indian organisations covered by the CERT-In Directions of 2022 must report specified classes of incident within six hours of noticing them, keep ICT logs for a rolling 180 days, and store those logs in India. Sector regulators add their own notifications on top. The practical consequence is that your provider has to be able to support a notification while the investigation is still incomplete — a notification that says what is known, what is not yet known, and what is being done. A provider who wants to wait for a complete picture before writing anything down will make you miss the window.
Our CERT-In empanelled audit guide covers the Directions and the reporting obligations in full, including what the log-retention rule means in practice.
Red flags
- A named response time with no contract term behind it.
- No written evidence-handling procedure, or one that appears only after you ask twice.
- Disk-only acquisition, or no answer on memory.
- A proposal that scopes the investigation in hours before anyone has looked at the environment.
- Reluctance to say which cases they have not been able to resolve, and why.
- Certifications listed for the firm but not for the people who would be assigned.
Where Macksofy fits
Macksofy is a CERT-In empanelled auditor and runs digital forensics and incident response for Indian and UAE organisations, mostly in BFSI. We will tell you plainly when a retainer is not the right purchase yet — if the logging is not there, the honest sequence is detection first, response capability second.
If you are deciding between a retainer and ad-hoc cover, or you want your current provider's evidence procedure reviewed, we will walk through it with you.