If you freelance in operations and a client’s security lead asks whether you can “do DetectionOps,” you are being invited to bid on a way of working, not a tool. The trouble is that there is more than one defensible way to deliver it, and the choice changes your scope, your risks and the evidence you can show afterwards. This comparison sets three delivery models side by side using the facts in the Ops Atlas entry, so you can recommend one with reasons rather than habit.

What you would actually be selling

The Ops Atlas description of DetectionOps defines the work as running detection logic through a software-delivery lifecycle: requirements, coded rules, tests, peer review, pipeline deployment, production measurement, tuning and retirement. It also warns that the name is an overlapping synonym and not a standard, with documented uses tracing to one European Commission project, and the same work already has mature documentation under the labels detection engineering and detection-as-code. The wording will shape your pitch: lean on the older, better-documented names in your proposals so the client can look up what you mean.

Scope matters even more. The Atlas places the alert queue, threat hunting, incident response, log onboarding and machine-learning analytics outside the practice. A contract that quietly absorbs those will balloon, so write the boundary into the statement of work, a habit also recommended in our beginner piece on common questions new freelancers ask before taking contracts.

Model A: native queries kept as code

What it is. You export the client’s existing rules in the monitoring product’s own query language, put them in Git, and add tests and a deployment script. Nothing is translated into a neutral format.

Evidence for it. The entry’s worked judgement favours this route for a team with a single monitoring platform whose requirements and tests are written in platform-neutral language, giving the example of storing KQL as code. It also stresses that a small environment needs little: just a Git repository, a pair of small scripts, some CI compute and a single API endpoint.

Strengths. Fast to start, low licensing and tooling surface, easy handover. Your deliverable is understandable to anyone who already knows the platform.

Weaknesses. Switching platforms later means rewriting. Portability is bought with extra effort at that moment, so the client should know before agreeing.

Model B: a portable rule format with converters

What it is. Rules are authored in Sigma, whose spec at version 2.1.0 requires a title, a log-source description and a detection condition, and whose rule IDs are version-4 UUIDs. Converters then generate queries for each target platform.

Evidence for it. The Atlas notes that a community repository of more than three thousand Sigma rules exists, useful for inspiration rather than wholesale import, and it lists Sigma among the standards worth knowing. A multi-platform client or a managed-services shop gains real leverage from one source feeding several backends.

Strengths. Portability, a shared language between clients, access to a wide community.

Weaknesses. Another layer to maintain. As a warning, the entry recounts what happened in early October 2026: the Python conversion library jumped to a second major version while the stock command-line wrapper and one SIEM backend kept demanding the first. The result for anyone unpinned is a broken pipeline overnight. If you pick this model, price in version pinning and a scheduled upgrade window. Sigma is also explicitly not mandatory, per the Atlas’s myth section.

Model C: advisory only, with the client’s team doing the work

What it is. You deliver the assessment, a maturity score and a thirty-sixty-ninety plan, then coach the client’s own engineers.

Evidence for it. The entry’s five-level ladder, from ad hoc through versioned, tested, validated and finally a managed portfolio, gives you a ready scoring frame, with thresholds such as at least ninety per cent test completeness at level two and ninety-five per cent rule health at level four. It also quotes Elastic’s warning that rushing the tiers causes burnout, which supports a slow, sequenced engagement.

Strengths. Light delivery risk and a clear end date.

Weaknesses. You hold less control over outcomes. If the client never writes the tests, your assessment gathers dust, and evidence of impact is harder to show.

Comparing them on the dimensions that matter

• Time to first value: A is fastest, C next, B slowest because of the converter set-up.
• Portability across platforms: B wins clearly, A is weakest.
• Ongoing maintenance load on you: highest for B, moderate for A, lowest for C.
• Visibility of results: A and B produce repository history and test results you can screenshot; C produces a report.
• Dependence on client discipline: highest for C.

What to measure so the client can see value

Whatever model you pick, agree the metrics at the start. The entry’s worked example gives four candidates: test completeness (84 of 120 rules, seventy per cent), validated coverage (18 of 30 prioritised implementations detected in emulation within ninety days, sixty per cent), rule health (114 of 120) and change failure rate (3 of 50). It also proposes analyst minutes per true positive as a readable unit. A report with these numbers is far more persuasive than a heatmap of technique tags, and the Atlas is plain that a label on a rule does not show the rule would catch anything.

Evidence matters for relationships too. First-time clients are wary, and showing a before-and-after of precision per rule is an easy way to earn confidence; the softer side is covered in a long-term relationships guide, building trust with clients on a first engagement.

A caution about sources

The only sourced case in the Atlas is the European Commission’s own security team, which says it manages hundreds of threat vectors, each linked to detection objectives and rules since 2022. The entry flags that this is the project’s own account and has not been independently assessed. Do not quote it to a client as proof that the method delivers results. Survey data in the entry is similarly modest in strength: in a 2025 survey of 264 practitioners only 45 per cent reliably measured detection effectiveness, a useful sales context but not a guarantee.

Recommendation

Start from the client’s platform count and their appetite for upkeep. One platform and a small team points to Model A with a roadmap toward tests. Several platforms or a service-provider client points to Model B with strict pinning. A mature team that merely wants an outside view fits Model C. In every case, write the scope boundary, agree the metrics and keep the evidence in the repository.