Skip to content
Skip to main content
Logs, Records & Provider Evidence Operational Explainer

How should an alert be described in a report?

Describe an alert as a detection result produced by stated logic over available data. Do not repeat its title, severity or disposition as though it were the underlying fact.

Explain what actually triggered

Identify platform, rule ID and version, time window, severity and source events, and whether the method was threshold, correlation, anomaly, score or indicator match. Translate the condition accurately: an “account takeover” title may represent only a new-device login followed by a password change.

Separate source-recorded values from added reputation, location and threat-intelligence assessments. Severity is prioritisation and analyst disposition is an assessment.

Report evidence and alert as different layers

Describe underlying attempts, blocks, failures, successes and consequences independently. Preserve later merges, suppression or reclassification and the data available when they occurred.

Prefer “the rule triggered because…” followed by what source records establish. “The system confirmed…” is suitable only where the system directly recorded that precise outcome.

The point to remember

Report the alert's rule-based interpretation and the underlying source events as separate evidential layers.

Reference: LOG-148Logs, Records & Provider Evidence