Incident Response Plan Template

INCIDENT RESPONSE PLAN

[ORGANIZATION NAME]

Classification: Confidential
Document Owner: [CISO/Security Director Name]
Effective Date: [DATE]
Last Reviewed: [DATE]
Next Review Date: [DATE]

TABLE OF CONTENTS

1. Executive Summary
2. Purpose and Scope
3. Incident Response Team
4. Incident Classification
5. Incident Response Phases
6. Communication Protocols
7. Legal and Regulatory Requirements
8. Documentation Requirements
9. Testing and Training
10. Plan Maintenance

1. EXECUTIVE SUMMARY

1.1 Purpose Statement

This Incident Response Plan (IRP) establishes the framework for detecting, responding to, containing, eradicating, and recovering from cybersecurity incidents affecting [ORGANIZATION NAME]. This plan aligns with NIST SP 800-61 Rev. 3 and the NIST Cybersecurity Framework 2.0.

NIST SP 800-61 Rev. 3 and CSF 2.0 are nonprescriptive guidance for nongovernmental organizations, not general legal mandates. The CISA playbooks cited here establish procedures for Federal Civilian Executive Branch systems; other organizations may adapt them as guidance. Binding duties must be entered in the applicability matrix below from current official sources.

1.2 Management Commitment

☐ This plan has been reviewed and approved by executive management

☐ Adequate resources have been allocated for incident response capabilities

☐ The organization commits to regular testing and improvement of this plan

Executive Approval:

Name: _________________________
Title: _________________________
Signature: _________________________
Date: _________________________

1.3 Mandatory Applicability Gate

Complete this register with legal counsel before approving the plan and update it when systems, data, locations, contracts, regulators, or law change.

2. PURPOSE AND SCOPE

2.1 Purpose

This plan:

• Establishes procedures for identifying, containing, and responding to security incidents
• Defines roles, responsibilities, and communication channels
• Supports analysis and execution of applicable legal, regulatory, and contractual notification requirements
• Minimizes damage and reduces recovery time and costs
• Preserves evidence for potential legal proceedings
• Enables continuous improvement through post-incident analysis

2.2 Scope

In Scope:

☐ All information systems owned or operated by [ORGANIZATION NAME]

☐ Cloud-based systems and services

☐ Third-party systems processing organizational data

☐ Employee-owned devices accessing organizational resources (BYOD)

☐ Operational technology (OT) systems

☐ Physical security incidents affecting information assets

Out of Scope:

☐ [SPECIFY EXCLUSIONS]

2.3 Alignment with NIST CSF 2.0

This plan addresses the following NIST CSF 2.0 functions:

3. INCIDENT RESPONSE TEAM

3.1 Team Structure

3.1.1 Core Incident Response Team (IRT)

3.1.2 Example Extended Team (Customize Using NIST Role Categories)

3.1.3 External Resources

3.2 Roles and Responsibilities

Incident Response Manager

☐ Overall coordination of incident response activities

☐ Decision authority for containment and eradication actions

☐ Escalation to executive leadership

☐ Authorization of external communications

☐ Final approval of incident closure

Security Analyst Lead

☐ Initial triage and classification of incidents

☐ Technical analysis and investigation

☐ Evidence collection and preservation

☐ Coordination with forensics specialists

☐ Development of containment strategies

Legal Counsel

☐ Assessment of legal and regulatory obligations

☐ Guidance on breach notification requirements

☐ Privilege considerations for investigations

☐ Coordination with law enforcement

☐ Review of external communications

4. INCIDENT CLASSIFICATION

4.1 Incident Categories

4.2 Severity Levels

The following are internal triage targets, not legal or regulatory notice deadlines. Customize them to the organization's risk tolerance, staffing, contracts, and completed applicability matrix.

4.3 Impact Assessment Criteria

Confidentiality Impact:

☐ Public data only (Low)

☐ Internal/proprietary data (Medium)

☐ Sensitive personal data (PII/PHI) (High)

☐ Classified/regulated data (Critical)

Integrity Impact:

☐ No data modification (Low)

☐ Non-critical data affected (Medium)

☐ Critical data affected (High)

☐ System integrity compromised (Critical)

Availability Impact:

☐ No service disruption (Low)

☐ Non-critical services affected (Medium)

☐ Critical services degraded (High)

☐ Critical services unavailable (Critical)

5. INCIDENT RESPONSE PHASES

5.1 Phase 1: Preparation (GOVERN, IDENTIFY, PROTECT)

5.1.1 Technical Preparation

☐ Security monitoring tools deployed and configured (SIEM, EDR, NDR)

☐ Baseline configurations documented

