It starts with a message.

Or:

Or worse:

Suddenly, everyone wants to do something.

An engineer starts revoking credentials. Someone suggests shutting down production. Another person is checking logs. The founder is asking whether customers need to be notified. Someone else is trying to find the number of the company’s lawyer.

Ten minutes disappear.

And the team still hasn’t answered the most basic question:

Who is in charge?

For many startups, the most dangerous thing about the first few minutes of a security incident isn’t the attacker.

It’s improvisation.

Most startups do not have a sophisticated incident response team.

That’s understandable.

A 15-person SaaS company probably doesn’t need a security operations center running 24/7.

But it does need to know what happens when something goes wrong.

There is a dangerous assumption inside many companies:

“If something serious happens, we’ll figure it out.”

The problem is that an incident is one of the worst possible environments in which to figure things out.

You have incomplete information.

You have time pressure.

You may have customer data at risk.

You may not know whether the attacker still has access.

And decisions made in the next few minutes may affect your ability to investigate the incident later.

Preparation matters enough that NIST’s current incident-response guidance treats response as something that should be integrated into an organization’s broader risk-management activities — not invented after the incident begins.

The purpose of an incident response plan is not to predict exactly what will happen.

It is to remove unnecessary decisions from the moment when your team is least equipped to make them.

Imagine five people discovering a compromise at roughly the same time.

One revokes API credentials.

Another disconnects infrastructure.

Another resets employee accounts.

Another starts rebuilding a server.

The CEO starts preparing a message for customers.

Everyone is trying to help.

That does not mean the company is responding well.

During an incident, independent action can create a second problem: the response itself becomes chaotic.

Your first objective is therefore not:

Fix everything.

It is:

Establish control.

One incident.

One Incident Commander.

One shared record of what is happening.

One coordinated response.

Startups are biased toward action.

Normally, that’s an advantage.

During an incident, uncontrolled action can become a liability.

Before you fully understand what happened, people may:

Some of those actions may ultimately be correct.

The problem is having five people make them independently.

Someone needs to coordinate the response, track decisions and establish priorities.

That person is the Incident Commander.

They do not necessarily need to be the company’s best security engineer.

Their job is to maintain control of the incident while the specialists investigate and respond.

One incident. One commander.

Imagine discovering that a server may have been compromised.

The instinctive reaction might be:

“Destroy it and rebuild.”

But that machine may also contain information your team needs to understand:

Containment is important.

So is preserving the information necessary to understand what happened.

NIST’s current guidance explicitly emphasizes predefined containment and eradication procedures, noting that choosing actions can be faster when organizations already have criteria and procedures in place.

The principle is simple:

Contain deliberately. Preserve what matters. Then eradicate.

Security incidents create an immediate communication problem.

The founder wants to know:

Those questions matter.

But early in an incident, the company may know very little.

There is a huge difference between:

“We are investigating a potential unauthorized access event.”

and:

“Customer data was stolen.”

The second statement is a conclusion.

If you do not know that yet, do not turn uncertainty into certainty.

This does not mean hiding an incident.

Legal, contractual and regulatory notification requirements must be handled appropriately.

It means separating two activities:

Investigating what happened

from

Deciding what should be communicated externally.

When necessary, involve qualified legal, privacy and security professionals before making external statements.

The objective of the first 15 minutes is not to completely solve the incident.

It is to move the company from:

chaos → coordinated response.

Think about the first 15 minutes in four stages.

You do not need a complete forensic investigation before deciding that something deserves an incident response.

Establish three things.

Record what you actually know.

Not assumptions.

For example:

Known: An admin account logged in from an unexpected location.

Not:

Assumption: An attacker has stolen our entire customer database.

Start the timeline immediately.

Record:

You will want this timeline later.

Someone takes ownership of coordinating the response.

Everyone should know who that person is before the incident happens.

Your first objective is not to solve the incident. It is to establish control of the response.

Now ask:

What can we safely do to prevent this from getting worse?

Depending on the incident, containment may involve things such as isolating an affected system, disabling compromised access, revoking exposed credentials or limiting a risky integration.

But there is no universal button labeled:

STOP ATTACK.

Turning everything off may create unnecessary damage.

Doing nothing may allow the incident to expand.

That is precisely why containment decisions should be considered before an incident.

Your startup should already know:

During the incident, you should be executing a decision framework — not inventing one.

Now activate your call tree.

Depending on the company, that may include:

The important part is not having a list of names.

The important part is having an order.

Because this:

is not a question you want to answer during an active incident.

Phone numbers, backup contacts and escalation paths should already exist somewhere accessible.

And not exclusively inside systems that may themselves be unavailable or compromised.

By this point, your team should be moving from immediate reaction toward structured investigation.

Create two columns.

Things supported by evidence.

Questions that still need answers.

For example:

That distinction matters.

Incidents become harder when assumptions quietly turn into “facts.”

Your first situation report should answer:

That is enough to begin making better decisions.

Security incidents are rarely resolved in 15 minutes.

Major breaches can take months to identify and fully contain.

IBM’s 2025 research found a global mean of 241 days to identify and contain a breach, the lowest level reported in nine years.

The lesson is not that your startup should solve a breach in fifteen minutes.

The lesson is that you should not voluntarily waste the first fifteen.

Relative Mean Time to Resolution

≈ 50% lower MTTR

Organizations with mature incident-response capabilities have been reported to achieve roughly a 50% reduction in mean time to resolution compared with less mature response capabilities. Mature response includes more than simply owning a document — it involves workflows, tools and streamlined communication.

Takeaway:
A runbook has value only when it turns preparation into faster coordinated action.

Speed is not simply a technical metric.

It becomes a business metric.

IBM's 2022 data found that breaches with a lifecycle below 200 days averaged approximately $3.74 million, compared with approximately $4.86 million for breaches lasting longer than 200 days — a difference of roughly $1.12 million.

Again, this does not mean that a 15-minute runbook magically saves $1 million.

It demonstrates the broader relationship:

Longer exposure and slower containment tend to be more expensive.

Average Data Breach Cost — 2022

associated with the longer breach lifecycle.

Source: IBM Cost of a Data Breach research.

You don't need a 70-page cybersecurity manual.

For the first minutes of an incident, your startup needs answers to a handful of operational questions.

Name your primary Incident Commander.

And a backup.

Create an ordered call tree.

Include direct contact information.

Identify your most important systems, accounts, credentials and integrations.

Determine the safe containment options for each.

Do not discover during an incident that the engineer who knows how to isolate something is waiting for approval from somebody who is asleep.

Authority matters as much as technical ability.

Your incident may affect:

Your backup communication method should not depend entirely on the same systems.

If your security incident runbook exists only inside a Notion workspace that nobody can access, you don't have an incident runbook.

Keep an accessible offline copy.

For critical contacts and instructions, consider keeping a printed copy as well.

The best time to decide who leads an incident isn't while unauthorized access may still be active.

The best time to find your lawyer's phone number isn't after discovering a potential data breach.

The best time to decide what infrastructure can safely be isolated isn't when production is already under pressure.

And the best time to discover that only one person has access to a critical account isn't at 2:13 in the morning.

The first 15 minutes of your next security incident start today.

We built a simple resource to help you prepare them.

Define your incident commander.

Build your emergency call tree.

Map your containment priorities.

Prepare your offline access.

Then keep a first-15-minute and first-24-hour checklist ready for the day you hope never comes.

The rest of this one is for members — the full framework, plus the working file to run it on your own company. → Subscribe to keep reading