Findings somebody fixes,
not a dashboard of red.
Datadog Cloud Security finds the open bucket, the unused admin role, the unpatched image and the process that should not be running. We implement it inside the Datadog you already run, decide with you which findings matter, and operate it every month so each one has an owner and a date.
Quick facts
Related
- Cloud SIEM, detection on the logs the estate already sends
- Code Security, the same findings view, earlier in the pipeline
- Security and compliance at Critical Cloud, the certifications we hold ourselves
The state of the runtime, checked continuously, in the tool the engineers already open
Security findings in a separate console get looked at before the audit. Findings next to the service map, the host and the trace get looked at on Tuesday, by the engineer who can fix them. That is the whole argument for doing this inside Datadog.
Posture, against rules you chose. Cloud accounts and Kubernetes clusters checked against misconfiguration rules, continuously. A public bucket or an open security group is a finding within the hour, not at the next review.
Identity, with the permissions nobody uses. Roles that can do more than they ever do, keys that have not rotated, and the path from a leaked credential to an admin. Shown as a graph, not a spreadsheet.
Vulnerabilities, on what is actually running. Hosts, containers and images scanned for known CVEs, ranked by whether the vulnerable package is loaded and exposed, not by the CVSS number alone.
Threats on the workload, and the evidence after. Processes, file changes and network activity watched at runtime by the Agent. Findings mapped to ISO 27001, SOC 2, PCI DSS and CIS, with the history kept for the auditor.
Switched on across everything, every rule enabled, and a findings list no team can work
How it bills. Cloud Security is billed per host it protects, whether the host is covered by the Agent or by agentless scanning, with containers metered against a per-host allotment. An organisation buys one plan, CSM Pro or CSM Enterprise, and Enterprise adds Workload Protection. Agentless scanners run inside your own cloud account, so their compute and networking appear on the cloud provider bill. Datadog publishes the meters and rates. The scope is the lever: a staging cluster and a batch fleet rarely need workload protection, and an account with nothing in it does not need posture scanning. We decide the scope with you before the first host is enabled.
The configuration traps. Every rule enabled on day one, including the ones the business has already accepted as a risk, so the real findings sit in a list with the noise. No ownership routing, so the finding reaches a shared channel and stays there. Agents rolled out without the security features, so posture is covered and the workload is not, and nobody notices because the dashboard still shows green for the accounts. Suppressions added without a reason, so a year later nobody knows whether the open port was accepted or forgotten.
Field noteThe most common gap we see is that the findings exist and nobody is paid to look at them. The tool was bought for the audit. After the audit, the list grows.
Field noteIdentity findings are the ones that stay open longest. The over-privileged role belongs to a pipeline somebody is afraid to touch, so the finding gets suppressed instead of fixed, and the suppression has no expiry.
Field noteVulnerability counts drop fast once the list is read through Datadog's severity score, which weighs production, exposure and exploit availability on top of CVSS. The first number is the whole estate. The useful number is the exposed slice, and it is the one worth working.
Field noteCompliance reports are opened once, for the evidence pack, and the gaps found that week were fixable long before. The finding had been sitting in the tool. Without a review cadence, it waited for the audit.
Scope first. Rules second. An owner for every finding before the first one lands.
The Cloud Security Accelerator is a four-week, fixed-scope delivery. If Datadog is new to the estate, LaunchPad runs the platform rollout first. The sequence inside the accelerator is the same either way.
- Agree the scope. Which cloud accounts, which clusters, which hosts, and which of the five capabilities each one gets. Production first. Everything else justified, not assumed.
- Connect the accounts and roll out the Agent features. Read-only integrations for posture and identity. Agent security features enabled on the hosts in scope, through your deployment tooling, not by hand.
- Choose the rules. Start from the framework you are measured against, switch off rules for risks the business has accepted in writing, and set a reason and an expiry on every suppression.
- Route the findings. Each finding type goes to a named team through the channel they already use. Critical workload threats page the on-call. Posture drift opens a ticket. Nothing lands in a channel with no owner.
- Work the first list together. The initial findings are triaged with your engineers in the first fortnight. The ones in the runtime we operate, we fix. The rest leave with an owner, a priority and the evidence attached.
- Hand over, in writing. Scope, rules in force, suppressions and their reasons, routing map, and the open findings on the day we finished.
A posture tool with no review cadence stops matching the estate it watches
New accounts appear. A role is widened for a migration and never narrowed. A base image goes out of support. Managed Observability is the monthly service that keeps the scope, the rules and the findings list matching the estate as it is now.
Every month, the new findings are triaged. Against the rules in force and the suppressions on file. Accepted risks are re-confirmed or expired. Nothing is left in a state nobody has looked at.
Scope follows the estate. New accounts, clusters and hosts are added to coverage when they appear, and decommissioned ones are removed from the bill.
The evidence is kept, dated. Compliance posture per framework, finding history, who fixed what and when. When the questionnaire or the auditor asks, the answer already exists.
The threat is contained, not forwarded. Under Critical Support a workload threat signal pages our engineers, 24x7. They isolate the runtime and tell the owner, in that order.
We operate the stack. You own the product.
We are not a security company, and we do not pretend to be. We are a managed runtime operator. We run the detection and posture tooling inside your Datadog, triage what it finds, fix what sits in the runtime we operate, and route the rest with the evidence attached. We operate and evidence the runtime controls that support your compliance obligations. The policy, the auditor and the decisions stay yours.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Cloud Security, answered plainly
What is included in Datadog Cloud Security?
Five capabilities that share one Agent and one findings view. Cloud Security Posture Management checks cloud accounts and Kubernetes against misconfiguration rules. Cloud Infrastructure Entitlement Management finds over-privileged identities and unused permissions. Vulnerability Management scans hosts, containers and images for known CVEs. Compliance maps findings to frameworks such as ISO 27001, SOC 2, PCI DSS and CIS. Cloud Workload Protection watches running processes, files and network activity for threats. Each has its own page here.
How is Datadog Cloud Security billed?
Cloud Security is billed per host it protects, whether through the Agent or agentless scanning, with containers metered against a per-host allotment. An organisation buys one plan, CSM Pro or CSM Enterprise, not both. Agentless scanners run inside your own cloud account, so their compute and networking appear on the cloud provider bill. Datadog publishes the current meters and rates, and we check them with you before anything is switched on, because the right scope is usually smaller than every host. We do not publish prices. We do decide, with you, which hosts and accounts belong in scope.
Does Datadog Cloud Security make us compliant?
No tool does. Cloud Security reports the state of the runtime controls against a framework and keeps the evidence. We operate and evidence the runtime controls that support your compliance obligations. The auditor, the policy and the people stay yours. What changes is that the evidence exists on the day it is asked for, with a timestamp, rather than being assembled the week before.
Is Critical Cloud a security company?
No. We are a managed runtime operator. We run the detection and posture tooling inside your Datadog, triage what it finds, fix what sits in the runtime we operate, and route the rest to the owner with the evidence attached. Penetration testing, security strategy and regulatory advice are not what we do, and we say so. Where you have a security team or an MDR provider, Cloud Security findings reach them through the same routing.
What does Critical Cloud do with Cloud Security every month?
Managed Observability reviews new findings against the rules in force and suppresses the ones that are accepted risks, with a written reason. It re-checks scope as hosts and accounts change, and reports what was found, fixed and routed. Under Critical Support a workload threat signal pages our engineers, 24x7, and they contain the runtime while the owner is told.
- Datadog products: every product, and how we implement and run each one
- Cloud Security Posture Management, Entitlement Management, Vulnerability Management, Compliance and Cloud Workload Protection, each on its own page
- Cloud Security Accelerator: scope, rules, routing and the first triage, in four weeks
- Security and compliance at Critical Cloud: the certifications we hold and how we were audited
Every finding with an owner. Every control with evidence.
Tell us which frameworks you are measured against and which accounts hold production. We will show you what Cloud Security would find, who should own it, and what it takes to run it.