The Definitive Guide to SOC Incident Management: A Playbook for Security Teams
Master the end-to-end incident response lifecycle within a Security Operations Center (SOC). Discover actionable strategies for preparation, rapid containment, establishing a SOC team, and leveraging Adayptus's Managed SOC services for ultimate cyber resilience.
Most incident response plans fail at the same point, and it is not the technical one. It is the moment someone has to decide whether this is an incident, at two in the morning, when the person named in the plan left the company eight months ago and nobody is certain who can authorise disconnecting a production system.
Detection tooling has improved considerably. Decision-making under pressure has not, because it is an organisational problem rather than a technical one — and it is the part that determines whether an intrusion is contained in twenty minutes or discovered by a customer three weeks later.
This guide is a practical playbook: how to structure the phases, what a genuinely useful runbook contains, how severity classification should work, the specific pressures created by CERT-In's six-hour reporting window, and the metrics that show whether your response capability is actually improving.
- 01Response fails on authority, not technology — pre-authorise containment before you need it.
- 02Severity must be defined by business impact, not alert severity from a tool.
- 03CERT-In's six-hour clock starts at detection, so classification cannot wait for full analysis.
- 04Preserve evidence before containment where possible — rebuilding a host destroys the investigation.
- 05A plan that has never been rehearsed out of hours is a document, not a capability.
The Six Phases, and Where Each Breaks
| Phase | Objective | Where it typically fails |
|---|---|---|
| Preparation | Runbooks, authority, tooling, contacts | Contact lists go stale; nobody owns maintenance |
| Detection & triage | Recognise and classify quickly | Alert fatigue; the real alert sits in a queue |
| Containment | Stop the spread | Analysts lack authority to act and wait for approval |
| Eradication | Remove the foothold | Root cause missed; the attacker returns through the same path |
| Recovery | Restore service safely | Restoring from a backup that already contained the compromise |
| Lessons learned | Fix what allowed it | Skipped once service is restored and attention moves on |
Two of these deserve particular attention because they are where the most expensive mistakes happen.
Containment authority. If an analyst who identifies a compromised host at 3 a.m. must wake a manager to get permission to isolate it, your effective containment time is however long that takes. Define scenarios in advance where analysts may act unilaterally — isolate an endpoint, disable an account, block an address — and accept that occasionally they will isolate something they did not need to. That cost is trivial compared to an hour of unchecked lateral movement.
Recovery from compromised backups. Ransomware in particular frequently dwells for weeks before executing, which means recent backups may already contain the attacker's persistence. Restoring without verifying reinstates the compromise, and organisations have been re-encrypted days after recovering. Restore into an isolated environment and verify before returning to production.
Severity Classification That Works
Most classification schemes fail because they inherit severity from the alerting tool. A tool's "critical" reflects a pattern match, not what it means for your business.
Classify on impact instead: what is affected, whether sensitive data is involved, whether the attacker retains access, and whether the incident is spreading. Each level should carry a defined response time, escalation path and named decision-maker — including out of hours, which is when incidents disproportionately occur.
A test worth running this week: pick your highest severity level and ask who, by name, can authorise taking a production system offline at 3 a.m. on a Sunday — and what happens if that person does not answer. If the answer takes more than a few seconds, that is your response bottleneck, and no detection improvement will fix it.
The Six-Hour Clock
For Indian organisations, CERT-In directions require specified cyber incidents to be reported within six hours of detection. The operational implication is frequently underestimated: the clock starts at detection, not at full understanding.
Six hours is not long enough to complete forensic analysis, so your process must be able to report on partial information and update later. That demands three things prepared in advance: clear criteria for what constitutes a reportable incident, a pre-drafted reporting template so nobody is composing prose under pressure, and a named person authorised to submit the report out of hours.
Where personal data is involved, DPDP notification obligations run in parallel to different recipients on a different timeline — so your triage step must evaluate each obligation independently. Our walkthrough of CERT-In six-hour reporting covers the mechanics in detail.
What a Useful Runbook Contains
Most runbooks are too long to use during an incident. A useful one fits on a page and assumes the reader is tired and under pressure.
- Trigger — the specific conditions under which this runbook applies.
- Immediate actions — the first three steps, in order, with the commands or console paths.
- Evidence to preserve first — memory, logs, disk images, before anything is changed.
- Containment options — with the authority level required for each.
- Who to notify — named roles with current contact details and a fallback.
- Regulatory triggers — whether this scenario is likely reportable, and to whom.
- Known false-positive causes — so a maintenance window is not escalated as an intrusion.
Build runbooks for the scenarios you will actually face: ransomware, business email compromise, credential compromise, data exfiltration, insider misuse, and public-facing application compromise. Six good runbooks beat a forty-page plan nobody opens.
Evidence Before Eradication
There is a genuine tension between containing quickly and preserving what you need to understand the incident, and teams under pressure default to rebuilding.
Rebuilding a compromised host destroys the evidence that would have told you how the attacker got in, what they accessed, and whether they are still present elsewhere. You then cannot answer the questions that determine your notification obligations, and you have not established root cause — so the same path remains open.
The workable compromise is to isolate rather than rebuild. Network isolation stops the spread while leaving the system intact for analysis. Capture volatile memory and preserve logs centrally before any remediation, because the attacker may be actively deleting them.
Metrics That Show Real Capability
- 01Measure mean time to detect and to contain, not tickets closed.
- 02Track time from detection to classification — the six-hour clock depends on it.
- 03Pre-authorise containment actions for defined scenarios, in writing.
- 04Verify the contact list quarterly — stale contacts are the most common plan failure.
- 05Keep a pre-drafted regulatory template ready to submit.
- 06Maintain an out-of-band communication channel — assume email and chat are compromised.
- 07Rehearse out of hours at least annually, including the escalation path.
- 08Confirm backups are recoverable and clean, by testing restoration.
The out-of-band channel matters more than it sounds. If an attacker has access to your email or chat platform, coordinating your response there tells them exactly what you are doing next.
How Adayptus Helps
- Incident Response & DFIR — containment and forensics, with retainer options for guaranteed response.
- Managed SOC & MDR — 24×7 detection so the clock starts as early as possible.
- Crisis Simulation — rehearsing the decision path, including out of hours.
- Advanced Threat Simulation and Red Teaming — proving detection and response work under pressure.
- SOC Maturity Assessment — an honest baseline of current response capability.
Related reading: traditional versus advanced SOC and the ransomware defence playbook.
Frequently Asked Questions
Click any question to expand the answer.
QWhy do incident response plans fail in practice?
Almost always on authority and currency rather than technology. Analysts who identify a compromise frequently lack permission to contain it and must wait for someone to approve, and the contact list naming that person has not been updated since people left. Detection tooling has improved considerably; the decision-making layer around it usually has not, and that is what determines whether an intrusion is contained in twenty minutes or discovered weeks later.
QShould analysts be allowed to contain without approval?
For defined scenarios, yes. Pre-authorise specific actions — isolating an endpoint, disabling an account, blocking an address — so an analyst can act immediately rather than waking someone for permission. You will occasionally isolate something that did not need isolating, and that cost is trivial against an hour of unchecked lateral movement. Reserve approval requirements for genuinely disruptive actions such as taking a production service offline.
QHow do we meet the six-hour CERT-In reporting window?
By accepting that you will report on partial information. The clock starts at detection, not at understanding, and six hours is not enough for forensic analysis. Prepare three things in advance: clear criteria for what constitutes a reportable incident, a pre-drafted template so nobody is composing prose under pressure, and a named person authorised to submit out of hours with a documented fallback. Then rehearse the path end to end.
QShould we rebuild a compromised system immediately?
Isolate first, rebuild later. Rebuilding destroys the evidence that would establish how the attacker entered, what they accessed and whether they remain elsewhere — leaving you unable to answer the questions that determine your notification obligations, and with the original entry path still open. Network isolation stops the spread while preserving the system. Capture volatile memory and secure logs centrally before remediation, since attackers frequently delete them.
QCan we restore from backup after a ransomware incident?
Only after verifying the backup is clean. Ransomware commonly dwells for weeks before executing, so recent backups may already contain the attacker's persistence mechanisms — organisations have been re-encrypted days after apparently recovering. Restore into an isolated environment, verify there is no persistence, and only then return to production. Test restoration regularly as well, since a backup that has never been restored is an assumption rather than a control.
QHow often should we rehearse our incident response plan?
At least annually, with a tabletop exercise more frequently, and crucially at least one rehearsal that simulates out-of-hours conditions. Incidents disproportionately occur at night and at weekends, which is exactly when the escalation path is weakest and stale contact details surface. Verify the contact list quarterly regardless — an unmaintained list is the single most common reason a rehearsed plan fails in a real incident.
Adayptus Security Research
Strategic Intelligence Division
Adayptus Consulting is a premier provider of enterprise cybersecurity solutions, specializing in Managed SOC, Penetration Testing, and GRC strategy. Our intelligence division regularly publishes research to help CISOs navigate the evolving threat landscape.
