Datadog Hardening Guide

Security Last updated: 2026-08-08

Observability platform hardening for Datadog including SAML SSO, role-based access control, sensitive data redaction, cloud integration security, and organization security settings

Product Docs API Docs

Code Packs: Terraform

View:

Datadog — Requirements Cheat Sheet

All controls condensed. Click any requirement to jump to full implementation details.

Requirement	Description	Rationale

Overview

Datadog is a leading observability and security platform used by thousands of organizations for infrastructure monitoring, APM, log management, and security monitoring. As a platform with access to sensitive operational data and infrastructure metrics, Datadog security configurations directly impact data protection and operational security.

Intended Audience

Security engineers managing observability platforms
IT administrators configuring Datadog
DevOps teams securing monitoring infrastructure
GRC professionals assessing observability security

How to Use This Guide

L1 (Crawl): Essential controls for all organizations
L2 (Walk): Enhanced controls for security-sensitive environments
L3 (Run): Strictest controls for regulated industries

Scope

This guide covers Datadog organization security including SAML SSO, role-based access control, API and application key management, session security, sensitive data redaction, cloud integration credentials, agent control plane configuration, and network-layer access restrictions.

Authentication & SSO
Access Controls
API & Key Security
Monitoring & Compliance
Data Protection
Integration & Agent Security
Compliance Quick Reference

1. Authentication & SSO

1.1 Configure SAML Single Sign-On

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	6.3, 12.5
NIST 800-53	IA-2, IA-8

Description

Configure SAML SSO to centralize authentication for Datadog users.

Rationale

Why This Matters:

Centralizes identity management
Enables enforcement of organizational MFA policies
Simplifies user lifecycle management
Required for SAML strict mode

Attack Prevented: Password-based account takeover, access by accounts outside centralized MFA and lifecycle management

Prerequisites

Datadog Administrator access
SAML 2.0 compatible identity provider
IdP admin credentials

ClickOps Implementation

Step 1: Access SAML Configuration

Navigate to: Organization Settings → Login Methods
Click on SAML settings
Enable SAML configuration

Step 2: Configure Identity Provider

Create SAML application in IdP:
- Active Directory
- Auth0
- Google
- LastPass
- Microsoft Entra ID
- Okta
- SafeNet
Configure required attributes

Step 3: Upload IdP Metadata

Download IdP metadata XML
Upload to Datadog SAML settings
Verify configuration

Step 4: Configure Datadog Settings

Datadog supports HTTP-POST binding
NameIDPolicy format: emailAddress
Assertions must be signed

Time to Complete: ~1 hour

Code Pack: Terraform

hth-datadog-1.01-configure-saml-sso.tf View source on GitHub ↗

# Enable SAML SSO for the Datadog organization
resource "datadog_organization_settings" "saml_sso" {
  name = "HTH Hardened Organization"

  settings {
    saml {
      enabled = true
    }

    saml_autocreate_users_domains {
      enabled = length(var.saml_autocreate_users_domains) > 0
      domains = var.saml_autocreate_users_domains
    }

    saml_idp_initiated_login {
      enabled = true
    }
  }
}

1.2 Enable SAML Strict Mode

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	6.3
NIST 800-53	IA-2

Description

Require SAML authentication for all users.

Rationale

Why This Matters:

Strict mode disables local password and social logins, forcing every login through your corporate IdP and its MFA and conditional-access policies
Leaving password or Google login enabled creates a parallel authentication path that bypasses SSO controls and is a prime target for credential stuffing and phishing
Centralized IdP authentication ensures departed employees lose Datadog access the moment they are deprovisioned, eliminating orphaned standing access
Datadog holds infrastructure telemetry, logs, and security signals that map your environment for anyone who gets in

Attack Prevented: Credential stuffing, phishing, MFA bypass, orphaned-account access

ClickOps Implementation

Step 1: Navigate to Login Methods

Navigate to: Organization Settings → Login Methods
Review enabled authentication methods

Step 2: Configure Strict Mode

Set Password login: Disabled
Set Google login: Disabled
Set SAML login: Enabled by Default

Step 3: Configure User Overrides

Allow per-user overrides if needed
Configure individual exceptions carefully

Code Pack: Terraform

hth-datadog-1.02-enable-saml-strict-mode.tf View source on GitHub ↗

# Enforce SAML strict mode -- disables password and Google login
# Only applied at profile level 2 (Hardened) and above
resource "datadog_organization_settings" "saml_strict" {
  count = var.profile_level >= 2 ? 1 : 0

  name = "HTH Hardened Organization"

  settings {
    saml {
      enabled = true
    }

    saml_strict_mode {
      enabled = var.saml_strict_mode_enabled
    }

    saml_autocreate_users_domains {
      enabled = length(var.saml_autocreate_users_domains) > 0
      domains = var.saml_autocreate_users_domains
    }

    saml_idp_initiated_login {
      enabled = true
    }
  }
}

1.3 Configure Session Security

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	6.2
NIST 800-53	AC-12

Description

Configure session timeout and security settings.

Rationale

Why This Matters:

Bounded session duration and idle timeout limit the window in which a stolen or hijacked session token remains valid
Without an idle timeout, an unattended or unlocked workstation leaves an authenticated Datadog session open indefinitely for anyone with physical or remote access
Shorter sessions force periodic re-authentication, reducing the value of exfiltrated session cookies
Datadog dashboards expose sensitive operational and security data, so a lingering session is a direct path to that data

Attack Prevented: Session hijacking, cookie theft, unattended-workstation access

