A practical detection rule quality checklist
Good detection engineering is editorial work: define the claim, verify the evidence, remove ambiguity and make the result useful to the analyst who receives it.
Quality is more than valid syntax
A rule can compile and still be operationally weak. It may depend on fields that are not collected, map to an unsupported technique, create avoidable noise or leave the analyst without a clear next action. Review should cover intent, data, logic and workflow together.
1. State the detection intent
Describe the behaviour the rule should identify, the threat scenario and what a useful alert would let an analyst decide.
2. Confirm the data dependency
Name the log source, required fields, event category and any audit or telemetry setting needed for the rule to work.
3. Test the logic against representative events
Use positive and negative examples. Check field types, case handling, wildcards, joins, time windows and platform-specific syntax.
4. Document likely false positives
Identify legitimate tools, administrators, automation or business processes that may match. Prefer contextual filters over broad exclusions.
5. Map ATT&CK carefully
Map the behaviour actually observed—not the threat family or incident you hope to detect. Use the most specific supported technique or sub-technique.
6. Define alert handling
Give analysts triage questions, enrichment sources, escalation conditions and evidence to preserve. A rule without a response path is unfinished.
7. Assign ownership and review dates
Record an owner, version, test status and review date. Revalidate after schema changes, platform migrations or major tuning.
Minimum release record
Keep the rule ID, owner, target platform, data requirements, ATT&CK mapping, test evidence, known false positives, severity rationale, response guidance and last review date together. This makes tuning and audit work much faster later.