Most businesses write their first incident response plan the week after their first serious security incident. By then, the plan is a post-mortem, not a playbook. The decisions that matter most in a cyber incident — who takes charge, who you call, what you shut down, what you say to customers — are exactly the decisions you don’t want to make for the first time at 2 a.m. while your systems are encrypted.
At COMNEXIA, we’ve spent 35 years helping Atlanta-area businesses keep their technology running, and we’ve seen the difference a written, tested plan makes. Businesses with a plan move in hours. Businesses without one lose days to confusion — and days of downtime are usually far more expensive than the incident itself.
This guide walks through what an incident response plan actually contains, who needs to be involved, and how to make sure it works before you ever need it.
What Is an Incident Response Plan?
An incident response plan is a written document that defines how your organization detects, contains, and recovers from a cybersecurity incident — and who is responsible for each step. It turns a chaotic event into a managed process.
A good plan answers questions like:
- Who declares an incident, and what counts as one?
- Who has authority to take systems offline?
- Who contacts the insurance carrier, legal counsel, and law enforcement?
- How do employees communicate if email itself is compromised?
- What are the recovery priorities — which systems come back first?
The most widely used framework for structuring a plan comes from the National Institute of Standards and Technology (NIST), whose Computer Security Incident Handling Guide (Special Publication 800-61) organizes incident response into a repeatable lifecycle: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. You don’t need to follow NIST word-for-word, but those four phases are a proven skeleton for any plan, whether you’re a 10-person office or a multi-location dealership group.
Why Do Small Businesses Need an Incident Response Plan?
Small and mid-sized businesses need incident response plans because they face the same threats as large enterprises — ransomware, phishing, business email compromise — but with far less margin for downtime and error. A large company can absorb a week of disruption. For many smaller businesses, extended downtime threatens payroll, customer relationships, and the business itself.
There are three practical reasons the plan matters:
Speed is everything in containment. Ransomware and similar attacks spread through networks quickly. The gap between “we noticed something odd” and “we isolated the affected machines” often determines whether you’re restoring one workstation or your entire environment. A plan removes the deliberation from that gap.
Regulators and insurers increasingly expect one. Cyber insurance applications routinely ask whether you have a written incident response plan, and your answers affect both eligibility and premiums. And for some industries, a plan isn’t optional at all — more on that below.
Incidents are a “when,” not an “if.” Phishing emails, credential theft, and malware attempts hit businesses of every size, every day. Perfect prevention doesn’t exist. Response capability is the layer that catches what prevention misses.
What Does the FTC Safeguards Rule Say About Incident Response?
If your business qualifies as a “financial institution” under the FTC Safeguards Rule — a category that includes automotive dealerships that arrange financing, mortgage brokers, and many other non-bank businesses — a written incident response plan is a legal requirement, not a best practice.
The revised Safeguards Rule, with full compliance required as of June 9, 2023, obligates covered businesses to maintain a written incident response plan addressing, among other things, the goals of the plan, internal processes for responding to a security event, clear roles and responsibilities, communications and information sharing, remediation of identified weaknesses, and post-incident evaluation.
The FTC also amended the rule to add a breach notification requirement: as of May 13, 2024, covered financial institutions must notify the FTC within 30 days of discovering a security breach involving the unencrypted information of 500 or more consumers. That reporting clock is a strong argument for having your discovery, investigation, and notification process documented in advance — 30 days evaporates quickly when you’re also trying to restore operations.
COMNEXIA works with dealerships and other covered businesses across Georgia on Safeguards Rule–aligned cybersecurity programs, and the incident response plan is consistently the component businesses have skipped — because it feels theoretical until it isn’t.
What Are the Key Components of an Incident Response Plan?
An effective incident response plan contains seven core components: defined roles, incident classification, detection and reporting procedures, containment steps, communication protocols, recovery priorities, and post-incident review. Here’s what each one looks like in practice.
1. Roles and Responsibilities
Name the incident response team by role (not just by individual, since people leave). At minimum you need an incident commander with authority to make decisions, a technical lead (often your IT provider or MSP), a communications owner, and an executive sponsor. Include after-hours contact information — printed and stored somewhere that isn’t on the network.
2. Incident Classification
Define what counts as an incident and how severe it is. A single phishing email that nobody clicked is not the same as active ransomware. A simple three-tier severity scale (low / moderate / critical) with examples keeps everyone calibrated and prevents both overreaction and dangerous underreaction.
3. Detection and Reporting
Spell out how incidents get reported and to whom. Every employee should know one simple rule: if something looks wrong, report it immediately, and you will never be punished for a false alarm. Many of the worst incidents grew because an employee sat on a suspicious email or a strange pop-up for days out of embarrassment.
4. Containment Procedures
Document, in advance, the actions your team is pre-authorized to take: disconnecting affected machines from the network, disabling compromised accounts, blocking traffic at the firewall, or in severe cases isolating entire network segments. Crucially, decide now who can authorize shutting down a revenue-generating system. That decision is agonizing in the moment if nobody knows who owns it.
5. Communication Protocols
Plan for internal communication that doesn’t depend on compromised systems — if attackers are in your email, you can’t coordinate your response over that email. Identify an out-of-band channel (phone tree, text thread, or a separate service). Externally, define who speaks to customers, vendors, insurers, and — only through counsel — the media. Everyone else says nothing.
6. Recovery Priorities
List your critical systems in restore order. For a dealership, that might be the DMS and phones before the marketing website. For a law firm, document management and email before anything else. This list should align with your backup strategy: your most critical systems should have the most frequent, most tested backups.
7. Post-Incident Review
Commit to a blameless review after every significant incident: what happened, what worked, what didn’t, and what changes to make. The organizations that improve fastest treat every incident — even the near-misses — as free training.
Who Should Be on an Incident Response Team?
An incident response team should include leadership, IT, legal, communications, and key operational managers — not just technical staff. Cyber incidents are business events with technical causes, and treating them as purely an “IT problem” is one of the most common planning mistakes.
For a small or mid-sized business, the realistic roster looks like this:
- Executive sponsor / incident commander — an owner or senior leader with authority to spend money and stop operations
- Technical lead — your internal IT lead or your managed service provider
- Legal counsel — identified in advance, ideally with breach experience; your cyber insurer often provides or requires specific counsel
- Insurance contact — your cyber policy carrier’s claims hotline, documented in the plan
- Communications owner — the one person authorized to communicate externally
- Operations leads — the people who know what each department needs to function
If you work with an MSP, clarify in writing what they will do during an incident and how fast. COMNEXIA’s IT consulting engagements often start exactly here — mapping who does what in a crisis, because most businesses have never written it down.
How Do You Test an Incident Response Plan?
You test an incident response plan with tabletop exercises: structured, discussion-based walkthroughs of a realistic scenario, run at least annually. No systems are touched — the team simply talks through a scenario (“It’s Monday morning, three employees report their files are encrypted, and there’s a ransom note”) step by step.
A good tabletop exercise takes 60–90 minutes and reliably exposes the same gaps:
- Contact lists that are outdated or stored only on systems that would be down
- Confusion about who has authority to disconnect systems
- Backups that exist but have never actually been restored
- Nobody knowing the cyber insurance carrier’s reporting requirements or hotline
- No plan for operating manually — taking orders, answering phones, serving customers — while systems are down
The Cybersecurity and Infrastructure Security Agency (CISA) publishes free tabletop exercise materials that small businesses can adapt, and your IT partner can facilitate a scenario tailored to your environment. Beyond tabletops, test the technical pieces on a schedule: restore real files from backup quarterly, verify your emergency contact tree, and re-run the exercise whenever key people or systems change.
The plan itself should be reviewed at least once a year. An incident response plan with a two-year-old phone list is a false sense of security.
How COMNEXIA Helps Atlanta Businesses Prepare
COMNEXIA has been serving Georgia businesses since 1991, and our cybersecurity services are built around a simple idea: prevention and response are two halves of the same program. We help hundreds of businesses across Georgia — including the automotive dealerships that make up our specialty — with layered security, monitored backups, Safeguards Rule compliance programs, and incident response planning and testing.
If your business doesn’t have a written, tested incident response plan today, that’s the gap worth closing first. It costs a fraction of what a single disorganized incident does.
Frequently Asked Questions
Q: What is the difference between an incident response plan and a disaster recovery plan? A: An incident response plan governs how you handle a security incident — detection, containment, investigation, and communication. A disaster recovery plan governs how you restore IT systems and data after any disruption, including fires, floods, and hardware failure. They overlap during recovery, and both feed into broader business continuity planning, but they answer different questions and you need both.
Q: How often should we update our incident response plan? A: Review it at least annually, and update it any time key personnel, vendors, insurance coverage, or critical systems change. Pair each review with a tabletop exercise so you’re testing the current plan, not last year’s.
Q: Are automotive dealerships really required to have an incident response plan? A: Yes. Dealerships that arrange or extend financing are “financial institutions” under the FTC Safeguards Rule, which requires a written incident response plan as part of a broader information security program, with full compliance required since June 9, 2023. Dealerships must also notify the FTC within 30 days of discovering breaches involving unencrypted information of 500 or more consumers.
Q: What should employees do first if they suspect a cyber incident? A: Report it immediately through the channel defined in your plan — and don’t turn the machine off unless instructed, since powering down can destroy evidence. Disconnecting the machine from the network (unplugging the cable or disabling Wi-Fi) while leaving it powered on is usually the better first move, but your plan and IT team should make that call.
Q: Can a small business build an incident response plan without a full-time IT staff? A: Absolutely. Frameworks like NIST SP 800-61 and free CISA tabletop resources provide the structure, and a managed service provider can supply the technical roles your team doesn’t have in-house. A useful plan for a small business can fit on a handful of pages — what matters is that it’s written, assigned, and tested.