Before We Start: The Two Most Important Things to Do Right Now
The worst time to write an incident response plan is when you're in the middle of an incident. Two things you should do today, before anything happens:
- Fill in your incident response contact card below with real names, phone numbers, and roles — and share it with every person on the list. A contact list that exists in only one person's head is useless when that person is unavailable.
- Print or save this checklist somewhere accessible offline. If your systems are down during an incident, a checklist stored only in your cloud drive is unreachable. Print one copy and keep it somewhere physical.
// Incident Response Contact Card — Fill This In
If you believe this is an active, ongoing attack: disconnect affected systems from the network immediately (pull the cable or disable Wi-Fi), but do NOT power them off. Powered-off machines lose volatile memory that may contain critical forensic evidence. Speed of isolation beats all other priorities in the first 5 minutes.
The Interactive Incident Response Checklist
Work through each phase in order. Tick each item as you complete it. Your progress is tracked below.
What systems are affected? What data is involved? Is this an active attack, a past breach, or a suspected compromise? Classify severity: Critical (data breach/ransomware), High (system compromise), Medium (suspicious activity), Low (policy violation). Document your initial assessment with timestamps.
Call your Incident Commander, IT/Security Lead, and Legal Counsel. Notify CyberCloak if we're your IR partner. Create a dedicated communication channel (separate Slack workspace, Signal group, or a bridge call) that doesn't use your potentially compromised systems.
Disconnect compromised systems from the network — pull network cables, disable Wi-Fi adapters, or use network switch ACLs to isolate affected VLANs. Do NOT turn machines off. If cloud-based, use security groups or firewall rules to isolate compromised instances. Document every system you isolate with the time of action.
Take memory dumps of affected systems before any remediation. Export security logs from your SIEM, firewall, and cloud provider immediately — some logs rotate and may be lost. Preserve email headers if the initial vector was phishing. Create forensic disk images if possible. Maintain chain of custody documentation.
Change passwords for: email accounts, admin accounts, cloud consoles, and any service the attacker may have accessed. Revoke active API keys and OAuth tokens. Enable MFA everywhere it isn't already active. Do this from a clean device — one you're confident wasn't part of the compromised environment.
Determine whether personal data, financial data, intellectual property, or credentials were accessed or taken. Review network egress logs for large data transfers. Check cloud storage access logs. This assessment determines your regulatory notification obligations and the severity of business impact.
If personal data of EU individuals was likely accessed or exfiltrated, you must notify your DPA within 72 hours of becoming aware. In Ireland, this is the Data Protection Commission (DPC). Get your legal counsel involved immediately. The notification must include: nature of the breach, categories and approximate number of individuals affected, likely consequences, and measures taken. Incomplete or late notification compounds the regulatory risk.
Call your cyber insurance provider immediately — many policies require prompt notification and include IR professional fees, legal costs, and ransom negotiation services. If you don't have internal IR capability, engage external specialists. Delayed notification can affect coverage. Also notify law enforcement (An Garda Síochána in Ireland, or relevant national authority) if criminal activity is involved.
Before recovering systems, identify how the attacker got in and close that path. Patch the vulnerability, deactivate the compromised account, fix the misconfiguration. Bringing systems back online before the initial vector is closed means you're recovering into an already-compromised environment — the attacker may still be present or able to return immediately.
Restore from your most recent clean backup (verify it pre-dates the compromise). Validate restored systems with integrity checks before reconnecting to the network. Monitor closely for 72 hours post-recovery for signs of persistent access. Conduct a full vulnerability scan before returning systems to production. Communicate recovery status to affected staff and stakeholders.
"The organisations that recover well from incidents aren't the ones with the best technology. They're the ones who practiced their response before they needed it."
— Tom Walsh, Lead Penetration Tester & IR Lead, CyberCloakPhase 5: Post-Incident Review (Within 2 Weeks)
Once the immediate crisis is resolved, the post-incident review is where the real learning happens. Schedule a dedicated session within two weeks while the details are still fresh. Cover:
- Root cause analysis: How did the attacker gain initial access? What was the first indicator of compromise? How long were they in the environment before detection?
- Detection gaps: Why wasn't this detected sooner? What alerts were missed or didn't exist? What logging was insufficient?
- Response gaps: What parts of this checklist were unclear or missing? Who didn't know their role? What communication broke down?
- Remediation actions: What specific changes will prevent a repeat? Assign owners and deadlines to every action item. Track to completion.
- Checklist updates: Update this runbook based on what you learned. An IR plan that's never updated is never ready for the next incident.
Don't wait for a real incident to test this checklist. Schedule a 90-minute tabletop exercise once a year where you walk your team through a simulated scenario — ransomware, phishing, insider threat — and practise the decisions you'd need to make. The gaps you find in a simulation are far less costly than the gaps you find during a real attack.
Get a Custom Incident Response Runbook for Your Business
This checklist is a starting point. A proper IR runbook is tailored to your specific systems, team structure, and regulatory obligations. We build and test these for businesses of all sizes — and run the tabletop exercises to make sure they work.