What we did
A customer wanted to consolidate security tooling, which is a real need and a good reason to trial Datadog's security products. To keep the cost and the disruption down, we scoped the trial to a small subset of their tenant. A few accounts. A few workloads. Enough to see the product, we thought.
Two weeks later the trial had generated no security events. Not because the estate was clean, but because we were watching a quiet corner of it for a fortnight. The customer looked at an empty detections list and drew the only conclusion an empty list supports: this does not do anything our current tooling does not. There was no wrap-up meeting, because nobody had booked one. The conversation drifted into a chat thread and stopped. No decision. Not a no, which we could have learned from. Nothing.
What the trial found anyway
Here is the part that still bothers us. In that small slice, the posture scan found a server that had fallen off the patch schedule and a user account that was inactive but still had access. Two real findings, in a corner of the estate, in two weeks. Both went into the customer's improvement backlog, because findings do not stop being true when a commercial conversation stalls. But neither was the kind of event that makes a detections dashboard light up, so neither counted as the trial "showing value". The trial had, in fact, shown value. We had set it up so that nobody would recognise it.
A security trial scoped to limit cost will produce a quiet trial. Quiet reads as worthless. The scope decision was reasonable. The outcome was guaranteed.
What we got wrong, in order of how much it mattered
- Scope. A security product proves itself on the whole tenant or not at all, because the events it exists to catch happen at the edges you did not include. Full-tenant scope costs more for two weeks. A trial that proves nothing costs the whole decision.
- No owner on the customer side. We had a sponsor, which is not the same thing. Without a named person whose job for two weeks included the trial, engagement depended on who happened to be free.
- No dates. A kickoff happened. A mid-point review and a wrap-up did not, because they were never in a calendar. A trial without an end date has no end.
- No success criteria. We never wrote down what "it worked" would look like: which detections we expected to fire, which findings we expected to confirm, how it would compare with the tool it was meant to replace. So nothing could be judged against anything.
- Side-of-desk. The trial lived in a chat channel. It needed to live in a project board with tickets, like any other piece of delivery, so that progress was visible and silence was noticeable.
We also had no vendor support during the window, which did not help, but is not an excuse. The other five were ours.
How we run trials now
Every trial is a project. Full-tenant scope for two weeks, or we say no to the trial. A named owner on each side. Kickoff, mid-point review and wrap-up booked before day one, with the wrap-up framed as the decision meeting. Success criteria written down in the kickoff, including what the trial would have to show for the answer to be yes, and what would make it no. Whatever the trial finds goes into the backlog on day one, with a ticket, regardless of what happens commercially, because the point of looking is to act on what you see.
For security products in particular, we start with Cloud SIEM and Cloud Security Management, because those are the two that produce something a security lead can compare against what they already run, and we add vulnerability management and workload protection once the first two have an owner.
Where we fit
Critical Cloud runs Datadog trials as projects, not favours. FETCH is our complimentary trial enablement: scoping, agent installation, the first dashboards and detections, and the three meetings that turn a trial into a decision. When the decision is yes, the Threat Management accelerator takes it into a four-week production rollout with detections routed to named owners, and Critical Support keeps watching afterwards, which is the part a trial cannot show you.
We got this one wrong first. That is why the rules exist.
Frequently asked questions
Why do security tool trials so often end without a decision?
Because the scope is set to limit cost and disruption, and a small scope produces a quiet trial. No events in the window reads as no value, when it is the expected result of watching a corner of the estate for two weeks. Add no dedicated owner on the customer side and no end date with a meeting attached, and the trial drifts into a chat thread and stops. The tool is rarely the reason.
How should a Datadog Cloud SIEM or Cloud Security trial be scoped?
Full tenant, two weeks, with success criteria written before day one: which detections you expect to see fire, which posture findings you expect to confirm, and what the comparison with the current tooling looks like. A named owner on each side, a kickoff, a mid-point review and a wrap-up booked up front, and the whole thing tracked as a project. Whatever the trial finds goes into the backlog regardless of the buying decision.
Does Critical Cloud run Datadog trials for customers?
Yes. FETCH is our complimentary trial enablement: we scope the trial, install agents, build the first dashboards and detections, and run the kickoff, mid-point and wrap-up so the trial ends in a decision. For security specifically, the Threat Management accelerator takes a successful trial into a four-week production rollout with detections routed to named owners.
Sources
- Our own trial wash-up, August 2026. The customer is not named and the sector is withheld on purpose. The two findings are described in general terms only.
- Datadog, Bits AI Security Analyst announcement, March 2026, for the general availability date. We do not repeat the vendor's outcome figures.