# [Organization Name] Cybersecurity Incident Response Plan

> Template version: 2026-09-11  
> Alignment: NIST SP 800-61 Rev. 3 and NIST Cybersecurity Framework 2.0  
> Instructions: Replace every bracketed field. Delete examples that do not apply. Verify legal, regulatory, contractual, insurance, law-enforcement, privacy, employment, public-records, and sector requirements with the responsible owners. Store the completed plan according to its sensitivity.

## 1. Document control

| Field | Organization entry |
|---|---|
| Plan owner | [Role] |
| Executive approver | [Role] |
| Version | [Version] |
| Classification | [Classification and handling rules] |
| Effective date | [YYYY-MM-DD] |
| Last exercised | [YYYY-MM-DD and scenario] |
| Next scheduled review | [YYYY-MM-DD] |
| Event-driven review triggers | [Material incident, architecture change, supplier change, leadership change, requirement change, failed recovery test, other] |
| Authoritative storage location | [Controlled location] |
| Offline or out-of-band access | [Method that does not depend on the affected environment] |

### Change history

| Date | Version | Change | Owner | Approver |
|---|---|---|---|---|
| [YYYY-MM-DD] | [Version] | [Summary] | [Role] | [Role] |

## 2. Purpose, outcomes, and scope

### Purpose

[State why the organization maintains this plan and the outcomes it must support.]

### Covered environment

- People and organizational units: [Scope]
- Business or mission services: [Scope]
- Systems, applications, endpoints, cloud tenants, and networks: [Scope]
- Data and records: [Scope]
- Facilities or operational technology: [Scope or not applicable]
- Suppliers and external dependencies: [Scope]
- Explicit exclusions: [Exclusions and owning plan]

### Planning assumptions

- [Assumption about staffing, communications, logging, backups, vendors, facilities, or external support]
- [Assumption that must be validated during an exercise]

## 3. Authority and incident declaration

### Declaration criteria

An authorized person may declare a cybersecurity incident when [observable criteria]. A suspected event should be escalated when its scope, impact, or authenticity cannot be determined inside [time or decision threshold].

### Delegated authority

| Action | Primary authority | Backup authority | Delegated limit | Required record |
|---|---|---|---|---|
| Declare an incident | [Role] | [Role] | [Threshold] | Declaration time and basis |
| Isolate an endpoint or account | [Role] | [Role] | [Threshold] | Asset, time, reason, result |
| Isolate a production service or segment | [Role] | [Role] | [Threshold] | Impact, alternatives, approval |
| Disable privileged access | [Role] | [Role] | [Threshold] | Identity, sessions, tokens, result |
| Authorize emergency change | [Role] | [Role] | [Threshold] | Scope, test, rollback, approval |
| Engage retained external support | [Role] | [Role] | [Threshold] | Provider, scope, authorization |
| Approve external notification | [Role] | [Role] | [Threshold] | Source, facts, approval, time |
| Accept residual risk for recovery | [Role] | [Role] | [Threshold and expiration] | Risk, controls, approver, expiry |
| Close the incident | [Role] | [Role] | [Closure conditions] | Closure and follow-up record |

## 4. Response organization and secure contacts

Use roles in the plan and maintain named contacts in an access-controlled roster.

| Function | Primary role | Backup role | Secure contact path | Out-of-band path | Responsibilities |
|---|---|---|---|---|---|
| Incident coordination | [Role] | [Role] | [Path] | [Path] | Timeline, assignments, operating picture, decisions |
| Security operations | [Role] | [Role] | [Path] | [Path] | Analysis, scoping, containment, eradication, monitoring |
| Service ownership | [Role] | [Role] | [Path] | [Path] | Mission impact, workarounds, workflow and recovery acceptance |
| Executive authority | [Role] | [Role] | [Path] | [Path] | High-impact decisions and resource authority |
| Legal and privacy | [Role] | [Role] | [Path] | [Path] | Privilege, obligations, notifications, evidence guidance |
| Communications | [Role] | [Role] | [Path] | [Path] | Internal, customer, partner, media, and public messages |
| Records or evidence | [Role] | [Role] | [Path] | [Path] | Preservation, access, retention, custody where required |
| Vendor management | [Role] | [Role] | [Path] | [Path] | Contract, escalation, evidence, supplier coordination |
| Human resources | [Role] | [Role] | [Path] | [Path] | Workforce process where applicable |
| Continuity and recovery | [Role] | [Role] | [Path] | [Path] | Workarounds, recovery priorities, backlog reconciliation |

### Communication safeguards

- Primary incident workspace: [Controlled location]
- Out-of-band alternative: [Independent method]
- Conference bridge owner and access rules: [Method]
- Prohibited content in shared channels: [Passwords, live tokens, private keys, unnecessary regulated or personal data, other]
- Approved status-update cadence and audiences: [Cadence]

## 5. Classification, severity, and escalation

Assess impact dimensions separately before assigning an overall level.

