TutorialUpdated 6 min read

Incident first-hour checklist

A practical first sixty minutes for scoping an incident, stopping active harm, preserving evidence, securing identity, and giving leadership facts instead of guesses.

The first hour of a suspected cyber incident is not the time to prove who did it. It is the time to establish command, stop obvious ongoing damage, preserve what you will need to understand the event, and create a reliable record of decisions.

Not every alert is a breach. Treat the situation seriously without upgrading guesses into facts.

This checklist aligns with NIST SP 800-61 Revision 3, the current NIST incident-response guidance. Adapt it to your approved response plan, contracts, and applicable requirements.

Minute 0-10: establish control

Name an incident lead. One person coordinates priorities and approves disruptive actions. Technical responders can investigate; leadership can manage business decisions. Without a lead, five well-meaning people reset the same account and nobody records when it happened.

Open a timeline. Record the time, time zone, reporter, symptoms, affected user or system, and every action taken. Preserve original timestamps. Use a shared response record that the suspected attacker cannot access.

Choose a safe communication channel. If email, Teams, or the identity tenant may be compromised, coordinate by phone or another known-clean, out-of-band channel. Do not announce containment in a mailbox the attacker may be reading.

Define the immediate safety issue. Ask whether encryption is spreading, money is moving, a public service is being abused, or sensitive data is actively leaving. Those answers determine what cannot wait.

Minute 10-20: scope without trampling evidence

Capture the initial alert, screenshot, email with full headers, EDR detection, user report, source address, account, hostname, and observed behavior. Export short-retention cloud and security logs when practical. Note where each item came from and preserve the original.

Build three lists:

  • Confirmed affected: direct evidence of unauthorized activity
  • Suspected: related systems, identities, or sessions needing review
  • Critical but not currently affected: services that must be protected and monitored

Do not run broad cleanup tools, delete messages, reimage endpoints, or browse through suspicious files from a privileged workstation. Investigation should reduce uncertainty, not create new access paths.

Check identity and endpoint telemetry from a known-clean administrative device. For Microsoft environments, the habits in five weekly Entra sign-in checks provide a useful starting vocabulary, but an active incident requires a wider time range and coordinated review.

Minute 20-35: contain the active path

Containment changes the environment. It may also change or destroy evidence. Choose the smallest action that reliably stops current harm, record it, and keep the business impact visible.

For active malware or ransomware: isolate affected endpoints from the network through EDR, a switch port, or by disconnecting Ethernet and Wi-Fi. CISA’s ransomware response checklist recommends immediate isolation. It also warns that powering down destroys volatile evidence and should be used when disconnection is not otherwise possible and spread must be stopped.

For an identity compromise: revoke active sessions or tokens, disable the account when needed, reset credentials through a known-clean path, and remove unauthorized MFA methods or app consent. Preserve sign-in, audit, mailbox, and identity-provider logs first when that can be done without prolonging active access. Review privileged and break-glass accounts separately; do not lock out the only recovery path.

For a leaked API key or secret: revoke or rotate it, identify where it was used, and search logs for use before and after the suspected disclosure. Replacing the string without finding deployed copies invites a second outage.

For fraudulent payment instructions: contact the originating financial institution immediately using a known telephone number and request recall or reversal. The FBI’s IC3 BEC guidance stresses speed. Do not continue the conversation using contact details from the suspicious message.

If several systems are encrypting or the affected path is unclear, broader network isolation may be necessary. That decision belongs to the incident lead with explicit awareness of safety and operational consequences.

Minute 35-45: preserve evidence deliberately

Evidence preservation is not the same as leaving an attacker connected. Contain first when active harm is occurring, then preserve the best available state.

Collect what your team is qualified and authorized to collect:

  • EDR alerts and process trees
  • Relevant Windows, firewall, DNS, VPN, email, identity, and cloud audit logs
  • Full message headers and original suspicious files without opening them
  • Hostname, logged-in user, IP and MAC addresses, serial number, and physical location
  • Photos of ransom notes or on-screen errors
  • Copies or snapshots of affected virtual and cloud systems when your platform supports them

Memory capture and forensic imaging can be valuable, but a first responder should not improvise them on critical systems. Engage a qualified incident-response provider when evidence quality matters. Record who collected each item, when, where it is stored, and any transfers. Never edit the only copy.

Minute 45-55: activate the right contacts

Use the approved plan to engage internal IT, the MSP or incident-response provider, leadership, and relevant system owners. Depending on known facts and your obligations, that may also include legal/privacy counsel, the cyber insurer’s designated response channel, sector partners, regulators, or law enforcement.

Do not promise that insurance will cover a service, that a notification is or is not required, or that the event is contained before evidence supports it. Policy terms, contracts, laws, jurisdictions, and incident facts vary. Record who was contacted, by whom, and what direction was received.

Give staff a short operational instruction: what service is affected, what they should stop doing, how to report symptoms, and where updates will appear. Avoid attribution, unverified scope, and reassuring phrases you may have to retract.

Minute 55-60: publish the first situation report

At the hour mark, write a one-page internal update:

  • What was observed and when
  • What is confirmed affected, suspected, and currently unaffected
  • What containment actions were taken and their business impact
  • What evidence was preserved
  • Which critical risks remain open
  • Who owns the next actions
  • Time of the next update

Recovery usually should not begin in the first hour. Restoring too early can overwrite evidence or reconnect clean systems to an attacker whose entry path persists. Protect backups from compromised identities, identify a known-clean recovery environment, and prioritize business services. Our air-gap and immutable backup explainer covers why a reachable backup is not automatically a safe recovery source.

Bottom line: the first hour is command, containment, evidence, and facts. Isolate active threats without wiping by reflex, secure compromised identities from a clean path, preserve short-lived telemetry, and put every decision on a timeline. By minute sixty, leadership should have an honest situation report—not a confident guess about a breach nobody has scoped yet.

Advertisement