Incident Response Plan Template: Roles, Escalation, Communications, and Breach Reporting

Overview

An incident response plan is a documented workflow for detecting, assessing, containing, recovering from, and learning from a security incident. It should cover more than malware or a confirmed data breach. Suspicious account activity, exposed credentials, website defacement, a lost device, a cloud misconfiguration, a compromised domain or DNS account, and a supplier outage may all require a coordinated response.

The plan should be usable under pressure by people who did not write it. Keep the operational version easy to find, including when normal identity systems, email, or collaboration tools are unavailable. Store a protected offline or alternate copy and review access to it periodically.

This template assumes an SMB or SaaS team with a small security function. Adapt the roles and escalation rules to your organization, contracts, customer commitments, insurance requirements, and applicable laws. Legal and regulatory decisions should be confirmed with qualified counsel or the relevant privacy lead.

Minimum plan contents

• Scope: Define which systems, products, offices, vendors, data types, and business processes the plan covers.
• Incident definition: Describe events that require logging, investigation, escalation, or formal response.
• Contact list: Record primary and backup contacts for security, IT, engineering, leadership, communications, privacy, legal, customer support, insurers, and key vendors.
• Severity model: Use clear criteria based on business impact, data sensitivity, service availability, spread, and uncertainty.
• Evidence process: State who may collect, preserve, access, and document evidence.
• Decision log: Record times, facts, assumptions, decisions, owners, and approvals.
• Recovery criteria: Define what must be verified before systems or accounts return to normal operation.

For related preventive controls, compare this plan with the Website Security Compliance Checklist and the Access Control Policy Checklist. Incident response is more effective when identity, logging, backups, and change control are already documented.

Checklist by scenario

1. First 15 minutes: stabilize and establish facts

Use this stage for safety, triage, and coordination. Avoid irreversible actions until the team understands what may be affected, unless immediate containment is necessary.

• Open an incident record with a unique identifier.
• Record the reporter, discovery time, affected service, current symptoms, and actions already taken.
• Assign an incident lead and name a backup.
• Classify the initial severity, marking it as provisional if facts are incomplete.
• Preserve relevant alerts, timestamps, screenshots, logs, emails, ticket data, and system notifications.
• Confirm whether the event is ongoing, contained, or historical.
• Identify potentially affected accounts, endpoints, domains, applications, cloud resources, vendors, and data stores.
• Move sensitive coordination to an approved channel that is not dependent on a potentially compromised account or system.
• Tell staff not to delete messages, reboot affected systems, contact customers, or post publicly unless directed.

2. Technical containment

Containment should reduce further harm while preserving the information needed to understand the event. The correct action depends on the incident and system architecture.

• Disable or restrict suspected accounts, sessions, API keys, tokens, service principals, or remote access paths.
• Isolate affected devices or workloads where practical, while considering operational and safety consequences.
• Block malicious indicators such as domains, IP addresses, hashes, email senders, or unauthorized application integrations.
• Protect backups and confirm that recovery copies are not exposed to the same compromise.
• Preserve volatile or short-retention logs before they are overwritten.
• Check related systems for the same indicators, credentials, configuration errors, or unauthorized persistence.
• Coordinate with hosting, cloud, domain, DNS, payment, identity, and other critical providers when their systems may be involved.
• Document every containment action, including the reason, approver, time, expected effect, and rollback plan.

3. Investigation and evidence preservation

• Build a timeline using a consistent time zone and distinguish event time from discovery time.
• Separate confirmed facts, credible indicators, working theories, and unknowns.
• Determine the initial access path, affected assets, attacker activity, persistence, and potential data access or alteration.
• Identify whether credentials, personal data, confidential business information, source code, payment information, or customer content may be involved.
• Retain original evidence where possible and analyze copies rather than altering originals.
• Record who collected each item, when it was collected, where it is stored, and how its integrity is protected.
• Ask vendors for relevant logs, incident reports, preservation steps, and a named contact.

4. Internal escalation and communications

Use a regular update rhythm rather than sending fragmented messages whenever a new theory appears. Each update should state what is known, what is not known, what has changed, the current risk, decisions required, and the next update time.

• Notify the incident lead, technical owner, executive decision-maker, privacy or legal lead, and communications owner according to severity.
• Give customer support a short approved explanation and an escalation route.
• Limit sensitive details to people who need them for response decisions.
• Prepare separate messages for employees, customers, vendors, regulators, insurers, and other stakeholders.
• Do not speculate about the attacker, scope, cause, or affected individuals before those points are verified.

5. Privacy and breach assessment

Not every security incident is a reportable personal-data breach, and the assessment depends on the facts, applicable jurisdictions, contractual commitments, and organizational role. Treat the assessment as a documented decision, not an assumption.

