Detection Engineering: Definition, Lifecycle, and Metrics

Bright curved horizon of a planet glowing against the dark backdrop of space.

Detection engineering is the practice of designing, testing, deploying, maintaining, and retiring the logic that tells a security team when activity in its environment looks malicious. It treats detections as maintained software with owners, tests, and a lifecycle, so coverage holds up as systems, log sources, and attacker techniques change.

Most security teams already run detections from their EDR, SIEM, and cloud tools. Fewer have a function that owns them. In a 2025 SANS survey of 264 security professionals, nearly 80% of respondents' organizations funded detection engineering, yet only 60% had a dedicated team.

This guide defines the discipline and covers what it owns, the lifecycle it runs, how to organize it, detection-as-code, the tools involved, and the metrics that show whether it works.

TL;DR:

Detection engineering owns detection logic end to end, from the telemetry a rule depends on to the day the rule is retired.
A program that depends on one rules-savvy analyst tends to stall when that person is busy or leaves; a backlog, a lifecycle, and acceptance criteria make the work durable.
Detection-as-code brings version control, peer review, testing, and automated deployment to rules, and most teams adopt the first steps before the last.
Coverage maps count rules that exist, so pair them with detection health checks that confirm each rule still receives the data it needs.
Incident reviews are one of the most useful inputs to the detection backlog, and they only reach it when someone formalizes the handoff.

What Detection Engineering Owns

The function's work falls into these areas, each with a named owner:

Telemetry requirements: deciding which logs each detection depends on and confirming they are collected, parsed, and normalized.
Backlog management: choosing what to detect next from structured inputs such as threat intelligence, coverage gaps, red and purple team results, and incident reviews.
The build and deployment pipeline: version control, testing, and automated release of rules across SIEM, EDR, and cloud tools.
Tuning and retirement: tracking false positives per rule and removing detections that no longer earn their place.

Alert triage, incident response, and threat intelligence production are adjacent functions that feed detection engineering and consume its output, although in smaller teams the same people often do several of them.

The inputs need structure to be useful. Intelligence handed to detection engineers should carry the metadata needed to build a detection, a point SpecterOps made in a 2022 post on backlog prioritization. A spreadsheet of indicators, a common format for those handoffs, rarely carries enough. The outputs are detections ready for production, investigation guidance attached to each alert, enrichment that speeds up the next step, and a coverage map.

Detection Engineering vs Threat Hunting

Threat hunting proactively searches telemetry for threats that existing detections and routine monitoring may miss, using the hypothesis-driven, baseline, and model-assisted approaches defined in Splunk's PEAK framework. Detection engineering turns what is already understood into automated, repeatable logic. The two feed each other: in a 2023 post, Splunk's David Bianco calls new detections the most obvious way a hunt improves security posture.

Deployed detections run automatically, either continuously or on a schedule, and produce alerts. Hunts run as deliberate, scoped efforts and produce findings, which may be a confirmed compromise, a gap in telemetry, or the specification for a new rule. A mature program routes hunt findings that can be automated into the detection backlog, so the next occurrence fires an alert instead of waiting for the next hunt.

How the Detection Engineering Lifecycle Works

The lifecycle runs from hypothesis to retirement, and each phase has its own inputs and gates. Skipping a phase usually shows up months after a rule ships, as noise, silence, or a rule nobody can explain.

Hypothesis and Requirements

Each detection starts as a question about attacker behavior that the team wants answered automatically, usually pulled from the backlog. Before anyone writes logic, the engineer confirms that the required log sources are collected and parsed.

For behavioral and statistical detections, the next step is a baseline: model normal activity first, then document why each threshold fits the environment.

ATT&CK itself now supports this phase more directly. With ATT&CK v18 in October 2025, MITRE replaced the detection notes on each technique with Detection Strategies and Analytics, which describe how a behavior can be observed across data components.

Build and Test

Engineers write the rule in a portable format such as Sigma or directly in the target platform's query language, then test it in layers. Unit tests check the logic against sample malicious and benign events. Integration tests generate real telemetry by emulating the technique in a lab that mirrors production. Libraries such as Atomic Red Team cover single techniques. Adversary emulation platforms such as Apache Caldera run multi-step scenarios.

Regression tests confirm a modified rule still fires, usually by replaying the same emulation on a schedule or after rule changes.

Deploy

A common deployment pattern uses a pipeline with a review checkpoint, a required true positive test, and a tracking ID on every rule. Many teams document each rule for that review with Palantir's Alerting and Detection Strategy framework, published in 2017, which covers the detection's goal, known gaps and assumptions, false positives, validation, and response.

