Incident Response for Startups: The Playbook for When Things Go Wrong

It is 2 AM on a Tuesday. Your monitoring tool fires an alert you have never seen before. A customer tweets that they can see another customer's data. Your CTO texts the Slack channel: "We might have a problem." In the next four hours, every decision you make will determine whether this is a rough week or the end of your company.

Most startups have no plan for this moment. According to the Ponemon Institute's 2024 Cyber Resilient Organization study, 77% of organizations do not have a consistently applied incident response plan, and for startups with fewer than 50 employees that number is closer to 95%.^[1] When a breach happens, these teams improvise. They panic. They make mistakes that compound the damage far beyond the original vulnerability.

This article is the incident response playbook we build with our startup clients. It is not the 200-page NIST framework document designed for Fortune 500 companies. It is a practical, opinionated guide for a 10-to-50-person company that needs to survive a security incident without imploding. If you have not built your security foundations yet, start there. But even the most prepared startups eventually face an incident. This is how you handle it.

Why most startups have no incident response plan

The excuses are always the same. "We're too small to be a target." "We'll figure it out if it happens." "We don't have time to plan for hypotheticals when we're trying to hit our quarterly numbers." Every single startup that has come to us mid-breach has said some version of these sentences in the months before the incident.

The reality is that startups are disproportionately targeted precisely because attackers know they lack defenses. Verizon's 2024 Data Breach Investigations Report found that 43% of cyberattacks target small businesses, yet only 14% of those businesses consider themselves prepared to defend against an attack.^[2] Startups are especially attractive targets because they often handle valuable data (customer PII, payment information, proprietary IP) while operating with minimal security infrastructure.

The cost of not having a plan is not abstract. IBM's 2024 Cost of a Data Breach Report found that organizations with an incident response team and regularly tested IR plans saved an average of $2.66 million per breach compared to those without.^[3] For a startup burning $200K per month, an uncontrolled breach can mean the difference between surviving to your next funding round and shutting down.

The incident response lifecycle

The NIST Cybersecurity Framework defines six phases of incident response. This structure works regardless of your company size, and it gives your team a shared mental model for what happens when an incident occurs. Here is what each phase looks like for a startup.

Phase 1: Preparation

This is everything you do before an incident happens. It is the phase that determines whether the remaining five phases go smoothly or devolve into chaos. For a startup, preparation does not require months of work. It requires deliberate decisions about a few critical things.

One detail that trips up nearly every startup we work with: your incident communication channel must be separate from your production infrastructure. If an attacker has access to your AWS account, they may also have access to your Slack workspace if it is integrated with SSO. A pre-established Signal group with your incident team's personal phone numbers solves this.

Phase 2: Detection and analysis

Detection is the moment you realize something is wrong. In startups, this often comes from an unexpected source: a customer complaint, a journalist's email, an anomalous cloud bill, or a strange entry in your logs that a developer notices during an unrelated investigation.

The critical task during detection is triage. Not every alert is a breach. Not every anomaly is malicious. Your incident commander needs to quickly assess three things:

1. Is this actually a security incident? A spike in 404 errors is different from unauthorized access to your database. Classify it before you escalate.
2. What is the scope? Is this one compromised account, one exposed endpoint, or a full infrastructure compromise? The scope determines everything that follows.
3. What data is potentially affected? Customer PII, payment data, health records, and proprietary business data each carry different regulatory obligations and response requirements.

Document everything from the moment you suspect an incident. Timestamps, who noticed what, what systems were accessed, what actions were taken. This documentation becomes critical for legal compliance, insurance claims, and post-incident analysis. Use a shared document or a dedicated incident channel, not scattered DMs.

Phase 3: Containment

Containment is where the most consequential mistakes happen. The instinct is to shut everything down immediately, wipe the compromised system, change every password, and restore from backup. That instinct is wrong. Premature containment destroys the evidence you need to understand what happened, and it can actually alert the attacker that you are onto them, causing them to escalate or cover their tracks.

There are two types of containment, and you need both:

Short-term containment stops the bleeding without destroying evidence. This might mean isolating a compromised server from the network (but not wiping it), revoking specific API keys or access tokens, blocking a malicious IP address, or disabling a compromised user account. The goal is to stop the active damage while preserving the forensic state.

Long-term containment involves building a clean parallel environment while you investigate the compromised one. Spin up new instances from known-good backups, rotate all credentials, and prepare to migrate traffic. This lets you restore service without destroying the evidence on the compromised systems.

