The Incident Response Operating Model

Every incident response capability needs a clear operating model that defines roles, phases, and decision-making authority. Without it, incidents devolve into chaos — people step on each other, critical decisions go unmade, and evidence is lost.

The Six-Phase Lifecycle

The PICERL model defines six sequential phases:

Preparation — Training, tooling, playbooks, and relationships established before an incident occurs. This is where you build the capability.

Identification — Detection and initial triage. Something is happening — is it an incident? What severity? Who needs to be involved?

Containment — Stop the bleeding before you understand everything. Take affected systems offline, block IPs, reset credentials. Contain first, investigate second.

Eradication — Remove the root cause once you understand it. Patch the vulnerability, remove the attacker's access, clean up persistence mechanisms.

Recovery — Safely restore normal operations. Verify the fix works, monitor for recurrence, and gradually return services to production.

Lessons Learned — The post-incident review. What happened? What did we do well? What should we change? This is a blameless exercise focused on improving systems and processes.

Incident Command Structure

For every incident, assign these roles:

• Incident Commander — Runs the response, makes decisions, delegates tasks. Does not fix technical issues.
• Technical Lead — Investigates and fixes the technical problem. Reports to the IC.
• Communications Lead — Manages internal and external communications. Drafts updates for stakeholders, customers, and regulators.
• Scribe — Maintains the incident timeline. Every decision, action, and observation is logged.
• Legal/Privacy Counsel — Advises on notification obligations, regulatory requirements, and legal risk.

One person can hold multiple roles in a small team, but the responsibilities must be assigned and clear.

Severity Classification & Escalation

A clear severity classification system ensures the right people are engaged at the right time with the right level of urgency. Every team member should be able to classify an incident without ambiguity.

Severity Levels

SEV-1 Critical: Active data breach, ransomware with encryption spreading, service-wide outage affecting all customers, confirmed payment card compromise. Response: Page the entire incident response team immediately. Executive notification within 15 minutes. Update every 30 minutes or more frequently.

SEV-2 High: Confirmed unauthorized access with limited scope, malware detected on a single system, critical service degraded but not down, phishing campaign targeting multiple employees. Response: Page the primary response team. Executive notification within 1 hour. Update every 2 hours.

SEV-3 Medium: Suspicious activity under investigation, policy violation without evidence of data exposure, single-user account compromise with contained impact. Response: Notify during business hours. Next-business-day update.

SEV-4 Low: Phishing simulation metrics review, tabletop exercise, minor policy exception. Response: Normal process, resolve within the sprint.

The Escalation Ladder

When an incident exceeds the current responder's capacity or authority, escalation is mandatory:

Level 1: On-call responder — Triages, contains if possible, decides whether to escalate.

Level 2: Security team lead — Takes over for confirmed SEV-2+ incidents, coordinates response, calls in additional resources.

Level 3: Incident Commander — Activates full incident response process for SEV-1. Has authority to engage executive leadership, external counsel, and law enforcement.

Level 4: Executive — Makes strategic decisions about public disclosure, ransom payment, regulatory notification, and business continuity.

When in Doubt, Round Up

The cost of escalating a non-incident is a few minutes of someone's time. The cost of failing to escalate a real incident can be millions of dollars. If you're unsure about the severity, escalate to the next level.