Signals and severities 1.0

Signals and severities

Last updated 10 Nov 2026
On this page

A signal is one thing a rule found, counted over every time it happened. Its severity says how urgently to look - by the same criteria Sigma uses.

What a signal is

A rule may match many records. Signal does not give you each match separately: it groups every match of one rule about one thing into one signal.

  • The "thing" is the rule's subject: a program, an account, a task, a log. A rule can name other fields to group by (its coalesce fields): one signal per command line, or per log and account.

  • A signal carries a count, its first and last time, what varied between the matches, and every occurrence on its timeline.

  • Its text describes one match. The count tells you how many there were.

The four severities

Severity

Criteria

What it means for you

critical

Never matches anything legitimate, and is of high relevance.

An incident. Act now.

high

A threat of high relevance to review by hand; false positives are rare.

An incident, unless it is a false positive. Review it first.

medium

Suspicious activity or a policy violation; false positives are expected.

Suspicious. Look at it in context.

low

Suspicious or against policy, often benign on its own.

Worth knowing. It matters most beside other signals.

Signal's own grading rules

Sigma's levels were written for event rules. Signal adds four rules for what Sigma does not cover:

  1. A state is not an act

    A rule about the host's configuration now - a setting off, an exclusion configured, a port open - is medium at most, unless the configuration is itself an intruder's artifact with no legitimate use (an accessibility program's debugger). The act that made the change, when a log recorded it, may be graded higher.

  2. A capability is not its use

    Software that can be misused - remote access tools, tunnels, miners - is medium or low. Its observed use is graded on its own evidence.

  3. Critical is a claim you can check

    A rule is critical only when no legitimate activity is known to match it. One known benign match makes it high.

  4. The severity is the rule's, not the host's

    Several signals on one entity are weighed together on the entity, by you. No single rule is raised because others fired.

Signals and context are different things

Every finding in Signal is a signal. Context about a host - "the Security log is small", "a policy is off" - is never a signal. It is a KPI with a note, a telemetry item or a column of a table.

Each rule's outcome

Every run lists every rule with its outcome on that host:

Outcome

Meaning

flagged

The rule's condition held: it produced at least one signal.

clear

The rule was evaluated over complete data and found nothing.

not_run

The rule could not be evaluated, and the reason says why: a policy its data depends on is off (dependency_off), unknown (dependency_unknown), its source was not read (source_not_read), its facts could not be collected (facts_unavailable), or the profile suppressed it (rule_excluded).

A clear may also carry the reason partial: some of its conditions could not be checked.

Approved signals

When a signal is about something your organisation runs on purpose - listed in the profile's baseline - it is kept and marked approved. It is never dropped: approval is your organisation's statement, not proof the thing is benign. See Baselines.

Next

Signals are grouped into entities.