Incident Response for Startups: What to Do in the First 60 Minutes After a Breach

Nobody wants to think about a security incident until they’re in the middle of one.

That’s the problem.

Because when a breach happens — or is suspected — the first 60 minutes are the most important. The decisions made in that window determine whether the incident is contained and managed professionally, or whether it becomes a chaotic, expensive, reputational crisis.

This post is your starting framework. Not a comprehensive incident response programme — that takes more than a blog post to build. But a clear picture of what needs to happen in the first hour and why it matters.

The Trigger: How Incidents Usually Start

Security incidents rarely start with a dramatic announcement. They usually start with something ambiguous:
– An employee reports that their account “seems to be acting strangely”
– A monitoring alert fires that nobody’s sure how to interpret
– A customer reports they’ve received a suspicious email that appears to be from your domain
– Someone notices an unusual login in the Google Workspace activity log
– A 3am phone call from a team member who can’t log in to a critical system

The first task is to determine: is this a real incident, or a false alarm?
This determination needs to happen fast — but not so fast that you act on bad information.

The First 60 Minutes: A Framework

Minutes 0-10: Establish facts

Before doing anything else, gather the basic facts:
– What exactly was noticed, and when?
– Which systems are potentially affected?
– Who first noticed the issue, and what did they observe?
– Is the issue still ongoing?

Do not shut anything down yet. Do not revoke any access yet. Preserve the evidence and understand the situation before taking action.

Minutes 10-20: Notify the right people

Who needs to know right now?

This should be pre-defined in your incident response plan, but if you don’t have one:
– The CEO or most senior leader available
– Your legal counsel or data protection officer (especially if personal data may be involved)
– Your IT lead or fractional IT consultant
– Potentially your CISO if you have one

Don’t notify the whole company. Don’t post in Slack. Keep the circle small until you understand what’s happening.

Minutes 20-35: Contain the incident
Once you understand what’s happening, act to stop it from getting worse.

Depending on the nature of the incident:
– Suspend compromised accounts
– Revoke active sessions
– Rotate compromised credentials
– Isolate affected systems from the network
– Preserve logs before they are overwritten

The goal at this stage is containment — not remediation. Stop the bleeding. Full investigation and recovery come later.

Minutes 35-50: Assess scope
What has been accessed or affected?
– Which accounts were compromised?
– Which systems were accessed?
– What data was potentially exposed?
– Is the incident contained, or is it ongoing?

This assessment drives your notification obligations. Under GDPR, if personal data has been compromised, you have a 72-hour window to notify your supervisory authority. You need enough information to make that determination.

Minutes 50-60: Document everything

From this point forward, everything should be documented. Every action taken. Every decision made. Every log reviewed. Every person involved.

This documentation serves multiple purposes: it helps you understand the timeline of the incident, it supports your GDPR notification if required, it provides evidence if legal action becomes relevant, and it supports the post-incident review.

What You Need Before the Incident Happens

The 60-minute framework above only works if certain things are already in place.

Contact list: You need to know who to call and how to reach them — without searching through Slack or email. Phone numbers. Out-of-hours contacts. Legal counsel details.

System inventory: You need to know what systems exist and who owns them. You can’t assess the scope of an incident if you don’t know what your systems are.

Access to logs: You need to be able to access system logs, identity provider activity, and cloud access records. If you don’t know where these are, you can’t investigate.

Authority to act: Someone needs to be designated with the authority to make decisions quickly — to suspend accounts, shut down systems, notify customers — without waiting for a committee to convene.

GDPR contacts: If you’re a UK or EU company, you need your ICO or supervisory authority contact details ready. The 72-hour clock starts from when you become aware of a breach, not when you’ve finished investigating it.

The Post-Incident Review

After the immediate crisis is managed, a post-incident review is essential.

What happened? How was it detected? How long had it been happening before detection? What did we do well? What should we have done differently? What needs to change to prevent recurrence?

The review is not a blame exercise. It’s a learning exercise. And it’s how incidents become the catalyst for better security practice, rather than just a stressful memory.

If your company doesn’t have an incident response plan, the free assessment at itops.zlefterov.com will show you where to start. And if you want help building one, that’s a core part of what I do with clients at zlefterov.com.

Leave a Comment

Your email address will not be published. Required fields are marked *