1. Purpose & Scope

This plan defines how [Organization Name] detects, responds to, and recovers from security incidents affecting its systems, data, or operations. It applies to all employees, contractors, and third parties operating on or with access to [Organization Name]'s systems, and covers incidents affecting confidentiality, integrity, or availability of company or customer data.

2. Definitions

Security Incident: Any event that jeopardizes the confidentiality, integrity, or availability of an information system or the data it processes, stores, or transmits — whether or not it results in actual harm. This is a broader category than "breach."
Breach: A security incident that results in unauthorized access to, acquisition of, or disclosure of protected or sensitive data. Every breach is a security incident; not every security incident is a breach.
Incident Commander: The individual with authority to direct the response and make containment decisions for the duration of a declared incident.

3. Incident Severity Classification

Tier	Example	Response Time Target
Critical	Active breach, ransomware, data exfiltration, or outage affecting production/customer systems	Immediate — IR team activated within 1 hour
High	Confirmed malware, unauthorized access attempt that succeeded, or a critical vulnerability actively being exploited	Within 4 hours
Medium	Suspicious activity requiring investigation, policy violation, or a vulnerability not yet exploited	Within 24 hours
Low	Isolated, contained event with no evidence of broader impact (e.g., a single phishing email reported before any action was taken)	Within 5 business days

4. Incident Response Team & Roles

Role	Assigned To	Responsibility
Incident Commander	[Name, Title]	Owns the response end to end. Declares and closes incidents. Final call on containment actions that affect availability.
Security/IT Lead	[Name, Title]	Technical investigation, containment, eradication, and recovery actions.
Legal Counsel	[Name, Title / Firm]	Regulatory notification obligations, privilege considerations, law enforcement coordination.
Communications Lead	[Name, Title]	Internal updates, customer/public communications, coordinates with Legal before anything external goes out.
Executive Sponsor	[Name, Title]	Resourcing decisions, business continuity tradeoffs, final sign-off on customer notification.

5. Phase 1 — Preparation

Before an incident happens:

Maintain an up-to-date contact list for the IR team, including after-hours contact methods
Keep required tooling (EDR, logging, forensic imaging capability) deployed and tested
Run tabletop exercises at the cadence defined in Section 13
Keep this plan and any referenced playbooks accessible outside of systems that might themselves be unavailable during an incident

6. Phase 2 — Identification & Reporting

Any employee who suspects a security incident must report it to [Security Team / IT Help Desk / email address] immediately — do not wait to confirm it's real. The Incident Commander (or on-call designate) triages the report, assigns an initial severity tier per Section 3, and formally declares the incident if warranted.

7. Phase 3 — Containment

Limit the damage without destroying evidence:

Isolate affected systems from the network (prefer network isolation over shutdown — a powered-off system can lose volatile forensic evidence)
Preserve logs, memory captures, and disk images before remediation where feasible
Revoke or rotate credentials believed to be compromised
Document every containment action taken, with timestamps

8. Phase 4 — Eradication

Remove the root cause — malware, the exploited vulnerability, the compromised account — rather than just the visible symptom. Confirm eradication with a scan or verification step before moving to recovery; reintroducing a system too early is how incidents reopen.

9. Phase 5 — Recovery

Restore systems to normal operation from known-clean backups or rebuilt images, not by patching a compromised system in place. Monitor restored systems more closely than usual for a defined period ([X] days) after recovery before standing down.

10. Phase 6 — Lessons Learned / Post-Incident Review

Within [5 business days] of closing any Medium-or-higher incident, hold a post-incident review covering:

Root cause and timeline
What worked and what didn't in the response
Whether this plan, tooling, or detection coverage needs to change
Whether the incident needs to be reported to a client, auditor, or regulator

11. External Notification & Regulatory Reporting Obligations

This table is a starting point, not a complete legal analysis — confirm applicable obligations with counsel for your specific facts, industry, and the states/countries where affected individuals reside.

Trigger	Governing Rule	Deadline
Any breach of unsecured PHI	HIPAA Breach Notification Rule	Affected individuals: without unreasonable delay, no later than 60 calendar days after discovery (45 CFR §164.404(b)). HHS: within 60 days (500+ affected) or annually (under 500).
Breach of personal information (varies by state)	State breach notification laws	Varies by state — Maine and most states require notification "without unreasonable delay"; some set a fixed outer limit (e.g., 30–45 days). Confirm the specific requirement for every state where affected individuals reside.
Cardholder data compromise	PCI DSS v4.0 / card brand rules	Immediate notification to acquiring bank and payment card brands per your merchant agreement — timelines are contractual, not statutory.
Breach affecting EU/UK data subjects	GDPR / UK GDPR	Supervisory authority: within 72 hours of becoming aware. Affected individuals: without undue delay if high risk to their rights.

12. Communication Plan

All external communication — customers, press, law enforcement, regulators — goes through the Communications Lead and Legal Counsel. No employee speaks externally about an active incident without their sign-off. Internal updates go to [Executive Sponsor / leadership distribution] at a cadence set by the Incident Commander based on severity.

13. Plan Testing & Tabletop Exercises

Run at least one tabletop exercise annually, simulating a realistic scenario relevant to [Organization Name]'s actual risk profile. Document findings and update this plan based on what the exercise reveals — an untested plan is a draft, not a plan.

14. Policy Review & Maintenance

This plan is reviewed at least annually and following:

Any actual security incident at or above Medium severity
A tabletop exercise that reveals a gap
Material changes to systems, vendors, or regulatory obligations

Incident Response Plan