ClickOps Implementation

Step 1: Configure Session Duration

Navigate to: Organization Settings → Security
Set Maximum session duration
Applies to all new web sessions

Step 2: Configure Idle Timeout

Enable Idle time session timeout
Users signed out after 30 minutes inactivity

Code Pack: Terraform

hth-datadog-1.03-configure-session-security.tf View source on GitHub ↗

# Configure session security via security monitoring rule that detects
# sessions exceeding the configured idle timeout.
#
# NOTE: Datadog does not expose session timeout as a direct Terraform resource.
# Session duration is configured via Organization Settings in the UI.
# This rule monitors for sessions that exceed the idle timeout threshold
# and alerts the security team for investigation.
resource "datadog_security_monitoring_rule" "session_idle_timeout_violation" {
  name    = "[HTH] Session Idle Timeout Violation Detected"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Session Idle Timeout Violation

    A user session has been active beyond the configured idle timeout
    of ${var.session_idle_timeout_minutes} minutes.

    **Recommended Action:**
    - Review session in Organization Settings > Security
    - Verify idle timeout is set to ${var.session_idle_timeout_minutes} minutes
    - Investigate if the session was legitimately active

    **HTH Control:** 1.3 Configure Session Security
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "session_violation"
    query           = "source:audit @evt.name:session @duration:>${var.session_idle_timeout_minutes}m"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Session idle timeout exceeded"
    status    = "medium"
    condition = "session_violation > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 900
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:1.3", "level:L1"]
}

2. Access Controls

2.1 Configure Role-Based Access Control

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	5.4
NIST 800-53	AC-6

Description

Implement least privilege using Datadog’s RBAC model.

Rationale

Why This Matters:

Least-privilege roles ensure each user can only see and change what their job requires, containing the blast radius if an account is compromised
Broad default roles grant more access than most users need, expanding the attack surface across dashboards, monitors, and integrations
Custom roles let you gate sensitive permissions such as key management, billing, and user administration to a small set of trusted operators
Datadog aggregates logs and metrics from across your infrastructure, so over-privileged accounts can expose data from systems the user never works on
Role permissions alone are all-or-nothing for log data: any role holding logs_read_data can read every indexed log unless you attach a restriction query, so one over-broad role exposes payment, healthcare, and production secrets logged anywhere in the org
A restriction query narrows logs_read_data to a filter such as team:acme, meaning members of that role see only logs matching the filter and nothing else, which contains the blast radius of a compromised standard user

Attack Prevented: Privilege escalation, lateral movement, insider data access, over-exposure of telemetry, cross-team log snooping

ClickOps Implementation

Step 1: Review Managed Roles

Navigate to: Organization Settings → Roles
Review default managed roles:
- Admin: Full access
- Standard: Read/write on assets
- Read Only: Read data only

Step 2: Create Custom Roles

Click Create Role
Configure specific permissions
Pay attention to sensitive permissions

Step 3: Review Sensitive Permissions

Sensitive permissions are flagged in UI
Review carefully before assigning

Step 4: Attach Logs Restriction Queries to Roles

Navigate to: Organization Settings → Roles
Select a role that holds the logs_read_data permission
Add a restriction query expressing the subset of logs that role may read, for example team:acme or env:staging
Confirm that members of the role now see only logs matching the query — everything else is filtered out of Log Explorer, dashboards, monitors, and the API for that role
Treat the Unrestricted Access allowlist as the deliberate exception: grant it only to roles that genuinely need to read every log (for example a security operations role), and record the business justification
Re-check restriction queries whenever tagging conventions change, since a renamed tag silently widens or empties the filter
Reference: How to Set Up RBAC for Logs

Code Pack: Terraform

hth-datadog-2.01-configure-rbac.tf View source on GitHub ↗

# Look up the built-in Datadog Read Only role for reference
data "datadog_role" "read_only" {
  filter = "Datadog Read Only Role"
}

# Look up the built-in Datadog Standard role for reference
data "datadog_role" "standard" {
  filter = "Datadog Standard Role"
}

# Look up the built-in Datadog Admin role for reference
data "datadog_role" "admin" {
  filter = "Datadog Admin Role"
}

# Create custom least-privilege roles from variable definitions
resource "datadog_role" "custom" {
  for_each = var.custom_roles

  name = each.value.name

  dynamic "permission" {
    for_each = each.value.permissions
    content {
      id = permission.value
    }
  }
}

# Security monitoring rule: detect admin role assignments
resource "datadog_security_monitoring_rule" "admin_role_assignment" {
  name    = "[HTH] Admin Role Assigned to User"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Admin Role Assignment Detected

    A user has been assigned the Datadog Admin role. Admin access should
    be limited to 2-3 users per the principle of least privilege.

    **Recommended Action:**
    - Verify the assignment was authorized
    - Confirm the user requires full admin access
    - Consider using a custom role with fewer permissions

    **HTH Control:** 2.1 Configure Role-Based Access Control / 2.2 Limit Admin Access
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "admin_assignment"
    query           = "source:audit @evt.name:role @action:modified @role.name:\"Datadog Admin Role\""
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Admin role assigned"
    status    = "high"
    condition = "admin_assignment > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:2.1", "control:2.2", "level:L1"]
}

2.2 Limit Admin Access

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	5.4
NIST 800-53	AC-6(1)

Description

Minimize and protect administrator accounts.

Rationale

Why This Matters:

