What happened
We integrated our endpoint protection platform's vulnerability feed into the compliance platform that runs our ISO 27001 programme. Sensible. More evidence, less manual work. The integration imported every finding at every severity, which is its default, and the risk score reacted exactly as designed.
Most of the volume was one thing. A low-severity flaw in a widely used cryptography library, present on every laptop because every laptop has the library. One issue, counted once per machine, with no realistic path to exploitation on a managed endpoint. Underneath that pile sat the findings that did matter: three critical vulnerabilities in two of our own code repositories, a device remediation overdue since the start of September, and a handful of process failures where tickets were missing the severity tag the audit expects.
Nobody had decided to bury the critical items. The import rule had made that decision on our behalf, and the score, which is supposed to tell us where to look, was telling us to look everywhere.
Vulnerability noise is alert noise wearing a different badge
If you run production on Datadog, this story is familiar. Across the estates we assess, most monitors never fire and a handful of monitors produce nearly all the alerts. The noisiest one is often a threshold that was reasonable on the day it was set. Security findings behave the same way: a few sources produce almost all the volume, the volume is dominated by things nobody can act on, and the rare item that needs a human by Friday is indistinguishable from the thousand that do not.
The second pattern is the same too. In the estates we review, security detection rules routed to no owner is one of the most consistent findings. The rule exists, it fires, it goes to a channel or a dashboard, and the channel is read when someone remembers. A finding without an owner is a log entry. So is a monitor.
A scanner that imports everything and routes it to nobody has the same failure mode as a monitor that pages for everything and is muted by Tuesday. In both cases the control is on, the evidence says so, and nobody is acting on it.
What we changed
- Filter at import. The feed now brings in critical and high findings and leaves the rest where the scanner keeps them. The low-severity library flaw is still patched, by the normal update cycle, without appearing as evidence of risk a hundred times over.
- A finding is a ticket, automatically. We are automating the path from the compliance platform to the ticketing system, so a critical finding arrives as work assigned to a person with a date, not as a number on a dashboard. Manual ticket creation was the step that kept not happening.
- Treat each finding class like a monitor. Owner, threshold, runbook. The code vulnerabilities belong to the engineer who owns the repository. The endpoint findings belong to whoever runs devices. The process failures belong to the person who owns the process. Written down.
- Measure time to a human, not findings count. The number that now goes in the review is how long a critical finding waited before someone acted. The total count is reported, and ignored.
We also started rotating the triage duty, so the person reading the findings each week is not always the same person who is also on call, also delivering, and also tired.
Where we fit
Critical Cloud sets security detection up with the ownership built in, because we have watched what happens when it is not. The Threat Management accelerator puts Datadog Cloud SIEM detections in place with a routing model, so every rule reaches a named person. The Cloud Security accelerator does the same for posture findings, delivered as a prioritised list with owners rather than a raw export. Both are fixed-scope, four-week deliveries. Inside Critical Support, we keep the routing honest as the estate changes, which is the part that does not fit in four weeks because it never ends.
We publish this because we would rather show a customer the gap we found in our own estate than describe a process we have never had to use. We operate and evidence the runtime controls that support your obligations, and sometimes the evidence is a number that went up for the wrong reason.
Frequently asked questions
Why does a vulnerability scanner make security worse when it is first switched on?
Because it imports everything at every severity, and the volume hides the handful of findings that matter. One widely used library with a low-severity flaw appears once per machine, so a team of ten sees ten findings for one issue that nobody can exploit, while the three real vulnerabilities in the code sit in the same list. The scanner is not wrong. The import rule is the problem, and it is a default.
How should security findings be routed in a small team?
The same way as a production alert. Each finding class has an owner, a threshold and a runbook. Critical and exploitable findings become a ticket automatically, assigned to a named person with a due date. Everything below the threshold is reported weekly, not individually. The metric to watch is the time between a critical finding appearing and a human acting on it, not the total count.
Does Critical Cloud set up security detection with ownership built in?
Yes. The Threat Management accelerator puts Datadog Cloud SIEM detections in place with an ownership model, so every rule routes to a named person, and the Cloud Security accelerator does the same for posture findings with a prioritised list rather than a raw export. Both are fixed-scope, four-week deliveries. In Critical Support we keep the routing honest as the estate changes.
Sources
- Critical Cloud quarterly ISMS management review, October 2026. Our own estate. Product names omitted on purpose.
- The alert-noise and routing patterns are from our own assessments of customer estates. We publish the pattern, not the counts.