How Long Does Incident Response Take?
Key takeaways
- Containment is the fastest phase, typically hours to a few days, and it is the only phase that reduces the damage in progress.
- Eradication, removing the attacker and their persistence, commonly takes one to two weeks because hidden access in identity providers and backup systems is the last thing to go.
- Recovery is the longest phase, from weeks to months, and it is set by how quickly the business can rebuild cleanly rather than by how fast it can restore files.
- Restoration is only safe if backups are offline or immutable, because restoring into a network the attacker still controls simply hands the encryption back.
- The six-hour CERT-In reporting window and the DPDP notification duty run in parallel with all of this and are not paused by a long investigation.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
How long does each phase of incident response take?
Treat the four phases separately, because they have different clocks. Preparation, a tabletop and a plan, is the phase most often skipped. Detection and analysis takes hours to a couple of days, longer if logs are missing. Containment takes hours to a few days and is the only phase that reduces ongoing harm. Eradication takes one to two weeks, because the access path is usually not the one you found first but somewhere in an identity provider or a backup console. Recovery takes weeks to months. And the reporting thread runs the whole way, with CERT-In notification due within six hours of noticing.
Why does recovery take longer than the technical work?
Because the constraint is business, not technology. Rebuilding a server takes an hour; rebuilding the trust in that server, the data on it, and the customer's willingness to use it again takes much longer. Clean restoration has to be proven: the system must be rebuilt or verified clean, the data must be checked for tampering, and the credentials and keys that lived on it must be rotated. Then the business has to plan for a return to service while parts of the estate are still offline, which usually means running a partial operation manually. In most Indian engagements we see, the technical recovery finishes well before the business is comfortable being back at full capacity.
What makes an incident take unusually long?
Four things, and all four are common. Incomplete logs, which mean the investigation has to infer rather than prove, and CERT-In expects 180 days of retained logs for exactly this reason. The attacker still having access, usually through a second identity that nobody thought to check. Backups that are not clean, either because they are online and were encrypted, or because they were never tested and fail at restore time. And unclear decision rights, where nobody can authorise taking the website offline or resetting every credential, so the containment step itself waits for a meeting. The last one is the cheapest to fix and is usually a plan problem, not a technical one.
How do I reduce the time an incident takes to resolve?
Four preparation steps, all done before the incident. Decide in advance who can declare an incident and who can authorise containment, and write down their names and phone numbers. Test the restore, not the backup, because an untested backup extends recovery by days when it fails. Keep 180 days of logs as CERT-In directs, and make sure they are somewhere the attacker cannot reach. And run one tabletop a year, in which the team walks a ransomware scenario from detection to decision without touching production. The measurable benefit is decision time, and in most Indian engagements the team cuts hours from the containment phase purely because the authority to act was never in doubt.
| Phase | Typical duration | Controlled by |
|---|---|---|
| Detection and analysis | Hours to a few days | Quality and retention of logs |
| Containment | Hours to a few days | Clear authority to take systems offline |
| Eradication | One to two weeks | Finding every persistence point, including identity |
| Recovery and restoration | A few weeks to a few months | Clean backups and business readiness |
| CERT-In reporting | Within 6 hours of noticing | The notification template and an owner |
| DPDP notification | Without delay once confirmed | Legal and the Data Protection Board process |
What are the frequently asked questions?
Get a straight answer on this
Send us your last restore test date and your log retention window, and we will show you where the timeline will stretch when an incident happens.
Send us the details See pricing