Admin accounts can modify org-wide security settings, manage users, and rotate keys, making them the highest-value target in the organization
Each additional admin multiplies the number of accounts an attacker can phish or compromise to gain full control
Keeping admin to a small, named set makes anomalous admin activity easier to detect and audit
A single compromised Datadog admin can disable logging, exfiltrate data, and weaken every other control in this guide

Attack Prevented: Admin account takeover, privilege escalation, audit tampering, security-control bypass

ClickOps Implementation

Step 1: Inventory Admin Users

Navigate to: Organization Settings → Users
Filter by Admin role
Document all admin accounts

Step 2: Apply Least Privilege

Limit Admin to 2-3 users
Remove unnecessary admin access
Use custom roles for specific needs

2.3 Restrict Access with the IP Allowlist

Profile Level: L3 (Run)

Framework	Control
CIS Controls	12.5, 13.4
NIST 800-53	AC-17, SC-7

Description

Restrict access to your Datadog organization to a defined set of IP ranges using the IP Allowlist, available on the Enterprise plan. Once enabled, requests originating outside the allowlisted ranges are rejected for the web UI, the mobile app, the public API, OAuth-based integrations, and the Datadog MCP Server. Configured at Organization Settings → Security → IP Allowlist. Reference: IP Allowlist.

Rationale

Why This Matters:

The IP Allowlist is the only network-layer control Datadog offers — every other control in this guide operates at the identity or permission layer, so this is the single place you can say “no request from outside our egress ranges, full stop”
A stolen session cookie, leaked application key, or phished SSO credential is useless to an attacker who cannot reach the org from an allowlisted address, turning a credential compromise into a non-event
Coverage extends beyond the UI to the public API and OAuth integrations, closing the common gap where a hardened console sits next to a wide-open programmatic surface
Datadog is a read-through window into your entire estate — logs, traces, infrastructure topology, and security signals — so restricting where that window can be opened from meaningfully shrinks the attack surface
Because the allowlist also governs the MCP Server, it constrains AI agent and automation access to the same approved ranges rather than letting a new integration surface bypass your network policy

Attack Prevented: Credential replay from attacker infrastructure, session hijacking from unapproved networks, API abuse with leaked keys, unauthorized OAuth and MCP access

Prerequisites

Datadog Enterprise plan
Administrator access with the org_management permission
A complete inventory of egress IP ranges: corporate networks, VPN concentrators, CI/CD runners, and any SaaS that calls the Datadog API

ClickOps Implementation

Step 1: Inventory Source Ranges Before Enabling

Collect every CIDR range that legitimately reaches Datadog: office and VPN egress, cloud NAT gateways, CI/CD runner pools, and third-party integrations that call the public API
Include mobile-app users’ expected networks, or accept that mobile access will be blocked off-network
Missing a range here locks out real users and breaks running automation, so treat this inventory as the actual work

Step 2: Configure the Allowlist

Navigate to: Organization Settings → Security
Open IP Allowlist
Add each approved CIDR range with a description identifying its owner and purpose
Verify your own current IP is included before enabling, so you do not lock yourself out

Step 3: Enable and Communicate

Enable the allowlist
Notify users and integration owners of the change and the process for requesting an added range
Document the approved ranges in your change management system

Step 4: Review on a Schedule

Re-review the allowlist quarterly and after any network change (new office, VPN migration, cloud region addition)
Remove ranges tied to decommissioned offices, retired VPN endpoints, or terminated vendors

Validation & Testing

From an allowlisted network, sign in to the Datadog UI and confirm normal access
From a non-allowlisted network (for example a mobile hotspot), attempt to load the Datadog UI and confirm the request is rejected
Issue an authenticated public API call from a non-allowlisted address and confirm it fails, proving the allowlist covers the programmatic surface and not just the console
Confirm CI/CD pipelines, Terraform runs, and any OAuth integrations still function after enabling — a silent pipeline failure is the most common post-enablement regression
Re-run these checks after every allowlist edit

Compliance Mappings

Framework	Control	Requirement
SOC 2	CC6.1	Logical access is restricted to authorized users and approved sources
SOC 2	CC6.6	Access from outside system boundaries is restricted
NIST 800-53	AC-17	Remote access is monitored and controlled
NIST 800-53	SC-7	Boundary protection restricts external connections
CIS Controls	12.5	Centralize network authentication and access enforcement
CIS Controls	13.4	Perform traffic filtering between network segments
ISO 27001	A.8.20	Networks are secured and access is controlled

3. API & Key Security

3.1 Secure API Keys

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	3.11
NIST 800-53	SC-12

Description

Secure Datadog API keys used for data ingestion.

Rationale

Why This Matters:

API keys authorize data ingestion and programmatic access, so a leaked key lets an attacker submit false telemetry or pull organizational data
Purpose-specific, descriptively named keys let you revoke a single compromised integration without breaking everything else
Storing keys in a secret manager and keeping them out of source code prevents the most common leak vector — credentials committed to repositories
Unused or orphaned keys are standing credentials an attacker can exploit undetected

Attack Prevented: API key leakage, credential exposure in source code, telemetry poisoning, unauthorized data access

ClickOps Implementation

Step 1: Review API Keys

Navigate to: Organization Settings → API Keys
Review all existing keys
Identify purpose of each key

Step 2: Implement Key Management

Create purpose-specific keys
Name keys descriptively
Remove unused keys

Step 3: Secure Key Storage

Store keys in secret manager
Use environment variables
Never commit to code

Code Pack: Terraform

hth-datadog-3.01-secure-api-keys.tf View source on GitHub ↗

