Incident response is the process an organisation follows once something has already gone wrong, from the moment an alert fires to the day the lessons are written down.
The short answer
Incident response is the structured handling of a confirmed or suspected security incident: detect it, work out what happened, stop it spreading, remove the attacker, restore service, and improve. It is a required control under SOC 2, ISO 27001, PCI DSS and every Indian regulator, and it runs against a clock, because breach notification deadlines start when you notice, not when you are ready.
Most teams write the plan and never run it. The gap between having a document and having a capability is where the cost of a breach actually accumulates.
On this page
The incident response lifecycle
Six stages, and the order matters. Skipping analysis to get to containment is how teams reimage a machine, lose the evidence, and watch the attacker return through the same door a week later. Stage 2 depends entirely on detection coverage that is already in place.
What changed at NIST
Almost every article on this subject still teaches the four-phase lifecycle from NIST SP 800-61 Revision 2. That document was formally withdrawn on 3 April 2025 and superseded in its entirety by Revision 3.
| Revision 2, withdrawn | Revision 3, current |
|---|---|
| Four discrete phases: preparation, detection and analysis, containment and eradication and recovery, post-incident activity | Activities distributed across the six CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond, Recover |
| Incident response treated as a bounded event lasting a few days | Incident response treated as a continuous part of cybersecurity risk management |
| Lessons learned as a meeting at the end | Improvement as an ongoing activity throughout, not a closing ritual |
The practical work has not changed. What has changed is the language auditors and insurers now expect to see. If your plan cites Revision 2, it is citing a withdrawn document.
What incident response is not
| Term | Covers |
|---|---|
| Incident response | Handling a security incident, from detection through recovery and improvement |
| Disaster recovery | Restoring systems and data after any outage, including fire, flood and hardware failure |
| Business continuity | Keeping the business running while something is broken, regardless of cause |
| Crisis management | Board-level decision authority and external communication when an incident threatens the company itself |
| Digital forensics | Preserving and analysing evidence, usually invoked inside the analyse stage |
What the plan has to contain
| Section | What it answers |
|---|---|
| Severity classification | Objective tiers, so nobody argues about whether this qualifies while the clock runs |
| Roles and contacts | Named people with named deputies, reachable outside working hours |
| Detection sources | Which systems feed the SIEM, and what an alert is expected to trigger |
| Containment options | What can be isolated, who is authorised to do it, and what breaks if they do |
| Evidence handling | What gets preserved before anything is wiped, and where it is stored |
| Notification matrix | Which regulator, which customer contract, which clock, and who signs |
| Recovery criteria | How you decide a system is safe to bring back, rather than merely working again |
| Exercise schedule | When the plan gets tested, and what evidence the test produces |
Untested is treated as unproven
Auditors do not ask whether an incident response plan exists. They ask for the tabletop exercise record: the scenario used, who attended, what broke, and whether the findings were closed. A plan with no exercise history is assessed as a document, not a control.
Where frameworks require it
| Framework | Status | What it expects |
|---|---|---|
| SOC 2 | Required | Common Criteria covering evaluation of security events and a defined response programme, evidenced across the observation window |
| ISO 27001 | Required | Annex A controls for incident planning, assessment and decision, response, evidence collection and learning |
| PCI DSS | Required | A documented plan, tested at least annually, covering payment card compromise specifically |
| CERT-In Directions | Required | Reporting of specified incident types within six hours of noticing them |
| DPDP Act | Required | Intimation of a personal data breach to the Data Protection Board and to affected individuals |
| Cyber insurance | Asked | Applications routinely ask whether an incident response programme aligned to NIST 800-61 is in place, and the answer affects terms |
The insurance line is the one teams forget. An incident response programme is not only an audit control. It is an underwriting input, and it is checked again at claim time.
How Osto runs incident response
The hardest part of incident response is not the plan. It is knowing an incident started. Osto covers detection by default rather than as a separate purchase. Correlated logging sees endpoint, cloud, identity, application and API activity in one stack, so a sequence that looks unremarkable in four separate consoles surfaces as one alert. Endpoint detection supplies the containment action, and cloud posture management and VAPT with regular penetration testing reduce how often the plan gets used at all.
The evidence layer is purpose-built for the audit side. Detection records, retention and closure map to ISO 27001, SOC 2, the DPDP Act and Indian sectoral frameworks from one evidence set, so the same work answers an auditor, an enterprise buyer and an insurer.
Platform walkthrough
The clock starts when you notice
Osto correlates endpoint, cloud, identity and application signals in one platform, so detection happens early and the evidence is already there. One owner, one dashboard.
Book a demoAudit-ready in days · SOC 2, ISO 27001 and DPDP mapped · One platform, everything
Frequently asked questions
What is incident response?
The structured process of handling a security incident: detecting it, analysing what happened and how far it reached, containing the damage, removing the attacker, restoring service safely, and feeding what you learned back into preparation. It is a required control under every major security framework.
What are the stages of incident response?
Operationally, six: prepare, detect, analyse, contain, eradicate and recover, and improve. NIST SP 800-61 Revision 3 now maps these activities to the six functions of the Cybersecurity Framework 2.0 rather than presenting them as a standalone lifecycle, but the order of work during a real incident is unchanged.
Is the four-phase NIST incident response lifecycle still current?
No. NIST withdrew SP 800-61 Revision 2 on 3 April 2025 and superseded it entirely with Revision 3, which restructures incident response around Govern, Identify, Protect, Detect, Respond and Recover. Plans that cite Revision 2 should be updated to reference Revision 3.
What is the difference between incident response and disaster recovery?
Incident response deals with a security event: an attacker, a compromise, a data exposure. Disaster recovery deals with restoring systems and data after any disruption, including outages with no attacker involved. An incident often triggers disaster recovery, but they answer different questions.
How often should an incident response plan be tested?
At least annually, and after any material change to systems or team. Testing means a tabletop exercise or simulation with a recorded scenario, participants, findings and closure evidence. Auditors and insurers both treat an untested plan as an unproven one.