Phase 4: Eradication

Once you understand how the attacker got in and what they did, you can remove the threat. Eradication means eliminating the root cause of the incident, not just the symptoms. If the attacker exploited a SQL injection vulnerability, patching that single endpoint is not eradication. You need to verify that the same vulnerability class does not exist elsewhere in your codebase.

Eradication typically involves:

• Patching the vulnerability that was exploited
• Removing any backdoors, malware, or persistence mechanisms the attacker installed
• Rotating all credentials that may have been exposed, including API keys, database passwords, SSH keys, and service account tokens
• Revoking and reissuing all user sessions
• Reviewing code changes made during the window of compromise for unauthorized modifications

Phase 5: Recovery

Recovery is bringing your systems back to normal operations. This is not just "flip the switch back on." It requires a deliberate process:

1. Restore from verified clean backups rather than trying to clean a compromised production environment in place.
2. Monitor closely for signs of re-compromise in the hours and days following restoration. Attackers often maintain multiple access points, and the one you found may not be the only one.
3. Gradually restore access starting with your core team and expanding outward. Do not re-enable all user access simultaneously.
4. Verify data integrity by comparing recovered data against known-good snapshots. If the attacker had write access to your database, you need to confirm they did not modify records.

Phase 6: Lessons learned

This is the phase that everyone skips and the phase that matters most for your long-term survival. Within one to two weeks of resolving the incident, conduct a blameless post-mortem with everyone involved. The goal is not to assign fault. The goal is to understand what happened, why your defenses failed, and what you are going to change.

Your post-mortem should produce three deliverables: a detailed incident timeline, a root cause analysis that goes beyond the immediate vulnerability to the systemic factors that allowed it, and a prioritized list of improvements with owners and deadlines. If the post-mortem does not result in concrete changes to your security posture, it was a waste of time.

Building a lightweight IR plan for a 10-to-50-person company

Your incident response plan does not need to be a 50-page document. For a startup, a plan that nobody reads is worse than no plan at all because it creates a false sense of preparedness. Your IR plan should fit on a few pages and cover five things:

Store this document somewhere accessible that is not dependent on your production infrastructure. A printed copy in your incident commander's desk drawer is old-fashioned but effective. A shared document in a personal Google Drive (not your corporate workspace) works too. The point is that when your AWS account is compromised, you can still access your plan.

Who to call: your incident response contacts

During an incident, you need outside help. The question is whether you have identified and vetted those resources before the crisis or whether you are Googling "data breach lawyer" at 3 AM. Here is who should be on your contact list and why.

Legal counsel

You need a lawyer who specializes in cybersecurity and data privacy, not your general startup counsel who handles your cap table. Breach response involves complex regulatory obligations that vary by jurisdiction, data type, and industry. Your lawyer will advise on notification requirements, help you navigate regulatory interactions, and protect sensitive communications under attorney-client privilege.

If you engage outside counsel to direct the forensic investigation, the work product may be protected by privilege. This is significant because anything your internal team documents during the investigation could potentially be discoverable in litigation. Your lawyer should be the first call after your incident commander, not an afterthought.

Digital forensics and incident response (DFIR) firm

Unless your startup has a dedicated security team (most do not), you need outside forensic expertise to investigate a serious incident. A DFIR firm can determine how the attacker got in, what they accessed, whether they exfiltrated data, and whether the threat has been fully eliminated. Many cyber insurance policies include pre-approved DFIR vendors, so check your policy.

Cyber insurance carrier

Notify your insurance carrier as early as possible. Most cyber insurance policies have specific notification windows and procedures that must be followed for coverage to apply. Your carrier may also provide access to their panel of approved vendors for legal, forensics, and crisis communications at pre-negotiated rates.

PR and communications

If your breach involves customer data, you will need to communicate publicly. A crisis communications professional can help you craft messaging that is transparent, legally appropriate, and does not make the situation worse. Many startups skip this and write their own breach notification. The result is usually a message that is either so vague it damages trust or so detailed it creates additional legal exposure.

Regulators

Depending on what data was compromised and where your users are located, you may have mandatory notification obligations to one or more regulatory bodies. These are not optional. Late or missed notifications carry their own penalties on top of the breach itself. We cover specific requirements in the regulatory section below.

The first 24 hours: a step-by-step decision tree

When an incident is confirmed, the first 24 hours set the trajectory for everything that follows. Here is the decision tree we walk through with our clients.

Hour 0-1: Confirm and classify

