In the first hour of a suspected incident: name one lead, start a written timeline, preserve evidence before you change anything, contain the spread, and decide who must be told. Do not try to find the root cause yet. The first hour is for limiting harm and keeping options open.
Minutes 0 to 10: orient
- Name an incident lead. One person decides. Everyone else supplies information.
- Open a private channel and a shared note. Every action goes in the note with a time and a name. This becomes the timeline.
- State what you know and what you only suspect. Keep the two apart. "Alert fired on host X" is a fact. "We are being attacked by Y" is a guess.
- Rate severity. Is customer data involved, is production down, is an attacker still active?
Minutes 10 to 30: preserve and contain
Evidence first, because containment often destroys it.
- Snapshot affected machines or cloud volumes where you can.
- Export logs from identity, cloud, source control and the affected application before retention rolls them over.
- Record running processes and network connections if a host is live.
Then contain, choosing the smallest action that stops the harm:
- Disable the suspected account and revoke its sessions and tokens.
- Isolate the host from the network rather than powering it off.
- Rotate credentials that the affected system could read.
- Block the specific indicators you have, such as an address or a malicious package version.
Avoid wiping and reinstalling yet. You will want to know how the attacker got in.
Minutes 30 to 60: widen and decide
- Check whether the same account, key or package appears elsewhere. Search across your estate, not just the first machine.
- Identify what data the affected systems hold.
- Decide who must be informed: leadership, legal, your insurer, affected customers or regulators. Notification duties and deadlines depend on your jurisdiction and contracts, so name the person who will check them. Do not guess.
- Set the next update time, for example every 30 minutes.
What not to do
Do not delete logs. Do not confront a suspected insider alone. Do not post speculation in public channels. Do not pay or reply to an extortion message before leadership and advisors decide.
Afterwards
Within a few days, write a short review: timeline, root cause, what worked, what slowed you down, and actions with owners. Practising this checklist in a tabletop session once a year finds gaps cheaply.
Practice makes this list usable. Print it, put it in the place the team will look at three in the morning, and run a short tabletop once a year with a made up scenario. Check that the contact numbers work, that the lead knows they are the lead, and that people can reach the log systems without the very accounts that might be compromised.
Quick check
Should we shut the system down?
Usually isolate, not power off. Powering off loses memory contents and can lose evidence. If data is actively leaving and you cannot isolate, a shutdown can be the right call.
Who is the lead if the security person is the suspect?
Pick an alternate in advance, such as the head of engineering, and write it in your plan.
Last reviewed: 19 October 2026.
