The first 72 hours of an incident, hour by hour

The phone call usually starts the same way: something looks wrong, nobody is sure how wrong, and three people are already trying to fix it in three different ways. The next 72 hours decide most of what the incident will cost. Not because the attacker is especially fast, but because the first decisions are made with the least information and the most adrenaline.

This is the timeline we work to when a client calls us. It is not a full playbook. It is the skeleton that a playbook hangs on.

Hours 0 to 4: stop guessing, start writing things down

The first job is not containment. It is getting one person in charge and one place where everything is written down.

1. Name an incident lead. One person decides; everyone else informs. In small companies this is often the CTO, which is fine, as long as they stop typing commands themselves.
2. Open a single timeline. A shared document with timestamps in UTC. Every observation, every action, every person who touched a system. You will need this for insurers, regulators and your own post-mortem.
3. Preserve before you clean. Snapshot the affected cloud instances, export the relevant logs, and copy the suspicious mailbox rules before anyone deletes them.

Hours 4 to 24: scope, then contain

Containment without scope is whack-a-mole. Before you rotate everything, answer three questions:

• Which identities are involved? Compromised accounts, tokens and API keys, including service accounts nobody remembers creating.
• Which systems did those identities reach? Your identity provider's sign-in logs and your cloud audit trail are the fastest map.
• Is there persistence? New OAuth app grants, mailbox forwarding rules, added SSH keys, new IAM users, scheduled tasks.

Once you have a first answer, contain in one coordinated move: revoke sessions, rotate the credentials in scope, block the indicators you have, and isolate the hosts. Doing it in one go matters. If you rotate one key at a time, an attacker who is watching will simply use the next one.

Hours 24 to 48: communicate before you are asked

By the second day, people outside the incident room start to notice. Customers see odd emails, staff hear rumours, and someone on the board reads about it in a chat.

Write three short messages, even if you do not send them all yet: one for staff, one for affected customers, and one for regulators or partners with contractual notification duties. Many data protection regimes have notification windows measured in days, not weeks, and the clock usually starts when you become aware, not when you finish investigating.

Hours 48 to 72: recover deliberately

Recovery is where incidents quietly restart. Systems come back with the same weak password, the same exposed admin panel, the same unpatched VPN appliance.

Before a system returns to production, check that the original entry point is closed, that monitoring is in place for the indicators you found, and that someone other than the person who rebuilt it has reviewed the change.

What to prepare this week, before any of this happens

You cannot buy back the first hours once they are gone. You can make them calmer:

• A one-page contact sheet: incident lead, deputy, legal, insurer, and your outside responders, with phone numbers that are not stored only in the systems that might be down.
• Log retention of at least 90 days on your identity provider, email and cloud audit trail.
• A practised drill. A 60-minute tabletop exercise once a quarter finds more gaps than any document review.

The companies that come through incidents well are rarely the ones with the most tools. They are the ones where, at hour two, everyone already knows who decides.