Cybersecurity & Incident Response · THE NO-PANIC PLAN
Record a Suspected Cyber Incident Safely Before Escalation
A useful incident record helps responders understand what was observed, when it happened, what was done, and what remains unknown. Preserve facts and provenance without opening suspicious links, changing affected systems, or placing secrets and sensitive evidence into an unapproved tool. This workflow covers initial documentation and escalation; it does not investigate, contain, determine legal notification duties, or replace the organization's incident response plan. Security Incident Timeline Builder can organize a redacted chronology, but it is not a forensic evidence repository. If an incident may be active, notify the designated security or IT contact immediately and follow their instructions.
MISSION Create a concise, time-stamped record of observable facts about a suspected organizational cyber incident and route it through the approved response channel.
Escalate active threats first, then record only safe, observable detailsTHE REAL-WORLD BIT
What happens outside this browser tab?
Escalate urgent activity; record observer, time, source, and direct observations; preserve original alerts through approved controls; separate facts from assumptions; build a limited chronology; restrict sensitive evidence to approved systems; route the record to the incident owner; and preserve updates and corrections.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Escalate first when activity may still be active
If you see active unauthorized access, ongoing data exposure, ransomware, account takeover, or a threat to safety or operations, use the organization's incident contact or emergency escalation route now. Do not delay responder instructions while filling out a report. Follow the incident plan and ask the authorized responder what to preserve and what actions to avoid; turning off equipment, deleting messages, resetting a device, or changing settings can affect evidence or service operations. This page records observations and does not decide severity, legal duties, or technical response actions.
- 02
Record who observed what, when, and where
Record the observer's role and approved callback route, when the issue was first noticed, when it was logged, the time zone, the affected service or asset identifier, and how it came to attention. Note if a device clock may be wrong. Describe visible facts plainly, such as an unexpected sign-in alert or service outage. Distinguish direct observation from another person's report. Keep the record limited to what responders need; do not paste passwords, authentication codes, private keys, full customer records, or unredacted personal data into a public form or unapproved document.
- 03
Preserve the original alert through approved controls
Keep the original email, alert, ticket, or log in the system designated by your organization. Use a report-phishing or incident-report control only as the security team directs; do not forward suspicious content to a personal account or copy it into a public tool. Record a safe reference such as a ticket number, alert ID, or approved message location instead of embedding executable content. Do not click links, open attachments, reply, scan a QR code, or browse to an indicator. Preserve the original and its collection context as the response plan requires; do not edit evidence in a way that obscures provenance.
- 04
Separate verified facts from assumptions and impact guesses
Write neutral entries that distinguish what you personally observed, what another person reported, and what is only a hypothesis. If known, record the affected account, service, device, or business process; otherwise say unknown and leave investigation to responders. Do not label an event a confirmed breach, attribute it to a person, estimate affected customers, or claim data was exfiltrated without evidence. NIST guidance emphasizes recording response actions and protecting record integrity and provenance; retain each entry's source so an authorized reviewer can verify it later.
- 05
Build a limited chronology for the response owner
Arrange safe observations in time order and include the source of each time, such as a monitoring alert, help-desk ticket, user report, or system event. If clocks disagree, preserve each time with its source instead of silently normalizing it. Security Incident Timeline Builder can organize redacted descriptions into a readable draft chronology; it cannot confirm timestamps or maintain evidentiary chain of custody. Check the result against approved source records and move sensitive details to the designated case system. Record later corrections as new entries with author and time rather than silently rewriting history.
- 06
Restrict sensitive evidence and route the record
Before sharing, remove credentials, authentication tokens, private keys, payment details, unnecessary personal identifiers, and exploitable technical details not needed by the recipient. Keep original logs, message headers, captures, and forensic images in the authorized evidence repository with access limited to responders; use a reference ID in the summary. Submit the record through the incident plan or named security contact, including actions already taken, unknowns, and a callback route. Do not notify customers, regulators, law enforcement, or media on the organization's behalf unless authorized. Route legal and notification decisions to responsible leaders and qualified counsel.
- 07
Track assigned actions and preserve correction history
After escalation, record the incident owner, next action, due time, and system of record for evidence. Update the chronology only with new verified information, preserving who made the update and when. Mark suspected cause or impact as provisional until responders confirm it, and connect corrections to earlier entries. Limit distribution to authorized recipients and follow retention or legal-hold directions. At closure, preserve the final record as policy requires and capture lessons without unnecessary personal or secret data. For suspicious links or files, use the related safe-indicator workflow rather than opening them.
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10