# 5.2 Initial Triage, Evidence, and Incident Classification

# Goals

Initial triage is the first controlled review of a possible incident.

The goal is to understand what may have happened, preserve useful evidence, decide how serious the situation is, and determine what action is needed next.

This step should be fast, but not careless. The company should avoid destroying evidence, making assumptions too early, or taking random actions that make the incident harder to understand.

At this stage, the company is trying to answer:

What happened?
Who or what is affected?
Is the incident still active?
What evidence exists?
How serious is it?
Who needs to be involved next?

# Step 1: Open an Incident Record

Create an incident record as soon as the issue moves beyond normal helpdesk handling.

Record:

Incident ID
Date and time reported
Who reported it
Who opened the incident record
Affected user, system, account, device, vendor, or business process
Short description of the issue
Initial severity
Current status
Response lead
Evidence location

Do not rely on scattered emails, chat messages, or memory. The incident record becomes the central timeline.

# Step 2: Preserve the First Evidence

Preserve evidence before it is deleted, overwritten, or changed.

Preserving evidence is important because it helps the company understand what happened, how the incident started, which systems or accounts were affected, and whether data was accessed or stolen. It also supports insurance claims, legal review, customer or regulatory reporting, and later improvements to security controls. If evidence is deleted or overwritten too early, the company may lose the ability to investigate the incident properly or prove what actions were taken.

Useful evidence may include:

Suspicious emails
Email headers
Screenshots
URLs
Files or attachments
Login alerts
MFA prompts
Endpoint alerts
Firewall logs
VPN logs
Cloud audit logs
SaaS audit logs
Website logs
Backup alerts
User statements
Ticket notes
Vendor or MSP reports
Payment requests or invoice messages

Do not wipe devices, delete emails, reset everything, or rebuild systems before deciding what evidence is needed.

If immediate containment is required, record what was done and when.

# Step 3: Identify the Affected Scope

Determine what appears to be involved.

Check whether the issue affects:

One user or many users
One device or many devices
One mailbox or multiple mailboxes
One SaaS platform or several systems
One department or the whole company
One vendor account or several external accounts
One file or a large data set
One website or multiple public systems
One backup job or the wider backup environment
Do not assume the first affected item is the only affected item.

Initial scope may change as more evidence is reviewed.

# Step 4: Check Whether the Incident Is Still Active

Determine whether the issue is ongoing.

Look for signs such as:

Active suspicious login sessions
New mailbox rules
New admin accounts
Active malware alerts
Ransomware-like file changes
Data still being downloaded
Public links still active
Vendor access still in use
VPN sessions still connected
Firewall exposure still open
Backup deletion activity still occurring
Website files still changing

If the incident appears active, move quickly toward containment.

# Step 5: Collect the Most Important Technical Facts

Collect enough technical information to make a decision.

Important facts may include:

Affected usernames
Affected device names
Affected IP addresses
Login times
Source countries or locations
Admin changes
File names
Domains and URLs
Email sender addresses
Email subject lines
Attachment names
File hashes, if available
Alert names
System names
Data involved
Business process affected
Known actions already taken

This does not need to be a full forensic investigation yet. It needs to be enough to make the first response decision.

# Step 6: Classify the Incident Severity

Classify the incident using simple levels.

# Low severity:

Suspicious activity reported, but no confirmed compromise, no sensitive data involved, and no business disruption.

# Medium severity:

User clicked a link, opened a suspicious attachment, replied to a suspicious message, or one device or account shows concerning activity, but there is no confirmed major impact yet.

# High severity:

Credentials were entered, MFA was approved unexpectedly, malware is suspected, sensitive data may be involved, a high-risk mailbox may be compromised, or a critical business system may be affected.

# Critical severity:

Confirmed compromise, ransomware signs, unauthorized admin access, fraudulent payment, public exposure of sensitive data, active malware, backup tampering, domain or DNS compromise, cloud compromise, or material business disruption.

Severity can change. If new facts show greater impact, update the classification.

# Step 7: Decide the Next Action

After initial triage, decide what happens next.

Possible actions include:

Close as false alarm.
Monitor for related activity.
Reset a password.
Revoke sessions.
Disable an account.
Isolate a device.
Block a sender, domain, IP address, URL, or file hash.
Remove a mailbox rule or forwarding rule.
Disable a public link.
Suspend vendor access.
Escalate to the MSP or external incident response provider.
Notify leadership.
Notify legal, insurance, or compliance contact.
Move into containment.
Move into the full Respond process.

For high or critical incidents, do not keep the issue in informal triage. Escalate.

# Step 8: Create the Initial Situation Summary

Create a short summary before handing off to the next response step.

Include:

What happened
When it was detected
How it was detected
Who or what is affected
What evidence has been collected
What is still unknown
Whether the incident appears active
Initial severity
Immediate actions already taken
Recommended next action

This summary helps leadership, IT, MSPs, legal, insurance, and recovery teams work from the same facts.

# Evidence Handling Rules

Following evidence handling rules is important because poor handling can damage, delete, overwrite, or contaminate the information needed to understand an incident.

Clear rules help the company preserve the timeline, confirm what systems or data were affected, support legal or insurance review, and make better response decisions.

They also prevent well-meaning employees or IT staff from taking rushed actions that make the incident harder to investigate.

Rules:

Do not delete suspicious emails before preserving them.
Do not wipe or rebuild devices before evidence needs are considered.
Do not reset all accounts blindly without recording why.
Do not turn off logging.
Do not allow employees to investigate on their own.
Do not share suspicious files or links casually in chat.
Do not use personal devices or personal accounts to manage the response unless there is no safer option.
Do record every major action, decision, and time.
Do preserve original messages, alerts, logs, screenshots, and reports where possible.
Do restrict access to incident evidence.

