Integrations / Security & monitoring
Screenata + DatadogHow do you turn Datadog into SOC 2 and ISO 27001 evidence?
Quick answer
Datadog does the monitoring. SOC 2 CC7.2 and ISO 27001 A.8.16 then ask you to prove the monitoring program around it operates, which is a different question from whether the tool is installed. Having Datadog is not the control. The control is the enforced configuration, such as monitors on the systems in scope, alerts routed to a responder, and log retention that meets your policy, plus the record that the configuration held across the whole audit period. Screenata runs 10 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Datadog read-only and runs 10 native checks against your account: monitor coverage, alert routing, log retention, and RBAC. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog, turning your observability stack into audit evidence.
10 native checks · read-only · signed evidence
What it proves
Datadog evidence, mapped to controls.
Monitor coverage on the systems your availability commitments depend on, verified against what your system description claims.
Proof that the monitoring your SOC 2 availability and monitoring controls describe actually exists and is active.
Whether monitor alerts route to a destination someone actually watches, so detection leads to response.
The link auditors probe between detection and incident response: an alert that goes nowhere is not a control.
Log retention configuration against the periods your policies commit to.
Proof that logs survive long enough to support investigations and the audit period.
Role assignments in Datadog and whether access follows least privilege.
Findings that access to logs and monitoring data is scoped, matching your access control policy.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Datadog, and why each matters.
Monitor Coverage
Verifies monitors cover the infrastructure and services behind your availability commitments. Thin coverage lets failures and threats go undetected, and an auditor checks that active monitoring exists on the systems your description names.
Log Retention Period
Confirms log retention meets the period your policy commits to. Short retention starves investigations and audit sampling of data, so an auditor verifies logs survive long enough to reconstruct events across the audit window.
Audit Trail Enabled
Checks that Datadog Audit Trail records configuration and access changes. Without it there is no record of who altered monitoring settings, and an auditor looks for a tamper-evident trail of administrative activity.
API Key Rotation
Verifies API keys are rotated within the maximum age you set. Stale keys widen the window for a leaked credential to be abused, and an auditor checks that access secrets are rotated on a defined schedule.
Role-Based Access Control
Confirms Datadog uses roles rather than granting every user admin. Over-broad access lets anyone alter monitoring and read sensitive telemetry, and an auditor verifies access to logs and monitoring data follows least privilege.
Capacity Threshold Monitors
Verifies active metric monitors track CPU, memory, and disk with explicit alert thresholds. Without them a host can exhaust capacity and cause an outage with no warning, and an auditor checks that capacity is monitored against your availability commitments.
Datadog Cloud SIEM Detection Rules Enabled
Confirms Cloud SIEM has enabled detection rules that notify responders. Without them malicious activity in logs goes uncorrelated and unnoticed, and an auditor verifies threats are detected and routed to someone who acts.
Datadog Incident Register Export
Exports every incident in the audit period with severity, state, and resolution. An incomplete register means you cannot show incidents were tracked and closed with root-cause follow-up, which is what an auditor samples for incident response.
Backup Failure Monitor Configured
Verifies a monitor watches backup job failures and notifies a responder. A silent backup failure risks permanent data loss discovered only at restore time, and an auditor checks that backup health is monitored and alerted.
Drawn from Screenata’s Datadog check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
What access does Screenata need to Datadog?
A read-scoped API and application key pair that you create and control. Screenata uses it for scheduled scans and never receives write access. You can revoke the keys at any time from the Datadog console.
Does Screenata replace Datadog?
No. Datadog does the monitoring; Screenata proves it. The integration turns monitor coverage, alert routing, and retention state into signed compliance evidence mapped to the monitoring and availability controls auditors test.
What happens when a Datadog check fails?
Vera opens a ticket describing the gap, such as retention below the policy commitment, and re-verifies after a human applies the fix. Nothing in your account is changed by Screenata; the connection is read-only by construction.
What are the steps to implement SOC 2 with Datadog?
First, create a read-scoped API and application key pair and connect it. Second, let the first scan run so the baseline reflects the monitors, retention, and roles you actually have rather than what the system description claims. Third, fix what fails: extend monitor coverage to the infrastructure behind your availability commitments, add capacity threshold monitors on CPU, memory, and disk, raise log retention to the period your policy commits to, enable Audit Trail, put Cloud SIEM detection rules in place with a notification target, add a monitor on backup job failures, and replace blanket admin access with roles. Fourth, leave the scheduled scans running so passing results accumulate as signed evidence across the observation window, which for a Type 2 report is usually three to twelve months. Fifth, hand the evidence package to an independent auditor. The audit is a separate engagement with a licensed CPA firm, which issues the report; Screenata prepares and holds the evidence it asks for.
What evidence do auditors ask for about system monitoring?
Four things. That monitoring exists on the systems in scope, matching the infrastructure your system description names rather than a subset of it. That alerts route to a human who actually responds, since an alert firing into an unwatched channel is not a control. That logs are retained long enough to investigate an incident and to support the audit sample, which means meeting the retention period your own policy commits to. And that the configuration held across the whole audit period, not just on the day someone took the screenshot.
Do auditors accept evidence Screenata collects from Datadog?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting Datadog, you know your real posture.
Related: Sentry · CrowdStrike · AWS · Wiz