Building an Incident Response Process That Works Under Pressure

Why Most Incident Plans Fail

Most incident response plans fail not because they're poorly written, but because they've never been tested. When a real incident hits, people panic and the beautifully documented plan sits unopened in a shared drive.

What You Actually Need

1. Clear Definitions

Define what constitutes a security incident vs. a security event. Not every alert is an incident, but every incident starts as an event.

Security Event: Something observable — a failed login, a vulnerability scan alert

Security Incident: An event that actually compromises confidentiality, integrity, or availability

2. Classification Scheme

Use a simple severity model:

•Critical Active data breach, ransomware, system-wide outage

•High Confirmed compromise, significant data exposure risk

•Medium Contained security issue, policy violation with limited impact

•Low Minor policy violation, suspicious activity with no confirmed impact

3. Response Procedures

#### Detection & Reporting

•How do people report incidents? (Email, Slack channel, phone number)

•Who monitors alerts outside business hours?

•What's the maximum time to acknowledge an incident?

#### Assessment & Triage

•Who decides severity classification?

•What's the escalation path?

•When do you involve legal, PR, or external parties?

#### Containment & Eradication

•Isolate affected systems

•Preserve evidence before wiping

•Remove the threat

•Verify clean state

#### Recovery

•Restore from clean backups

•Monitor for recurrence

•Gradually return to normal operations

#### Post-Incident Review

•What happened and when?

•What worked well in the response?

•What could be improved?

•What corrective actions are needed?

Testing Your Plan

•Tabletop exercises Walk through scenarios with key people (quarterly)

•Technical drills Test detection and response tools (semi-annually)

•Full simulations End-to-end exercise including communications (annually)

What Auditors Check

•Is there a documented incident response procedure?

•Are roles and responsibilities defined?

•Is there evidence of incidents being reported and handled?

•Are lessons learned captured and acted upon?

•Has the plan been tested?

Key Requirement

ISO 27001 doesn't expect you to have zero incidents — it expects you to handle them properly and learn from them.