I read my first detection engineer posting in a fintech security operations center (SOC) and thought I knew the job. Write rules and map them to MITRE ATT&CK. Tune false positives. I'd been triaging alerts on the night shift for two years.
This felt like the natural promotion. Three months in, I was spending most of my week on none of those things: debugging a log pipeline that had silently dropped a field name after a vendor agent update, rewriting an exclusion list a former engineer had built and never documented. The JD describes the visible work.
The rest is maintenance, debugging broken pieces and writing down what nobody captured. Most hiring teams writing a detection engineer JD are writing a job description for the wrong role.
In Brief:
- Most detection engineer JDs describe rule writing and ATT&CK mapping. The actual work includes maintaining undocumented detections and broken telemetry, plus writing investigation context no one advertises.
- A detection can pass its original tests, remain marked active in the rule library, and stop catching the behavior it was built for because a log schema changed underneath it. No JD warns you that catching this is your job.
- Detection engineers own the telemetry their rules depend on, and many are building on incomplete visibility without knowing it. The SANS 2025 Detection Engineering Survey reports only 45% of organizations have adequate access to the data feeds their detections depend on.
- The best hiring signal is whether a candidate has maintained detections through a schema change and worked an incident from the receiving end.
What detection engineering actually is
Detection engineering is the systematic process of building and testing logic, then maintaining what turns telemetry into actionable alerts. That's true and almost useless, because it gives equal weight to building and maintaining when the operational reality is lopsided toward the second.
A rule is an implementation detail; the engineering work is proving that coverage exists and keeping it true as the environment changes. Rule writing produces the visible artifact; detection engineering is the discipline of keeping that artifact working against a moving target.
Telemetry ownership: you can't detect what you can't see
The JD implies your detections run against clean, complete data that some data engineering team delivers to you. The work requires owning the pipeline underneath the rule. When it breaks, the rule breaks silently and you're the one who finds out. That same survey found only 45% of organizations have adequate access to necessary data feeds, which means more than half of detection engineers are building logic on incomplete visibility and don't always know it.
Telemetry outages fail quietly because the security information and event management (SIEM) system keeps showing the data it still receives, so a rule can remain enabled in the console while the log sources it depends on have gone dark.
I learned to treat heartbeat checks and ingestion volume baselines as part of my own surface, with parse error rates alongside the platform team's work. Detection rules degrade when source infrastructure changes, and the only person watching for that drift is usually you.
Most of the work is maintaining detections, not building them
The JD frames the role as a builder shipping new coverage. The work is closer to a sysadmin keeping a hundred existing detections from quietly rotting. Detections age like software, and nobody staffs for the maintenance.
I've had a rule pass every original test and live in the library as active, then fail to catch the exact technique it was built for. The over-tuning trap makes it worse: heavy exclusion logic creates fragile, high-maintenance rules, and those exclusion lists are exactly the kind of thing an engineer builds under deadline pressure and never documents. Many teams measure false positives without having the capacity to reduce them, and that alert fatigue feeds back into the same queue. That backlog, knowing the problem exists but never having the time to touch it, is where most of the real week goes.
Your best detections come from incidents your SOC already worked
The JD says you'll write detections from threat intelligence. The work is that your best detections come from incidents your own SOC already worked. Integrating that feedback is a discipline most orgs never operationalize. The strongest detections usually start after someone has had to chase an alert all the way through a real incident, and I made this shift the hard way after leading a credential compromise response where the inherited detection had missed the lateral movement entirely.
Working that incident changed how I read every alert afterward. Instead of just closing a false positive, I started asking why it fired and what data supported it, then what blind spot it revealed. Detection work and incident response often live in separate operating rhythms, so the lessons from a real incident die in the postmortem doc instead of becoming a rule. Tighter integration between detection and incident response matters because the SOC analyst who flags a recurring alert as noise is feeding your tuning backlog whether your process captures it or not.
A detection without investigation context is an alert without triage
The JD treats the detection rule as the deliverable, but a rule that fires without embedded context forces every analyst who sees it to reconstruct the same enrichment from scratch. They're pivoting across endpoint and identity consoles and cloud tools that weren't designed to work together, which is the difference between fast alert triage and slow, multiplied across every shift. Writing that investigation context is engineering work: it determines whether the rule survives contact with an analyst at 3 am.
It also creates a coverage ceiling: rules that analysts can't investigate become rules the SOC can't use, so engineers quietly hold back logic the analyst team can't absorb. Investigation guides attached to the rule as Markdown documents that render in the alert workflow give the analyst the queries and context without leaving the screen. Every detection I ship now carries a documented purpose, triage steps, and a change log. It's the part of the job the JD never mentions.
The role translates threat intelligence into detection logic
The JD often reduces ATT&CK mapping to a tagging exercise, but the work is translating a threat report into working, back-tested logic against the telemetry you actually have. After a report documents observed TTPs, you map them to ATT&CK techniques and write the detection artifact: a YARA or Sigma rule back-tested against production data. Sigma is a translation layer, letting you write once and compile to whatever SIEM you run, which matters when threat intel moves faster than platform migrations.
The top ATT&CK techniques in 2024 mirrored 2023 almost exactly. Command and scripting led at 44.6%, followed by obfuscation at 37.3% and remote services at 35.3%. These figures have been stable for years, which means a failure to detect T1059 is a coverage maintenance problem, looping straight back to the unglamorous work.
The parts of the role no job posting advertises
If I wrote an honest JD, it would lead with the things every posting omits. Those omissions are what actually consume the week. They are also the work that decides whether shipped detections keep working.
- Documentation and reporting: Documentation is institutional memory: every closed alert should produce a record that gives the next analyst context and feeds the next tuning cycle.
- Suppression and exclusion engineering: A suppression is a real capability you build to dynamically mute alerts for known service accounts and scheduled tasks, and maintaining those lists is a discipline.
- The vendor rule tax: Vendor-provided rules are a major source of false positives, and you inherit the job of tuning logic you didn't write and can't always see inside.
- The cross-functional crossfire: Detection engineering sits between threat intel, hunting, SOC ops, and red teams, each of which points at you when something breaks, none of them coordinated.
None of this fits in a JD bullet about writing detection rules, but all of it is the actual operating load the role carries.
What to look for when you're hiring a detection engineer
I'd start with the opposite signal from rule output and SIEM query fluency: who has kept detections alive. The SANS 2025 Detection Engineering Survey finds 41% of organizations report difficulty finding skilled detection engineers, and the hybrid profile is genuinely rare. Detection-as-code needs software engineering habits that many detection teams are still building, so screen for it directly.
Ask a candidate to walk you through a time a detection silently failed and how they found it. Ask what an exclusion list they inherited looked like and what they did with it. Ask whether they've worked an incident from the receiving end, because the engineers who've lived the tug-of-war between writing alerts and triaging them build detections analysts can actually use. Anyone can show you a rule; the ones worth hiring can show you a detection they kept working through schema changes and tuning fights after an incident postmortem.
Frequently asked questions about detection engineers
What does a detection engineer do?
A detection engineer builds and tunes the logic that turns telemetry into actionable alerts, then maintains that logic as log schemas and agents change and threats shift. The visible part is writing rules and mapping them to MITRE ATT&CK. The larger part is keeping existing detections alive, owning the telemetry pipeline underneath them, and embedding the investigation context that makes an alert triageable.
What skills does a detection engineer need?
Query language fluency in at least one SIEM (SPL, KQL, or similar) and MITRE ATT&CK knowledge at the technique and sub-technique level, plus scripting in Python or PowerShell. Detection-as-code maturity matters too: version control and CI/CD tied to test-case authoring. The rarest and most valuable trait is real software engineering proficiency, because detection-as-code turns rules into software artifacts that have to be reviewed, tested, versioned, and maintained.
How is detection engineering different from threat hunting?
Detection engineering is a systematic, logic-based process to catch known threats and runs largely on automation. Threat hunting is exploratory and manual, chasing anomalies that no rule covers yet. They feed each other: a hunt that uncovers a novel technique becomes a new detection rule, and that rule frees the hunter to look for the next unknown.
Do small SOC teams need a dedicated detection engineer?
Usually not at first. With one or two people covering all SOC roles, a dedicated detection engineer is unrealistic, and you're better off building query fluency and pipeline fundamentals before formalizing custom detections. Staff the role when maintenance load becomes the thing consuming your week.
What does a detection engineer's day actually look like?
Largely interrupt-driven, with a meaningful share going to debugging a detection that fired wrong or stopped firing and tuning rules against false positives. Telemetry drift after an agent or schema change can take the rest. New rule development competes for whatever time is left, which is often less than the JD implies, and documentation is the part most engineers leave for last.