| Dimension | Questions | Current criteria or scale |
|---|---|---|
| Confidentiality and privacy | What data may have been accessed, disclosed, or exfiltrated? | [Criteria] |
| Integrity | Can the organization trust records, transactions, configurations, or decisions? | [Criteria] |
| Availability | Which services are degraded or unavailable, and for how long? | [Criteria] |
| Safety | Could people, facilities, or physical processes be harmed? | [Criteria] |
| Mission or business impact | Which critical outcomes or customers are affected? | [Criteria] |
| Scope | Which users, assets, sites, tenants, partners, or jurisdictions are affected? | [Criteria] |
| Privilege and persistence | Are privileged identities, security tools, backups, or control planes affected? | [Criteria] |
| Confidence | What is confirmed, suspected, contradicted, or unknown? | [Criteria] |

| Overall level | Observable trigger | Required roles | Update cadence | Decision authority |
|---|---|---|---|---|
| [Level 1] | [Criteria] | [Roles] | [Cadence] | [Authority] |
| [Level 2] | [Criteria] | [Roles] | [Cadence] | [Authority] |
| [Level 3] | [Criteria] | [Roles] | [Cadence] | [Authority] |

## 6. Reporting, notification, and communications register

Do not place a universal notification deadline in this plan. Maintain current sources and assign the person responsible for determining applicability.

| Source or obligation | Scope and trigger | Decision owner | Authoritative reference | Required recipient or channel | Time rule | Evidence of decision |
|---|---|---|---|---|---|---|
| [Law or regulation] | [Trigger] | [Role] | [Current source] | [Recipient] | [Verified rule] | [Record] |
| [Contract or funding term] | [Trigger] | [Role] | [Clause or source] | [Recipient] | [Verified rule] | [Record] |
| [Cyber insurance] | [Trigger] | [Role] | [Policy or carrier source] | [Recipient] | [Verified rule] | [Record] |
| [Oversight or law enforcement] | [Trigger] | [Role] | [Current source] | [Recipient] | [Verified rule] | [Record] |

### Message approval

- Internal workforce messages approved by: [Role]
- Customer or partner messages approved by: [Role]
- Public or media messages approved by: [Role]
- Technical indicators shared externally approved by: [Role]
- Single source of approved facts: [Location and owner]

## 7. Response workflow

### Detect and validate

1. Record the alert or report, source, timestamp, reporter, and initial evidence.
2. Protect the report and avoid altering original evidence.
3. Determine whether the event is expected, benign, suspicious, or an incident candidate.
4. Escalate uncertainty when impact, privilege, persistence, or scope cannot be established.
5. Declare the incident and activate the appropriate roles when criteria are met.

### Coordinate and scope

1. Create the incident identifier, authoritative timeline, decision log, and evidence inventory.
2. Establish primary and backup communications.
3. Identify affected services, assets, identities, data, locations, and providers.
4. Separate confirmed facts, hypotheses, and unanswered questions.
5. Set update cadence, next decision time, and initial containment objective.

### Contain and eradicate

1. Compare containment options, expected operational impact, evidence risk, and rollback path.
2. Obtain the required authority and timestamp the decision.
3. Isolate affected assets, identities, sessions, integrations, or network paths as approved.
4. Preserve volatile and durable evidence according to the evidence procedure.
5. Remove malicious access, persistence, unsafe configuration, and incident-linked vulnerabilities.
6. Rotate credentials, secrets, tokens, keys, or certificates based on exposure and trust.
7. Validate the result and revise scope when new evidence changes the operating picture.

### Recover and monitor

1. Restore or rebuild from a trusted state.
2. Validate identity, configuration, data integrity, logging, detection, integrations, and priority workflows.
3. Reconcile manual workarounds and accumulated transaction or service backlogs.
4. Document residual risk, compensating controls, and expiration.
5. Obtain security and service-owner recovery approval.
6. Define heightened monitoring, ownership, duration, and recontainment triggers.

### Close and improve

1. Confirm required notifications, recovery evidence, decisions, and records are complete.
2. Document root causes, contributing conditions, control failures, and response friction.
3. Assign corrective actions with owners, due dates, evidence, validation, and risk escalation.
4. Update relevant controls, architecture, suppliers, contracts, playbooks, training, and exercises.
5. Obtain closure approval and schedule the follow-up review.

## 8. Incident record and evidence handling

### Authoritative records

- Incident timeline: [Location and owner]
- Decision log: [Location and owner]
- Evidence inventory: [Location and owner]
- Approved communications: [Location and owner]
- Corrective-action register: [Location and owner]

### Evidence rules

- Timestamp standard and clock synchronization: [Standard]
- Collection and preservation procedure: [Procedure]
- Hashing or custody requirements: [Requirements]
- Access approval and review: [Roles]
- Retention and disposal source: [Current authority]
- Legal or investigative escalation trigger: [Trigger]

### Decision log

| Timestamp | Decision or question | Confirmed facts | Unknowns | Options and impact | Decision owner | Decision and rationale | Follow-up |
|---|---|---|---|---|---|---|---|
| [UTC or stated zone] | [Question] | [Facts] | [Unknowns] | [Options] | [Role] | [Decision] | [Action] |

