Anyone who follows daily legal reporting knows how a story gets from a courtroom to a reader: someone writes it, an editor checks it, a version goes out, and afterwards corrections are logged when something turns out wrong. A similar habit has taken hold in cybersecurity under the name DetectionOps, and this note explains it in everyday terms for readers who follow legal and current-affairs coverage rather than server logs. It is general information about a working method, not advice on any compliance duty or legal question.

What DetectionOps means in one paragraph

Organisations that watch their computer systems for trouble rely on written rules: “raise an alert if a new scheduled task appears on this machine at an odd hour.” DetectionOps treats those rules like published copy. Each rule starts from a stated need, is drafted in a shared repository, gets tested against sample events, is reviewed by a second person, goes live through a controlled path, and is later measured and either tuned or retired. According to the Ops Atlas entry on DetectionOps, the label itself is an informal synonym rather than an official standard, and every documented use the Atlas could find traces back to a single European Commission project. The better-established names for the same work are detection engineering and detection-as-code.

That caveat matters for a news-minded reader. When a supplier says it “does DetectionOps,” you are hearing a nickname, and press for detail on which underlying practices the vendor really carries out.

The newsroom analogy, step by step

Think of a legal desk that publishes a daily digest. The editors do not simply type whatever arrives. They follow a chain, and the chain maps neatly onto the security practice.

• The assignment corresponds to the requirement. A rule should exist because of a specific threat the team cares about, not because a template happened to include it.
• The draft is the rule itself, kept in version control so each edit carries a name and a timestamp.
• The fact-check is testing. The Atlas, citing a vendor recommendation, suggests pairing each rule with a minimum of two checks, a malicious-looking event that must fire it and an ordinary one that must stay quiet.
• The second reader is peer review. No rule goes out because one person felt confident.
• Publication is deployment, and the entry describes a quiet trial of about a week in “shadow mode,” where the rule records what it would have flagged without paging anybody.
• The correction log is the tuning and retirement record: why a rule was loosened, who approved it, and when the exception ends.

Our own daily coverage, for instance the twenty-item Indian legal digest dated 19 June, depends on the same discipline of sourcing, checking and dating every item. Without the dates, nobody can tell whether a summary still reflects the current position, and the same is true of a detection rule whose last review is a mystery.

Why a tag is not proof

One of the more instructive warnings in the Atlas concerns coverage claims. Security teams often label rules with technique codes from the MITRE ATT&CK catalogue and then boast of covering a large share of the catalogue. The Atlas cites the Summiting the Pyramid project for a blunt point: a technique label on a rule, by itself, proves nothing about whether an attack would be caught. In publishing terms, putting a topic label on an article does not show that the article is accurate, current or even readable.

The Atlas offers a worked illustration with 120 rules. The tag heatmap suggested complete coverage, yet when the team staged realistic attacks, 18 of 30 prioritised implementations were actually caught within 90 days. That is 60 per cent validated coverage against an apparent 100 per cent. The lesson is to ask for the validation date and the method, the way a careful editor asks where a statistic came from.

Measuring without fooling yourself

The same worked example defines rule precision as true alerts divided by all alerts, whether they were truly malicious, harmless-but-real, or false. For one noisy rule that fired 40 times, only six were genuine, which gives 15 per cent. The entry also proposes a human-scale unit, the analyst minutes spent per genuine finding, and notes that this noisy rule cost roughly forty minutes each time. For a legal-news analogue, imagine measuring a desk not by how many items it pushes out but by how many reader-relevant items per hour of editorial effort.

Surveys cited in the entry point to a gap between intention and practice. In the 2025 SANS survey of 264 respondents, only 45 per cent said they reliably measure detection effectiveness, and 71 per cent named time and resources as the main obstacle. A later sponsor summary of 307 practitioners found 62 per cent using version control and 58 per cent using peer review, while only 42 per cent had automated delivery pipelines. Those are the sponsor’s own figures from a self-selected group, so read them as a mood indicator rather than a census.

Where the method stops

The Atlas draws careful borders. DetectionOps covers the rules, their requirements, tests, coverage evidence and tuning records. It does not cover the queue of alerts that analysts triage, the hunting for new threats, incident response, or the plumbing that collects and stores logs. Those belong to neighbouring disciplines, with information flowing between them: threat reports and missed incidents come in, finished alerts go out, and verdicts from the analysts return so rules can be sharpened. A newsroom has the same separation between the people who commission stories, the people who write them and the people who handle reader complaints.

Reading claims from suppliers

The entry contains a short myth-busting section that translates well to any procurement conversation. A supplier’s “90 per cent ATT&CK coverage” is a mapping, not a measured result, so the useful questions are which implementations, what precision, and when last validated. Importing thousands of ready-made community rules is a starting point, not a finished library, because each one must be tested against your own environment. And a small team does not need a grand platform: the Atlas says a lab can manage with a Git repository, a couple of scripts, a continuous-integration runner and one API.

There is also a candid note on emergency changes. When a live campaign is under way, a team may skip the staging trial, but never the tests or the review, and the change should be re-reviewed within five working days. Think of an urgent news correction: it goes out fast, but it still gets a second pair of eyes, and a follow-up check happens afterwards.

A short reading list for the curious

If this interested you, do not stop at security blogs. The habit of dating, sourcing and reviewing is the common thread, and our digest of legal developments from June 18 shows how a regular, consistently structured format makes later verification easier. The security world is learning what editors have long known: process quality shows up in the boring records.

One last point from the Atlas on timing. The European Commission’s security team began using its own tooling for this approach in September 2022 and released it as open source in 2024, according to the entry, and the account of the benefits comes from the project’s own side with no independent evaluation. Treat it as an interesting data point, not proof.