The detection engineering lifecycle: from threat idea to trusted signal

Choose valuable behaviour

Use threat intelligence, incidents, architecture and MITRE ATT&CK to prioritise behaviours relevant to the environment. Avoid chasing every technique equally.

Link the detection to a critical service or control assumption. This gives severity and response context.

• Threat and service relevance
• Expected attacker objective
• Available telemetry
• Actionable response path

Define a data contract

Document source fields, collection latency, retention, owner and failure signals. A detection without monitored data health can silently stop working.

Enrich with asset, identity and change context before alerting where possible. Analysts should not spend every case searching for an owner.

• Required events and fields
• Quality and latency threshold
• Asset and identity enrichment
• Collection health alert

Test before and after deployment

Use controlled simulation, historical replay and synthetic events. Validate both expected detection and acceptable noise.

Deploy gradually, compare outcomes and let analysts give structured feedback. Record coverage limits so a quiet dashboard is not mistaken for absence of threat.

• Unit tests for logic
• Adversary emulation or safe simulation
• False-positive scenarios
• Runbook walk-through

Operate the portfolio

Review detections after incidents, platform changes and data migrations. Measure useful investigations, missed behaviour, response value and analyst effort.

Retire duplicate or non-actionable rules. A smaller maintained portfolio is stronger than thousands of unowned alerts.

• Owner and review date
• Version history
• Efficacy measures
• Retirement decision

A practical 30-day field plan

Week one — Hypothesise. Threat behaviour and protected service. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.

Week two — Engineer. Data, analytics, context and runbook. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.

Week three — Validate. Simulation, replay and analyst review. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.

Week four — Operate. Tune, measure, improve or retire. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.

Evidence worth keeping

Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.

• Threat and service relevance — owner, current state, last validation and any open exception
• Required events and fields — owner, current state, last validation and any open exception
• Unit tests for logic — owner, current state, last validation and any open exception
• Owner and review date — owner, current state, last validation and any open exception
• Decision log showing who approved residual risk and when it will be reviewed
• Test or exercise result with the actual outcome, not only a pass label

Questions for the leadership review

Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.

• Who is accountable for the detection engineering outcome when teams disagree about delivery and risk?
• Which critical service or customer promise would be affected by a failure in this area?
• What evidence would tell us the design is working in production today?
• Which exception creates the largest concentration of access, dependency or recovery risk?
• What would the team contain first, and how would it restore a trustworthy service?
• Which improvement can be completed in the next 30 days without waiting for a large programme?