This article explains how Torq's Auto Triage evaluates alerts ingested from security sources and determines the final verdict (True Positive – Malicious, True Positive – Benign, or False Positive) and severity level (Critical, High, Medium, Low, or Informational). CrowdStrike is used as an example source, but the evaluation logic applies consistently across supported alert sources.

Auto Triage is not enabled by default and requires separate enablement. To get access, contact Torq Support.

Evaluating ingested alerts

Auto Triage evaluates alerts in a way similar to an experienced Tier 1/2 security analyst. It examines the alert end-to-end and weighs multiple signals together rather than relying on a single field or label from the source.

The evaluation considers:

The behavior described by the alert
The observables associated with the activity
The potential impact of the behavior
How similar activity has appeared and been handled previously in the environment

This approach allows Auto Triage to reason about risk rather than simply echoing source-provided values.

Starting from a risk-first assumption

Auto Triage evaluates alerts using a risk-first approach grounded in observed facts and available evidence, rather than relying solely on source-provided labels. The potential impact of the activity is assessed based on the alert's data and associated observables.

Contextual analysis is applied throughout the triage process. During triage, alerts may be elevated in severity if additional validated evidence indicates a higher potential risk. Once a verdict is reached, the alert is not re-evaluated.

Applying organizational context through Guidance and Rules

Auto Triage incorporates organization-specific inputs through Guidance and Rules.

Guidance provides interpretive signals about expected behavior in the organization. These signals influence how activity is assessed but do not enforce a fixed outcome.
Rules enforce deterministic outcomes based on defined conditions in the alert data. Rules can directly influence severity or verdict when their criteria are met.

For example, endpoint activity generated by creative or gaming software may be considered expected on user workstations when organizational context indicates it is allowed. The same behavior occurring on a critical system, such as a domain controller, production server, or restricted network segment, may be evaluated with higher risk and severity when rules enforce increased sensitivity for those assets.

Together, Guidance and Rules ensure that severity and verdict decisions reflect the organization's operating environment.

For configuration details, see:

Weighing observables and enrichment

Auto Triage places strong emphasis on observables when evaluating alerts.

Examples include:

File hashes and their reputation
Network indicators such as IP addresses or domains
Whether observables have appeared previously in the environment or have known prevalence based on available threat intelligence.

A rare file hash associated with known malicious activity increases the assessed risk. An observable that appears frequently and has a benign history may reduce concern. These signals often explain why severity differs from the source value.

Evaluating attack stage and MITRE TTP alignment

Auto Triage evaluates how the observed behavior aligns with known attack patterns and stages.

Behavior associated with later stages of an attack kill chain or MITRE attack TTPs has a greater potential impact than early-stage activity. This context influences how aggressively risk is assessed, even when the underlying alert type appears similar.

Learning from Torq's case history

Auto Triage continuously incorporates outcomes from Torq's case history. When closed or resolved cases exist in your account, Auto Triage searches for matches to the current alert's observables — including IP addresses, URLs, file hashes, hostnames, and email addresses. Matching is based on shared observables extracted from the alert: the more observables a historical case shares with the current alert, the higher its relevance weight in the enrichment.

The context from matched cases is analyzed and passed into Auto Triage as a structured input — alongside threat intelligence, MITRE alignment, and organizational guidance — to inform the final verdict. It does not override other signals but contributes to the overall conclusion as one of several factors.

This approach allows Auto Triage to adapt to the organization's real operating environment and reduce repeated misclassification over time. The more consistently your team documents resolution reasons and associates observables when closing cases in Torq, the stronger this enrichment becomes.

Using source-provided severity and metadata

Auto Triage uses severity labels, detection metadata, and observables provided by the alert source as input signals — not as final conclusions.

Source-assigned severity is considered alongside other factors such as observables, attack-stage alignment, organizational Guidance, Rules, and prior case outcomes.

For example, a source may label an alert as Informational. Auto Triage may assess higher severity if additional signals indicate meaningful risk. Conversely, a source-labeled High alert may be assessed as lower risk when organizational inputs or historical outcomes explain the behavior.

CrowdStrike is one example of a source that provides severity labels, observables, and detection metadata. The same evaluation model applies consistently across supported alert sources.