What it means
Detection use-case acceptance criteria define the threat behavior, data, logic, context, expected alert, performance, ownership, response path, and evidence required before a detection is treated as operational.
Why it matters
A rule that fires in a test is not production-ready if data quality, false positives, severity, enrichment, playbooks, failure monitoring, and maintenance are undefined.
Practical focus
- State the adversary behavior, protected asset or process, hypothesis, required telemetry, analytic logic, exclusions, and expected evidence.
- Test true-positive, false-positive, missing-data, delayed-data, volume, evasion, maintenance, and failure scenarios.
- Approve alert fields, severity, ownership, triage questions, escalation, response, tuning limits, health monitoring, and review cadence.
- Preserve this evidence: Retain the use-case specification, ATT&CK mapping, data validation, test cases, results, tuning, approval, playbook, health checks, and change history.
- Exercise this failure scenario: A detection enters production with no reliable owner or data-health check, producing either chronic noise or silent loss of coverage.
Common mistakes
- Using the label Detection Use-Case Acceptance Criteria without defining scope, ownership, decision authority, and the exact data, systems, people, or process affected.
- Treating a policy, contract, diagram, dashboard, or tool demonstration as proof that Detection Use-Case Acceptance Criteria operates consistently in production.
- Closing work without retaining the evidence needed to reconstruct the decision and verify the intended control outcome.
- Testing only the normal path and never rehearsing the failure condition: A detection enters production with no reliable owner or data-health check, producing either chronic noise or silent loss of coverage.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: