Cyber Incident Response Plan Guide 2026: Templates, Steps & Best Practices

1. What Is an Incident Response Plan?

An incident response plan (IRP) is a documented, structured approach that defines how an organization detects, contains, eradicates, and recovers from cybersecurity incidents. It is not a theoretical exercise. It is the operational playbook that your people follow when alarms fire at 2 a.m. on a Saturday, when a phishing email compromises executive credentials, or when ransomware begins encrypting file shares across your domain.

The difference between organizations that survive a breach and those that do not almost always comes down to preparation. According to the IBM Cost of a Data Breach Report 2024, organizations with a tested incident response plan and an incident response team reduced the average cost of a data breach by $2.66 million compared to those without. That is not a marginal improvement. It is the difference between a manageable disruption and an extinction-level event for a small or midsize business.

An effective cyber incident response plan addresses four critical dimensions:

• People: Who is on the IR team, what are their roles, and who has decision-making authority during an incident?
• Processes: What specific steps does the team follow during each phase of the incident lifecycle?
• Technology: What tools are available for detection, containment, forensics, and recovery?
• Communication: How does the organization notify internal stakeholders, regulators, law enforcement, customers, and the public?

Without a written plan, organizations improvise under extreme pressure. Evidence gets destroyed. Containment is delayed. Legal obligations are missed. Regulatory notification deadlines pass. Insurance claims are denied. The cost of improvisation is measured in millions of dollars, lost customers, and in the case of healthcare or critical infrastructure organizations, potentially in human safety.

Every major compliance framework requires an incident response plan. CMMC mandates it under the Incident Response (IR) domain. HIPAA requires it as part of the Security Rule's administrative safeguards. NIST 800-171 includes 3 IR requirements, and NIST 800-53 devotes an entire control family to it. SOC 2, PCI DSS, GDPR, and the FTC Safeguards Rule all mandate incident response capabilities. An IRP is not optional. It is a business requirement.

2. The 6 Phases of Incident Response (NIST SP 800-61)

The National Institute of Standards and Technology's Special Publication 800-61 Rev. 2, "Computer Security Incident Handling Guide," is the foundational reference for incident response in the United States. While other frameworks exist (SANS uses a similar model, ISO 27035 provides an international perspective), NIST SP 800-61 is the standard that most compliance frameworks reference and that most organizations adopt. The framework defines six distinct phases that form a continuous cycle.

These six phases are not strictly linear. Detection may reveal new information that changes the containment strategy. Eradication may uncover additional compromised systems that require returning to containment. Recovery may trigger new detections. The phases form a cycle of continuous improvement, with lessons learned from each incident feeding back into preparation for the next.

3. Incident Response Plan Template

A complete incident response plan template should be a living document that is reviewed quarterly and updated whenever significant changes occur in your environment, team, or threat landscape. The following framework covers every component that regulatory frameworks require and that real-world incidents demand. Use this as a starting point and customize it for your organization's size, industry, and regulatory obligations.

This template aligns with the incident response requirements of CMMC 2.0 (IR.L2-3.6.1 through IR.L2-3.6.3), NIST 800-171 (3.6.1, 3.6.2, 3.6.3), HIPAA Security Rule (164.308(a)(6)), PCI DSS (Requirement 12.10), and SOC 2 (Common Criteria 7.3-7.5). If your organization is subject to any of these frameworks, this template provides the structural foundation you need.

4. Incident Response Plan for Small Business

Small and midsize businesses (SMBs) face the same threats as large enterprises but with a fraction of the resources. According to the Hiscox Cyber Readiness Report, 43 percent of cyberattacks target small businesses, and 60 percent of those that suffer a significant attack close within six months. The National Cyber Security Alliance data is even more sobering: only 14 percent of small businesses rate their ability to mitigate cyber risks as "highly effective."

The good news is that an effective incident response plan for a small business does not need to be 100 pages long or require a dedicated security operations center. It needs to be practical, actionable, and tested. Here is what SMBs should prioritize:

Essential IR Components for SMBs

