Incident Response Plan Template: Build, Test, and Maintain a Breach-Ready Playbook

Overview

An incident response plan is more than a list of emergency phone numbers. It is an operating guide for deciding what happens, who owns each action, what evidence must be preserved, and how the organization communicates while facts are still developing.

The plan should work for both technical and privacy incidents. A compromised account, exposed storage bucket, lost device, ransomware event, malicious insider, or vendor notification may require different technical steps, but each should follow the same basic lifecycle:

1. Prepare: Maintain contacts, access, tools, policies, backups, and training.
2. Detect and assess: Confirm the signal, establish scope, and assign an initial severity.
3. Contain: Limit further damage while avoiding unnecessary destruction of evidence.
4. Eradicate: Remove malicious access, vulnerable components, persistence, or unauthorized changes.
5. Recover: Restore trusted services, monitor closely, and validate business operations.
6. Review: Document decisions, identify control gaps, and update the plan.

Keep the main playbook short enough to use during an outage. Store detailed technical runbooks separately, such as identity-provider containment, cloud logging, endpoint isolation, backup restoration, and database recovery procedures. Your broader incident response plan requirements guide for SaaS businesses can help connect operational steps to governance expectations.

Core roles to define

• Incident commander: Coordinates the response, sets priorities, and records major decisions.
• Technical lead: Directs investigation, containment, eradication, and recovery.
• Privacy or legal lead: Assesses personal-data impact, contractual duties, privilege, and notification requirements.
• Communications lead: Manages internal updates, customer messaging, and approved external statements.
• Business owner: Explains operational impact and approves service-restoration priorities.
• Evidence custodian: Tracks logs, images, timelines, correspondence, and chain-of-custody details where needed.

Assign a primary and backup for each role. Record how to reach them outside normal corporate systems, since those systems may be unavailable or compromised.

Checklist by scenario

Use the following incident response checklist as a starting point. Adapt it to your infrastructure, data flows, contractual commitments, and applicable laws. The person coordinating the incident should open a dedicated case record and timestamp important actions.

For every suspected incident

• Open an incident record with a unique identifier.
• Capture the initial report, source, time discovered, affected system, and current symptoms.
• Assign an incident commander and provisional severity.
• Move response discussions to a trusted channel if normal collaboration tools may be affected.
• Identify potentially affected systems, accounts, people, vendors, and data categories.
• Preserve relevant logs, alerts, email, endpoint data, cloud records, and screenshots before they expire or are altered.
• Record assumptions separately from confirmed facts.
• Set the next decision time, even if the investigation has not produced new information.

For a suspected compromised account

• Confirm whether the activity is genuinely unauthorized rather than a normal travel, automation, or administrator event.
• Revoke active sessions, tokens, API keys, and refresh tokens as appropriate.
• Reset credentials using a trusted process and check for newly added authentication methods.
• Review mailbox rules, forwarding settings, OAuth grants, privilege changes, and recent sign-ins.
• Search for lateral movement, data access, exports, or messages sent from the account.
• Preserve authentication and audit logs before changing retention or account state.
• Assess whether personal data, customer data, credentials, or regulated records were accessed.

For ransomware or destructive activity

• Activate the incident commander and business continuity contacts immediately.
• Isolate affected hosts, segments, workloads, or credentials using the least destructive effective action.
• Protect clean backups and prevent compromised credentials from reaching backup systems.
• Do not wipe or rebuild systems before deciding what forensic evidence is required.
• Identify the earliest known malicious activity and the likely path of entry.
• Confirm whether data was copied, altered, encrypted, or merely made unavailable.
• Validate restoration sources before recovery and restore a limited, monitored environment first.
• Coordinate decisions about extortion communications, law enforcement contact, insurance, and legal advice through the designated leads.

A ransomware response checklist should address availability and confidentiality separately. Encrypted systems may create an outage, while data exfiltration may create privacy, contractual, and notification concerns even if services are restored quickly.

For a lost device, exposed repository, or misconfigured cloud resource