• Identify whether personal data was accessed, acquired, disclosed, altered, lost, or made unavailable.
• Determine the categories of people and data potentially affected.
• Estimate the scope, duration, likelihood of misuse, and possible consequences using the information available.
• Establish whether the organization is acting as a controller, processor, service provider, or another role for the relevant data.
• Review customer contracts, data processing agreements, insurance terms, and vendor obligations for notice requirements.
• Record the rationale for notifying or not notifying each relevant party.
• Track deadlines separately by jurisdiction and obligation, and obtain legal review before sending formal notices where appropriate.
• Prepare a clear notice describing known facts, likely impact, protective steps, and a contact route without exposing unnecessary technical details.

For privacy preparation, see the GDPR Website Compliance Checklist and review how subprocessors are documented in the Subprocessor List Best Practices guide.

6. Eradication, recovery, and validation

• Remove unauthorized access, persistence, malicious files, unsafe rules, and exposed credentials.
• Patch or correct the exploited vulnerability and verify the fix.
• Reset credentials using a prioritized plan, including privileged, service, API, vendor, and user accounts.
• Restore from a known-good source and verify integrity before reconnecting systems.
• Increase monitoring for recurrence and document the period of heightened observation.
• Validate authentication, authorization, logging, backups, integrations, customer access, and critical business functions.
• Obtain approval from the system owner and incident lead before closing containment or returning to normal operations.

7. Closure and improvement

• Write a final incident summary with timeline, impact, root or contributing causes, actions, and unresolved risks.
• List corrective actions with an owner, priority, due date, dependency, and verification method.
• Update policies, runbooks, architecture diagrams, asset inventories, vendor records, and training material.
• Review whether alerts were timely, contacts were current, and the escalation path worked.
• Schedule a lessons-learned meeting focused on process improvement rather than blame.
• Retain the incident record and evidence according to the organization’s retention and access rules.

What to double-check

Before approving the plan, test the details that commonly fail during a real event:

• Contacts: Do primary and backup contacts still work outside business hours? Can the team reach the domain registrar, DNS provider, host, cloud provider, insurer, and legal contact?
• Access: Can responders access logs, backups, ticketing, documentation, and emergency accounts without relying on one person?
• Time: Are system clocks, log retention periods, and time-zone conventions understood?
• Authority: Who can isolate a server, suspend an account, take a site offline, approve customer communications, or engage a specialist?
• Evidence: Does the team know which logs are short-lived and how to preserve them without contaminating the record?
• Privacy: Are data maps, processing records, vendor contacts, and contract notice clauses available to the people performing the assessment?
• Recovery: Have backups been restored in a test, and are recovery priorities tied to actual business dependencies?
• Communications: Are message templates factual, plain-language, accessible, and reviewed for unnecessary disclosure?

Run a tabletop exercise at least around the scenarios most relevant to your environment: an administrator account takeover, ransomware or destructive activity, a cloud storage exposure, a compromised website, a vendor incident, and a lost or stolen device. Record decisions made during the exercise and convert gaps into tracked work.

Common mistakes

• Making the plan a contact sheet: Names alone do not explain severity, authority, technical steps, or decision criteria.
• Waiting for certainty: Early response should use provisional facts and clearly labeled assumptions rather than delaying action until the scope is known.
• Destroying evidence through rushed remediation: Rebuilding systems or deleting accounts may remove information needed to understand the event.
• Ignoring third parties: Hosting, identity, DNS, payment, analytics, and SaaS providers may hold essential logs or control critical response actions.
• Overpromising in early notices: State what is confirmed, what remains under investigation, and how affected people can obtain updates.
• Closing after containment: A contained incident still requires recovery validation, privacy assessment, documentation, and corrective actions.
• Writing for an ideal team: A plan that assumes a dedicated security operations center may not work for a small business. Assign realistic owners and backups.

When to revisit

Review this incident response plan before seasonal planning cycles and whenever workflows or tools change. At minimum, revisit it after a significant incident, tabletop exercise, acquisition, product launch, infrastructure migration, identity-provider change, hosting or DNS change, major vendor onboarding, or material change in the data your organization collects.

Use a short review checklist:

• Confirm contacts, escalation thresholds, system owners, and emergency access.
• Compare the asset list with production systems, domains, cloud accounts, repositories, and critical vendors.
• Check that logging, backup, retention, and alerting assumptions remain accurate.
• Review data flows, subprocessors, contracts, and privacy responsibilities.
• Test one communication path and one recovery procedure.
• Close or reassign overdue corrective actions from prior incidents.
• Record the review date, approver, changes made, and next review trigger.

Keep the plan short enough to use and detailed enough to guide decisions. Pair it with a broader Incident Response Plan Checklist for Websites and SaaS Teams, and use your organization’s actual systems, owners, and contractual obligations to replace placeholders. The goal is not a perfect document; it is a practiced workflow that helps people preserve options, reduce harm, and make accountable decisions when information is incomplete.