1. Purpose
This Incident Response Plan (“IRP”) defines how [Company Name] detects, contains, recovers from, and documents cyber incidents, with the goal of minimizing business disruption, legal exposure, and customer impact.
2. Scope
This plan applies to all systems, networks, and data owned or used by the company, including cloud services (Microsoft 365, Google Workspace, SaaS), vendor-managed systems, and personally- owned devices accessing company data.
3. Incident classification
- ✓Low — nuisance events (single phishing email, blocked malware, low-risk policy violation)
- ✓Medium — contained events (single endpoint compromise, a user who clicked, suspicious login blocked by MFA)
- ✓High — active or successful compromise (ransomware on one system, credential theft of a privileged account, data exfiltration underway)
- ✓Critical — business-impacting event (widespread ransomware, confirmed data breach of PII / PHI / CUI, any incident triggering regulatory notification obligations)
4. Roles and responsibilities
- ✓Incident Response Lead: [Name] — decision authority, communication owner
- ✓Technical Lead: [MSP or internal IT lead] — owns containment and eradication
- ✓Legal / Compliance: [Counsel] — owns notification obligations and litigation hold
- ✓Communications: [Owner or designated spokesperson] — handles client, employee, and regulator communication
- ✓Cyber-insurance Contact: [Carrier + policy #] — notified within policy's reporting window (often 24-72 hours)
5. The six phases
Phase 1 — Preparation (before anything happens)
- ✓IR plan written, signed, distributed
- ✓Annual tabletop exercise documented
- ✓Contact list (internal + external) up to date
- ✓Cyber-insurance policy + reporting instructions readily available
- ✓Backups tested and restore confirmed in the last 90 days
Phase 2 — Detection & triage
- ✓Source of alert logged (EDR, user report, MSP, external notice)
- ✓Initial classification assigned
- ✓Incident ticket opened with timestamp
- ✓Preliminary scope (what systems / users / data) documented
Phase 3 — Containment
- ✓Affected systems isolated from the network (not powered off — preserve volatile memory)
- ✓Compromised accounts disabled, sessions revoked, passwords rotated
- ✓Firewall / conditional-access rules tightened as needed
- ✓Communications with the attacker (ransomware notes, extortion emails) preserved, not engaged
Phase 4 — Eradication & recovery
- ✓Root cause identified and documented
- ✓Malicious artifacts removed from all affected systems
- ✓Systems rebuilt from clean backup or known-good images
- ✓Validation that the attacker no longer has access (credential resets, token revocation, persistence check)
- ✓Gradual return-to-service with monitoring
Phase 5 — Notification
- ✓Cyber-insurance carrier notified within policy window
- ✓Legal / compliance review triggers: HIPAA 60-day clock, state breach-notification laws, client contracts, GLBA, FERPA where applicable
- ✓Regulator notification if required (HHS, state AG, SEC for public companies)
- ✓Client / customer notification per legal review
- ✓Internal communication to staff
Phase 6 — Post-incident review
- ✓Written post-incident report within 30 days
- ✓Lessons-learned review with IR team and leadership
- ✓IR plan updated with new playbook items
- ✓Control gaps remediated or entered into the risk register
6. Communication templates
Keep pre-drafted communication templates on hand so you’re not writing from scratch during a live incident:
- ✓Internal staff announcement (short, factual, what to do / not do)
- ✓Client notification (per your counsel's guidance — legal exposure is real)
- ✓Regulator notification letter (per your compliance framework)
- ✓Press statement (only used if incident is public — prepared, not sent by default)
7. Annual testing
Schedule a tabletop exercise every 12 months. Walk through one ransomware scenario and one data-breach scenario with the full IR team, your MSP, and your legal / insurance contacts. Document what worked and what didn’t — the point isn’t to pass the test; it’s to find the gaps before they matter.