• Identify the device, repository, bucket, database, or service and its owner.
• Determine whether encryption, access controls, monitoring, or network restrictions reduced exposure.
• Remove public access or disable the exposed resource without deleting useful evidence.
• Rotate exposed secrets and inspect access logs for downloads, queries, or unusual activity.
• Establish the exposure window and the types of information that could have been available.
• Check whether a vendor, subprocessor, customer, or other third party needs to be involved.
• Document the final determination, including why data access was confirmed, ruled out, or left uncertain.

For a vendor-reported incident

• Verify the notice through a known vendor contact rather than relying only on the original message.
• Record the vendor’s incident time, affected service, data categories, locations, and containment status.
• Review the contract, data processing agreement, security addendum, and notification clause.
• Ask what evidence supports the vendor’s scope and whether subcontractors or subprocessors are involved.
• Map the affected service to internal systems, customers, data subjects, and retention records.
• Assign an owner for follow-up questions, evidence collection, and customer or regulator communications.

What to double-check

Severity and escalation

Define severity using observable criteria rather than intuition. Consider the sensitivity of data, number of affected records or customers, service disruption, privilege level, likelihood of ongoing access, geographic scope, and whether the event involves a critical supplier. A provisional severity can change as evidence improves.

For each level, specify who must be notified, how frequently updates occur, who can authorize major containment actions, and when legal, privacy, executive, or communications review is required.

Evidence handling

Preserve evidence proportionately and consistently. Record who collected each item, when it was collected, where it came from, and whether it was copied, transformed, or analyzed. Keep the incident timeline factual: use timestamps, source references, and clear labels for unknowns. Avoid editing original logs or relying on screenshots when a native export is available.

Privacy and breach notification decisions

Do not treat every security alert as a reportable breach, and do not assume that uncertainty removes the need for assessment. Determine whether personal data was involved, whose data it was, what happened to it, whether access or acquisition occurred, and what harm or risk may result.

Notification duties depend on the organization’s role, affected individuals, jurisdictions, contracts, and the facts established during the investigation. Verify applicable breach notification requirements with qualified legal or privacy counsel, document the decision, and record the reasoning even when no notification is made. Review the organization’s GDPR compliance checklist and DPIA guidance when the event reveals a new or changed processing risk.

Communications

Prepare holding language that states what is known, what is being investigated, and where questions should be directed. Avoid speculation, blame, unsupported assurances, and technical detail that could expose defensive measures. Use one approved fact base so support, sales, executives, and incident responders do not publish conflicting accounts.

Common mistakes

• Keeping the plan in one person’s head: Document decisions, backups, contact methods, and escalation paths.
• Confusing containment with recovery: A system can be available while unauthorized access still exists. Confirm eradication before declaring recovery complete.
• Destroying evidence during cleanup: Coordinate resets, rebuilds, and log changes with the technical and evidence leads.
• Writing a notification before understanding scope: Prepare a clear initial statement, but update it as confirmed facts change.
• Ignoring vendors: Maintain current service owners, contract contacts, data maps, and escalation routes.
• Testing only the security team: Include executives, privacy, communications, support, finance, facilities, and business owners in exercises.
• Failing to record negative findings: Document systems checked, evidence reviewed, and why suspected exposure was ruled out.

When to revisit

Review the incident response plan at least before major seasonal planning cycles and after any significant incident, exercise, acquisition, cloud migration, identity change, or business-process change. Update it whenever response workflows, tools, vendors, systems, or contact details change.

Run a tabletop exercise using a realistic scenario such as a compromised administrator, ransomware during a release window, or a vendor data exposure. Test whether participants can find the plan, reach backups, access logs, approve containment, identify affected data, and make a documented notification decision. Record each gap with an owner and due date.

Before closing an incident, confirm that the final report includes the timeline, impact, root or contributing causes, evidence location, notifications and decisions, recovery validation, and corrective actions. Then update the playbook—not only the post-incident report. A maintained plan is easier to follow when the next alert arrives.

For related operational controls, review the security awareness policy checklist, the data processing agreement checklist, and the subprocessor management checklist. Together, these documents help connect incident response to broader cybersecurity compliance and privacy compliance work.