1. Verify that the incident is real. False positives happen. A customer reporting a bug is different from a customer reporting they can see another customer's data.
2. Activate your incident commander. This person now owns all decisions.
3. Establish your out-of-band communication channel (Signal group, phone bridge).
4. Classify severity: Is this a data exposure (someone could see data they should not), a data breach (data was actually accessed or exfiltrated by an unauthorized party), or an active compromise (the attacker is still in your environment)?
5. Begin documentation. Start a shared incident log with timestamps for every action and decision.

Hour 1-4: Contain and investigate

1. Implement short-term containment. Isolate affected systems without destroying evidence.
2. Preserve evidence. Snapshot affected instances, export logs, capture any volatile data.
3. Contact legal counsel. Brief them on what you know so far. Follow their guidance on privilege.
4. Notify your cyber insurance carrier if you have a policy.
5. Begin scoping: What systems are affected? What data is potentially exposed? How many users are impacted?

Hour 4-12: Assess and plan

1. Engage DFIR resources if the incident warrants it (any confirmed data breach or active compromise does).
2. Determine the attack vector. How did the attacker get in? Is the vulnerability still exploitable?
3. Assess data impact. What specific records were accessed? Can you determine if data was exfiltrated?
4. Draft internal communication for your broader team. People will notice something is happening. Control the narrative before rumors fill the vacuum.
5. Begin planning your eradication and recovery steps.

Hour 12-24: Communicate and remediate

1. Brief your executive team and board (if applicable) with facts, not speculation.
2. Determine regulatory notification obligations based on the data involved and affected jurisdictions.
3. Begin eradication: patch the vulnerability, rotate credentials, remove attacker access.
4. Prepare customer communication if notification is required or if the incident is likely to become public.
5. Plan your recovery timeline and communicate it internally.

Containment strategies that do not destroy evidence

The single most common mistake we see during incident response is premature eradication. A panicking engineer wipes the compromised server, reimages the machine, and restores from backup. The immediate threat is gone, but so is every piece of evidence that could tell you what the attacker did, what data they accessed, and whether they left other backdoors in your environment.

Here are containment strategies that stop the damage while preserving the evidence:

A useful analogy: treat a compromised system like a crime scene. You would not demolish a building to stop a robbery in progress. You would secure the perimeter, prevent the robber from leaving, and call in investigators. The same principle applies to your infrastructure.

Communication templates

Writing clear, accurate communications under the pressure of an active incident is extremely difficult. Having pre-drafted templates that you can adapt saves time and reduces the risk of saying something that creates legal exposure or damages trust unnecessarily. Here are the four communications you should have ready.

Internal team notification

Your team will notice something is happening. Engineers will see unusual activity. Customer support will start getting questions. If you do not control the narrative internally, rumors and speculation will fill the gap.

Customer notification

If customer data is involved, you will need to notify affected users. This notification should be reviewed by your legal counsel before it goes out. The template below is a starting point.

Regulatory notification

Regulatory notifications have specific requirements that vary by jurisdiction. Your legal counsel should draft the final version, but having a template with the required elements accelerates the process. Most regulatory notifications require: a description of the incident, the types of data involved, the number of affected individuals, the measures taken to address the incident, and contact information for further inquiries.

Press statement

If your breach becomes public (through customer reports, social media, or journalist inquiries), you need a press statement. This should be brief, factual, and written with legal review.

Regulatory notification requirements by framework

Notification deadlines are legal obligations, not suggestions. Missing a deadline can result in fines that dwarf the cost of the breach itself. Here are the major frameworks and their requirements.

GDPR (EU/EEA users)

If you have users in the European Union or European Economic Area, GDPR applies to you regardless of where your company is based. You must notify your lead supervisory authority within 72 hours of becoming aware of a breach involving personal data. If the breach poses a high risk to individuals, you must also notify the affected individuals "without undue delay." Fines for non-compliance can reach 4% of annual global turnover or 20 million euros, whichever is greater.^[4]

HIPAA (health data)

If you handle protected health information (PHI) in the United States, HIPAA requires notification to affected individuals within 60 days of discovering the breach. If the breach affects more than 500 individuals, you must also notify the Department of Health and Human Services (HHS) and prominent media outlets in the affected jurisdiction within the same 60-day window. Breaches affecting fewer than 500 individuals can be reported to HHS annually.^[5]

US state breach notification laws

