The evidence exists the day the auditor asks.
Dated, not assembled.
Datadog Compliance maps every Cloud Security misconfiguration finding to the controls of ISO 27001, SOC 2, PCI DSS, CIS, NIST and the other frameworks you are measured against, scores the posture over time, and exports the report. We implement it as Runtime Evidence inside the Datadog you already run, and operate it every month so the month before an audit looks like every other month.
Quick facts
Related
- Cloud Security, the group this belongs to
- Audit Trail, who changed what in Datadog, kept as evidence
- Access Control, the roles and permissions an auditor asks about
The technical controls, reported in the auditor's own structure, with the history behind every line
The ISO 27001 auditor asks for evidence that access to cloud storage is restricted, and the evidence is a screenshot taken last week. Compliance turns the same question into a control with a pass or fail state, the resources behind it, and fifteen months of history showing when it last changed. That is the difference between a snapshot and a record.
Rules mapped to controls. Each Datadog rule is tagged to the controls of the frameworks it supports. A failed check on a storage bucket appears under the ISO 27001 control, the SOC 2 criterion and the CIS recommendation it violates, at once.
Posture as a trend. A score per framework, tracked over time, so the question is not "are we at ninety" but "why did it drop in June". The resources with the most failures and the top failing rules sit at the top of the report.
Your own baseline as a framework. A custom framework built from Datadog rules and your own Rego rules, for the internal policy the published frameworks do not describe. It scores and exports the same way.
The export the auditor accepts. A framework report as PDF or CSV, control by control, dated. Underneath it the finding history, the mutes with reasons, and the Audit Trail of who changed what in Datadog itself.
The wrong framework in force, a score chased with mutes, and a report opened once a year
How it bills. Compliance reporting is a view over the Cloud Security findings rather than a separately metered product. It is included with the Cloud Security plan, which is billed on the hosts and containers it covers. One dependency has its own cost: the monitoring section of the CIS AWS benchmark needs CloudTrail logs forwarded to Datadog and evaluated by Cloud SIEM, which counts on the log and SIEM meters. Datadog publishes the meters and rates. The decision we make with you is which frameworks are in force and which accounts they apply to, because a framework applied to an account it does not govern produces failures nobody is obliged to fix.
The configuration traps. Every default framework left on the dashboard while nobody filters to the one the auditor uses, so the score on the dashboard measures something nobody is certified against. The score treated as the goal, so findings are muted to raise it and the mute dates tell the auditor exactly when. The CIS AWS monitoring controls failing because CloudTrail never reached Cloud SIEM, read as a security gap when it is a plumbing gap. The report exported for the first time in the week before the audit, when the history underneath it has been there for over a year.
Field noteThe most common gap we see is the framework mismatch. The auditor works to ISO 27001:2022, the report in force is a CIS benchmark, and the two share many controls but not all. The gaps found in audit week were visible under the right framework for months.
Field noteA posture score that jumps in the fortnight before the audit is read correctly by the auditor. The mutes that produced it carry their creation dates, and a cluster of mutes with the same week and no expiry is the first thing a competent reviewer asks about.
Field noteThe pattern we keep finding is the dark control. A whole section of the CIS AWS benchmark fails every month because the logs it needs never reached Cloud SIEM. The failures are real, the cause is a missing log forwarder, and the fix is an afternoon that is never scheduled because the section is assumed to be hard.
Field noteThe most common gap we see in the evidence pack is the single export. The framework view has no monthly owner, so the fifteen months of history underneath the report is first read in audit week. By then the controls it shows failing can no longer be fixed in time.
The auditor's framework first. The accounts it governs second. A dated export from month one.
Compliance is delivered inside the Cloud Security Accelerator, four weeks and fixed scope, on top of the posture findings the same accelerator sets up. If Datadog is new to the estate, LaunchPad runs the platform rollout first. The compliance sequence is the same either way.
- Name the frameworks you are measured against. The edition matters: ISO 27001:2022 and 2013 are both available and differ. The customer questionnaire frameworks are listed alongside the audit ones.
- Map frameworks to accounts. PCI DSS applies to the accounts that touch card data, not the sandbox. Each framework is scoped to the accounts and clusters it governs, so every failure is one somebody is obliged to fix.
- Close the dark controls. The controls that fail for want of data, such as the CIS AWS monitoring section without CloudTrail in Cloud SIEM, are fixed first, because they are plumbing and they distort the score.
- Build the custom framework where the policy needs it. Your internal baseline as a framework, from Datadog rules and your own Rego rules, so the internal audit reports the same way as the external one.
- Set the mute policy and the review cadence. Every mute carries a reason, an approver and an expiry. The framework report is exported, dated and filed at the end of the accelerator and every month after, so the trend exists before anyone asks for it.
- Hand over, in writing. Frameworks in force per account, the dark controls closed, and the custom framework definition. The mutes with their reasons, the first dated export, and the failing controls with their owners on the day we finished.
Access is admin on the Datadog organisation and read-only on the cloud accounts. We do not write your policies, run your risk assessment or speak to your auditor on your behalf. We give you the runtime evidence they will ask for, and we are available to explain how it was produced.
Runtime Evidence is a cadence, not a document
A framework is revised. An account is added to the card data environment. A control that passed in March fails in June because a role was widened for a migration. Managed Observability is the monthly service that keeps the frameworks, the scope and the evidence matching the estate as it is now, so the audit month is not a special month.
Every month, posture per framework is reviewed. Failing controls in the runtime we operate are fixed by us. The rest go to a named owner with the resource, the rule and the control attached. The score moves because the estate improved, not because a mute was added.
Scope follows the estate and the frameworks. New accounts are placed under the frameworks that govern them. Framework revisions are adopted when Datadog publishes them, with the differences from the previous edition noted.
Mutes are kept honest. Every mute is renewed with a fresh reason or removed when it expires, and the mute list is part of the monthly report, so the auditor sees a record of decisions rather than a pattern of avoidance.
The evidence is exported and filed, dated. The framework report, every month, in PDF and CSV, alongside the Audit Trail of changes in Datadog and the Access Control state. When the questionnaire or the auditor asks, the answer is a folder with twelve files in it. Our own certifications are described on the security and compliance page.
We operate the stack. You own the product.
We are not a security company and we are not a regulation adviser. We are a managed runtime operator. We operate and evidence the runtime controls that support your compliance obligations. The policies, the risk register, the people controls and the conversation with the auditor stay yours. What we add is that the runtime part of the evidence is produced every month by the people who run the runtime. We hold ISO 27001 and Cyber Essentials Plus ourselves, so we have sat on your side of the audit table.
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 Compliance, answered plainly
Which frameworks does Datadog Compliance report against?
The ones most UK and Irish buyers are measured against are all there. ISO/IEC 27001 in both the 2013 and 2022 editions, SOC 2, PCI DSS v4.0, NIST 800-53, the NIST Cybersecurity Framework, UK Cyber Essentials, GDPR, DORA, NIS2 and HIPAA. Alongside them sit the CIS Foundations benchmarks for AWS, Azure and Google Cloud and the CIS Kubernetes, Docker and Linux distribution benchmarks. Each Datadog rule is mapped to the controls of the frameworks it supports, and a custom framework can be built from the rules that match your own baseline.
How is Datadog Compliance billed?
Compliance reporting is a view over the Cloud Security findings rather than a separately metered product. It is included with the Cloud Security plan, which is billed on the hosts and containers it covers. One dependency carries its own cost: the monitoring section of the CIS AWS benchmark needs CloudTrail logs forwarded to Datadog and evaluated by Cloud SIEM, which counts on the log and SIEM meters. Datadog publishes the meters and rates. We do not publish prices. We decide with you which frameworks are in force and which accounts they apply to.
Does Datadog Compliance make us compliant?
No tool does, and we do not claim it. Datadog reports the state of the technical controls it can observe against the framework you choose, and keeps the history. We operate and evidence the runtime controls that support your compliance obligations. The policies, the people controls, the risk assessment and the auditor stay yours. What changes is that the runtime part of the evidence exists on the day it is asked for, with a timestamp, rather than being assembled in the week before the audit.
What evidence can we export from Datadog Compliance?
A framework report, exported as PDF or CSV, showing each control, its pass and fail state, the resources behind each failure and the top failing rules. Underneath it, the misconfiguration history for every resource over fifteen months, the mutes with their reasons and dates, and the posture score over time. That combination is what we mean by Runtime Evidence: the control, the date, and what the runtime looked like when it was checked.
What does Critical Cloud do with Compliance every month?
Managed Observability reviews posture per framework every month. We fix the failing controls in the runtime we operate. The rest go to a named owner with the resource and the rule attached. We confirm that every mute still has a valid reason. We export the dated report so the trend exists before anyone asks for it. The month before an audit looks the same as every other month, which is the point.
- Datadog products: every product, and how we implement and run each one
- Cloud Security: the group, with the posture findings this reports on
- Audit Trail and Access Control: the other two things the auditor asks for from Datadog itself
- Security and compliance at Critical Cloud: the certifications we hold and how we were audited
Every control with evidence. Every month, not every audit.
Tell us which frameworks you are measured against and when the next audit is. We will show you what Datadog Compliance reports today, which controls are failing for want of data, and what it takes to have the evidence ready every month.