☐ Network diagrams and asset inventories current

☐ Forensic tools and jump kits ready

☐ Isolated analysis environment available

☐ Backup and recovery capabilities tested

☐ Contact lists and escalation procedures current

5.1.2 Administrative Preparation

☐ Incident response policies approved

☐ Team members trained and certified

☐ Tabletop exercises conducted at the approved risk-based frequency: [FREQUENCY]

☐ Retainer agreements in place with external resources

☐ Cyber insurance policy current

☐ Legal counsel identified and briefed

5.2 Phase 2: Detection and Analysis (DETECT)

5.2.1 Detection Sources

5.2.2 Initial Triage Checklist

☐ Alert received and documented

☐ Initial classification assigned

☐ False positive ruled out

☐ Scope of impact assessed

☐ Affected systems identified

☐ Incident ticket created

☐ Timeline initiated

☐ Appropriate team members notified

5.2.3 Analysis Procedures

Evidence Collection (Maintain Chain of Custody):

☐ Memory capture (if volatile evidence needed)

☐ Disk imaging (forensic copy)

☐ Log collection (system, security, application)

☐ Network traffic capture

☐ Screenshots and documentation

Analysis Questions:

• What happened?
• When did it happen (timeline)?
• How did it happen (attack vector)?
• Who is affected?
• What systems are involved?
• What data may be compromised?
• Is the attack ongoing?
• What is the potential impact?

5.3 Phase 3: Containment (RESPOND)

5.3.1 Containment Strategy Selection

5.3.2 Containment Checklist

☐ Containment strategy approved by Incident Response Manager

☐ Business impact of containment assessed

☐ Affected stakeholders notified

☐ Containment actions documented with timestamps

☐ Evidence preserved before containment

☐ Effectiveness of containment verified

☐ Backups isolated/protected

5.4 Phase 4: Eradication (RESPOND)

5.4.1 Eradication Procedures

☐ Root cause identified

☐ All instances of threat removed

☐ Malicious files/code deleted

☐ Compromised accounts disabled/reset

☐ Vulnerabilities patched

☐ Backdoors removed

☐ Clean systems verified

☐ Threat hunting for persistence mechanisms completed

5.4.2 Eradication Verification

☐ Full system scans completed

☐ Log analysis confirms no active threats

☐ Network monitoring shows no suspicious activity

☐ Vulnerability scans completed

☐ Configuration review completed

5.5 Phase 5: Recovery (RECOVER)

5.5.1 Recovery Procedures

☐ Recovery plan developed and approved

☐ Systems restored from clean backups or rebuilt

☐ Data restored and integrity verified

☐ Systems hardened before reconnection

☐ Monitoring enhanced for affected systems

☐ Gradual restoration of services

☐ Business operations validated

☐ Users notified of service restoration

5.5.2 Recovery Verification

☐ All systems functioning normally

☐ Security controls operational

☐ Monitoring confirms no reinfection

☐ Performance baseline achieved

☐ Business processes validated

5.6 Phase 6: Lessons Learned and Improvement (ALL FUNCTIONS)

5.6.1 Lessons Learned Meeting

Capture and share lessons throughout response and recovery when useful; do not defer urgent improvements until closure.

Formal review meeting target: [X] business days after [MILESTONE]

Required Attendees:

☐ All incident responders

☐ Affected business unit representatives

☐ Executive sponsor (for Severity 1-2)

☐ Legal counsel (if applicable)

Discussion Topics:

☐ Timeline review (what happened, when)

☐ What worked well

☐ What could be improved

☐ Detection effectiveness

☐ Response effectiveness

☐ Communication effectiveness

☐ Resource adequacy

☐ Recommended improvements

5.6.2 Post-Incident Report

The post-incident report shall include:

☐ Executive summary

☐ Incident timeline

☐ Root cause analysis

☐ Actions taken

☐ Impact assessment

☐ Lessons learned

☐ Recommendations

☐ Appendices (logs, evidence, communications)

5.7 Phase 7: Continuous Improvement

☐ Incident metrics analyzed

☐ Plan updates implemented

☐ Training updated based on lessons learned

☐ Detection capabilities enhanced

☐ Security controls strengthened

☐ Playbooks updated

6. COMMUNICATION PROTOCOLS

6.1 Internal Communication

6.1.1 Communication Channels

6.1.2 Escalation Matrix

6.2 External Communication

6.2.1 Approval Requirements

6.2.2 Communication Templates

Template locations: [FILE PATH/SYSTEM]

☐ Internal incident notification

☐ Executive briefing

☐ Board notification

☐ Customer notification (various types)

☐ Regulatory notification