# Simple Incident Classification Guide

# Low:

Suspicious report with no confirmed action taken and no sensitive system involved.

# Medium:

Interaction occurred, but compromise is not confirmed.

# High:

Credentials, MFA, sensitive data, malware suspicion, high-risk accounts, or critical systems are involved.

# Critical:

Confirmed compromise, ransomware signs, unauthorized admin access, payment fraud, data exposure, backup tampering, or active business disruption.

# Recommended Open Source and Affordable Tools

The following tools help provide the best ROI to help prepare for and conduct incident response:

Tool or Solution	Link	Type	Best Use
TheHive	TheHive	Commercial, with community/project history	Security case management, incident records, collaboration, investigation tracking
Zammad	Zammad	Open-source	Ticket intake, triage workflow, employee and IT/security reports
osTicket	osTicket	Open-source	Simple helpdesk intake and report tracking
GLPI	GLPI	Open-source	IT service management, assets, tickets, and incident records
Jira Service Management	Jira Service Management	Free tier and commercial	Incident tickets, escalation workflows, approvals, and task tracking
Request Tracker	Request Tracker	Open-source with commercial support	Ticketing and incident workflow tracking
Velociraptor	Velociraptor	Open-source	Endpoint triage, forensic collection, endpoint visibility, incident response investigation
DFIR ORC	DFIR ORC	Open-source	Windows forensic artifact collection during incident response
osquery	osquery	Open-source	Endpoint state queries for users, processes, services, software, and configuration
Fleet	Fleet	Open-source and commercial	osquery management, endpoint visibility, device posture
Sysmon	Sysmon	Free	Detailed Windows and Linux system activity logging
Hayabusa	Hayabusa	Open-source	Fast Windows event log timeline and threat hunting review
Chainsaw	Chainsaw	Open-source	Windows event log hunting using Sigma-style detection
Timesketch	Timesketch	Open-source	Collaborative forensic timeline analysis
Plaso	Plaso	Open-source	Log and artifact timeline generation
Autopsy	Autopsy	Open-source	Disk and file-system forensic analysis
Volatility 3	Volatility 3	Open-source	Memory forensics and volatile artifact analysis
CyberChef	CyberChef	Open-source	Decode, parse, transform, hash, and inspect technical indicators safely
YARA	YARA	Open-source	Malware pattern matching and file classification
Sigma	Sigma	Open-source	Detection rules for logs and SIEM platforms
MISP	MISP	Open-source	Threat intelligence and indicator tracking
Cortex	Cortex	Open-source companion tool	Analyze observables such as IPs, domains, URLs, hashes, and email indicators
VirusTotal	VirusTotal	Free and commercial	Check suspicious files, URLs, domains, and hashes
urlscan.io	urlscan.io	Free and commercial	Analyze suspicious URLs and webpages
Wazuh	Wazuh	Open-source	SIEM/XDR, endpoint alerts, log review, and incident visibility
Security Onion	Security Onion	Open-source with paid support	Network security monitoring, log review, intrusion detection, and investigation
Graylog Open	Graylog Open	Free/source-available options	Central log search, dashboards, and alert review
OpenSearch Security Analytics	OpenSearch Security Analytics	Open-source	Security analytics, detection rules, investigation, and alerting

# Practical Tool Stack for SMEs

# Very small company:

Use a ticketing system such as Zammad, osTicket, GLPI, Jira Service Management, or Freshdesk, plus Microsoft 365 or Google Workspace audit logs, endpoint protection alerts, backup alerts, and a simple incident register.

# Microsoft-based SME:

Use Microsoft Defender, Microsoft Purview Audit, Entra ID sign-in logs, Outlook reported-message submissions, Jira Service Management or Zammad, and a protected evidence folder.

# Google Workspace SME:

Use Google Admin audit logs, Google Workspace Alert Center, Gmail security reports, Drive sharing activity, a ticketing system, and a protected evidence folder.

# Cost-conscious technical company:

Use Wazuh, Velociraptor, osquery or Fleet, Sysmon, Hayabusa, Timesketch, CyberChef, YARA, Sigma, and Zammad or TheHive for case tracking.

# More mature security team:

Use TheHive for case management, Cortex for enrichment, Velociraptor for endpoint triage, Timesketch for timelines, MISP for indicators, Wazuh or Security Onion for logs, and VirusTotal or urlscan.io for external enrichment.

# Incident Record Template

The company should maintain a simple incident record with these fields:

Incident ID
Date and time opened
Reported by
Detection source
Incident owner
Affected users
Affected systems
Affected data
Business process affected
Initial description
Evidence collected
Known timeline
Initial severity
Immediate actions taken
Current status
Next action
Escalation required
External support required
Leadership notified
Legal, insurance, or compliance notified
Date and time closed
Final outcome

# Expected Outputs from This Section

At the end of this section, the company should have:

An incident record opened.
Initial evidence preserved.
Affected scope identified.
Active risk checked.
Key technical facts collected.
Incident severity classified.
Next action decided.
Initial situation summary created.
Evidence stored in a controlled location.
A clear handoff to containment, escalation, or closure.

# Objective

Triage should be fast, factual, and recorded.

A company should leave this section able to say:

“We know what was reported, what evidence exists, what may be affected, how serious it appears, and what must happen next.”

That is initial triage, evidence, and incident classification.