Incident Response Checklist: 16-Item Guide for Security Incidents

TL;DR

Stop. Breathe. Work the list in order. 6 critical items must be done immediately to stop ongoing damage, 6 important items help you understand what happened, and 4 recommended items cover communication. Containment first, then investigation, then communication. Don't say anything externally until you know what actually happened.

If you're reading this mid-incident, you're already ahead. Looking for a structured process instead of panicking is the right instinct. The biggest mistakes happen when people rush to fix things before they understand the full picture. Print this out. Work through it top to bottom, and resist the urge to skip ahead to communication before containment is done.

Quick Checklist (5 Critical Items)

Rotate compromised credentials immediatelyChange API keys, database passwords, or tokens that may be exposed

Revoke suspicious sessionsInvalidate all user sessions if attacker has active access

Start an incident logRecord time discovered, who discovered, initial symptoms

Preserve logs before they rotateExport application, server, database, and auth logs immediately

Determine attack vectorHow did they get in? Exposed credentials, vulnerability, social engineering?

Immediate Containment 4

Rotate compromised credentials immediatelyChange API keys, database passwords, or tokens that may be exposed. How to rotate API keys

Revoke suspicious sessionsIf attacker has active sessions, invalidate all user sessions if needed. How to revoke sessions

Block malicious IPs or accountsIf you can identify attacker, block their access immediately. How to block malicious access

Consider taking service offlineIf damage is ongoing, temporary downtime may be better than continued breach. How to set up emergency maintenance

Document Everything 4

Start an incident logRecord: time discovered, who discovered, initial symptoms. How to document incidents

Preserve logs before they rotateExport application logs, server logs, database logs, auth logs. How to preserve logs

Screenshot relevant dashboardsCapture current state of monitoring, analytics, error tracking. How to capture incident evidence

Record all actions takenLog every change you make, who made it, and when. How to create an incident timeline

Investigate 4

Determine attack vectorHow did they get in? Exposed credentials, vulnerability, social engineering? How to investigate a breach

Identify scope of accessWhat systems, data, or accounts were accessed or modified? How to assess breach scope

Determine data exposureWhat user data was potentially accessed? Emails, passwords, payment info? How to assess data exposure

Check for persistenceDid attacker create backdoors, new accounts, or scheduled tasks? How to check for backdoors

Communicate 4

Notify internal stakeholdersInform team leads, founders, legal as appropriate. How to communicate internally

Determine notification requirementsCheck GDPR, state laws, contracts for breach notification requirements. How to determine notification requirements

Draft user communicationIf required, prepare honest, clear communication about what happened. How to write a breach notification

Notify affected usersSend notification with: what happened, what data, what you're doing, what they should do. How to notify affected users

After the Incident

Once the crisis is over, run a post-mortem. Write down the root cause, the timeline, and what you'd do differently, while the details are still fresh. Then change something. A post-mortem that doesn't change your security practices is just a document.

Think about whether this needs reporting to law enforcement. For significant breaches, especially ones involving payment data or large volumes of personal information, talk to legal counsel about what you're actually required to report.

Should I take my site offline during an incident?

It depends. If the attacker still has access and is actively causing damage, downtime beats an ongoing breach. If you've already contained it by rotating credentials and blocking access, you can usually stay online while you investigate.

When do I need to notify users?

Legal requirements depend on where your users are. GDPR gives you 72 hours to report a personal data breach; US state laws set their own clocks. Beyond the legal floor: if passwords, payment details, or anything sensitive was accessed, notify affected users anyway.

Should I admit fault publicly?

Be honest, but measured. Say what happened without speculating about what might have, and keep the focus on what you're doing to fix it. Skip the blame and the over-apologizing. For anything significant, run the statement past legal counsel first.

TL;DR

Quick Checklist (5 Critical Items)

Immediate Containment 4

Document Everything 4

Investigate 4

Communicate 4

After the Incident

Should I take my site offline during an incident?

When do I need to notify users?

Should I admit fault publicly?

Related Articles

Post-Incident Security Checklist

Cost of Data Breach for Startups

How to Rotate API Keys

Prevent the Next Incident

Incident Response Checklist: 16-Item Guide for Security Incidents