Kaspersky's Securelist team warns that handing off deployment to SOC engineers can introduce errors when the two teams work with different data models. Daylight's own detection engineering process is one worked example of this phase, with new rules running silently against live data before they can alert.

Tune and Retire

Tuning starts the day a rule meets production data, and retirement is often the most neglected phase. Periodic content reviews, which can run on a quarterly cadence, catch rules aimed at decommissioned systems, rules a better control now covers, and rules that have gone a long period without firing.

A long quiet spell is a reason to check a rule before retiring it, since silence can mean a rare threat as easily as a broken data feed. Confirm the rule is still relevant, that its log sources still arrive, and that it fires on a test of the technique, then retain, revise, or remove it.

A silently deleted rule looks identical to one that never worked, so version every retirement with a change log and a deprecation note. Make sure it is disabled in production too, because repository changes do not always reach deployed content. In Microsoft Sentinel, for example, deleting content from a connected repository leaves it in the workspace.

How to Organize a Detection Engineering Function

One common mature model places detection engineering inside security operations, with engineering time protected from day-to-day alert triage. Protected time makes backlogs, sprint planning, and acceptance criteria workable, because without it the build work loses to whatever alert is open.

Kyle Bailey's Detection Engineering Maturity Matrix, published in 2021, describes the early-stage version of the staffing problem: detection quality depends heavily on the understanding of whoever writes the rule. At its managed level, the same matrix accepts either a dedicated team or detection and response engineers on a rotation. Shared standards remove the dependency on any one contributor:

A backlog with required fields, such as source, ATT&CK technique, priority, data requirements, owner, and status.
A charter that defines scope, intake, prioritization criteria, and approval gates for production.
Acceptance criteria for a shippable detection, including peer review, documented true positive testing, and enrichment attached before release.
A formal channel from incident response to the backlog.

Teams that run detection engineering as a shared service rather than a dedicated team need the same conditions plus explicit ownership. Others hand part of the work to a provider through detection engineering services and keep the backlog and acceptance criteria in-house.

How Detection-as-Code Works

Detection-as-code applies software engineering practices to detection content: rules live in version control, changes go through review, automated tests run on every change, and a CI/CD pipeline deploys them. The major platforms support it directly: Elastic maintains its own rules in a public detection-rules repository, and Splunk and Microsoft Sentinel offer repository-based workflows for detection content.

Sigma makes much of the approach portable. Teams write a rule in the vendor-neutral Sigma format, currently at specification version 2.1.0, and convert it with pySigma and sigma-cli into each supported platform's query language. Each platform still needs correct log source and field mappings, and the converted query has to be tested against that platform's data.

Adoption tends to stall partway through. In the 2026 SANS/Anvilogic report, a survey of 307 practitioners, 62% used version control for rules, 58% had peer review, and 42% had CI/CD integration. Respondents named time and resource constraints and a lack of in-house skills as the main barriers.

Detection Engineering Tools and Languages

Detection engineers work in the query language of each platform they deploy to, plus a few portable formats. The table below maps the common formats.

Detection Engineering Tools and Languages

	Where it runs	Typical use
Sigma	Converted to most SIEM languages	Portable log-based detections shared across platforms
KQL	Microsoft Sentinel and Defender	Analytics rules and hunting queries in Microsoft environments
SPL	Splunk	Correlation searches and detections in Splunk
EQL	Elastic Security	Event sequences and correlation over Elastic data
YARA-L 2.0	Google Security Operations	Multi-event rules over normalized security data
YARA rules	YARA and YARA-X scanning engines	Pattern matching on files and malware samples
Snort and Suricata rules	Network sensors	Signatures on network traffic

‍

Most programs pair these with an emulation library for testing, a version control system, and a coverage tool that maps rules to ATT&CK. Whatever the format, every rule should pass through the same review and testing gates.

Where AI Fits in Detection Engineering

AI now drafts candidate rules, converts between query languages, and suggests enrichment fields, but practitioners have not handed it the final call. In the 2026 SANS/Anvilogic survey, 83% of respondents used AI tools while only 42% trusted them for core work such as tuning detections.

The judgment that decides whether a rule performs well in one environment still comes from the engineer who knows its data, exceptions, and normal behavior. AI shortens the drafting step, and AI detection engineering depends on the same review, testing, and tuning against real telemetry as any other rule.

How to Measure Detection Engineering

Detection engineering metrics answer two questions: whether the function is shipping, and whether what it ships still works. Most programs track these:

