---
{
  "title": "Incident response",
  "summary": "Follow an account-compromise example to understand investigation, containment, recovery, communication, and incident ownership.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Turning uncertainty into coordinated action

Incident response is the organized work of investigating and managing security incidents, limiting harm, and restoring trustworthy service. It requires technical analysis, authority to act, communication, and a record of decisions. A suspicious event starts a question; the response process helps the organization decide what the event means and what should happen next.

NIST SP 800-61 Revision 3 connects incident response with broader cybersecurity risk management. Preparation and improvement support the work before and after a particular incident. During an incident, investigation, containment, and recovery can overlap rather than following an inflexible sequence.

## A compromised mailbox scenario

Imagine an employee reports messages sent from their account that they do not recognize. The responder records the report and obtains relevant account and mailbox events through authorized tools. An initial question is whether an unauthorized person accessed the mailbox and what that person did.

The team may need to restrict access while investigating. Resetting a password might be one action, but active sessions, registered authenticators, forwarding rules, delegated access, and connected applications could require separate review. The specific actions depend on the service and evidence.

A service owner decides how essential business communication will continue while the account is restricted. The investigator preserves useful records before retention limits or response actions make them unavailable. Someone records actions and times so other responders can distinguish attacker activity from the team's own changes.

## Containment is a decision with consequences

[[containment]] limits ongoing harm. Blocking an account can interrupt an attacker, but it can also interrupt legitimate work. Isolating a host can protect other systems while changing what evidence remains accessible. The response lead needs enough context to weigh those effects and the authority to choose.

A useful decision record states the evidence available, the expected benefit, the likely disruption, and the person responsible. It also notes what would cause the team to change course. New evidence may expand the scope beyond the first account or show that the original explanation was incomplete.

## Recovery needs evidence of readiness

[[eradication-and-recovery]] addresses the cause and restores service under appropriate conditions. “The alert stopped” is not the same as demonstrating that an attacker no longer has access. The recovery plan should identify which weaknesses were addressed, which access routes were checked, and what monitoring will support the restored service.

[[incident-reporting]] explains how to communicate the findings and their limits. Separate observed facts from hypotheses. If the team cannot determine whether a document was downloaded because the necessary logs were unavailable, report that uncertainty rather than turning an evidence gap into reassurance.

## Practice before the urgent event

Use [[incident-playbooks]] for a short tabletop exercise. Give a fictional team one mailbox report and ask who leads, who can suspend access, which records are needed, and how decisions will be shared. Introduce a second affected account halfway through.

The exercise should reveal missing ownership and dependencies, not reward memorizing a perfect script. Use the findings to improve the process, then practice the difficult parts again.