Incident Response Checklist for Small IT Teams

A practical incident response checklist helps a small IT team move fast under pressure: Triage → Contain → Preserve evidence → Eradicate → Recover → Learn. Use this as a repeatable, SOC-less playbook to reduce downtime, limit attacker spread, and keep clean documentation for stakeholders, legal/insurance, and future prevention.

How it works (for small teams without a SOC)

Small teams succeed in incident response by reducing decisions under pressure. The checklist below is designed for “no SOC” environments: one or two admins, limited tools, and lots of shared infrastructure.

0) Before you touch anything: establish control

• Declare an incident (even if you’re not sure yet). Create a ticket/war-room channel.
• Assign roles (one person can hold multiple roles):
• Incident Lead (decision maker)
• Comms (internal/external updates)
• Technical (hands-on containment/investigation)
• Scribe (timeline, actions, evidence list)
• Start an incident timeline: time detected, who reported, what changed, what you observed.

1) Triage (first 15 minutes)

Goal: confirm “is this real?”, determine blast radius, and prevent spread.

Checklist

• Identify the incident type (pick the closest):
• Phishing / account takeover (ATO)
• Malware / ransomware
• Business email compromise (BEC)
• Data exposure (public bucket/share)
• Suspicious admin activity / privilege abuse
• Web app compromise
• Capture the minimum critical facts:
• What systems/users are involved?
• What’s the first known bad time?
• What indicators exist (IP, domain, hash, process, file path)?
• Decide severity quickly:
• High: ransomware, active data exfil, admin compromise, widespread lateral movement
• Medium: single endpoint malware, suspicious login contained
• Low: blocked phishing attempt with no sign of compromise

Do now

• Freeze risky changes: pause planned deploys, avoid reboots unless needed (memory evidence may be lost).
• If email-based: search for the message org-wide and quarantine it.
• Start an IOC list (hashes/domains/IPs/filenames) so you can block and hunt consistently. (If you need a quick refresher on what qualifies, see What is an IOC?: what is an ioc/)

2) Containment (first 15–60 minutes)

Goal: stop ongoing attacker access and limit spread while preserving evidence.

Account containment

• Disable or reset credentials for suspected accounts (prioritize admins).
• Revoke sessions/tokens (SSO, M365/Google, VPN).
• Enforce MFA if not already enabled; rotate emergency break-glass credentials if exposure is suspected.

Endpoint/server containment

• Isolate affected endpoints from the network (EDR isolation, switch port, Wi‑Fi removal).
• For servers: restrict inbound/outbound via firewall/security group; don’t “wipe and rebuild” until evidence is collected.

Network containment

• Block known-bad IPs/domains at firewall/DNS/proxy (be cautious of overblocking production dependencies).
• If ransomware suspected: consider temporarily disabling SMB shares, RDP exposure, or lateral movement paths.

Evidence preservation

Save logs before they roll over:

• IdP/SSO sign-in logs
• Email audit logs
• VPN logs
• EDR alerts and event timelines
• Firewall/proxy/DNS logs
• Server auth logs (Windows Security, Linux auth)

Tooling note (optional, don’t derail containment): If you’re missing endpoint visibility, deploying a reputable endpoint security tool can help with isolation/telemetry. For example, Malwarebytes offers business endpoint protection options that can support containment workflows (Get Malwarebytes →). Validate fit against your environment and policies before rolling out during an incident.

3) Investigation and scoping (hours 1–24)

Goal: determine entry point, affected assets, and what the attacker did.

Checklist

• Identify initial access:
• Phishing? Stolen credentials? Exposed RDP/VPN? Vulnerable web app?
• Identify persistence:
• New admin accounts, OAuth app grants, mailbox rules, scheduled tasks, services, cron jobs, startup items
• Identify lateral movement:
• New remote logins, SMB/RDP/WMI, unusual admin tool use, password spraying
• Identify data access/exfil indicators:
• Large outbound transfers, new cloud shares, unusual API calls, mass downloads

Decision points

• If regulated data or confirmed exfiltration: consult legal/privacy and follow notification obligations.
• If you can’t confidently scope: consider bringing in an IR firm for forensic imaging and attacker tradecraft analysis.

4) Eradication (once contained)

Goal: remove attacker footholds and close the path used.

Checklist

