Zip × CrowdStrike Threat Briefing: Exclusive insights into today's evolving threat landscape — Jul 2305d:20h:09m:25s
All Posts
Security·13 min read

Incident Response Plan Template for Companies Without a Security Team

Learn more
Incident Response Plan Template for Companies Without a Security Team
Josh Zweig

Josh Zweig

July 17, 2026

Key Takeaways

  • A written response plan with leadership approval and quarterly review helps teams respond consistently.
  • A small-company response needs named owners for command, technical work, and communications, and none of them needs a security title.
  • Print the contact list, because during a real incident your usual communication and file systems may be down.
  • Every playbook depends on working controls, so verify EDR and identity coverage now. Also check any device-management controls the playbooks need before you rely on the isolate button.
  • An incident response plan is one layer of a modern, automated security stack, not a substitute for detection and containment tools that act whether or not someone reads the plan in time.

3:14 PM on a Tuesday. Files on the shared drive start locking one by one, and everyone recognizes it as ransomware before anyone says the word. Nobody in the room is sure whose job it is to make the next call.

That's the moment an incident response plan is for, a document that already names who calls it, who works the machines, and who talks to customers, so nobody has to figure that out live. The basics recommended for small organizations follow the same incident response lifecycle as current federal guidance, just scaled down for a team of one or two people who have a dozen other things to do today.

See Zip's modern alternative to building and maintaining this plan by hand.

A Written Plan Beats Improvising, and Most Companies Don't Have One

77% of businesses lack a proper incident response plan, so when something happens, teams default to knee-jerk decisions that make it worse. A proper plan is a written document approved by senior leadership that makes each person's role clear during a suspected or confirmed incident, and a lean first version can take shape quickly. The cost of a bad breach makes that work worth doing.

  • Breach costs remain high and disruptive, with breach lifecycles still measured in months.
  • Smaller companies face the same costs. Breach response can still threaten budgets below enterprise scale.
  • Catching a breach yourself, instead of hearing about it from the attacker, shortens the lifecycle by 61 days and saves nearly $1 million.

Together, those costs make a simple written plan worth the time.

Enterprise vendor reviews often ask whether you have a formal response plan. That question is much easier to answer when the document already exists, especially if you're answering without security staff.

The Incident Response Plan Template for Companies Without a Security Team, Section by Section

Ten pieces make up a plan like this, and none of them take more than a paragraph to write, even without a dedicated security hire. Put them together once, and everyone on the team knows exactly where to look when an incident occurs.

  1. Plan owner and review cadence. Name an owner, get the CEO's dated signature, and set a quarterly review, plus a review after every incident or near miss. That signature turns the plan from a draft into something leadership has committed to using.
  2. What counts as an incident, and who can declare one. List concrete triggers, such as a ransom note, a suspected account takeover, a data exfiltration alert, a vendor breach notice, repeated MFA prompts, or a missing device. Name who can declare an incident and how.
  3. Severity tiers. SEV-1 covers ransomware, confirmed exfiltration, legal or safety risk, and widespread outages, while SEV-2 covers everything smaller and easier to contain. That two-level split mirrors the impact-based approach NIST uses to prioritize incidents, just simplified for a lean team.
  4. Roles with named backups. Every role needs a primary and a backup, since incidents don't wait for someone's vacation to end. Write both names next to each role, backup included.
  5. A printed contact list. Print it and give a copy to everyone with a role, since internal email and chat may be down during the incident. Include vendors, your attorney, your insurer, your outside incident response (IR) firm, and law enforcement contacts.
  6. A communication plan with a holding statement. Decide in advance who gets notified and when, from employees to customers to press. Write the holding statement now, before a reporter calls and forces you to improvise.
  7. Short playbooks for your top scenarios. A few modular, threat-specific playbooks beat a hundred-page binder nobody opens. Start with ransomware, business email compromise, lost or stolen laptops, and departing-employee data theft.
  8. A pre-selected outside IR firm. Select one before a compromise happens, not during it. Searching for a firm mid-attack costs you the hours you need most.
  9. Legal and notification obligations. Have an attorney review the entire plan, beyond the notification steps alone. Counsel often has strong preferences on how to engage vendors and law enforcement.
  10. A blameless post-incident review. Incidents are usually system failures, not one person's fault. A blameless review keeps people honest about what happened, and that honesty makes the review worth running.

