Before You Start
- An inventory of critical business systems and data assets
- Identified key stakeholders including IT, legal, and executive leadership
- Understanding of your regulatory obligations for breach notification
- Contact information for external resources such as legal counsel and cyber insurance carrier
Define incident categories and severity levels
Start by establishing a common language for incidents across your organization. Define what constitutes a security incident versus a routine IT issue. Create severity levels, typically four tiers. Severity one is a critical incident affecting core business operations or involving confirmed data exfiltration. Severity two is a high-impact incident such as ransomware on a single system or unauthorized access to sensitive data. Severity three is a medium-impact event like a malware infection on a workstation or a phishing compromise of a single account. Severity four is a low-impact event such as a blocked phishing attempt or a failed intrusion attempt. For each severity level, define the expected response time, escalation path, and communication requirements. This classification system ensures proportionate responses and prevents alert fatigue.
Assign incident response team roles and responsibilities
Identify who is on your incident response team and what each person is responsible for during an incident. At minimum, designate an Incident Commander who leads the response and makes decisions, a Technical Lead who performs investigation and containment, a Communications Lead who handles internal and external notifications, and a Scribe who documents all actions and timeline entries. In an SMB, one person may fill multiple roles. For each role, document a primary assignee and a backup. Include contact information with personal cell phone numbers, not just work email, since email may be compromised during an incident. Define the escalation path from the person who first detects the incident to the Incident Commander. Include external contacts such as your cyber insurance carrier breach hotline, outside legal counsel, and forensic investigation firm.
Write detection and analysis procedures
Document how incidents are detected and initially assessed. List your detection sources including security tools like endpoint detection, SIEM alerts, firewall logs, and user reports. Create a procedure for the initial triage of an alert that includes verifying the alert is not a false positive, determining the scope of affected systems, identifying the attack vector, and classifying the severity. Define what evidence should be preserved immediately, such as system logs, network captures, and memory dumps. Create templates for incident tickets that capture key information including the date and time of detection, who reported it, affected systems, initial observations, and assigned severity. Include a decision tree that helps the first responder determine whether to escalate to the full incident response team or handle the event through normal IT support channels.
Document containment and eradication steps
Create playbooks for containing different types of incidents. For a compromised account, the containment steps should include resetting the password, revoking active sessions, reviewing recent activity, and checking for mail forwarding rules or OAuth app grants. For malware or ransomware, containment means isolating the affected system from the network while keeping it powered on to preserve memory evidence. For a network intrusion, containment may involve blocking attacker IP addresses, disabling compromised accounts, and segmenting affected network zones. After containment, document eradication procedures for removing the threat. This includes reimaging compromised systems, removing malware artifacts, patching the vulnerability that was exploited, and rotating all credentials that may have been exposed. Define who has the authority to take systems offline and the approval process for production changes during an incident.
Define recovery and communication procedures
Document the process for restoring normal operations after an incident. This includes restoring systems from clean backups, bringing services back online in priority order, monitoring recovered systems for signs of re-infection, and validating that the threat has been fully eradicated. Create a communication plan template that covers internal notifications to employees and leadership, external notifications to customers if their data was affected, regulatory notifications required by laws such as state breach notification statutes or HIPAA, and public communications or press statements if needed. Include notification timelines since many regulations require notification within seventy-two hours of discovering a breach. Pre-draft template communications for common scenarios so you are not writing them under pressure during an active incident.
Create post-incident review procedures
Every incident should result in a post-incident review, sometimes called a retrospective or lessons-learned meeting. Schedule this within one to two weeks after the incident is resolved while details are still fresh. Document what happened in a timeline format, what went well, what could be improved, and specific action items with owners and due dates. The review should be blameless and focused on process improvement rather than assigning fault. Create a template for the post-incident report that includes an executive summary, detailed timeline, root cause analysis, impact assessment, and remediation actions taken. Store completed reports in a secure location and review them during quarterly security reviews. Use findings to update the incident response plan itself, creating a continuous improvement cycle.
Test and maintain the plan
An untested plan is not a plan. Schedule tabletop exercises at least twice a year where the incident response team walks through a simulated scenario. Create realistic scenarios based on threats relevant to your industry, such as a ransomware attack, a business email compromise, or a data breach. During the tabletop, the facilitator presents the scenario in stages and the team discusses their response at each stage. Document gaps and areas of confusion that emerge during the exercise. Update the plan to address these gaps. Review and update the plan at least annually or whenever there is a significant change to your IT environment, team membership, or regulatory requirements. Keep the plan accessible in multiple formats including a printed copy, because during a major incident your digital systems may be unavailable.
Common Mistakes to Avoid
Writing the plan but never testing it with tabletop exercises, leaving gaps undiscovered until a real incident
Not including personal contact information, making the team unreachable when email systems are compromised
Failing to define clear authority for who can take systems offline during an incident
Not pre-identifying external resources like forensic firms and legal counsel, causing delays during a breach
Storing the plan only in digital format that may be inaccessible during a major cyberattack
Get your Cyber Defense Score™ in 60 seconds.
100 tools. No installation. No credit card.
Get My Cyber Defense Score™ →