All 50 US states have breach notification laws, and they vary significantly. Most require notification within 30 to 60 days, but some states have shorter windows. California's CCPA requires notification "in the most expedient time possible and without unreasonable delay." Some states require notification to the state attorney general in addition to affected individuals. If you operate across multiple states, you are subject to the most stringent applicable law.

SEC requirements (if applicable)

If your startup has gone public or has certain SEC reporting obligations, the SEC's 2023 cybersecurity disclosure rules require disclosure of material cybersecurity incidents within four business days of determining materiality. While most startups are not subject to SEC rules, if you have investors with reporting obligations, this may still affect your timeline.

PCI DSS (payment card data)

If you process, store, or transmit payment card data and experience a breach involving that data, you must notify your acquiring bank and the relevant card brands (Visa, Mastercard, etc.) immediately. The card brands may require a forensic investigation by an approved PCI Forensic Investigator. Using a payment processor like Stripe reduces your PCI scope significantly, but if you handle card data directly, these obligations apply in full.

Post-incident: root cause analysis and security improvements

A breach that does not result in meaningful security improvements is a wasted crisis. The post-incident phase is where you transform the pain of an incident into lasting organizational resilience. This is not a blame exercise. It is a learning exercise.

Conducting a blameless post-mortem

Schedule the post-mortem within one to two weeks of resolving the incident, while details are still fresh. Include everyone who was involved in the response. The agenda should cover:

1. Incident timeline - reconstruct exactly what happened, when, and in what order. Use your incident log as the source of truth.
2. Root cause analysis - go beyond the immediate vulnerability. Ask "why" five times. The SQL injection was the proximate cause, but the root cause might be that your code review process does not include security checks, or that your developers lack security training, or that you do not have automated scanning in your CI/CD pipeline.
3. Response evaluation - what went well during the response? What went poorly? Where did the plan break down? Were the right people available? Did communications go smoothly?
4. Improvement actions - generate a prioritized list of changes with assigned owners and deadlines. These should address both the specific vulnerability and the systemic factors that allowed it.

Translating lessons into action

Common post-incident improvements include:

• Implementing automated security scanning in the CI/CD pipeline
• Adding monitoring and alerting for the attack patterns observed during the incident
• Conducting a broader vulnerability assessment or penetration test to find similar issues before attackers do
• Updating access controls and authentication mechanisms based on what the investigation revealed
• Enhancing logging to cover gaps identified during the forensic analysis
• Revising the incident response plan based on what worked and what did not

If you are an early-stage startup, a breach is often the forcing function that transforms security from "something we will get to" into an actual organizational priority. Use that momentum. The improvements you make in the 90 days after an incident will define your security posture for the next several years.

Cyber insurance: what it covers and what it does not

Cyber insurance is not a substitute for security. It is a financial safety net for when security fails. Understanding what your policy actually covers (and what it excludes) is critical before you need to file a claim.

What cyber insurance typically covers

• Forensic investigation costs - the DFIR firm that investigates your breach, often the largest single expense
• Legal fees - breach counsel, regulatory response, and defense against lawsuits
• Notification costs - the expense of notifying affected individuals, including credit monitoring services
• Business interruption - lost revenue during the period your systems are down
• Ransom payments - some policies cover ransomware payments, though this is increasingly controversial and may require pre-approval
• Crisis communications -PR and communications support during and after the incident
• Regulatory fines and penalties - coverage varies significantly by policy and jurisdiction

What cyber insurance typically does not cover

• Pre-existing vulnerabilities - if the insurer determines you knew about the vulnerability before the policy was in effect, the claim may be denied
• Failure to maintain minimum security standards - most policies require basic security hygiene (MFA, patching, backups); failure to maintain these can void coverage
• Reputational damage - the long-term brand impact and lost future business are generally not covered
• Cost of security improvements - the upgrades you implement after the breach to prevent recurrence are your expense
• Intellectual property theft - the value of stolen trade secrets or proprietary code is difficult to quantify and often excluded
• Social engineering losses - some policies exclude losses from phishing or business email compromise unless you have specific endorsements

For a startup, cyber insurance premiums typically range from $1,500 to $5,000 per year for $1 million to $2 million in coverage. The application process itself is useful because the questionnaire forces you to assess your security posture honestly. If you cannot truthfully answer "yes" to the baseline security questions (MFA enabled, backups in place, patching current), address those gaps before applying.

Tabletop exercises: practicing your response before you need it

A plan that has never been tested is a hypothesis, not a plan. Tabletop exercises are the most efficient way to test your incident response plan without the pressure and consequences of an actual breach.

