Begin with what you know and what you do not
An unusual alert is not yet a complete incident narrative. The first report may describe a symptom: a new administrator, encrypted files, suspicious outbound traffic or an unexpected payment instruction. Record what was observed, when it was observed and the source of that observation. Keep confirmed facts separate from working hypotheses.
The first hour is a useful planning frame, not a fixed deadline that applies to every incident. A destructive event may require immediate containment; an ambiguous signal may need rapid validation. The goal is to establish a reliable decision process while reducing harm. NIST’s incident response guidance places this work within wider preparation, risk management and recovery responsibilities.
Assign a lead and establish a trustworthy channel
Name an incident lead with authority to coordinate work and record decisions. Separate the coordination role from specialist investigation where staffing allows. Someone needs to maintain the timeline, track assigned actions and ensure that operational changes are communicated. Without that structure, several capable people can make conflicting changes at the same time.
Choose a communication channel appropriate to the suspected compromise. If organisational email or identity is affected, the usual collaboration tools may not be trustworthy or available. Use a pre-agreed alternative where one exists. Verify participants, limit sensitive distribution and avoid posting credentials or raw personal information into an incident chat.
Make a bounded initial assessment
Ask which services and identities appear affected, whether harm is continuing, what business processes depend on them and which evidence is likely to disappear. Identify the system owners and the people who can authorise disruptive changes. Record uncertainty explicitly; an incomplete inventory should not be presented as proof that the incident is contained.
For example, an unexpected privileged login could involve one account, a stolen session or a broader identity compromise. The early investigation should test those possibilities without treating any as established fact. Compare the alert with relevant identity and application logs and obtain context from the account owner through a trusted route. Avoid asking a potentially compromised account to verify itself.
Choose containment with its consequences visible
Possible actions include isolating a host, revoking sessions, disabling an account, blocking a malicious destination or pausing an exposed service. Each has different consequences for evidence and business continuity. The incident lead should record the purpose, expected impact, owner and time of a containment action so the team can assess whether it worked.
Where ongoing harm makes immediate action necessary, act through the authorised response process and record the trade-off. Where circumstances permit, preserve relevant volatile information and logs before making changes that erase them. There is no universal rule that every machine should be powered off or that every alert requires shutting down a service. The decision must reflect the observed threat and operational dependencies.
Preserve an evidence trail people can follow
Keep original log exports and relevant artefacts with restricted access, record where they came from and document collection times and methods. Work from copies when practical. A timeline is more useful when it distinguishes the time an event occurred from the time an investigator discovered it. Note time zones and known clock differences.
Use a simple action log: time, actor, action, reason and result. Capture commands or administrative changes that alter systems. Do not quietly “clean up” suspicious files while another responder is trying to understand them. Evidence handling requirements vary with the investigation, so involve appropriate forensic and legal expertise when the circumstances require it.
Communicate decisions, then set the next checkpoint
A short internal update should explain the observed impact, what is being done, what remains unknown and when the next update will arrive. Avoid promising that no data was accessed before the evidence supports that conclusion. External notifications require the relevant operational and legal owners to assess the facts and applicable obligations; a generic article cannot determine those obligations for an organisation.
End the initial coordination cycle with named tasks and a review time. Confirm who is investigating scope, who is managing containment, who is considering recovery and who owns stakeholder communication. Preserve unanswered questions in the incident record. After the incident, use the timeline to improve preparation and decision-making, rather than judging responders only by how quickly they closed the first alert.