Incident Response & Security Operations

The fire drill: when (not if) something goes wrong, who’s on call, what do they do first, and how do we get back to normal fast.

At a glance

• What it is: the people, monitoring, and rehearsed processes (SOC, SIEM, playbooks) that detect a security incident, contain it, and drive the organization back to a safe state — plus the review that happens afterward.
• Why it matters: incidents happen even in well-designed systems; the difference between a contained, hours-long incident and a sprawling, weeks-long crisis is almost always whether there was a rehearsed response, not luck.
• For developers: know who to notify and what not to do (e.g. don’t quietly patch and redeploy without informing the incident owner) if you suspect you’ve found or caused a security incident.
• When to use it: every organization needs at least a basic incident response process before it needs one — waiting until the first real incident to design the process is too late.
• When not to use it: N/A — the scale of the response team and tooling scales with organization size, but every organization needs some version of this.
• Prerequisites: Identity & Access Management (IAM) — most incidents involve an identity or access question early in the investigation.

Mental model

flowchart LR
    M[Monitoring / SIEM detects anomaly] --> T[Triage: real incident?]
    T -- No --> Close[Close as false positive]
    T -- Yes --> C[Contain: isolate affected systems/accounts]
    C --> Er[Eradicate root cause]
    Er --> Rec[Recover to normal operation]
    Rec --> Rev[Post-incident review]

Step-by-step walkthrough

1. Set up monitoring/SIEM to detect anomalies (unusual logins, privilege escalation, abnormal traffic) and alert the right people.
2. Write playbooks in advance for likely incident types (phished credentials, DDoS, data exposure) so responders aren’t improvising under pressure.
3. On detection, triage quickly: is this a real incident, and how severe is it?
4. Contain first — isolate the affected account/system — before trying to fully understand root cause; containment limits damage while investigation continues.
5. After recovery, run a blameless post-incident review: what happened, what worked, what didn’t, and what changes prevent a repeat.

Worked example

The phished support engineer’s account (see Identity & Access Management) triggers an anomaly alert when it logs in from an unusual location and attempts to access the admin console.

• Input: a SIEM alert for an unusual login pattern on a privileged account, with no rehearsed process for what happens next.
• Process: the on-call responder follows a pre-written playbook for suspected account compromise — disabling the account and forcing a password/session reset immediately, then notifying the security lead, before starting root-cause investigation.
• Output: the compromised account is contained within minutes of detection rather than remaining active for hours, and a post-incident review drives the MFA and network segmentation fixes covered elsewhere in this section. Concretely, Microsoft Sentinel raises the anomaly from Entra ID sign-in logs, and the responder’s containment step revokes the account’s active sessions and disables sign-in directly in Microsoft Entra ID — automated as a Sentinel playbook (Logic App) for the most common incident types.

resource law 'Microsoft.OperationalInsights/workspaces@2023-09-01' = {
  name: 'law-security-ops'
  location: location
  properties: { sku: { name: 'PerGB2018' }, retentionInDays: 90 }
}

Application Insights telemetry and Entra ID sign-in logs both feed this same Log Analytics workspace, which is what lets one Sentinel alert rule correlate an app-level anomaly with an identity-level one instead of investigating each in isolation.

Common use cases

Use case	When to use	Notes
Unusual login or privilege escalation detected	Immediately	Contain (disable account/force reset) before completing full investigation
A new class of incident occurs with no existing playbook	During the incident, and immediately after	Write the playbook while it’s fresh so the next occurrence isn’t improvised again
An incident is resolved	Within days of recovery	Run a blameless post-incident review and track resulting action items
Building an incident response capability for the first time	Before the first real incident	Start with monitoring/alerting and at least one playbook, even a simple one

Advanced details

• SOC and SIEM: a Security Operations Center (SOC) is the team (in-house or outsourced) responsible for monitoring and responding; a SIEM (Security Information and Event Management) system aggregates logs and raises alerts on suspicious patterns.
• Containment before full root-cause analysis: waiting for complete certainty before acting lets damage continue to spread — contain based on reasonable suspicion, then investigate.
• Blameless post-incident review: focusing on what the process/system allowed rather than who made a mistake produces more honest, useful findings and faster fixes.

Quick reference

Term	Meaning
SOC	Security Operations Center — the team monitoring and responding to security events
SIEM	Security Information and Event Management — aggregates logs and raises alerts
Playbook	A pre-written, rehearsed response procedure for a specific incident type
Containment	Isolating an affected system/account to stop an incident from spreading
Post-incident review	A blameless retrospective after an incident, producing concrete follow-up actions

Troubleshooting

Symptom	Likely cause	Fix
An incident takes hours to contain after detection	No pre-written playbook, responders improvising	Write playbooks in advance for likely incident types
The same type of incident recurs	Post-incident review findings weren’t tracked to completion	Assign owners and deadlines to post-incident action items, same as any other tracked work
Responders wait for full certainty before acting	No guidance on acting under reasonable suspicion	Explicitly authorize containment actions (disable account, isolate host) on reasonable suspicion, not proof

Check your understanding

• Why is containing a suspected incident before fully understanding its root cause usually the right call?
• What makes a post-incident review “blameless,” and why does that produce better outcomes?

Related pages

Part of Introduction to Security Architecture. See also Identity & Access Management (IAM), Cloud Security Posture & Perimeter Defense, Security Governance & Compliance Frameworks, and the Glossary.