A tabletop exercise is a facilitated discussion where your team walks through a realistic incident scenario step by step. There is no hands-on-keyboard activity. It is a discussion exercise designed to surface gaps in your plan, confusion about roles, and assumptions that do not hold up under pressure.

Running a tabletop exercise

1. Choose a realistic scenario. Base it on threats that are actually relevant to your business. If you are a SaaS startup, a customer data breach scenario is more useful than a nation-state APT scenario. Good starter scenarios include: a developer laptop stolen with production database credentials, a customer reports they can access another customer's data, your cloud provider notifies you of unauthorized access to your account, or a ransomware attack encrypts your production database.
2. Gather the right people. Include your incident commander, lead engineers, your CEO, and whoever handles customer communications. This should not be a security team exercise. Everyone who would be involved in a real incident should participate.
3. Walk through the scenario in stages. Present the initial alert, then reveal new information every 15 to 20 minutes that changes the situation. This simulates how real incidents unfold with incomplete and evolving information.
4. Ask hard questions at each stage. Who makes this decision? Who do we call? What do we tell customers? What if the backup is also compromised? What if the attacker is still in the environment? What if a journalist contacts us before we are ready to go public?
5. Document gaps and action items. The value of the exercise is in the gaps it surfaces. Every "I'm not sure" or "we don't have a process for that" is a finding that needs to be addressed.

Run a tabletop exercise at least twice a year. It takes two to three hours and costs nothing beyond the time of the people in the room. The first time you run one, you will be surprised at how many assumptions fall apart when you actually walk through the scenario.

Common mistakes during incident response

We have been involved in enough incident response engagements to see the same mistakes repeated across different organizations. Here are the most damaging ones and how to avoid them.

Destroying evidence

This is the number one mistake. A well-meaning engineer wipes the compromised server, reimages the machine, or restores from backup before anyone has captured forensic evidence. Once the evidence is gone, you may never know what the attacker accessed, whether they exfiltrated data, or whether they left other backdoors. This makes it impossible to accurately scope the breach, which in turn makes it impossible to determine your notification obligations.

Premature communication

The pressure to communicate quickly is intense, especially if customers or the press are asking questions. But communicating before you understand the scope of the incident creates two risks. First, you may understate the severity and have to issue embarrassing corrections later, which damages credibility. Second, you may overstate the severity and cause unnecessary panic among customers and investors. Wait until you have confirmed facts before communicating externally. "We are investigating an incident and will provide more information shortly" is an acceptable holding statement.

Scope creep

During an incident, there is a temptation to investigate every anomaly and fix every security issue you discover. This is not the time for a comprehensive security overhaul. Stay focused on understanding and resolving the specific incident. Document other issues you discover for post-incident follow-up, but do not let them distract from containing and eradicating the active threat.

Not involving legal early enough

Legal counsel should be involved from the first hour. Attorneys do not just advise on notification requirements. They establish attorney-client privilege over the investigation, guide communications to reduce legal exposure, and coordinate with insurance carriers and regulators. Every hour of investigation conducted without legal involvement is an hour of unprotected documentation.

Single-threaded response

Having one person try to handle investigation, containment, communication, and legal coordination simultaneously is a recipe for failure. Even in a small startup, divide responsibilities. The incident commander coordinates overall. One person handles the technical investigation. Another handles communications. Another coordinates with legal and insurance. These can be part-time roles drawn from your existing team, but they need to be explicitly assigned.

Failing to learn

Skipping the post-mortem is the final common mistake. The incident is over, everyone is exhausted, and the temptation is to move on. But if you do not conduct a thorough post-mortem and implement the resulting improvements, you are likely to face a similar incident again. The breach is the tuition. The post-mortem is the education. Do not pay the tuition without getting the education.

Your incident response readiness checklist

Here is a summary checklist you can use to assess your current IR readiness. If you can check all of these boxes, you are better prepared than the vast majority of startups.

Moving from reactive to prepared

The difference between a startup that survives a security incident and one that does not is rarely the severity of the breach. It is the quality of the response. Companies with tested incident response plans, pre-established relationships with legal and forensic partners, and a team that has practiced for this moment consistently emerge from incidents with their business and reputation intact.

You do not need a massive budget or a dedicated security team to build incident response readiness. You need a few hours to write your plan, an afternoon to run a tabletop exercise, and the discipline to treat preparation as a priority rather than something you will get to next quarter. The best time to prepare for a breach was a year ago. The second best time is today.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.