None of this requires new headcount or specialized security training, just the discipline to write it down before you need it. Getting the roles right is the piece that decides whether a plan holds up under pressure or falls apart with it, so start there.

Fill Three Roles With People You Already Have

A three-person response covers most small companies, and none of the three roles need a security title to fill well. Automation now handles a lot of what used to take a full security team, isolating a device, killing a malicious process, flagging the anomaly before a person even notices. What's left still needs people. One person makes the call, one acts on whatever automation can't handle alone, and one talks to everyone outside the room. Here's who typically takes each seat.

Role During an Incident Where Automation Fits Who Usually Fills It
Incident commander Sets severity, assigns roles, approves containment actions, runs status updates, documents decisions Starts from automated severity flags instead of raw alerts Senior IT admin, an engineering manager, or your fractional CISO
Technical lead Investigates, contains, eradicates, and restores, doing the hands-on technical work Containment often already ran. This role verifies and finishes the cleanup Your most senior technical person
Communications lead Drafts internal updates, customer notices, and the press response, and coordinates with counsel Pre-built templates cut the drafting time, but tone and judgment calls still need a person Founder, COO, or head of operations

Keep the incident commander and technical lead as two different people, even on a three-person team. One tracks the clock and the deadlines, while the other tracks whatever the tools are flagging. Combine the two and something slips.

If you work with a virtual CISO (vCISO) through a fractional CISO or vCISO engagement, response planning sits squarely in their lane, since they typically build the plan and run the tabletop exercises. During a live incident, they take the leadership seat while your team handles the hands-on work, which plays to what each side does best.

Write These Four Playbooks First

With roles filled, the next job is making sure those people know what to do when something happens. Most small companies won't face every possible attack, but a handful cause the bulk of the damage. Ransomware has hit 29% of small businesses with fewer than 25 employees, the highest rate of any size group. Business email compromise (BEC) now shows up in more observed incidents (21%) than ransomware (16%), according to 2025 threat data.

Ransomware

Ransomware moves in minutes, and every minute spent deciding is a minute the encryption keeps spreading. Move through this sequence in order, even though skipping the evidence step feels like the fastest way through.

  1. Disconnect affected machines from the network by unplugging Ethernet or dropping them from Wi-Fi, or let automated EDR isolation handle it instantly if that's running. Power off only as a last resort, since a hard shutdown wipes the memory evidence investigators need.
  2. Coordinate by phone. Attackers may be watching internal company chat.
  3. If you can, capture a system image (a full copy of the device) and a memory snapshot (what was running at that moment) from a sample of affected devices, preserving evidence for investigators. EDR tools tied to automated isolation often capture this automatically before a person reaches the device.
  4. Call your outside IR firm and report to CISA or the FBI. Use the ransomware response checklist. Law enforcement may know of a working decryptor for your variant.
  5. Restore from offline backups only after you've closed the entry point, then reset passwords across affected systems. Restoring too early gets you re-compromised through the same door.

Manual disconnection buys you time, but only if someone notices fast enough. Zip Security, a Built and Managed Security Platform (BMSP) that runs tools like CrowdStrike for lean teams, triggers that same containment automatically, cutting the response from minutes to seconds.

Business Email Compromise

One email is usually all it takes. Business email compromise doesn't need malware or a stolen password, just a message convincing enough to act on, and it happened roughly 10.7 million times in Q1 2026 attacks alone.

  1. Reset the password and revoke every active session through your identity access management tooling. Revoking sessions is critical once you see signs of active compromise, and modern identity platforms can trigger this the moment risk is flagged, without waiting on a person.
  2. Audit inbox rules, forwarding settings, and newly registered MFA methods. Attackers add these to keep access. Identity and email security tools can flag or auto-revert unauthorized changes like these instead of waiting for a manual audit.
  3. If money moved, call your bank immediately to request a fund recall. File a report at ic3.gov too. Banks and law enforcement may still be able to interrupt the transfer.
  4. Check what else the account touched, including internal phishing sent, shared files accessed, and email threads hijacked.

