Governance and authority
Purpose, scope, approval, delegated containment authority, incident declaration criteria, executive escalation, and named ownership for legal, privacy, communications, service, vendor, and security decisions.
Free editable templateNIST SP 800-61 Rev. 3 aligned
Free cybersecurity incident response plan template
Download a practical starting point for declaring, coordinating, containing, recovering from, and learning from a cybersecurity incident. The template is editable Markdown, requires no email address, and keeps technical actions connected to decision authority, evidence, communications, vendors, and service recovery.
Use it as a planning scaffold, not a finished plan. Replace every bracketed field, verify reporting duties for your organization, store the completed document securely, and exercise the decisions before an incident.
What you get
A plan skeleton built for real decisions—not shelfware.
A usable incident plan should tell people what they are allowed to do, when to escalate, where to record facts, and how the organization decides that service is safe to restore.
Operational response
Detection intake, triage, severity, containment, eradication, evidence preservation, vendor coordination, communications, recovery validation, heightened monitoring, and recontainment triggers.
Improvement and exercises
Playbook inventory, exercise schedule, decision-log prompts, after-action review, corrective-action ownership, plan review triggers, and a short checklist for the opening hour.
Why the template follows all six CSF 2.0 Functions
NIST SP 800-61 Rev. 3 treats incident response as part of organization-wide cybersecurity risk management. Govern, Identify, and Protect establish the authority, asset knowledge, safeguards, suppliers, and readiness that make response possible. Detect, Respond, and Recover cover finding, managing, containing, communicating about, and restoring from incidents. Improvement connects lessons back into every Function. The template reflects that model instead of preserving the older idea that preparation is merely the first step in an isolated security-team cycle.
Plan architecture
Complete twelve sections before calling the plan ready.
Keep the policy-level plan stable and concise. Put technology-specific commands, screenshots, indicators, and rapidly changing procedures in linked playbooks that owners can maintain more frequently.
1. Document control and approval
Record the plan owner, approver, version, classification, effective date, next review, storage location, offline access path, and change history. Identify what events force an early review.
2. Purpose, scope, and assumptions
Define the people, systems, cloud tenants, facilities, data, suppliers, and business services covered. State exclusions and dependencies instead of leaving responders to infer them under pressure.
3. Authority and declaration
Name who may declare an incident, isolate systems, disable identities, preserve evidence, convene the response team, authorize emergency changes, and accept operational impact within delegated limits.
4. Roles and contact paths
List operational roles rather than relying only on employee names. Include primary and backup contacts, secure communications, out-of-band alternatives, on-call paths, and vendor escalation routes.
5. Classification and escalation
Assess confidentiality, integrity, availability, safety, mission impact, privilege, scope, persistence, and confidence. Tie escalation to observable conditions and decision authority.
6. Reporting and communications
Maintain an obligation register that points to current legal, regulatory, contractual, insurance, oversight, and law-enforcement sources. Do not invent one universal notification clock.
7. Response workflow
Describe intake, validation, incident declaration, coordination, scoping, containment, eradication, communications, recovery, heightened monitoring, and closure. Link each incident class to the right playbook.
8. Evidence and records
Define the authoritative timeline, decision log, evidence inventory, access restrictions, timestamp standard, preservation method, fact-versus-hypothesis labels, and any required chain-of-custody procedure.
9. Third-party coordination
Document customer and supplier responsibilities, support entitlements, emergency contacts, provider-controlled evidence, notification commitments, containment dependencies, and executive escalation paths.
10. Recovery gates
Require technical validation and service-owner acceptance. A system being reachable is not proof that attacker access is removed, data is trustworthy, priority workflows work, or monitoring is restored.
11. Playbooks and exercises
Maintain playbooks for credible scenarios such as identity compromise, ransomware, exposed cloud data, vendor incidents, lost devices, denial of service, and business email compromise. Exercise decision points, not only technical steps.
12. After-action improvement
Assign each material finding an owner, due date, required evidence, validation method, and risk path. Feed lessons into controls, architecture, procurement, training, continuity, and future exercises.
Decision rights
Resolve authority before the incident bridge opens.
The fastest technical team can still stall when nobody knows who may take a revenue-producing system offline, disable an executive account, rotate a shared secret, notify a customer, engage outside counsel, require a supplier to preserve logs, or restore a service with known residual risk. The template separates the incident coordinator from the people authorized to accept mission, legal, safety, privacy, financial, and public-communication consequences.
Pre-authorize where practical
- Isolation of endpoints, accounts, applications, network segments, and cloud workloads.
- Revocation or rotation of privileged credentials, tokens, keys, and certificates.
- Emergency production changes with testing and rollback expectations.
- Activation of retained forensic, legal, communications, insurance, or recovery support.
- Temporary service degradation inside a defined impact threshold.
Escalate when consequences exceed delegation
- Containment would materially interrupt a critical service or create a safety concern.
- Regulated, sensitive, or high-volume data may be affected.
- A privileged identity, security control plane, backup system, or evidence source is compromised.
- A provider cannot supply necessary facts, containment, or recovery support.
- The organization cannot state the incident scope or trust the recovery state.
Use the companion incident-response governance matrix to assign an owner, evidence requirement, approval record, and status to these decisions.
Evidence discipline
Build one record another reviewer can reconstruct.
The incident record supports coordination during the event and later reporting, recovery assurance, root-cause work, insurance, audit, and corrective action. Protect it according to its sensitivity.
Minimum operational record
- Incident identifier, detection source, reporter, and synchronized timestamps.
- Confirmed facts, working hypotheses, confidence, and unanswered questions.
- Affected services, assets, identities, data, locations, and suppliers.
- Indicators and evidence references without copying secrets into an unsafe document.
- Actions taken, person responsible, result, and rollback status.
- Changes to scope, severity, impact, and confidence.
- Material decisions, decision owner, rationale, alternatives, and known tradeoffs.
- Notifications, communications, recovery evidence, residual risk, and closure approval.
Record safeguards
- Choose an authoritative workspace and an out-of-band alternative before the primary environment fails.
- Restrict access and avoid placing passwords, live tokens, private keys, regulated records, or unnecessary personal data in the plan.
- Preserve original evidence and record hashes or custody information when investigative procedures require them.
- Record collection gaps honestly. Missing telemetry is a finding, not permission to turn an assumption into a fact.
- Keep public communications, privileged legal material, technical evidence, and working notes in appropriately controlled channels.
- Retain records according to verified legal, contractual, insurance, investigation, and organizational requirements.
Make it operational
Exercise the plan against decisions that can fail.
A tabletop exercise should test more than whether participants know their job titles. Use a credible scenario with incomplete information, business pressure, unavailable people, third-party dependencies, and a containment choice that creates real operational cost. Observe how the team declares the incident, protects communications, distinguishes facts from hypotheses, invokes authority, obtains evidence, coordinates providers, evaluates reporting, and proves recovery.
Before
- Choose objectives and success criteria.
- Identify observers and facilitators.
- Define what is simulated.
- Protect exercise artifacts.
During
- Timestamp decisions and handoffs.
- Introduce evidence gaps and change.
- Test primary and backup contacts.
- Record unresolved authority.
After
- Separate plan, control, and training gaps.
- Assign owners and due dates.
- Require closure evidence.
- Schedule validation and re-exercise.
Exercise cadence should follow risk and change. Run another exercise when critical architecture, identity, suppliers, leadership, obligations, recovery procedures, or incident communications materially change—not only when the calendar reaches an annual date.
Tailoring checklist
Do not publish the brackets and call it complete.
Replace and verify
- Every bracketed placeholder and example threshold.
- Current primary and backup role assignments.
- Secure and out-of-band contact methods.
- Exact systems, services, data, facilities, and vendors in scope.
- Current reporting authorities and contract clauses.
- Playbook links, evidence locations, and recovery dependencies.
Approve and prove
- Obtain approval from the authority named in the plan.
- Confirm responders can access the plan during an outage.
- Test at least one disruptive containment decision.
- Validate backup, restore, identity, logging, and communication paths.
- Record exercise findings and close them with evidence.
- Set scheduled and event-driven review triggers.
Primary sources
Verify current guidance and obligations.
- NIST SP 800-61 Rev. 3 — current NIST incident-response recommendations as a CSF 2.0 Community Profile.
- NIST Cybersecurity Framework 2.0 — outcomes across Govern, Identify, Protect, Detect, Respond, and Recover.
- CISA Cyber Threats and Advisories — current federal advisories and incident resources.
Zeph Tech is not the authority that sets your notification, evidence, employment, privacy, insurance, law-enforcement, public-records, or sector obligations. Verify applicability with current primary sources and qualified organizational, legal, privacy, communications, and investigative owners. This resource is general operational guidance, not legal advice.