☐ Press statement

☐ Law enforcement report

7. LEGAL AND REGULATORY REQUIREMENTS

7.1 Incident-Specific Legal Review

Do not infer a notification duty from the label “security incident” or “data breach.” Counsel must determine each applicable law, covered entity and data type, trigger, discovery rule, risk-of-harm standard, recipient, deadline, content, method, exception, and law-enforcement delay from current official sources.

For every incident with possible external duties:

☐ Record when the event was first known and when reasonable diligence would have identified it

☐ Identify all affected entities, systems, vendors, people, locations, and data classifications

☐ Preserve the facts supporting applicability, trigger, materiality, and risk-of-harm determinations

☐ Calendar the earliest possible contractual or legal deadline while analysis continues

☐ Document any permitted delay and the authority required to invoke it

7.2 Jurisdiction and Contract Notification Matrix

Add one row for every potentially applicable state, country, territory, tribal jurisdiction, regulator, contract, insurance policy, license, or grant. Do not rely on a five-state summary or assume that the same affected-person count controls consumer and regulator notice.

7.3 Selected Federal Rules — Apply Only If the Organization Is Covered

7.4 Incident Notification Worklist

7.5 Legal Hold Procedures

When legal counsel directs preservation because of an incident, investigation, claim, litigation, regulatory matter, contract, or other duty:

☐ Legal counsel notified immediately

☐ Legal hold notice issued

☐ Relevant data and systems preserved

☐ Auto-deletion suspended for affected data

☐ Chain of custody established

8. DOCUMENTATION REQUIREMENTS

8.1 Incident Log

All incidents must be logged with the following minimum information:

8.2 Chain of Custody

Evidence collection must maintain proper chain of custody:

☐ Evidence tag/label with unique identifier

☐ Date and time of collection

☐ Collector name and signature

☐ Description of evidence

☐ Location where evidence was found

☐ Condition of evidence

☐ All transfers documented with signatures

☐ Secure storage location

8.3 Retention Requirements

Do not use a universal seven-year period. Counsel and records-management personnel must reconcile law, regulation, legal holds, contracts, insurance requirements, limitation periods, privacy minimization, and secure-disposal rules.

9. TESTING AND TRAINING

9.1 Testing Schedule

Set these frequencies through the risk assessment and any binding requirement identified in Section 1.3. The frameworks cited in this template do not create a universal quarterly, semiannual, or annual exercise schedule.

9.2 Training Requirements

9.3 Exercise Scenarios

Recommended exercise scenarios:

☐ Ransomware attack with data exfiltration

☐ Business email compromise and wire fraud

☐ Insider threat and data theft

☐ Nation-state APT compromise

☐ Third-party/supply chain breach

☐ Cloud service provider incident

☐ Physical security breach with cyber impact

10. PLAN MAINTENANCE

10.1 Review Schedule

10.2 Change Control

All changes to this plan must be:

☐ Documented with rationale

☐ Reviewed by CISO

☐ Approved by [APPROVING AUTHORITY]

☐ Communicated to all IRT members

☐ Reflected in version history

10.3 Version History

SOURCES AND REFERENCES

Official sources checked 2026-08-03:

• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST Cybersecurity Framework 2.0
• CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• CISA CIRCIA rulemaking and current implementation status
• 45 C.F.R. § 164.404 — Notification to individuals
• 45 C.F.R. § 164.406 — Notification to the media
• 45 C.F.R. § 164.408 — Notification to the Secretary
• 45 C.F.R. § 164.412 — Law-enforcement delay
• 16 C.F.R. § 314.4 — FTC Safeguards Rule elements
• FTC final rule adding 16 C.F.R. § 314.4(j), 88 Fed. Reg. 77499
• 17 C.F.R. § 249.308 — Form 8-K
• SEC current Form 8-K, General Instruction B.1 and Item 1.05

The NIST and CISA materials are guidance within the scope stated by their issuing agencies. They do not replace the completed applicability matrix or current binding authority.

APPENDICES

Appendix A: Contact List

[Detailed contact list with 24/7 numbers]

Appendix B: System Inventory

[Critical systems list with owners]

Appendix C: Network Diagrams

[Reference to network documentation]

Appendix D: Playbooks

[Links to specific incident playbooks]

Appendix E: Templates

[Communication and documentation templates]

Appendix F: Tool Documentation

[Forensic and analysis tool guides]

DOCUMENT CONTROL

Classification: Confidential
Distribution: [AUTHORIZED RECIPIENTS]

Approval:

This Incident Response Plan is a controlled document. Unauthorized distribution is prohibited. For questions, contact [SECURITY TEAM EMAIL].