# Create purpose-specific API keys with descriptive names.
# Each key should map to a single use case (e.g., prod-agent, staging-agent).
resource "datadog_api_key" "managed" {
  for_each = toset(var.api_key_names)

  name = each.value
}

# Security monitoring rule: detect API key creation or deletion
resource "datadog_security_monitoring_rule" "api_key_lifecycle" {
  name    = "[HTH] API Key Created or Deleted"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## API Key Lifecycle Event

    An API key was created or deleted. All API key changes should be
    authorized and documented per key management policy.

    **Recommended Action:**
    - Verify the change was authorized
    - Confirm the key name follows naming conventions
    - Update key inventory documentation
    - Ensure unused keys are revoked

    **HTH Control:** 3.1 Secure API Keys
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "api_key_change"
    query           = "source:audit @evt.name:api_key @action:(created OR deleted)"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "API key lifecycle event"
    status    = "medium"
    condition = "api_key_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:3.1", "level:L1"]
}

3.2 Secure Application Keys

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	3.11
NIST 800-53	SC-12

Description

Secure application keys used for API access.

Rationale

Why This Matters:

Application keys inherit the full permissions of the user who created them, so a leaked key grants an attacker that user’s entire level of access
Scoping keys to the minimum required permissions limits what a compromised key can read or change
Regular rotation shortens the lifespan of any key that is exposed before the leak is detected
Tying a privileged user’s app key to a broad scope effectively turns a key leak into an account takeover
Application keys do not expire natively — Datadog issues them without a built-in lifetime, so a key leaked today stays valid indefinitely unless you revoke it, which makes authorization scoping plus a deliberate rotation schedule the real control rather than an optional nicety
Keys owned by individual employees become orphaned credentials when that person changes teams or leaves; a service account owns the key instead, so integrations keep running through employee departure and the key’s ownership is an org asset rather than a personal one
Service accounts are non-interactive by design — they cannot log in to the UI — which means a compromised automation key cannot be used to browse the console interactively

Attack Prevented: Application key leakage, over-scoped access, credential reuse, account impersonation, orphaned credentials surviving offboarding

ClickOps Implementation

Step 1: Review Application Keys

Navigate to: Organization Settings → Application Keys
Application keys inherit user permissions

Step 2: Configure Key Scopes

Create keys with limited scopes
Grant minimum required permissions
Use authorization scopes to bound what each key can do: navigate to Organization Settings → Application Keys, open the key, and select only the scopes the integration actually calls
An unscoped key inherits the owning user’s full permissions, so scoping is what separates “this key reads monitors” from “this key can do anything its owner can”
Reference: API and Application Keys

Step 3: Own Automation Keys with Service Accounts

Navigate to: Organization Settings → Service Accounts
Create a service account for each integration or automation workload rather than issuing the key from a named employee’s account
Assign the service account a role carrying only the permissions that workload needs
Generate the application key from the service account, then store it in your secret manager
Service accounts are non-interactive — they cannot sign in to the Datadog UI — so the credential is usable only for the programmatic access it was created for
Because the account is owned by the organization rather than a person, the integration survives employee departure and offboarding no longer silently breaks or leaves orphaned keys behind
Reference: Service Accounts

Step 4: Rotate Keys Regularly

Establish rotation schedule (90 days)
Update integrations before deleting
Application keys never expire on their own, so rotation must be a scheduled operational task with an owner — there is no platform-side expiry to fall back on
Audit the Application Keys page for keys with no recent use and revoke them

Code Pack: Terraform

hth-datadog-3.02-secure-application-keys.tf View source on GitHub ↗

# Create purpose-specific application keys with descriptive names.
# Application keys inherit the permissions of the user who creates them.
# Use service accounts with limited roles for automation keys.
resource "datadog_application_key" "managed" {
  for_each = toset(var.app_key_names)

  name = each.value
}

# Security monitoring rule: detect application key creation or deletion
resource "datadog_security_monitoring_rule" "app_key_lifecycle" {
  name    = "[HTH] Application Key Created or Deleted"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Application Key Lifecycle Event

    An application key was created or deleted. Application keys inherit
    the permissions of the creating user, so changes must be carefully
    controlled. Keys should be rotated every 90 days.

    **Recommended Action:**
    - Verify the change was authorized
    - Confirm the key is tied to an appropriate service account
    - Check that the owning user has minimal required permissions
    - Update key rotation schedule

    **HTH Control:** 3.2 Secure Application Keys
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "app_key_change"
    query           = "source:audit @evt.name:application_key @action:(created OR deleted)"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Application key lifecycle event"
    status    = "medium"
    condition = "app_key_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:3.2", "level:L1"]
}

4. Monitoring & Compliance

4.1 Configure Audit Logs

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	8.2
NIST 800-53	AU-2

Description

Monitor administrative and security events.

Rationale

Why This Matters:

The audit trail records configuration changes, logins, and sensitive operations, providing the evidence needed to detect and investigate abuse
Without alerting on sensitive events, malicious changes such as disabling SSO or creating new admin accounts go unnoticed
Exporting logs to a SIEM with independent retention preserves evidence even if an attacker tampers with the Datadog console
Detection and forensic readiness are the backstop for every preventive control — they catch what slips through

Attack Prevented: Undetected configuration tampering, insider abuse, delayed breach detection, log destruction

ClickOps Implementation

Step 1: Access Audit Trail

Navigate to: Organization Settings → Audit Trail
Review logged events

Step 2: Configure Alerts

Create monitors for audit events
Alert on sensitive operations

Step 3: Export Logs

Export audit logs for retention
Integrate with SIEM

Code Pack: Terraform

hth-datadog-4.01-configure-audit-logs.tf View source on GitHub ↗

# Monitor for organization settings changes (security-critical events)
resource "datadog_security_monitoring_rule" "org_settings_changed" {
  name    = "[HTH] Organization Settings Modified"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Organization Settings Modified

    A change was detected to Datadog organization settings. This includes
    changes to authentication methods, security settings, and access controls.

    **Recommended Action:**
    - Review the specific setting that was changed
    - Verify the change was authorized via change management
    - Check if the change impacts security posture
    - Document in change log

    **HTH Control:** 4.1 Configure Audit Logs
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "org_change"
    query           = "source:audit @evt.name:org_settings @action:modified"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Organization settings modified"
    status    = "high"
    condition = "org_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:4.1", "level:L1"]
}

# Monitor for user access changes (invitation, role change, removal)
resource "datadog_security_monitoring_rule" "user_access_changed" {
  name    = "[HTH] User Access Modified"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## User Access Modified

    A user was invited, had their role changed, or was removed from the
    Datadog organization. User access changes should follow the principle
    of least privilege.

    **Recommended Action:**
    - Verify the user access change was authorized
    - Confirm the assigned role follows least privilege
    - Update user access inventory
    - Review if the user needs a custom role instead

    **HTH Control:** 4.1 Configure Audit Logs
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "user_change"
    query           = "source:audit @evt.name:user @action:(created OR modified OR deleted)"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "User access modified"
    status    = "medium"
    condition = "user_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:4.1", "level:L1"]
}

# L2: Monitor for SAML configuration changes
resource "datadog_security_monitoring_rule" "saml_config_changed" {
  count   = var.profile_level >= 2 ? 1 : 0
  name    = "[HTH] SAML Configuration Modified"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## SAML Configuration Modified

    A change was detected to the SAML/SSO configuration. Unauthorized
    changes to SAML settings can enable authentication bypass attacks.

    **Recommended Action:**
    - Immediately verify the change was authorized
    - Check if SAML strict mode is still enabled
    - Verify IdP metadata has not been tampered with
    - Review login methods for unauthorized additions

    **HTH Control:** 4.1 Configure Audit Logs (SAML monitoring)
    **Profile Level:** L2 (Hardened)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "saml_change"
    query           = "source:audit @evt.name:saml @action:modified"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "SAML configuration modified"
    status    = "critical"
    condition = "saml_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:4.1", "level:L2"]
}

5. Data Protection

5.1 Redact Sensitive Data with the Sensitive Data Scanner

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	3.1, 3.11
NIST 800-53	SC-28, SI-19

Description

Configure the Sensitive Data Scanner to identify and redact, hash, or partially mask sensitive values — personally identifiable information, payment card numbers, API keys, and other secrets — inside telemetry as it streams through Datadog, before it lands in Logs, APM spans, or RUM events. Configured at Organization Settings → Sensitive Data Scanner. Reference: Sensitive Data Scanner.

Rationale

Why This Matters:

Application logs and traces routinely capture things nobody intended to store: request bodies with customer PII, authorization headers carrying bearer tokens, stack traces embedding connection strings, and form submissions containing card numbers
Once that data is indexed, every person and every application key holding log read access can retrieve it, which quietly turns your observability platform into an unmanaged secondary copy of your most regulated data
Scanning at ingestion means the sensitive value is redacted or hashed before it reaches the index, so there is no sensitive copy to leak, subpoena, or accidentally export — a materially stronger position than detecting the exposure afterward
Secrets that appear in logs are live credentials: an attacker with log read access harvests API keys and tokens without touching your secret manager at all, and redaction at ingestion breaks that path
Hashing rather than deleting preserves the operational value of the field — engineers can still correlate on a consistent hash during an incident without ever seeing the underlying value
Regulated data in an observability platform expands the scope of PCI DSS, HIPAA, and GDPR assessments to cover Datadog itself; redacting at ingestion keeps that scope contained

Attack Prevented: Secret harvesting from logs, PII exposure through telemetry, regulated-data scope creep, insider data browsing, downstream leakage via log exports

Prerequisites

Datadog Administrator access
Knowledge of which services emit sensitive fields and in what shape
An inventory of the data classifications your organization must protect (PII, PCI, PHI, credentials)

ClickOps Implementation

Step 1: Review Predefined Scanning Rules

Navigate to: Organization Settings → Sensitive Data Scanner
Review the library of predefined rules covering common patterns: credit card numbers, email addresses, national identifiers, cloud provider credentials, and API keys
Start from the predefined library rather than writing custom expressions, since the shipped rules are maintained by Datadog

Step 2: Create a Scanning Group

Create a scanning group and define its filter — the subset of telemetry the group applies to, such as a service, environment, or tag
Scope groups deliberately: a group filtered too broadly scans everything and costs performance, one filtered too narrowly misses the noisy service that actually leaks

Step 3: Add Rules and Choose an Action

Add rules to the group from the predefined library, or define custom rules for organization-specific formats such as internal account identifiers
For each rule, choose the action applied on match:
- Redact — replace the matched value with a placeholder
- Partially redact — retain a fragment (for example the last four digits) for troubleshooting
- Hash — replace the value with a consistent hash so correlation remains possible without exposure
Prefer hashing where engineers need to join on the field during incidents, and full redaction where the value has no operational use

Step 4: Extend Coverage Beyond Logs

Apply scanning groups to APM spans and RUM events, not only Logs — traces and browser events carry the same sensitive payloads and are frequently overlooked
Confirm each telemetry type your organization ingests is covered by at least one group

Step 5: Tune and Monitor

Review scanner match volume after enabling to confirm rules fire where expected
Investigate services with unexpectedly high match counts — a service redacting thousands of card numbers per minute is telling you about a logging defect that should be fixed at the source
Re-review rules whenever new services onboard

Validation & Testing

Send a test log containing a synthetic value matching each configured rule (for example a test card number and a fake API key) and confirm the indexed event shows the redacted or hashed form, not the original
Query Log Explorer for the original plaintext value and confirm zero results — this is the check that proves nothing sensitive reached the index
Repeat the same test against an APM span and a RUM event to confirm coverage extends beyond Logs
Verify that a hashed field produces the same hash across two separate events with the same input, confirming correlation still works
Review scanner match metrics weekly for the first month, then on a regular cadence, to catch newly onboarded services emitting unscanned sensitive data

Compliance Mappings

Framework	Control	Requirement
SOC 2	CC6.1	Sensitive information is protected from unauthorized disclosure
SOC 2	C1.1	Confidential information is identified and protected
NIST 800-53	SC-28	Information at rest is protected
NIST 800-53	SI-19	De-identification is applied to sensitive data
CIS Controls	3.1	Establish and maintain a data management process
CIS Controls	3.11	Encrypt or protect sensitive data at rest
PCI DSS	3.3	Mask or render unreadable primary account numbers
ISO 27001	A.8.11	Data masking is applied in accordance with access control policy

6. Integration & Agent Security

6.1 Use IAM Role Delegation for the AWS Integration

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	5.4, 6.8
NIST 800-53	AC-3, IA-5

Description

Connect the Datadog AWS integration using cross-account IAM role delegation with an external ID, rather than embedding static AWS access keys in the integration configuration. Static keys remain necessary only for AWS China and for GovCloud accounts monitored from a commercial Datadog site. Reference: Amazon Web Services Integration.

Rationale

Why This Matters:

Static AWS access keys handed to a third party are long-lived bearer credentials that never expire on their own — if the integration configuration is ever exposed, the key works until someone notices and rotates it
Role delegation issues short-lived STS credentials on each assume-role call, so there is no durable secret sitting in Datadog’s configuration to steal in the first place
The external ID binds the trust relationship to your specific Datadog organization, defeating the confused deputy attack where another Datadog customer could otherwise induce the shared Datadog principal to assume your role
The delegated role’s IAM policy is yours to write and yours to tighten: you grant exactly the read permissions the integration needs and can revoke or narrow them from your own console at any time, without waiting on the vendor
Revocation is instant and unilateral — deleting the trust relationship cuts access immediately, whereas a leaked static key requires you to find and rotate it everywhere it was used
The Datadog AWS integration reads across your entire account inventory, so the credential backing it is one of the highest-value pieces of your cloud attack surface

Attack Prevented: Long-lived cloud credential theft, confused deputy attacks, unrevocable third-party access, over-permissioned integration roles

Prerequisites

AWS account access with IAM role creation permissions
Datadog Administrator access
The Datadog-provided AWS account ID and generated external ID

ClickOps Implementation

Step 1: Start the Integration in Datadog

Navigate to: Integrations → Amazon Web Services
Begin adding an AWS account and select role delegation as the access method
Copy the generated external ID — it is specific to your organization and must be used in the trust policy

Step 2: Create the Cross-Account Role in AWS

In the AWS IAM console, create a role for cross-account access
Set the trusted entity to the Datadog AWS account ID
Require the external ID from Step 1 in the trust policy condition — do not omit this, since the external ID is what prevents another tenant from assuming your role
Attach a policy granting only the read permissions the integration requires for the services you actually monitor

Step 3: Complete the Connection

Return to Datadog and supply the role name
Confirm the integration validates and begins collecting metrics
Select only the AWS services and regions you intend to monitor, keeping both the IAM policy and the collected data scoped

Step 4: Handle the Static-Key Exceptions Explicitly

Use access keys only where role delegation is unavailable: AWS China, and GovCloud accounts monitored from a commercial Datadog site
Where a static key is unavoidable, create a dedicated IAM user with a minimal read-only policy, document the exception, and put the key on a rotation schedule with a named owner

Step 5: Review Periodically

Re-review the role’s attached policy quarterly and remove permissions for services you no longer monitor
Remove trust relationships for Datadog organizations or AWS accounts that are no longer in use

Validation & Testing

Inspect the IAM role’s trust policy and confirm the external ID condition is present — a trust policy naming the Datadog account without an external ID condition is the failure mode to look for
Confirm the Datadog AWS integration page shows the account connected and metrics arriving
Audit the integration configuration for any remaining static access keys and confirm each is either removed or a documented China/GovCloud exception
Review the role’s attached policy for wildcard actions or write permissions the integration does not need
Test revocation in a non-production account by removing the trust relationship and confirming metric collection stops

Compliance Mappings

Framework	Control	Requirement
SOC 2	CC6.1	Access to systems is restricted to authorized entities
SOC 2	CC6.3	Credentials are managed and access is revocable
NIST 800-53	AC-3	Access enforcement is applied to third-party integrations
NIST 800-53	IA-5	Authenticator management, including avoiding static shared secrets
CIS Controls	5.4	Restrict administrator privileges to dedicated accounts
CIS Controls	6.8	Define and maintain role-based access control
ISO 27001	A.5.19	Information security in supplier relationships