A compromised inbox rarely stays contained to one person. Attackers use it to target vendors and customers next, which is why checking the blast radius in step 4 counts for as much as the password reset in step 1. It's also why identity, email, and endpoint controls need to hold independently of each other. Zip runs all three as layers of one defense-in-depth approach, so an account takeover gets caught even if one layer misses it.

Lost or Stolen Laptop

A lost laptop only becomes a real incident if it forces a breach notification, and that depends on what's on the device and whether the session is still live. An unlocked laptop with an active session can expose the same customer data a breach would, putting you on the same notification clock covered later in this plan.

  1. Lock or wipe the device remotely through your device management platform. Most platforms, whether Jamf, Intune, or another, can trigger this the moment a device is reported missing. Remote lock works differently on a Mac than on a phone, so document the specific steps for macOS lock and wipe in advance.
  2. Revoke sessions and rotate credentials for every account signed in on the device. Identity platforms tied to your device management system can trigger this automatically as soon as the device is marked lost or stolen.
  3. Report the theft to local police, and to the carrier if it's a phone.

Devices you can't reach remotely are the ones that turn a lost laptop into a real breach, and an unenrolled device can't be reached at all. This playbook only works with full enrollment coverage across every device, checked before a loss happens, not after.

Departing-Employee Data Theft

Employees are 83% more likely to move sensitive data in the two weeks before giving notice, exactly when oversight tends to be lowest.

  1. Review the person's file activity for the 30 days before and after notice, including mass downloads, external shares, and transfers to personal storage. DLP and monitoring tools can flag this activity automatically instead of someone pulling logs by hand.
  2. Cut all access on the departure date and rotate any shared keys or credentials the person held. Identity platforms tied to your HR system can trigger this the moment a termination date is entered, instead of relying on someone to remember.
  3. Wipe and re-enroll the device before reissuing it to anyone else.

Revoking every credential the departing employee held, immediately and everywhere, counts more than trying to recover what already left. Whatever copied out during those two weeks won't come back, but a live credential left behind can cause new damage long after the exit interview.

Know the Notification Clocks Before They Start

Most teams assume the clock starts once they've confirmed what happened, but almost every regulator disagrees. The trigger is discovery or awareness, not certainty, which means you could be several days into your notification window before you've even finished figuring out what got taken. That mismatch between what teams assume and what the law requires is where deadlines get missed.

Regime Deadline Who Gets Notified
HIPAA 60 days from discovery Affected individuals, HHS, media if 500+ residents of a state affected
GDPR (EU and UK) 72 hours from awareness, phased reporting allowed Supervisory authority
California State-specific timing and Attorney General notice triggers. Consult counsel on current requirements Individuals, California AG
SEC (public companies only) Four business days after leaders determine the incident is material, meaning significant enough to disclose to investors SEC, via Form 8-K, the public-company disclosure filing
Other U.S. states Varies widely by state Individuals, often the state AG

California doesn't give you much runway. If you have customers there, your detection-to-notification workflow has to move fast, since the state treats detection speed as a compliance requirement on top of being a security metric.

Test the Plan Twice a Year

An untested plan is a theory, and testing it doesn't have to be expensive. More than 100 free, ready-made tabletop scenarios cover common threats such as ransomware and phishing, and you can run one with only about 30 minutes of planning.

