1. Start with the decision
Before collecting more data, define the question the investigation must answer. Examples include whether an account was compromised, whether suspicious access succeeded, which systems were affected, or whether containment is required. A clear decision question prevents broad searches from becoming an unfocused data exercise.
2. Preserve the original context
Keep the source system, collection time, event time, timezone, host or tenant, account identifiers, and relevant parser or export details. Normalization helps analysis, but the original evidence should remain traceable. If timestamps are converted, document the conversion.
3. Build a minimal timeline
Place the trigger in time, then expand carefully before and after it. Include successful and failed activity, authentication changes, process execution, network connections, administrative actions, and evidence gaps. A timeline should distinguish observed events from inferred relationships.
| Field | Purpose |
|---|---|
| Observed time | When the source recorded the event, including timezone. |
| Source | The log, system, or evidence item that supports the entry. |
| Observation | What occurred without interpretation. |
| Interpretation | The current explanation or hypothesis. |
| Confidence | How strongly the available evidence supports that interpretation. |
4. Form testable hypotheses
A useful hypothesis predicts what additional evidence should exist. For example, if a failed-login burst was followed by account compromise, there may be a successful authentication from the same infrastructure, a new session, privilege use, or follow-on activity. Also define evidence that would weaken the hypothesis.
5. Correlate identities, assets, and indicators
Names and IP addresses alone can mislead. Resolve identities, device ownership, NAT or proxy context, cloud tenancy, expected administrative tools, and the time relevance of threat-intelligence information. Treat enrichment as context, not proof of maliciousness.
6. Separate findings from unknowns
Use three clear categories: confirmed observations, supported interpretations, and unresolved questions. This makes review easier and reduces the risk that a plausible narrative becomes an asserted fact.
7. Choose the next proportional action
Recommendations should match evidence and business risk. Options may include collecting another source, validating with a system owner, increasing monitoring, revoking a session, isolating a host, or escalating to an incident-response authority. Follow the organization’s authorization and change-control process.
8. Prepare a reviewable report
A concise report should include scope, evidence sources, timeline, key findings, confidence and limitations, actions already taken, recommended next steps, decision owners, and preserved references. The report should allow another analyst to understand how each conclusion was reached.
Where AI assistance fits
AI can help summarize repeated events, organize a timeline, surface questions, and draft structured findings. It can also misunderstand fields, miss collection gaps, or overstate relationships. Require source-aware outputs, verify important claims, and keep a human analyst responsible for operational decisions.
SecureViewIQ is designed around this evidence-grounded, analyst-reviewed workflow. Learn about the AI security investigation workspace or use the incident-response evidence checklist.