1. Glossary
  2. Incident Response
Glossary

Incident Response

Incident response is the structured set of steps a team follows when something goes wrong, such as a security breach, an outage or a data leak, to contain the damage, remove the cause, restore normal operations and prevent a repeat.

In security, incident response (IR) is how an organization handles a breach or an attack. In operations and SRE teams, the same words describe the hands-on work of fixing an outage. The goals are the same either way: limit the impact, get back to normal quickly, and learn enough to stop it happening again.

The phases of incident response

The widely used lifecycle from NIST's incident handling guide (SP 800-61) has four phases:

  1. Preparation. Playbooks, on-call rotations, access, tooling and logging are in place before anything happens.
  2. Detection and analysis. Alerts, logs and reports are triaged to confirm an incident and judge its scope.
  3. Containment, eradication and recovery. Affected systems are isolated, for example by blocking an IP address, revoking credentials or rolling back a release. Then the cause is removed and service is restored while the team watches for a recurrence.
  4. Post-incident activity. A review documents the timeline, the root cause and the actions that will prevent a repeat.

The SANS model splits the same work into six steps: preparation, identification, containment, eradication, recovery and lessons learned.

What a good incident response plan includes

  • Roles: an incident commander, a technical lead, a communications lead and someone keeping the timeline.
  • Severity definitions and escalation paths, so everyone knows when to wake whom.
  • Playbooks for likely scenarios, such as a leaked credential, a DDoS attack or a database failover.
  • Communication templates for customers, internal stakeholders and regulators. Some deadlines are legal: under GDPR, a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, where feasible.
  • Evidence handling: preserve logs and disk images before systems are rebuilt.

Why logs and telemetry matter

You can only respond to what you can see. Centralized, retained logs and audit trails let responders work out who did what, when and from where, long after the attacker or the faulty deploy is gone. That is the job of a SIEM in security teams and of log analysis and tracing in operations teams. Logs that were never collected, or that rotated away last week, can't be investigated.

Incident response vs. incident management

Incident response is the work done during an incident. Incident management is the wider process around it, including on-call, communication and the follow-up after the incident is closed.

Incident response with Atatus

Atatus SIEM detects threats with built-in rules mapped to MITRE ATT&CK and lets analysts triage, assign and suppress signals. Security logs collect audit trails from Linux, Kubernetes, AWS CloudTrail, Okta, GitHub and other tools into one timeline per user. For outages, alerting and AI SRE bring the related alerts, traces and logs into one place.

← All glossary terms

Get started

See the root cause first.

Start free and send your first trace with OpenTelemetry or the Atatus agents. APM, logs, RUM, infrastructure and SIEM, all on one timeline.

  • SaaS
  • On-premises
  • Hybrid
  • BYOC
  • No per-user pricing