Use a maintenance rhythm a lean team can hold:

  • Tabletop exercise, twice a year. Walk one scenario against the plan each time, and add more sessions if the team has the bandwidth for it.
  • Contact list audit, quarterly. Numbers go stale fast, and a disconnected line for your outside IR firm is easy to miss until you need it. Pulling contacts from your HR or identity system instead of a static doc keeps this current automatically.
  • Backup restore drill, annually at minimum, or more often if automated monitoring handles the checking. "We have backups" means nothing until you've timed a real restore, since untested backups are not a real recovery strategy.
  • Plan update after every incident or near miss. Start the lessons-learned log within 24 hours, while details are still fresh in everyone's mind. Logging and alerting tools can auto-capture the incident timeline, so the log starts from a record instead of memory.

Skip this rhythm and nothing looks wrong, at first. Then an incident hits, and the line has gone dead or the backup won't restore, right when you needed both to work.

The Template Assumes Your Controls Work

Every playbook above depends on a technical capability working in the background. If any of these fail, the playbook breaks with it. You need:

  • EDR tools to isolate a host
  • Mobile device management (MDM) to wipe a laptop
  • Identity tooling to revoke a session
  • Centralized logging and alerting to see the problem in the first place

The plan can fail if those controls only cover part of your devices. Many companies come to Zip believing their CrowdStrike coverage is complete, when in reality it's running on well under half their devices. Nobody finds the shortfall until the isolate button doesn't exist for the machine that needed it.

Closing that shortfall before it costs you is exactly the job Zip Security does, running as the platform behind lean teams that don't have a full-time security hire. Jamf, Microsoft Intune, CrowdStrike, and Okta all run through it, set up and kept verified day to day, so the capabilities above get checked daily instead of assumed. Zip's Endpoint Security keeps the endpoint security tool healthy on every device, while 24/7 managed security operations watch the alerts your team can't be awake for.

One Observa employee clicked a malicious sponsored search result and downloaded malware disguised as legitimate software. The CrowdStrike and Managed Detection and Response (MDR) stack Zip had already deployed took over from there. It killed the process and isolated the device automatically, before anyone on the two-person team had to step in. The incident cost nothing, caused zero customer impact, and never spread past that one device, across a fleet of more than 150 endpoints.

Observa's plan worked because the response ran automatically, before anyone had to remember what to do. Write yours this week, then let Zip keep the technical layer under it true as your team, tools, and headcount change.

Request pricing from Zip to see what that coverage costs for your fleet.

Frequently Asked Questions About Incident Response Plan Template for Companies Without a Security Team

What framework should a small-company incident response plan follow?

A 2025 revision updated the leading federal incident response framework to SP 800-61 Revision 3, the current version. The older four-phase model still shows up often. It covers preparation, detection and analysis, containment and eradication, recovery, and post-incident review. A six-step version covers the same ground. Any of these frameworks works, and you can write the same steps in plainer language for a small team.

How long should the plan document be?

One page plus short playbooks. The shorter it is, the less it depends on someone reading and remembering it, and the more it relies on automated controls doing the daily work instead. Avoid multi-volume binders, even for enterprises. A few modular, threat-specific playbooks that share common functions, like communication and assessment, hold up far better under pressure than a document nobody opens.

Do we need an outside incident response firm before anything happens?

Yes. Select the firm before a compromise happens. Vetting vendors mid-attack burns the hours you need most. Put the firm's emergency phone number on the printed contact list, and document how counsel wants the firm engaged. Also decide in advance what evidence the firm will expect you to preserve.

Will enterprise customers ask to see our incident response plan?

Almost certainly. Enterprise vendor questionnaires and third-party risk frameworks treat incident response as one of the main things they check. They ask about detection, containment, evidence handling, and escalation, and some buyers require an IR policy alongside a SOC 2 report. A documented, tested plan turns that questionnaire section into a fast pass instead of a deal delay.

When do breach notification deadlines start?

Breach notification deadlines start at discovery, before your investigation finishes. HIPAA's 60-day clock starts when the incident is first known, even if it's still unclear whether the incident qualifies as a breach. GDPR's 72 hours run from awareness. Build your investigation timeline around that fact, and keep a dated log from the first alert. That way, counsel can reconstruct the timeline later.

Learn more

Questions about this article? Get in touch with our team below.

Form loads as you scroll…