Incident Response Planning When You Don't Have a Security Team

Most companies don’t have a security team. That’s not a failure. It’s a resource reality. But incidents don’t wait until you’re ready for them. A ransomware infection, a compromised database, a credential stuffing attack on your login page: these things happen to 50-person companies just as often as they happen to enterprises.

The difference is that enterprises have a playbook and a team on call. You probably don’t. So let’s build one.

Why You Need a Plan Before the Incident

When something goes wrong, people panic. That’s human. The problem is that panicking teams make bad decisions. They wipe servers before preserving evidence. They post vague messages on social media that create more questions than answers. They spend three hours arguing about whether it’s “really” an incident while the attacker moves laterally through the network.

A plan doesn’t eliminate panic. It gives panicking people a checklist to follow. That’s the whole point.

Step 1: Assign Roles, Not Titles

You don’t need a “Chief Information Security Officer” or a “Security Operations Center.” You need three people with clear responsibilities.

The Incident Commander (IC). This person makes decisions during the incident. They don’t need to be technical. They need to be calm under pressure and willing to make calls with incomplete information. Your VP of Engineering or CTO is usually the right fit. Pick a backup.

The Technical Lead. This person does the hands-on investigation and remediation. Your most senior infrastructure engineer or SRE is the right call. They need access to production systems, logging tools, and the authority to take systems offline if necessary. Pick a backup.

The Communications Lead. This person handles internal and external communication. They draft the messages to customers, coordinate with legal, and keep the rest of the company informed. This is often a founder or head of product. Pick a backup.

Three roles. Six people total (including backups). Write their names and phone numbers on a physical card and put it somewhere everyone can find it.

Step 2: Define What Counts as an Incident

This sounds obvious, but it’s where teams get stuck. Someone sees a weird log entry. Is that an incident? A customer reports they can see another customer’s data. Is that an incident? Your monitoring tool fires an alert at 2 AM. Is that an incident?

Define three levels:

SEV-1: Confirmed breach or active attack. Data has been exfiltrated, systems are compromised, or an attacker is actively in your environment. All hands on deck. Wake people up.

SEV-2: Suspected breach or significant vulnerability. You’ve found evidence that something is wrong but haven’t confirmed the scope. Examples: unusual outbound traffic, a publicly exposed database that may have been accessed, a phishing email that someone clicked. Investigate immediately during business hours. After hours, start investigation within one hour.

SEV-3: Security event that needs investigation. Failed login attempts, a vulnerability scan finding, a dependency with a known CVE. Investigate within 24 hours.

The point of these levels is not bureaucracy. It’s so your team doesn’t waste time debating whether something is “serious enough” to act on.

Step 3: The First 60 Minutes

The first hour of an incident determines everything. Here’s the playbook.

Minutes 0-10: Triage and activate. The person who discovers the issue contacts the IC. The IC makes an initial severity call (you can change it later). If it’s SEV-1 or SEV-2, the IC activates the Technical Lead and Communications Lead. Create a dedicated Slack channel or video call. Name it #incident-YYYY-MM-DD so it’s easy to find later.

Minutes 10-30: Contain and preserve. The Technical Lead’s first job is containment, not investigation. Stop the bleeding. If a server is compromised, isolate it from the network but don’t shut it down (you’ll lose volatile memory). If credentials are compromised, rotate them. If an API key is exposed, revoke it. Do not delete anything. Do not wipe logs. Do not rebuild servers yet. Preservation matters for the investigation and potentially for legal reasons.

Minutes 30-60: Assess scope and communicate. With containment in place, the Technical Lead starts scoping the impact. What systems are affected? What data was potentially exposed? How did the attacker get in? The Communications Lead drafts an initial internal message to leadership. No external communication yet unless you’re legally required (more on that below).

Keep a running log of every action taken, every decision made, and the timestamp. A shared Google Doc works fine. This log will be invaluable during the post-incident review and for any regulatory reporting.

Step 4: Communication Templates

Draft these before you need them. Editing a template under pressure is ten times easier than writing from scratch.

Internal notification (to leadership): “We’ve identified a [severity] security incident involving [brief description]. The incident team is engaged and working on containment. Current impact assessment: [what we know]. Next update in [timeframe]. Please direct all questions to [Communications Lead].”

Customer notification (if required): “We identified a security issue affecting [specific scope]. We took immediate steps to [containment actions]. Based on our investigation, [what was/wasn’t affected]. We are [ongoing steps]. If you have questions, contact [email/phone].”

Two rules for external communications. First, never say “we take security seriously.” Everyone says it and nobody believes it. Describe what you actually did. Second, never speculate about what happened. State what you know, what you don’t know, and when you’ll provide an update.

Step 5: Know When to Call for Help

There is no shame in bringing in outside help during an incident. In fact, waiting too long is one of the most expensive mistakes we see.

Bring in external incident response support if any of these are true:

• You suspect a sophisticated attacker (nation-state, organized crime)
• The breach involves regulated data (PII, HIPAA, student records, financial data)
• You’re not sure how the attacker got in and can’t determine the scope
• Your team has been working the incident for more than 12 hours and is fatigued
• You need forensic evidence preservation for potential legal proceedings

Your cyber insurance policy (you do have one, right?) likely has a list of approved incident response firms. Know who they are before the incident. Some policies require you to use their approved vendors to get coverage.

If you’re in ed-tech or handle student data, you may have a 72-hour notification window under state breach notification laws. Some states require notification within 24 hours. Know your obligations before the clock starts ticking.

Step 6: The Post-Incident Review

After the incident is resolved, hold a blameless post-incident review within one week. Not one month. One week, while memories are fresh.

Cover five questions:

1. What happened? (Timeline of events)
2. How did we detect it? (And how could we detect it faster next time?)
3. What was the impact? (Systems, data, customers affected)
4. What did we do well?
5. What specific changes will we make? (Assign owners and deadlines)

The “blameless” part matters. If your post-incident review turns into a blame session, people will start hiding incidents. That’s far more dangerous than any single breach.

Common Mistakes During Real Incidents

After helping clients through dozens of incidents, we see the same mistakes repeat.

Shutting down compromised systems immediately. This destroys volatile evidence in memory. Isolate the system from the network instead. Image the disk and capture memory before rebuilding.

Communicating too early with too little information. Sending a vague “we may have been breached” email to customers before you understand the scope creates panic and erodes trust. Take the time to understand what happened before communicating externally.

Not rotating all potentially affected credentials. Teams rotate the one credential they know was compromised and miss the other 15 that the attacker could have accessed. When in doubt, rotate everything.

Skipping the post-incident review. The incident is over, everyone is tired, and there’s a backlog of work. The review gets pushed to next week, then next month, then never. Schedule it before you close the incident.

Not updating the plan. Every incident teaches you something about your plan’s gaps. If your plan doesn’t change after an incident, you didn’t learn anything.

Start Small, Start Now

You don’t need a perfect plan. You need a plan that exists. Print out the role assignments and severity definitions. Draft the communication templates. Walk through a tabletop scenario with your team: “It’s Tuesday at 3 PM. A customer emails saying they can see another customer’s data. What do we do?”

That one-hour exercise will reveal more gaps than any consultant’s report. And when a real incident hits, your team will have muscle memory instead of blank stares.

If you want help building a plan tailored to your environment or running a tabletop exercise with your team, reach out. This is one of the first things we do with new clients, because everything else depends on it.