6.2 Use Service Account Impersonation for the Google Cloud Integration

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	5.4, 6.8
NIST 800-53	AC-3, IA-5

Description

Connect the Datadog Google Cloud integration using service account impersonation with automatic project discovery, rather than generating and uploading a downloadable service account key file. Reference: Google Cloud Platform Integration.

Rationale

Why This Matters:

A downloaded service account key is a JSON file containing a private key that never expires, and every copy of it — in a config directory, a chat message, a ticket attachment, a backup — is a working credential to your cloud environment
Impersonation replaces that file with a trust relationship: Datadog’s principal is granted permission to impersonate your service account, and short-lived tokens are minted per request, so there is no key file to leak
Google itself treats downloaded key files as a discouraged pattern precisely because their lifecycle is unmanageable at scale; organizations frequently cannot say how many copies of a given key exist
Automatic project discovery means new projects are picked up without minting a new credential for each one, removing the operational pressure that leads teams to create and share long-lived keys
Revocation is a single IAM change on your side — remove the impersonation grant and access stops immediately, with no need to hunt down distributed copies of a key file
The integration reads across your GCP estate, so this credential is a high-value target and deserves the strongest available binding

Attack Prevented: Service account key file leakage, unrevocable cloud access, credential sprawl across projects, long-lived private key compromise

Prerequisites

Google Cloud project access with IAM administration permissions
Datadog Administrator access
The Datadog principal identifier provided during integration setup

ClickOps Implementation

Step 1: Begin Setup in Datadog

Navigate to: Integrations → Google Cloud Platform
Start adding a Google Cloud account and select the service account impersonation method
Note the Datadog principal that will be granted impersonation rights

Step 2: Create the Service Account in Google Cloud

In the Google Cloud console, create a service account dedicated to Datadog monitoring
Grant it the roles the integration requires for the telemetry you want, keeping to read-level roles
Do not generate or download a key for this service account — the whole point of the pattern is that no key file exists

Step 3: Grant Impersonation to Datadog

On the service account, add the Datadog principal with the role permitting token creation and impersonation
Complete the connection in Datadog and confirm it validates

Step 4: Enable Automatic Project Discovery

Enable automatic project discovery so newly created projects are monitored without provisioning additional credentials
Review the discovered project list and exclude projects that should not be monitored

Step 5: Retire Existing Key Files

Inventory any existing Datadog Google Cloud integrations still configured with uploaded key files
Migrate them to impersonation, then delete the corresponding service account keys in Google Cloud so the retired credential cannot be reused
Deleting the key in Google Cloud is the step that actually revokes it — removing it from Datadog alone leaves the key valid

Validation & Testing

In the Google Cloud console, confirm the Datadog service account has zero user-managed keys — any key present is a credential that can leak
Confirm the IAM policy shows the Datadog principal granted impersonation on the service account
Verify in Datadog that Google Cloud metrics are arriving and the integration reports healthy
Create a test project and confirm automatic discovery picks it up without any new credential being issued
Test revocation in a non-production project by removing the impersonation binding and confirming collection stops

Compliance Mappings

Framework	Control	Requirement
SOC 2	CC6.1	Access to systems is restricted to authorized entities
SOC 2	CC6.3	Credentials are managed and access is revocable
NIST 800-53	AC-3	Access enforcement is applied to third-party integrations
NIST 800-53	IA-5	Authenticator management, including avoiding downloadable private keys
CIS Controls	5.4	Restrict administrator privileges to dedicated accounts
CIS Controls	6.8	Define and maintain role-based access control
ISO 27001	A.5.19	Information security in supplier relationships

6.3 Review Remote Configuration Enablement

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	4.1, 4.8
NIST 800-53	CM-6, CM-7

Description

Remote Configuration lets Datadog push configuration changes from the platform down to running Datadog Agents and tracing libraries without a local deployment. It is enabled by default at the organization level. Review whether your organization actually uses it, and disable it at Organization Settings → Remote Configuration if not. Toggling this setting requires the org_management permission. Reference: Remote Configuration.

Rationale

Why This Matters:

Remote Configuration is a control plane reaching into every host running the Datadog Agent, which means a compromise of that plane or of a sufficiently privileged Datadog account translates into configuration changes pushed across your fleet
Because it is on by default, most organizations have this channel open without having made a decision about it — the default is the exposure, and reviewing it is the control
If you do not use remote-configured features, leaving the channel open is standing capability with no offsetting benefit, which is exactly what least-functionality principles say to remove
Disabling it forces agent configuration back through your normal deployment pipeline, where changes are version controlled, peer reviewed, and auditable — properties a platform-side push does not inherently have
Where the capability is genuinely needed, the mitigation shifts to tightly controlling who holds org_management and the permissions governing remote config, and to alerting on changes through the audit trail

Attack Prevented: Fleet-wide agent configuration tampering, control plane abuse, unaudited configuration drift, over-broad standing capability

Prerequisites

Datadog Administrator access with the org_management permission
An inventory of which Datadog features your organization uses that depend on Remote Configuration

ClickOps Implementation

Step 1: Determine Whether You Actually Use It

Identify which Datadog capabilities in use rely on Remote Configuration to push settings to agents and tracing libraries
If no team depends on remote-pushed configuration, the capability is unused standing exposure

Step 2: Review the Organization Setting

Navigate to: Organization Settings → Remote Configuration
Note the current state — it is enabled by default, so an untouched organization will show it on
Confirm which users and roles hold org_management and can therefore change this setting

Step 3: Disable If Unneeded