ATT&CK technique coverage.
False positive volume and precision per detection over a set review period.
Time from identifying a technique to deploying a detection.
The share of alerts that ship with investigation context.
Detection health, tracked per rule as working or broken.

Define the denominator for each one, since the share of reviewed alerts that turn out benign is a different number from a statistical false positive rate across all benign activity.

Report coverage at the technique level. A USENIX Security 2024 study by researchers at the University of Illinois analyzed the 2022 rulesets of three commercial products. Technique coverage ranged from 48% to 55%, while tactic coverage reached at least 13 of 14 tactics. The gap shows how tactic-level reporting can hide large holes at the technique level, though the figures reflect 2022 rulesets mapped to ATT&CK v11's 191 techniques and leave out sub-techniques.

Coverage counts rules that exist, while health confirms they still run. CardinalOps' 2025 SIEM detection risk report measured deployed SIEMs and found detections for 21% of ATT&CK techniques on average. Of the rules that did exist, 13% would never trigger because of misconfigured data sources and missing log fields.

MITRE's Center for Threat-Informed Defense adds detection quality to the picture in a September 2026 post on measuring coverage. Two organizations can show the same technique as covered on a heatmap while the detections behind it differ widely in depth and quality, including how hard they are for an attacker to evade.

False positive tracking needs a follow-through step. The 2026 SANS/Anvilogic survey found that 59% of teams tracked false positive rates, but only 14% prioritized reducing them.

Why Detection Engineering Programs Stall

The same failure modes recur across maturity levels, usually because the work behind them has no owner:

Rule bloat: technical debt builds as environments change and rule dependencies break.
Silent failure: detections look active but stopped working after a schema change, a broken parser, or an ingestion gap.
Unmanaged backlogs: engineers pick work by interest or recency instead of structured priority.
Uncustomized vendor content: the 2026 survey attributes 66% of false positives to vendor-provided rules.

Each one traces to a gap in the structure above, whether retirement, health checks, backlog rules, or tuning of imported content.

Where to Start Building a Detection Engineering Function

With no process and a single contributor, start by inventorying every deployed rule with its last modified date and its false positive volume over a recent review period. Then stand up the backlog and charter described earlier, even in minimal form.

With some process but reactive maintenance, write the feedback loop from incident response into your incident response plan. After every confirmed incident, review which detections worked, which failed or arrived late, and whether telemetry, logic, tuning, or investigation guidance needs work, then route the actionable findings to the backlog. A formal review loop is often the highest-return structural change, because without one a technique that got through once stays a gap until someone fixes it informally.

With a defined process, metrics, and a growing backlog, make health monitoring continuous and turn the retirement steps above into a formal end-of-life process with owners and criteria.

Every alert a detection fires still needs an investigation. Daylight treats detection as an input to investigation. Its security experts build custom detection rules on customer log data with each customer's team, and alerts from those rules or from existing security tools start an investigation and, where needed, a response.

Frequently Asked Questions About Detection Engineering

What Does a Detection Engineer Do?

A detection engineer sits between the people who produce intelligence and the people who answer alerts, and writes the logic that connects the two. The core skills are reading attacker techniques closely enough to describe them as data, writing queries in each platform's language, and testing rules against real telemetry. Version control and basic software engineering are now part of the job too, as more teams adopt detection-as-code.

Is Detection Engineering the Same as Threat Detection?

Threat detection is the outcome: noticing malicious activity in time to act on it. Detection engineering is the upstream work of writing, testing, and keeping those rules running. Threat detection and response also covers investigating each alert and acting on it, work that sits downstream of the detection engineer's.

How Many People Does a Detection Engineering Function Need?

Team size has no universal minimum. Staffing depends on how many platforms and data sources the team covers, the development and maintenance workload, testing requirements, and release cadence. A practical way to size it is to measure the current load first: how many rules are deployed, how many platforms they run on, and how many tuning and new-rule requests arrive each month.

Can You Do Detection Engineering Without a SIEM?

Yes. Detection engineering applies wherever teams write custom logic: EDR custom rules, cloud provider alerting, data lake queries, and network sensors. A SIEM centralizes the data and makes cross-source correlation easier, and the lifecycle and metrics apply on any platform, with field mappings and tests set up for each one.

Which ATT&CK Version Should Detections Map To?

Map to the current version and plan for change. MITRE released ATT&CK v20 on October 13, 2026, with 15 Enterprise tactics, and major releases can rename, split, or deprecate techniques. Store the ATT&CK version alongside each mapping in the rule metadata so coverage reports stay accurate after an update.