• Remove persistence mechanisms (accounts, rules, scheduled tasks, services, startup entries).
• Patch/mitigate exploited vulnerabilities; close exposed ports; remove risky public access.
• Rotate secrets:
• Admin passwords, service account secrets, API keys, SSH keys
• VPN pre-shared keys, SSO app secrets, database credentials
• Rebuild or reimage compromised systems when integrity is doubtful (especially domain controllers, identity systems, and jump hosts).

5) Recovery (restore safely)

Goal: return to business without reintroducing the attacker.

Checklist

• Restore from known-good backups (verify backup integrity and restore points).
• Bring systems online in a staged manner: 1) Identity (IdP/AD), core networking, logging 2) Critical servers and apps 3) User endpoints
• Validate:
• No known persistence remains
• EDR is healthy and reporting
• Monitoring/alerts are working
• Users can operate normally
• Increase monitoring for 7–14 days (or longer for high-severity incidents).

6) Post-incident actions (within 1–2 weeks)

Goal: turn the incident into durable improvements.

Checklist

• Hold a blameless review:
• What happened (timeline)
• What worked / what didn’t
• What to change (owners + deadlines)
• Update:
• IR checklist/playbooks
• Firewall rules, conditional access, MFA policies
• Backup strategy (immutability, offline copies, restore tests)
• Admin access model (least privilege, JIT, separate admin accounts)
• Preserve evidence per policy (for legal/insurance) and store it securely.

When you’ll encounter it

Small IT teams typically need an IR checklist when:

• A user reports phishing and you suspect credentials were entered.
• You see impossible travel, MFA fatigue prompts, or unfamiliar logins in SSO logs.
• EDR flags ransomware behavior, suspicious PowerShell, or credential dumping.
• A server starts beaconing outbound or hosting unknown processes.
• A cloud storage container/share is discovered public.
• A vendor notifies you of potential exposure or you receive an extortion email.
• You detect unusual mailbox rules, forwarded mail, or payment detail changes (common in BEC).

Technical notes: quick evidence to collect (copy/paste)

Create a simple evidence folder and save exports/screenshots with timestamps.

Evidence to capture (minimum):
- Affected usernames, hostnames, IPs, MACs
- Alerts (EDR/SIEM), screenshots with time
- Email headers of suspicious messages
- SSO sign-in logs for affected users (24-72h window)
- VPN logs for affected users (24-72h)
- Firewall/DNS/proxy logs around first-known-bad
- List of running processes + network connections (affected hosts)
- Hashes of suspicious files (if safe to do so)

Technical notes: Windows quick triage commands

Run in an elevated prompt/PowerShell on affected machines when safe (preferably after isolation).

# Network connections
netstat -abno

# Logged on users
quser
whoami /all

# Recent logons (local)
wevtutil qe Security /q:"*[System[(EventID=4624)]]" /c:20 /f:text

# Scheduled tasks (persistence)
schtasks /query /fo LIST /v | more

# Services (look for unusual paths)
sc query state= all | more
Get-CimInstance Win32_Service | Select Name, State, StartMode, PathName | Sort Name

# Autoruns locations (basic)
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"

Technical notes: Linux quick triage commands

# Logged in users and recent auth events
who
last -a | head
sudo grep -i "sshd\|authentication failure\|Accepted\|Failed" /var/log/auth.log 2>/dev/null | tail -n 50
sudo journalctl -u ssh --since "24 hours ago" 2>/dev/null | tail -n 80

# Running processes and network listeners
ps auxf --sort=-%cpu | head
sudo ss -tulpn

# Persistence checks
crontab -l 2>/dev/null
sudo ls -la /etc/cron.* /var/spool/cron 2>/dev/null
sudo systemctl list-unit-files --type=service | grep enabled

Technical notes: log patterns worth searching

Identity/SSO:
- Multiple failed logins followed by success
- New device, new location, impossible travel
- MFA prompt spikes or MFA method changes

Email:
- New inbox rules (auto-forward, delete, mark as read)
- OAuth consent grants to unfamiliar apps
- Login from unusual ASN/country

Endpoints/servers:
- PowerShell encoded commands
- New local admin accounts
- Remote service creation / scheduled tasks
- Unusual outbound connections to rare domains

Further reading (recommended)

• If you need to align endpoint tooling and isolation capabilities with your environment, compare options here: best antivirus for windows business endpoints 2026
• For terminology you’ll use during triage and scoping (especially when sharing IOCs), see: what is an ioc

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.