Eight Checks Before You Recommend ThreatOps to a Client

Clients keep asking consultants a version of the same question: should we be doing ThreatOps? The honest reply starts with a definition problem. According to the Ops Atlas, no formal standard defines the term, and a search of the NIST glossary comes back empty, although the practices inside it, threat intelligence and threat hunting, are well established. An adviser who answers “yes, buy this” without pinning down the meaning is selling a label. Here are eight evidence-based checks to run before recommending anything, each tied to a specific point in the Atlas entry.

1. Check what the client really means by the word

The Atlas lists at least three vendor uses of the name: an intelligence-driven blocking service from 2022, a managed detection brand and a hunting-training platform that existed between 2020 and 2026. A procurement document that says ThreatOps could therefore mean a subscription, a team or a training game. Settle the scope in writing before a single workshop is scheduled. The Atlas itself defines the discipline as intelligence and hunting run as one operation, and it explicitly excludes alert triage, incident handling, detection engineering, vulnerability prioritisation and telemetry plumbing.

2. Check whether there is data to hunt in

Hunting needs history. The Atlas decision tree begins with a hard stop: if the client cannot show three months of usable telemetry, repair that before anything else. This single check disqualifies a surprising number of engagements, and it saves the consultant from running a hunt that cannot reach a conclusion.

3. Check that someone owns the findings

The same tree has a second branch: with no named owner for findings, the Atlas recommends buying managed hunting rather than building a team that nobody will act on. For a consulting practice the lesson is to ask who receives the output. A hunt that ends in a report to nobody is a cost line, not a capability.

4. Check the requirements before the sources

Most clients start with feeds. The Atlas starts with priority intelligence requirements, five to eight at a time, where every entry pairs a lone question with the fact that answers it and the decision it feeds, and the set is reviewed each quarter. A consultant who begins by auditing the subscription list will find waste, but one who begins with requirements will find direction. If stakeholders cannot name a decision that intelligence would change, the tree says to run a lean advisory model instead of a full build.

5. Check the blocking rules against measured precision

This is where the evidence is most concrete. The Atlas gives a sample policy that allows automatic blocking only when the source is rated A or B, credibility is one or two, the feed’s precision exceeded ninety percent over ninety days and the entry is absent from every allowlist. Any responder holding the pager may reverse a block immediately, with the intelligence owner reviewing inside sixty minutes. Its worked quarter shows a feed at fifteen percent precision, which stays alert-only. Ask clients for their actual precision figure, because most have never measured it.

6. Check how well the programme handles stale facts

Indicators decay. The sharing standard leaves expiry optional, so unless the client sets lifetimes, entries live forever. The Atlas example policy gives addresses fourteen days, URLs thirty, domains sixty and file hashes a year. A quick audit of how many entries in the client’s store are older than their type’s lifetime gives you a number that is easy to put in front of an executive.

7. Check which framework version the maps were drawn against

Frameworks move. The Atlas notes that the October 2026 release of the ATT&CK knowledge base carries 15 enterprise tactics and 227 techniques and introduces two new tactic names, which breaks mappings built on older versions. If a client’s coverage spreadsheet predates it, the heat map is describing a previous catalogue. The Atlas goes further and argues against treating a coloured grid as a goal at all, quoting the position that not every technique in the catalogue is intended to become a detection.

8. Check the metrics for vanity

Ask which numbers the client reports upward. The Atlas prefers four ratios: how many requirements are covered, how much intelligence turns into action, how many hunts yield an artefact and how many gaps get closed. It names indicators ingested, reports published, hunts started and heat maps as vanity measures. In its worked quarter the four ratios come out at eighty-three, thirty-five, forty-two and forty-four percent, which is a believable picture of a middling programme rather than a polished one.

A worked illustration of check five

Consider a generic mid-sized client whose firewall pulls an address feed and drops anything on it. A week after go-live, the helpdesk reports that customers cannot reach a hosted payment page. The cause turns out to be a listed address that belongs to a large content delivery network shared by thousands of innocent sites. Nobody did anything unusual; the feed simply had no concept of shared hosting. A consultant who had asked for the precision figure and the revert rule in advance would have recommended alert-only mode and a monthly count of blocks that were reverted, a metric the Atlas suggests tracking. The fix costs nothing, and the conversation about it is far easier before the outage than after.

The same pattern applies to every item on the list. Each check exists because a particular failure is common and cheap to prevent, so treat the list as a pre-flight inspection rather than a maturity grade.

What the public record adds

Two external anchors help a consultant keep the conversation honest. The 2026 edition of a large incident-response report cited by the Atlas puts the global median dwell time at fourteen days, up from eleven the year before, with espionage-style cases running to 122 days. And the February 2024 joint advisory on a state-linked intrusion set found conventional indicators to be generally lacking and described footholds kept for at least five years, which is why the Atlas warns that an indicator sweep alone cannot support a claim that the client is “not affected”. These are context, not a sales pitch, and a careful consultant presents them that way.

Fitting this into a normal engagement

None of the eight checks requires new tooling, and each fits into the assessment phase that most consulting engagements already contain. If you follow a structure like a blueprint that runs from assessment through enablement, the checks belong in the assessment, and the thirty-sixty-ninety-day plan from the Atlas becomes the enablement roadmap. Teams that already weave security into delivery pipelines will find the handoffs familiar: a validated hunt finding becomes a detection request, then moves through the change process you already run for rules.

A closing caution on scope creep. ThreatOps is an input to security operations, not a replacement for it, and a consultant who promises round-the-clock monitoring under this banner is mixing disciplines. The Atlas draws the line firmly, which is useful when a client asks for everything at once.

How to report the results

Present the eight checks as a one-page scorecard with three states each: confirmed, partial or absent. Resist the urge to total the marks. A client with six confirmed items and no named owner for findings is in a worse position than one with four confirmed and an owner, and a single sum would hide that. Pair each absent item with one concrete next step and a date, so the scorecard doubles as the first sprint plan.

Where to verify these claims

Every figure above comes from one place, and clients deserve to read it first-hand. The full Atlas article on the ThreatOps discipline and its maturity model sets out the scope, the sample policies and the worked metrics in detail. Bring it to the kickoff, mark the eight checks, and let the client’s own answers decide whether the engagement is a build, a managed purchase or a lean advisory.

Kabir Malhotra