• Designate an incident coordinator: This does not have to be a full-time security role. It can be a senior IT person or office manager who is responsible for initiating the response process. What matters is that one person knows they own this responsibility and has the authority to act.
• Create a one-page quick reference card: A laminated card with the top five actions to take in an incident, the three phone numbers to call (IT provider/MSSP, cyber insurance, legal), and the decision tree for escalation. Post it near server rooms and give copies to all managers.
• Establish a relationship with an IR provider before you need one: Attempting to find, vet, and engage a forensics firm during an active breach wastes critical hours. Establish a retainer or pre-engagement agreement with a firm like Petronella Technology Group, Inc. so that response begins immediately when you call.
• Know your insurance policy: Read your cyber insurance policy before an incident. Know the claims number, the list of approved vendors, the notification requirements, and whether your policy requires insurer approval before engaging forensics or paying a ransom.
• Test annually with a tabletop exercise: A two-hour tabletop exercise (see Section 8) is affordable for any business and reveals gaps that no amount of document review will find.
• Implement basic forensic readiness: Enable logging on critical systems (firewalls, domain controllers, email), ensure logs are retained for at least 90 days, and store them in a location that an attacker cannot easily delete.
• Document your technology environment: Maintain a current asset inventory, network diagram, and list of critical business applications with vendor contact information. During an incident, this information is essential and nearly impossible to reconstruct under pressure.

5. Ransomware Incident Response Playbook

Ransomware is the most common and most damaging incident type that organizations face today. The Verizon DBIR consistently shows ransomware involved in approximately 25 percent of all data breaches. Modern ransomware attacks are not random. They are targeted, methodical operations conducted by professional criminal organizations that may spend weeks inside your network before deploying encryption. The following playbook provides step-by-step guidance for responding to a ransomware incident.

Immediate Actions (First 30 Minutes)

1. Do NOT power off affected systems. Powering off destroys volatile memory that may contain decryption keys, attacker tools, and forensic artifacts. Instead, isolate systems by disconnecting network cables or disabling network adapters.
2. Isolate the network. Disable inter-VLAN routing, shut down VPN connections, and segment affected network zones to prevent lateral movement. If the attack is spreading rapidly, disconnect the entire network from the internet.
3. Activate your IR team and contact your MSSP. Call 919-348-4912. If you have a retainer with Petronella Technology Group, Inc., response begins immediately. Do not attempt remediation without experienced forensic support.
4. Preserve evidence. Take screenshots of ransom notes. Document the file extensions used by the ransomware. Record which systems are affected and which appear clean. Do not delete any files or run antivirus scans on affected systems until forensic images are captured.
5. Contact your cyber insurance carrier. Most policies require notification within 24 to 72 hours. The carrier will assign a breach coach (attorney) who coordinates the response and protects communications under attorney-client privilege.

Investigation Phase (Hours 1-24)

1. Identify the ransomware variant. The variant determines whether free decryption tools exist (check nomoreransom.org), whether the group is known for data exfiltration, and how they typically gain initial access.
2. Determine the initial access vector. How did the attacker get in? Phishing email, exploited vulnerability, compromised RDP, supply chain compromise? This is critical for eradication and for preventing re-compromise.
3. Assess data exfiltration. Modern ransomware groups (LockBit, BlackCat/ALPHV, Cl0p, Play, Royal) routinely exfiltrate data before encrypting. Review outbound network traffic, check for staging directories, and look for evidence of archive tools (7-Zip, WinRAR) or cloud upload utilities.
4. Map the blast radius. Which systems are encrypted? Which systems were accessed but not encrypted? Which backup copies are intact? This assessment drives recovery planning and regulatory notification decisions.
5. Engage law enforcement. Report the incident to the FBI's Internet Crime Complaint Center (IC3) and your local FBI field office. Law enforcement may have intelligence about the group, decryption keys, or ongoing operations that can assist your recovery.

Recovery Phase