## 9. Third-party incident interface

| Provider | Service or dependency | Emergency contact and entitlement | Provider-controlled evidence | Customer-controlled evidence | Notification commitment | Containment or recovery dependency | Executive escalation |
|---|---|---|---|---|---|---|---|
| [Provider] | [Service] | [Path] | [Logs or artifacts] | [Logs or artifacts] | [Contract clause] | [Dependency] | [Path] |

For each material supplier, verify log preservation, engineering participation, change-freeze support, customer notification, root-cause evidence, remediation evidence, data ownership, export, and exit expectations before an incident.

## 10. Recovery and return-to-service gate

| Check | Evidence | Owner | Pass, exception, or not applicable | Approver |
|---|---|---|---|---|
| Known malicious access is removed or contained | [Evidence] | [Role] | [Status] | [Role] |
| Exposed credentials and secrets are addressed | [Evidence] | [Role] | [Status] | [Role] |
| Systems are restored or rebuilt from a trusted state | [Evidence] | [Role] | [Status] | [Role] |
| Data and transaction integrity are validated | [Evidence] | [Role] | [Status] | [Role] |
| Logging and detection are operating | [Evidence] | [Role] | [Status] | [Role] |
| Priority user workflows succeed | [Evidence] | [Role] | [Status] | [Role] |
| Integrations and external dependencies succeed | [Evidence] | [Role] | [Status] | [Role] |
| Workarounds and backlogs have a reconciliation plan | [Evidence] | [Role] | [Status] | [Role] |
| Residual risk has an owner and expiration | [Evidence] | [Role] | [Status] | [Role] |
| Heightened monitoring and recontainment triggers are active | [Evidence] | [Role] | [Status] | [Role] |

## 11. Playbook register

| Scenario | Owner | Playbook location | Last validated | Key dependency | Next review |
|---|---|---|---|---|---|
| Identity or privileged-account compromise | [Role] | [Location] | [Date] | [Dependency] | [Date] |
| Ransomware or destructive activity | [Role] | [Location] | [Date] | [Dependency] | [Date] |
| Cloud or data exposure | [Role] | [Location] | [Date] | [Dependency] | [Date] |
| Vendor or supply-chain incident | [Role] | [Location] | [Date] | [Dependency] | [Date] |
| Business email compromise or payment fraud | [Role] | [Location] | [Date] | [Dependency] | [Date] |
| Denial of service or major availability incident | [Role] | [Location] | [Date] | [Dependency] | [Date] |
| Lost or stolen device | [Role] | [Location] | [Date] | [Dependency] | [Date] |

## 12. Exercises, training, and improvement

### Exercise record

| Field | Entry |
|---|---|
| Scenario and date | [Scenario and YYYY-MM-DD] |
| Objectives | [Decision, communication, containment, recovery, vendor, or other objectives] |
| Participants and observers | [Roles] |
| Success criteria | [Observable criteria] |
| Decisions that stalled | [Findings] |
| Missing or unusable evidence | [Findings] |
| Communication or contact failures | [Findings] |
| Recovery assumptions that failed | [Findings] |
| Corrective-action record | [Location] |
| Re-exercise date | [YYYY-MM-DD] |

### Corrective actions

| Finding | Root cause or contributing condition | Owner | Due date | Required evidence | Validation method | Risk if overdue | Status |
|---|---|---|---|---|---|---|---|
| [Finding] | [Cause] | [Role] | [Date] | [Evidence] | [Method] | [Risk path] | [Status] |

## Opening-hour checklist

- [ ] Protect life and safety; use emergency procedures where applicable.
- [ ] Record the report, source, time, and initial evidence.
- [ ] Validate the event without altering original evidence unnecessarily.
- [ ] Declare or escalate according to observable criteria.
- [ ] Assign the incident coordinator and activate required roles.
- [ ] Establish the authoritative timeline, decision log, and secure communication path.
- [ ] Identify services, assets, identities, data, providers, and known impact.
- [ ] Separate confirmed facts, hypotheses, and unknowns.
- [ ] Preserve volatile evidence and request supplier preservation where needed.
- [ ] Define the next decision, owner, deadline, and update cadence.
- [ ] Compare containment choices with operational impact and rollback.
- [ ] Check the current reporting and notification register with responsible owners.

## Primary references

- NIST SP 800-61 Rev. 3: https://csrc.nist.gov/pubs/sp/800/61/r3/final
- NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework
- CISA Cyber Threats and Advisories: https://www.cisa.gov/topics/cyber-threats-and-advisories
- Zeph Tech implementation guide: https://zephtech.net/guides/public-sector-incident-response-governance.html
- Zeph Tech decision matrix: https://zephtech.net/static/downloads/public-sector-incident-response-governance-matrix.csv

This template is general operational guidance, not legal advice. Verify applicability and current requirements for the organization, incident, data, jurisdiction, sector, contracts, funding, insurance, workforce, and investigative context.