Detection Requirement Specification: A Theory and Template

A requirement begins with a decision, not a data source

Imagine being asked to “detect account takeover.” The request names an outcome, but it does not tell you which account types matter, which takeover path is in scope, what evidence exists, or what anyone should do with the result. If you begin with available sign-in fields, the data source quietly becomes the definition of the problem.

A detection requirement is a reviewable statement of the behavior you want to recognize, the decision the result should support, the evidence needed to support it, and the conditions under which the claim is valid. It sits between threat analysis and implementation. The threat analysis explains what could happen. The requirement chooses a bounded part of that concern and turns it into a promise that can be tested.

Start with the consumer. An identity analyst deciding whether to investigate can tolerate a different level of uncertainty from an automated service deciding whether to revoke a session. The first may need timely evidence and plausible alternatives. The second also needs authority, safeguards, and a very low chance of harmful interruption. Until you name that decision, “high fidelity” has no stable meaning.

Turn the behavior into a claim that can be contradicted

A useful requirement describes one behavior path closely enough that evidence could support or contradict it. Suppose the concern is theft of a cloud session. One path is reuse of a session token from an environment that does not share the original device state. The requirement might predict a new resource-access pattern under the same session after an abrupt change in network, device, or geographic context.

That prediction is a hypothesis, not a verdict. Legitimate roaming, proxy infrastructure, device privacy features, and delayed events can create similar evidence. The requirement should name those alternatives because they shape the context an analytic needs. It should also say which token and session types are outside scope. A detection that sees interactive web sessions should not imply that it covers workload credentials or refresh-token theft.

Falsifiability matters. “Find suspicious sessions” cannot be proven wrong because suspicious is left undefined. “Identify a production user session that accesses a sensitive application after a device-context discontinuity within thirty minutes” can be challenged: the fields may not exist, the session identifier may change, or the window may be unjustified. Those challenges improve the design before the query hides them.

Describe evidence as meaning, not merely as fields

Requirements often fail by listing fields without explaining what they mean. A field called user can represent the actor, the target account, an owner, or an enrichment added later. A timestamp can represent occurrence, observation, ingestion, or processing. Writing “requires user and time” does not tell an implementer which relationship the analytic depends on.

Describe the evidence in source terms first. State who produces the record, where that producer observes the activity, what identity each value represents, which clock supplies the time, and which transformations occur before analysis. Then state acceptable mappings. This preserves the security meaning even if a platform changes field names.

Absence deserves the same care. No event may mean the behavior did not happen, auditing was disabled, the provider withheld the event, collection failed, the record arrived late, or parsing removed a required value. If the detection interprets absence, the requirement must explain which of those alternatives it can distinguish. Evidence is not just the material that supports a match; dependency health is evidence about whether a non-match can be trusted.

Acceptance criteria test the promise at its boundaries

An acceptance criterion says what evidence would make you accept the implementation as satisfying the requirement. Include an intended behavior, a plausible benign alternative, a boundary condition, and a dependency failure. For the session example, you might expect the intended sequence to create a result, normal movement through an approved proxy not to create one, an event arriving exactly at the time-window edge to behave consistently, and a missing session identifier to degrade rather than silently join unrelated activity.

The criterion should follow the entire path. A query match is not enough if the alert drops the session identifier or reaches the wrong queue after the decision window. In the detection engineering lifecycle, validation covers observation, transport, transformation, logic, delivery, and consumer use. Each layer supports a different part of the promise.

Passing a test establishes bounded confidence. It says that the tested variation worked in the recorded environment and version. It does not establish universal recall, future health, or immunity to adversary adaptation. Preserve the test conditions so later reviewers know exactly what the word validated means.

Keep the requirement alive as the environment changes

A requirement is not complete when a rule is deployed. It needs an owner, review triggers, version history, known gaps, and retirement conditions. A provider schema change can break the evidence. A new tenant can expand the population beyond what was tested. A broad exception can narrow the result. A preventive control can remove the original decision while leaving the rule running.

Coverage language should change with those conditions. Use a statement such as: “This version detects the tested session-reuse pattern for interactive production users in the primary tenant when identity and application audit feeds meet the recorded latency and completeness thresholds.” The sentence is deliberately less sweeping than “account takeover covered.” It is also something a consumer can evaluate.

The completed specification therefore preserves a chain of reasoning: concern, behavior path, consumer decision, evidence meaning, analytic expectation, delivery, acceptance evidence, dependencies, and limits. Its purpose is not paperwork. It prevents a later implementation from retaining the title of a detection after the claim underneath it has changed.