You Have Been Breached. The First 24 Hours.

It arrives as a message from a customer, an alert from a cloud provider, a ransom note on a screen, or a journalist's email. However it arrives, the first reaction is the same: a spike of adrenaline and a strong urge to do something. The companies that recover well are the ones that do the right somethings, in roughly the right order, and write them down as they go.

This is the plan I give to founders. It assumes you do not have a security team; you have a few capable people and a phone.

Hour 0: assemble and decide who decides

Three roles, which can be three people or one person wearing three hats:

Incident lead — makes decisions, keeps the log. Usually a founder or CTO.
Technical lead — investigates and contains.
Communications lead — handles customers, staff, regulators and press.

Open a channel that the attacker cannot read. If your email may be compromised, that means a phone call or a fresh chat workspace, not the company Slack. Start a timeline document: every action, every finding, with a timestamp. This is the most valuable artefact of the entire incident — for the investigation, for regulators, for insurance, and for your own memory.

Hours 0–2: contain without destroying evidence

The instinct is to wipe the affected machine and reset everything. Resist it for a moment: you need to know what happened to know whether it is over.

Isolate, do not erase. Disconnect affected machines from the network; take a snapshot of affected cloud servers before touching them. Keep the ransom note. Keep the phishing email.
Cut the attacker's access. Rotate the credentials you know are involved and force sign-out everywhere: the compromised account, the cloud console, API keys, service accounts. If in doubt about which, rotate the admin ones.
Block the obvious. Remove mail-forwarding rules, revoke unfamiliar OAuth apps, disable unknown users, close firewall rules that should not be open.
Preserve logs. Make sure audit logs, cloud trails and application logs are not about to roll over or be deleted; export them somewhere safe.

If ransomware is actively encrypting, isolation comes first and fast — power off or disconnect everything that is still clean, then think.

Hours 2–6: understand the scope

Now the technical lead answers four questions, as honestly as the evidence allows:

How did they get in? Phishing, a leaked key, an unpatched system, a vendor.
What did they reach? Which systems, which accounts, which data stores.
What did they take or change? Look at outbound traffic, download logs, unusual queries, new users, altered records.
Is it over? Are there persistence mechanisms — new accounts, scheduled tasks, backdoor keys, a second compromised identity?

If the answer to any of these is "we can't tell", say so in the log. This is the point to call for help: your cloud provider's support, an incident-response firm, your cyber-insurer's hotline if you have a policy — most policies require you to call before engaging anyone else.

Hours 4–8: work out who you must tell, and by when

Breach notification is a legal obligation in most jurisdictions, and the clocks start now.

GDPR (if you have EU/UK customers): notify the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals; tell the individuals themselves "without undue delay" if the risk is high.
Qatar's PDPPL (Law No. 13 of 2016): controllers must notify the regulator and the affected individuals of a breach that could cause serious harm to their personal data or privacy. Check the current guidance for timing; do not wait for certainty.
Payment card data: your acquirer and card brands have their own rules (PCI DSS) and short timelines.
Contracts: your customers' contracts may require notification within a set number of hours. The vendor list you built for third-party risk is where you find out which.

You do not need every fact to notify; regulators expect an initial notice followed by updates. A late, complete report is worse than an early, honest one.

Hours 8–16: communicate

Staff first. Tell the team what happened in plain terms, what to do (reset passwords, watch for phishing, do not talk to press), and where to send questions.

Customers next, if their data or service was affected. The message that works is short and human: what happened, what data was involved, what you have done, what they should do, and how to reach you. Do not speculate, do not minimise, do not blame. Draft it before you need it — a template written in calm conditions reads far better than one written at 3 a.m.

Everyone else: press and social media get the same facts as customers, through one spokesperson. Do not let individual employees improvise.

Hours 16–24: recover deliberately

Only after you understand how the attacker got in do you rebuild — otherwise you restore the door with the lock still broken.

Rebuild affected systems from clean images and known-good backups; do not "clean" a compromised machine and put it back.
Rotate every credential that the compromised system or account could reach, not just the ones you saw used.
Patch the entry point. Close the vulnerability, remove the leaked key, enforce the two-factor that was missing.
Bring systems back one at a time, watching the logs for the attacker's return.

Then everyone sleeps, because day two is longer than it looks.

What not to do

Do not pay a ransom on day one. Talk to law enforcement and your insurer first; understand what backups you have.
Do not contact the attacker yourself.
Do not post on social media before you know what happened.
Do not delete evidence to make things look tidier.
Do not blame the person who clicked. You will need their honest account, and the next person needs to know it is safe to report.

After: the review that makes the next one smaller

Within two weeks, hold a blameless review: timeline, root cause, what worked, what did not, and a short list of changes with owners and dates. Most of those changes will be boring — two-factor everywhere, backups tested, logs kept longer, a vendor's access reduced. Boring is what prevents the sequel.

Print this plan. Put the three names on it. The day you need it is not the day to be searching for it.