1. Validate backup integrity. Before restoring, verify that backup copies are clean (not encrypted or tampered with) and are from a point in time before the attacker gained access. Attackers may have been in the network for weeks, and restoring a backup from within the compromise window reintroduces the threat.
2. Rebuild from known-good images. Do not attempt to "clean" encrypted systems. Rebuild them from scratch using verified operating system media and application installers. Apply all current patches before reconnecting to the network.
3. Restore data in priority order. Critical business applications first, then supporting systems, then user workstations. Test each restored system before moving to the next.
4. Implement enhanced monitoring. Deploy additional detection on recovered systems and monitor for indicators that the attacker is attempting to return. Threat actors frequently re-target organizations that have paid a ransom or that were known to have weak defenses.

Ransom Payment Decision Framework

The decision to pay a ransom is complex and should involve your executive leadership, legal counsel, cyber insurance carrier, and forensics team. Factors to consider:

• Are clean backups available that would allow recovery without payment?
• Has data been exfiltrated, and would non-payment result in publication of sensitive information?
• Is the ransomware group on the OFAC sanctions list (paying sanctioned entities carries legal liability)?
• What is the group's track record of providing working decryptors after payment?
• What are the total costs of recovery without payment versus with payment?
• Does your cyber insurance policy cover ransom payments, and does the carrier approve?

Petronella Technology Group, Inc. always explores every recovery option before considering payment. In many cases, we recover data without paying through backup restoration, decryption tool availability, or forensic data recovery techniques. For more on our ransomware capabilities, see our ransomware protection and recovery services.

6. Data Breach Response: Legal, Technical, and Communication Steps

A data breach, defined as unauthorized access to or disclosure of protected information, triggers a cascade of legal, technical, and communication obligations that are separate from (though overlapping with) the technical incident response. Missing any of these obligations can result in regulatory fines, lawsuits, and reputational damage that exceeds the cost of the breach itself.

Legal Response

• Engage breach counsel immediately. All communications about the breach, including internal emails, Slack messages, and documents, may be discoverable in litigation. Having an attorney direct the investigation protects communications under attorney-client privilege. Your cyber insurance carrier typically provides a breach coach at no additional cost.
• Determine notification obligations. All 50 U.S. states plus D.C., Guam, Puerto Rico, and the U.S. Virgin Islands have breach notification laws, each with different definitions of "personal information," different notification timelines (ranging from 30 to 90 days), and different requirements for the content of notifications. If you handle data from residents of multiple states, you must comply with each applicable law.
• Federal requirements: HIPAA requires notification within 60 days for breaches affecting 500+ individuals, with simultaneous notification to HHS and prominent media. CMMC requires contractor notification to DIBCAC within 72 hours. GDPR requires notification within 72 hours of awareness. The FTC Safeguards Rule requires notification to the FTC within 60 days for breaches affecting 500+ consumers.
• Preserve all evidence. Issue a litigation hold to prevent destruction of any data that could be relevant to the breach investigation, regulatory inquiries, or future litigation.

Technical Response

• Conduct forensic analysis to determine what was accessed. Regulators and courts want specifics: which records, which individuals, what data elements. "We think they may have accessed some data" is not sufficient. Forensic analysis must reconstruct the attacker's activities to identify exactly what was viewed, copied, or exfiltrated.
• Preserve forensic evidence to litigation-grade standards. This means forensic imaging with hash verification, documented chain of custody, and secure storage. Our digital forensics team follows standards that hold up in court.
• Remediate the vulnerability that allowed the breach. This must be documented for regulators and insurers. "What are you doing to prevent this from happening again?" is a question every regulator asks.

Communication Response

