How should an alert be described in a report?¶

An alert should be described as the result of a detection rule, analytic process or security assessment applied to available data.

It should not be reported as though it were the underlying event itself.

Avoid the dangerous assumption¶

The dangerous assumption is that an alert title can be repeated as a confirmed factual conclusion.

It cannot.

A report should identify the alerting platform, rule name, rule version, severity, time window and source events. Explain whether the alert was based on a threshold, correlation, anomaly, risk score or known indicator.

State what triggered the rule in plain language. If the alert was called “account takeover”, explain the actual conditions, such as a new-device sign-in followed by a password change.

Severity should be described as the platform’s prioritisation, not proof of maliciousness. An analyst closure or disposition should be identified as an assessment made using the information then available.

The underlying events should be examined and reported separately. They may show attempted, blocked, failed or successful activity, and they may not support the full wording of the alert title.

Where the alert used enrichment, geolocation or threat intelligence, distinguish those added assessments from source-recorded facts. Record whether the alert later changed, was merged, suppressed or reclassified.

Avoid phrases such as “the system confirmed” unless the system directly recorded the stated outcome. It is usually safer to say that the rule triggered and then explain what the source records established.

Operational takeaway¶

Report an alert as a detection outcome based on stated rules and data, then describe the underlying events separately rather than adopting the alert title, severity or disposition as proof.