If your organization does not use remote-configured features, disable Remote Configuration at the org level
Record the decision and its rationale in your change management system, so a future enablement is a deliberate reviewed action rather than a silent default

Step 4: Harden If Retained

Where Remote Configuration is required, restrict the org_management permission to the minimum set of administrators
Create a monitor against the audit trail alerting on changes to Remote Configuration state and on remote configuration pushes
Re-review the decision on your regular access review cycle

Validation & Testing

Load Organization Settings → Remote Configuration and confirm the state matches your documented decision rather than the platform default
Enumerate the users and roles holding org_management and confirm the list matches your approved administrator inventory
If disabled, confirm agents continue reporting normally and that no team reports a broken feature that silently depended on remote configuration
If retained, verify the audit trail monitor fires by making a benign configuration change in a non-production organization
Re-verify the setting after any organization migration or plan change, since defaults reassert on newly created organizations

Compliance Mappings

Framework	Control	Requirement
SOC 2	CC6.1	Access to configuration capabilities is restricted
SOC 2	CC8.1	Changes to system configuration are authorized and tracked
NIST 800-53	CM-6	Configuration settings are established and enforced
NIST 800-53	CM-7	Least functionality — unnecessary capabilities are disabled
CIS Controls	4.1	Establish and maintain a secure configuration process
CIS Controls	4.8	Uninstall or disable unnecessary services and capabilities
ISO 27001	A.8.9	Configuration management

7. Compliance Quick Reference

SOC 2 Trust Services Criteria Mapping

Control ID	Datadog Control	Guide Section
CC6.1	SSO/SAML	1.1
CC6.1	IP Allowlist	2.3
CC6.2	RBAC	2.1
CC6.3	Cloud integration credentials	6.1
CC6.6	Session security	1.3
CC6.7	Key security	3.1
CC7.2	Audit logging	4.1
CC8.1	Remote Configuration review	6.3
C1.1	Sensitive data redaction	5.1

NIST 800-53 Rev 5 Mapping

Control	Datadog Control	Guide Section
IA-2	SSO	1.1
AC-6	Least privilege	2.1
AC-17	Network-restricted access	2.3
SC-12	Key management	3.1
IA-5	Authenticator management	3.2
SC-28	Protection of data at rest	5.1
SI-19	De-identification	5.1
AC-3	Third-party access enforcement	6.2
CM-7	Least functionality	6.3
AU-2	Audit logging	4.1

Appendix A: References

Official Datadog Documentation:

API & Developer Documentation:

Compliance Frameworks:

SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, ISO 27701 — via Trust Center
HIPAA-compliant Log Management available
CSA Security, Trust & Assurance Registry (STAR) registered
Annual penetration testing by NCC Group

Security Incidents:

No major public security incidents identified affecting the Datadog platform directly.

Changelog

Date	Version	Maturity	Changes	Author
2026-08-08	0.2.1	draft	Cheat-sheet cell repair: added missing Attack Prevented line(s) to §1.1 (no content-facts changed)	Claude Code (Fable 5)
2026-08-03	0.2.0	draft	Add IP Allowlist (2.3), Data Protection section with Sensitive Data Scanner (5.1), Integration & Agent Security section with AWS role delegation (6.1), GCP service account impersonation (6.2), and Remote Configuration review (6.3); extend RBAC with Logs Restriction Queries and application keys with service accounts and authorization scopes	Claude Code (Sonnet 5)
2026-06-29	0.1.1	draft	Add cheat-sheet Description and Rationale for all controls	Claude Code (Opus 4.8)
2025-02-05	0.1.0	draft	Initial guide with SSO, RBAC, and key security	Claude Code (Opus 4.5)

Contributing

Found an issue or want to improve this guide?

Report outdated information: Open an issue with tag content-outdated
Propose new controls: Open an issue with tag new-control
Submit improvements: See Contributing Guide

Datadog Hardening Guide

Overview

Intended Audience

How to Use This Guide

Scope

Table of Contents

1. Authentication & SSO

1.1 Configure SAML Single Sign-On

Description

Rationale

Prerequisites

ClickOps Implementation

1.2 Enable SAML Strict Mode

Description

Rationale

ClickOps Implementation

1.3 Configure Session Security

Description

Rationale

ClickOps Implementation

2. Access Controls

2.1 Configure Role-Based Access Control

Description

Rationale

ClickOps Implementation

2.2 Limit Admin Access

Description

Rationale

ClickOps Implementation

2.3 Restrict Access with the IP Allowlist

Description

Rationale

Prerequisites

ClickOps Implementation

Validation & Testing

Compliance Mappings

3. API & Key Security

3.1 Secure API Keys

Description

Rationale

ClickOps Implementation

3.2 Secure Application Keys

Description

Rationale

ClickOps Implementation

4. Monitoring & Compliance

4.1 Configure Audit Logs

Description

Rationale

ClickOps Implementation

5. Data Protection

5.1 Redact Sensitive Data with the Sensitive Data Scanner

Description

Rationale

Prerequisites

ClickOps Implementation

Validation & Testing

Compliance Mappings

6. Integration & Agent Security

6.1 Use IAM Role Delegation for the AWS Integration

Description

Rationale

Prerequisites

ClickOps Implementation

Validation & Testing

Compliance Mappings

6.2 Use Service Account Impersonation for the Google Cloud Integration

Description

Rationale

Prerequisites

ClickOps Implementation

Validation & Testing

Compliance Mappings

6.3 Review Remote Configuration Enablement

Description

Rationale

Prerequisites

ClickOps Implementation

Validation & Testing

Compliance Mappings