• Internal: Brief executive leadership, board of directors, and affected departments. Provide talking points for customer-facing employees. Establish a single source of truth for information about the breach.
• Affected individuals: Notification letters must comply with applicable state and federal requirements. Include what happened, what data was involved, what you are doing about it, and what the individual can do to protect themselves (typically credit monitoring, which is offered at the organization's expense).
• Regulators: File required notifications with appropriate regulatory bodies. Do not wait until the last day. Early, cooperative communication with regulators typically results in better outcomes.
• Media: Prepare a holding statement and a detailed press release. Designate a single spokesperson. Be transparent but precise. Overstatements and understatements both create liability.
• Business partners: If the breach affects data you hold on behalf of clients or partners, contractual notification obligations may apply. Review your business associate agreements, data processing agreements, and vendor contracts.

7. Cloud Incident Response: AWS, Azure, and GCP Considerations

Cloud environments introduce unique incident response challenges that traditional on-premises playbooks do not address. The shared responsibility model means that your cloud provider secures the infrastructure, but you are responsible for securing your configurations, data, identities, and applications. Most cloud breaches result from customer misconfigurations, not provider vulnerabilities.

Cloud-Specific IR Challenges

• Ephemeral resources: Containers, serverless functions, and auto-scaling instances may spin up and terminate before traditional forensic imaging is possible. Your IR plan must account for capturing runtime data before resources disappear.
• Shared responsibility: Know exactly which security functions are your responsibility versus the cloud provider's. In IaaS (EC2, Azure VMs, Compute Engine), you own everything above the hypervisor. In PaaS and SaaS, the boundary shifts.
• Identity is the perimeter: Cloud breaches overwhelmingly begin with compromised credentials or misconfigured IAM policies. Your detection must focus heavily on identity-based indicators: impossible travel, unusual API calls, privilege escalation, and cross-account activity.
• Logging at scale: AWS CloudTrail, Azure Activity Log, and GCP Cloud Audit Logs generate massive volumes of data. Your SIEM must be configured to ingest, correlate, and alert on cloud-native logs alongside on-premises sources.

Platform-Specific Considerations

Amazon Web Services (AWS)

• Enable CloudTrail in all regions, including regions you do not use (attackers will)
• Enable GuardDuty for automated threat detection across accounts
• Use AWS Organizations SCPs to restrict high-risk actions (disabling CloudTrail, creating IAM users in production)
• For forensic imaging, create EBS snapshots of affected instances before termination
• Isolate compromised instances by moving them to a quarantine security group (no ingress/egress), do not terminate

Microsoft Azure

• Enable Microsoft Defender for Cloud across all subscriptions
• Configure Azure AD (Entra ID) sign-in and audit logs with 90-day retention
• Use Conditional Access policies to enforce MFA and block risky sign-ins
• For forensic imaging, create disk snapshots and export for offline analysis
• Leverage Azure Sentinel (Microsoft Sentinel) for cloud-native SIEM and automated playbooks

Google Cloud Platform (GCP)

• Enable Cloud Audit Logs (Admin Activity + Data Access) across all projects
• Use Security Command Center for centralized threat and vulnerability management
• Configure VPC Flow Logs for network traffic analysis
• Export logs to a separate, locked-down project for tamper-resistant retention
• For forensic imaging, create persistent disk snapshots before any remediation

Petronella Technology Group, Inc. provides cloud-native incident response across all three major platforms. Our cloud IR team includes engineers certified in AWS, Azure, and GCP security, and we maintain forensic tools and procedures specifically designed for cloud environments. For organizations using cloud hosting services, we integrate IR capabilities directly into your cloud architecture.

8. Incident Response Tabletop Exercises: How to Run One

A tabletop exercise is a discussion-based simulation where key personnel walk through a hypothetical incident scenario to test their decision-making, communication, and coordination. It is the most cost-effective way to validate your incident response plan and identify gaps before a real incident exposes them. NIST SP 800-84 provides detailed guidance on designing and conducting exercises, and both CMMC and HIPAA require regular testing of incident response capabilities.

Planning the Exercise (2-4 Weeks Before)

1. Define objectives. What are you testing? Examples: notification timeline compliance, executive decision-making, cross-department communication, ransomware-specific procedures, regulatory reporting accuracy.
2. Select participants. Include IT, security, legal, HR, communications, executive leadership, and finance. Do not limit it to IT. Real incidents require cross-functional coordination, and tabletop exercises are often the first time non-technical leaders realize the decisions they will need to make under pressure.
3. Develop the scenario. Base it on a realistic threat relevant to your industry. A ransomware scenario is universally applicable. Healthcare organizations should include PHI exposure. Defense contractors should include CUI compromise. Financial services firms should include wire fraud.
4. Create injects. These are new pieces of information introduced during the exercise to escalate the scenario and force additional decisions. Examples: "The media has called asking about the breach." "Law enforcement has contacted you about the attack group." "A second wave of encryption has started."
5. Prepare a facilitator guide. The facilitator keeps the exercise on track, introduces injects, asks probing questions, and ensures all participants engage. An external facilitator provides objectivity and expertise that internal facilitators may lack.

Running the Exercise (2-4 Hours)

1. Set expectations. This is a learning exercise, not a test. There are no wrong answers. The goal is to identify gaps and improve.
2. Present the scenario. Describe the initial indicators that an incident has occurred. Ask: "What do you do first? Who do you call? What authority do you need?"
3. Walk through each IR phase. For each phase, ask participants to describe their actions, identify who is responsible, and flag any resources they need but do not currently have.
4. Introduce injects at planned intervals. Increase pressure and complexity. Force participants to make decisions with incomplete information, just as they will during a real incident.
5. Document gaps and decisions. Assign a note-taker to capture every gap, question, and decision point. These notes are the raw material for improving your IR plan.

After the Exercise

1. Conduct a hot wash. Immediately after the exercise, gather participant feedback while it is fresh. What surprised them? What was unclear? What worked well?
2. Produce an after-action report. Document findings, gaps, and recommendations. Assign owners and deadlines for each remediation item.
3. Update the IR plan. Incorporate lessons learned into the plan within 30 days.
4. Schedule the next exercise. Best practice is quarterly exercises with different scenarios. At minimum, conduct one annually.

For more on the importance of regular tabletop exercises, read our articles on IR tabletop exercises and disaster recovery tabletop exercises. Our red team services can also enhance your exercises with realistic attack simulations.

9. NIST Incident Response Framework Alignment

The NIST incident response framework is not a standalone document. It is embedded across multiple NIST publications, each addressing incident response from a different perspective and level of detail. Understanding how these publications interconnect helps organizations build an IR program that satisfies multiple compliance requirements simultaneously.

Key NIST Publications for Incident Response

Cross-Framework Mapping

For organizations subject to multiple frameworks, incident response requirements overlap significantly. Building your IR program on the NIST SP 800-61 foundation satisfies the IR requirements across multiple frameworks:

• CMMC Level 2 (IR domain): Maps directly to NIST 800-171 Section 3.6. Three practices: establish IR capability, test IR plan, report incidents to designated authorities.
• HIPAA Security Rule (164.308(a)(6)): Requires a security incident response and reporting process. NIST SP 800-66 provides implementation guidance specific to healthcare.
• PCI DSS (Requirement 12.10): Requires an incident response plan that is tested annually, includes specific procedures for compromise, and defines roles and responsibilities.
• SOC 2 (CC7.3-CC7.5): Requires incident detection, response, communication, and remediation processes that are designed, implemented, and operating effectively.
• NIST CSF 2.0 (RS and RC functions): RS.MA (Incident Management), RS.AN (Incident Analysis), RS.MI (Incident Mitigation), RS.RP (Response Planning), RC.RP (Recovery Planning), RC.CO (Communications).

Petronella Technology Group, Inc. implements IR programs that satisfy multiple frameworks simultaneously, eliminating the duplication and inefficiency of maintaining separate IR processes for each compliance requirement. Our unified approach reduces cost and complexity while ensuring comprehensive coverage.

10. Building Your IR Team: Roles and Responsibilities

An incident response team is not just an IT function. Effective incident response requires coordination across technical, legal, communications, and executive functions. The composition of your team depends on your organization's size, but even the smallest business needs clearly defined roles with named individuals assigned to each.

Team Readiness Requirements

• Contact information: Primary and backup contact methods for every team member, including personal cell phones and out-of-band communication channels (assume corporate email and messaging may be compromised).
• Training: Annual IR-specific training for all team members. Technical staff need hands-on forensic and detection training. Non-technical members need decision-making and communication training.
• Authority documentation: Written authorization for the incident commander to take specific actions (isolate systems, engage vendors, authorize spending up to a defined threshold) without waiting for additional approval.
• Succession planning: Identify backup personnel for every role. Incidents do not wait for people to return from vacation or recover from illness.

For organizations that lack the resources for a full internal IR team, Petronella Technology Group, Inc. provides incident response training and virtual CISO (vCISO) services that fill the gaps. Our team integrates with your staff and becomes an extension of your organization, providing the expertise and rapid response capability that your business requires.

11. IR Metrics and KPIs to Track

What gets measured gets improved. Incident response metrics provide quantifiable evidence of your IR program's effectiveness, justify security investments to leadership, and identify specific areas where improvement is needed. The following metrics are essential for any mature IR program.

Reporting Cadence

• Weekly: Incident volume, open incidents, alert-to-incident ratio for the security team
• Monthly: MTTD, MTTR, MTTC trending, false positive rate, incidents by type for IT leadership
• Quarterly: Executive dashboard with cost per incident, compliance metrics, tabletop exercise results, lessons learned completion rate for the board or executive team
• Annually: Year-over-year trend analysis, benchmark comparison against industry peers, IR program maturity assessment, budget justification for security investments

12. How PTG Helps: AI-Enhanced Incident Response & Digital Forensics

Petronella Technology Group, Inc. is not a company that read a book about incident response and built a service offering. We are a team that has investigated real breaches, responded to active ransomware attacks at 3 a.m., testified as expert witnesses in cybercrime cases, and helped organizations navigate the most difficult days in their history. Our incident response capabilities are built on 23+ years of hands-on experience and continuously refined with AI-enhanced detection and automation.

Our IR Service Offerings

• IR Plan Development and Documentation: We build complete, framework-aligned incident response plans customized to your organization's size, industry, regulatory requirements, and technology environment. Not templates. Custom plans that your team can actually execute.
• Tabletop Exercise Facilitation: Our experienced facilitators design and run realistic tabletop exercises that test your team's decision-making, communication, and coordination. We provide detailed after-action reports with prioritized recommendations.
• IR Retainer Services: Pre-engagement agreements that guarantee response time SLAs when an incident occurs. No scrambling to find help during a crisis. One call to 919-348-4912, and our team mobilizes immediately.
• Digital Forensic Investigation: Led by Craig Petronella (NC Licensed Digital Forensics Examiner, License #604180-DFE), our forensics team conducts litigation-grade investigations including endpoint forensics, network forensics, malware analysis, data exfiltration assessment, and expert witness testimony.
• AI-Enhanced Detection (Eve): Our AI agent Eve provides 24/7 continuous monitoring of your environment, detecting the behavioral indicators that precede major incidents, including credential harvesting, lateral movement, privilege escalation, data staging, and backup tampering. Eve reduces MTTD from days to minutes.
• Ransomware Response and Recovery: Battle-tested ransomware response capabilities including containment, forensic analysis, variant identification, backup validation, system restoration, and coordination with law enforcement and insurance carriers.
• Compliance-Integrated IR: IR programs that satisfy the incident response requirements of CMMC, HIPAA, NIST 800-171, NIST 800-53, PCI DSS, SOC 2, and the FTC Safeguards Rule simultaneously.
• Incident Response Training: Role-specific training for IR team members, general security awareness training that includes incident reporting, and specialized training for executives on breach decision-making and communication.

Why Organizations Choose PTG for Incident Response

• 23+ years of experience: We have been protecting businesses in Raleigh, Durham, Chapel Hill, and the Research Triangle since 2002. We have seen threat landscapes evolve from script kiddies to nation-state actors, and our IR methodology reflects that experience.
• Certified forensic examiner: Craig Petronella holds NC Digital Forensics Examiner License #604180-DFE and serves as an expert witness in cybercrime and compliance cases for law firms across the Southeast.
• CMMC Registered Practitioner Organization: We understand the specific IR requirements for defense contractors and help organizations achieve and maintain CMMC compliance.
• 2,500+ businesses served: Our experience spans healthcare, legal, financial services, manufacturing, defense contracting, education, and technology sectors.
• BBB A+ rated since 2003: Two decades of trusted service, demonstrated by consistent client satisfaction and ethical business practices.
• Published thought leadership: Craig Petronella is an Amazon number-one best-selling author of cybersecurity and compliance books, and has been featured on ABC, CBS, NBC, FOX, and WRAL.