DetectionOps in 2026: What Survey Data and Standards Show

DetectionOps in 2026: What Survey Data and Standards Show

Digital health keeps adding connected equipment, patient portals and data exchanges, and every addition widens the surface a monitoring team must watch. Behind the scenes, the discipline that decides which events deserve attention has been changing quickly. This state-of-play note looks at DetectionOps as it stands in late 2026: how many teams actually practise it, what the standards bodies changed this year, and where the evidence is thin. It is an operations and governance review aimed at health-technology readers. It does not discuss clinical care.

A name still in flux

The first thing to know is terminology. According to the Ops Atlas page that catalogues DetectionOps, the term is just one of several overlapping labels with no formal standing behind it, and every documented use the editors found traces back to a single open-source programme run by a European public institution. The substance, by contrast, is covered in depth by the longer-established vocabulary of detection engineering and, alongside it, detection-as-code. Anyone benchmarking their organisation should search on that older vocabulary, because vendor reports rarely use the newer one.

That matters for reading the numbers below. Survey authors count practices, not slogans, so the figures describe the underlying habits whatever the team calls them.

Adoption: version control is common, pipelines less so

A 2026 summary from a vendor-sponsored survey of 307 practitioners gives the clearest picture of habits. Roughly six in ten respondents (62 percent) keep their detection logic under version control, 58 percent require peer review, and 42 percent have automated build-and-release pipelines. The pattern is a staircase: the cheaper the practice, the more widely it is followed.

The same survey exposes a priority gap. Fifty-nine percent of respondents track false-positive rates, but just 14 percent make cutting them an actual priority. Measuring noise without acting on it is a familiar pattern in any operational field, but the cost here is concrete, because every wasted alert consumes analyst time that could have gone to a real one.

An earlier, independent survey of 264 respondents conducted in 2025 reported that fewer than half could reliably measure whether their detections worked, that seven in ten named limited time or staff as the main obstacle, and that close to half lacked adequate access to the data feeds they needed. Put the two studies side by side and the story is coherent: teams are building the plumbing, but still struggle to prove value and to secure the inputs.

The standards moved this year

The public catalogue of attacker behaviours that most teams use for mapping changed shape in three releases. Version 18 (October 2025) brought in formal detection strategies and retired the earlier data-source objects. Version 19 (April 2026) divided the evasion-themed tactic in two: one half for stealth and one for impairing defences. By October 2026, version 20 listed 703 enterprise-level strategies and 1,770 analytics. For a team that maintained tactic tags by hand, each of those changes was a small cleanup job; the Atlas points out that tags typed manually tend to fall out of date first, while tags derived from technique identifiers stay in step automatically.

On the rule-format side, the open Sigma specification has stood at release 2.1.0 since the summer of 2025, and the community collection now holds over three thousand rules. The conversion library behind it jumped to a new major version in the first half of October 2026, yet two widely used companions had not yet been updated to accept it. For governance readers, the lesson is dull but important: pin dependencies, and treat a toolchain upgrade as a change with its own tests.

Tooling consolidation and retirement dates

Vendors are also reshaping their offerings. The Atlas notes that one large SIEM vendor’s content-management command-line tool no longer accepts outside contributions as the company shifts investment to a new studio product, and that Microsoft will stop supporting the Azure portal experience for its Sentinel service after 31 March 2027, recommending a custom-detections feature (still in preview, and tied to a premium licence tier) for new rules. If your hospital group runs that stack, a migration plan belongs on the 2026 calendar, not the 2027 one.

These are the kinds of dates that detection-as-code repositories handle well. When rules live in files rather than in a console, a platform change becomes a conversion project with tests, not a manual rebuild.

Where the measurement conversation is heading

Another development is a shift from counting tags to counting evidence. A research programme at a non-profit defender community published its “Summiting the Pyramid” analysis in 2023 and, in September 2026, released version 5.0 with a calculator for detection coverage. Its guiding statement, which the Atlas quotes, is that a mapping tag alone is not evidence of coverage. The Atlas’s worked example makes the gap vivid: in a month with 120 rules, test completeness was 70 percent and overall rule health 95 percent, but validated coverage, meaning prioritised implementations that emulation actually detected, was 60 percent while a tag heatmap claimed 100.

That is one illustration, not a sector average, and the Atlas is clear about it. But the direction is plain. Procurement questions are moving from “what percentage of the framework do you map to” toward “which implementations, at what precision, validated when”.

One more point for governance readers concerns ownership. In the surveys, resource and time pressure outranks every technical complaint, which implies that the bottleneck is rarely a missing product. It is a missing owner. A rule with a named maintainer, a review date and a test is cheap to keep alive; a rule with none becomes inherited clutter, and inherited clutter is where false positives accumulate. Health-technology leaders who ask for one-line ownership records across their rule inventory often learn more from that exercise than from any new tool purchase.

It also helps to separate three questions that often get merged in committee meetings: whether the team has the data, whether the team has a rule, and whether the rule has been shown to work. The surveys suggest most organisations can answer the first two with some confidence, and far fewer can answer the third.

What the evidence cannot yet tell us

  • Outcomes. The surveys measure practices and attitudes, not breach rates. No source reviewed here shows that teams adopting these practices suffer fewer incidents.
  • Independent case evidence. The single named adopter in the Atlas is a public-sector security team, and its account of replacing spreadsheets with a linked threat and rule repository comes from the people who built the platform. No outside evaluation is cited.
  • Health-sector specifics. The surveys here are cross-industry. They say nothing particular about hospital estates with older medical devices and strict uptime expectations.
  • Machine-assistance trust. The 2026 survey reports that 83 percent use machine-assisted tools while only 42 percent trust them for tuning, which suggests cautious experimentation, but the data stop there.

Reading this as a digital-health team

For readers who follow our coverage of connected care, such as the entry on the digital side of cardiology and its data-driven tools, the takeaway is practical. Every new data stream raises a monitoring question, and the answer is rarely another dashboard. It is usually a written requirement, a test, a review and a measured trial. Our earlier note on how observability tooling gives IT teams visibility covers the neighbouring discipline of watching system health, which supplies much of the raw data that detection rules consume.

Practical readings for the next twelve months

  1. Benchmark yourself against the staircase: version control first, then review, then automation.
  2. Pick one number you do not currently have, such as precision for your noisiest rule, and obtain it.
  3. Replace any coverage claim that rests on tags alone with a short list of validated implementations and dates.
  4. Pin your toolchain and calendar the platform retirement dates that touch you.
  5. Record every accepted blind spot with an owner and an expiry.

In short, DetectionOps in 2026 is a field with wide agreement on method, uneven adoption, rapidly shifting standards and thin outcome data. That combination rewards teams who measure modestly and honestly, and it penalises those who rely on headline coverage percentages.