The Detection Engineering Lifecycle

What are we protecting, for whom, and what consequences matter?

Everything downstream inherits its value from this stage. Coverage that is not grounded in what the organization actually needs to protect produces alerts nobody can act on.

produces → Agreed environment and consequence model

What happens here

• ▸Inventory the assets, identities, and business processes worth protecting
• ▸Map the architecture, existing controls, and telemetry landscape
• ▸Establish response authority: who can act, on what, and how fast
• ▸Agree on risk tolerance and the consequences that matter most

How could a realistic attacker create those consequences?

Threat modeling connects attacker behavior to the consequences identified in stage 1. The output is a picture of realistic attack paths, not a generic list of techniques.

produces → Relevant threat scenarios and attack paths

What happens here

• ▸Model realistic threats, attack paths, and attacker objectives
• ▸Fold in incidents, intelligence, hunts, and adversary emulation findings
• ▸Keep the model grounded in this environment, not a borrowed threat list

Which risks deserve action, how should they be addressed, and where does detection contribute?

Three distinct decisions live here. The risk response: avoid, mitigate, transfer or share, or accept. Control design: the mix of preventive, detective, and corrective controls that carries out the mitigation. The detection requirement: the decision and response each detection must support. Detection is one possible part of the approach, not the default answer to every risk.

produces → Defensive decision and detection requirement

What happens here

• ▸Prioritize risk scenarios by consequence, threat relevance, existing controls, and expected defensive value
• ▸Make the risk decision per item: avoid, mitigate, transfer or share, or accept
• ▸Design the control mix: preventive, detective, and corrective controls working together
• ▸Accept residual risk explicitly: attributed to an accountable risk owner, dated, and scheduled for review
• ▸Define the detection requirement: the decision and response each detection must support
• ▸Govern the detection candidate backlog as a portfolio, creating candidates only where the decision gives detection a role

What evidence can support the decision, what logic interprets it, and what should reach a human?

Telemetry is often the gating dependency of the whole lifecycle, so design starts from one question: can the available evidence support the intended claim? A candidate match is still not the customer outcome; grouping, severity, routing, and response guidance are designed here, not left to chance.

produces → Evidence-backed detection and alert design

What happens here

• ▸Answer the gating question first: can the available evidence, with its collection assumptions, coverage, latency, and retention, support the intended claim?
• ▸If not: onboard or repair telemetry, narrow the claim, choose a different detection approach, or return to stage 3 and reconsider whether detection is viable
• ▸Identify the normalization, enrichment, and reference data needed to interpret the evidence
• ▸Choose the simplest operationally sustainable detection form that supports a reliable decision
• ▸Design the alert: grouping, severity, routing, and response guidance

Does it work against malicious, benign, malformed, and historical cases?

Validation means demonstrating behavior before production, not discovering it there. Every detection must have representative validation evidence, malicious and benign, before unrestricted alerting: automated fixtures and repeatable simulation are preferred, and historical replay, controlled production observation, or another documented method may supply equivalent evidence where direct simulation is impractical.

produces → Validated implementation and test evidence

What happens here

• ▸Define the release acceptance criteria: the intended malicious behavior is detected, representative benign behavior is handled acceptably, required context is present, and expected volume, latency, and execution cost remain within tolerable bounds
• ▸Implement the rule and its supporting context
• ▸Prove the acceptance criteria with representative malicious and benign evidence: fixtures and simulation preferred; historical replay, controlled production observation, or another documented method where direct simulation is impractical
• ▸Measure expected alert volume and inspect representative matches against the acceptance bar

Can it enter production without surprising customers or analysts?

Detections are production software and ship like it: reviewed, versioned, observable, and reversible. A detection should not move directly from offline validation to unrestricted alert delivery: introduce controlled production exposure through monitor-only operation, deployment rings, limited audiences, enhanced observation, or an equivalent safeguard.

produces → Approved, observable, reversible deployment

What happens here

• ▸Version and review changes like any other production code
• ▸Release with ownership, severity, response guidance, and telemetry dependencies attached
• ▸Introduce controlled production exposure before unrestricted alerting: monitor-only operation preferred; rings, limited audiences, or enhanced observation as valid alternatives
• ▸Where controlled exposure is genuinely impossible, document the alternative safeguard, its limitation, the rollback plan, and the accountable approval
• ▸Stage the rollout with guardrails, observability, and a rollback path

Is the detection healthy, and does it help someone make a timely decision?

A rule executing successfully is not the same as a detection remaining effective. Every production detection must be revalidated; the cadence and mechanism should reflect its consequence, dependencies, rate of change, and practical testability, and high-consequence or fragile coverage should move toward continuous validation or canaries. The lifecycle spans these activities even when responsibility crosses detection engineering, SOC, incident response, platform, and business teams.

produces → Operational evidence, investigations, and outcomes

What happens here

• ▸Monitor rule health, data health, and dependency health
• ▸Watch alert volume, suppressions, and dispositions
• ▸Investigate and respond; capture what each alert was missing
• ▸Revalidate on an explicit trigger or cadence: scheduled replay, simulation, or regression tests confirm the claimed behavior is still detectable
• ▸Regression-test after schema, parser, platform, or context changes; watch dependencies for compatibility drift

What did production teach us, and is this still the right coverage?

The learning hub of the loop. Production learning returns to every stage whose assumptions need to be revisited, and assurance results and residual-risk reviews owned elsewhere can trigger reconsideration of the stage 3 defensive decision. Observed alert metrics cannot reveal what the program missed, so measurement includes misses, latency, blind time, and response efficacy. Coverage earns its place while the protected consequence still matters, the evidence still exists, scheduled validation still passes, alerts still lead to action, and the value justifies the execution and maintenance cost.

produces → Accountable continue, tune, revise, or retire decision

What happens here

• ▸Measure alert quality: true positives, noise, time to decision, alert-to-action rate, and analyst effort
• ▸Measure the foundations: evidence and telemetry availability, scheduled validation success, execution cost, and maintenance cost
• ▸Measure what was missed: incidents, hunts, and adversary emulation that found what detections did not, detection latency against the response window, and telemetry blind time
• ▸Judge response efficacy and outcomes, not merely whether an action occurred
• ▸Attach confidence and limitations to coverage claims, and separate portfolio-level outcomes from per-rule metrics
• ▸Confirm the protected business consequence still matters
• ▸Review exceptions and periodically reconfirm the claimed behavior remains detectable as threats and the environment change
• ▸Tune narrowly, preserving visibility into suppressed activity; routine tuning may belong to detection engineering, but material scope, severity, control, or risk changes return through stage 3 and the appropriate accountable owner
• ▸Revise or retire coverage that no longer earns its place, remaking the stage 3 decision