Record what is known now
An early incident note should help the next responder understand what happened, what remains uncertain and what actions have already changed the situation. Calling everything a breach too early can mislead people; describing only that the computer is weird gives them almost nothing to work with.
Use a private, approved location. Incident notes can contain device identifiers, personal information and details that would help an attacker. A free document tool is enough if access and backup are handled appropriately.
Build a short factual record
- Record the observation time and time zone, the affected system and the person reporting it. Distinguish the time you noticed the event from the time a log says it occurred.
- Describe the symptom precisely: an unexpected sign-in, a renamed file, a security alert or an unexplained forwarding rule. Include the exact error text when safe and useful.
- Record the relevant business impact, such as a service unavailable to two users. Separate confirmed impact from possible wider exposure that has not been checked.
- List every response action with its operator and time. Disconnecting a network, resetting credentials or rebooting a computer can affect later evidence, so make those changes visible.
Verify observations before adding conclusions
Where practical, preserve the original alert or a sanitised screenshot in the approved incident folder. Label a copied message as a copy and retain the original through the supported process. Do not repeatedly rerun a suspicious attachment to produce a clearer screenshot.
Use language that matches the evidence: account activity shows a successful sign-in at this time is stronger and clearer than an unqualified claim that someone stole every file.
Define the next decision
Record who has been informed, who owns the next action and which evidence is needed. For financial fraud, the urgent bank-contact action should not disappear beneath technical detail. For a work system, follow the established response authority rather than making unrelated changes independently.
Update without erasing history
Add dated corrections when new evidence changes the interpretation. Do not silently replace the first account with a cleaner story. A useful timeline preserves uncertainty and explains why decisions were made. Its purpose is coordinated response and learning, not assigning blame before the facts are established.
Official references
Consult the current vendor documentation if your version or screen differs.
Documentation-based draft. Commands have not all been executed against the named products in a lab. Validate configuration examples against your installed version before changing a working system.