Who can change the monitoring.
A list, not an estimate.
Datadog access control is roles, permissions, SAML single sign-on, restriction queries, and the API and application keys that bypass all of them. We implement it so the answer to who can do what is a list the organisation can evidence, and we keep that list true every month.
Quick facts
Related
- Audit Trail, the record of every role and key change
- Teams, ownership the roles are built around
- Governance Console, unscoped and unused keys found across the organisation
A permission model that can be read out loud to an auditor
A customer's security questionnaire asks who can modify monitoring and alerting for the service they buy. The answer, in most Datadog organisations, is every user, because every user holds the Standard role and the Standard role can edit monitors. Access control is the work of making that answer short and true.
Roles that match the job. Admin, Standard and Read Only cover the trial. Custom roles cover the organisation: an on-call role that can mute monitors, a finance role that can read usage, a developer role that can edit its own team's dashboards and nothing else.
Sign-on from the identity provider. SAML single sign-on with group mapping, so joining and leaving happens in the identity provider and Datadog follows, and the leaver's access ends the day it should.
Data scoped by role. Restriction queries limit which logs a role can read, so a team sees its own service's logs and a contractor sees the environment they were engaged for.
Keys that can be accounted for. API keys for Agents, application keys for people and service accounts, each scoped to the permissions it needs, with an owner, and with the ones nobody uses revoked.
A Standard role that can do most things, keys that outlive their owners, and a SAML setup that maps every group to Admin
How it bills. Access control is not metered. Datadog lists it among the platform's built-in features, and its pricing list carries no meter for roles, restriction queries or keys. The pricing page shows SAML single sign-on on every Infrastructure Monitoring plan, with multiple SAML providers and IP allowlists on Enterprise. The cost of getting it wrong is not on the invoice. It is in the questionnaire that cannot be answered.
The configuration traps. The Standard role is the default for every invited user, and it can edit monitors, dashboards and notebooks across the organisation. Application keys inherit the full permissions of the user who created them unless they are scoped, and an unscoped key in a CI pipeline carries an engineer's rights into every build. When that engineer's account is disabled their application keys are revoked, but any API keys they created stay valid. SAML group mapping set up in a hurry maps the engineering group to Admin because that was the group that needed it on the day. Roles do not cross from a parent organisation to its children, so a multi-org estate has the same work to do several times.
Field noteThe most common gap we see is the number of administrators. The Admin role was granted to whoever asked during the rollout and never reduced. Years later, the people who can change billing, revoke keys and alter roles include most of the engineering team, and the questionnaire has to say so.
Field noteThe pattern we keep finding is an unscoped application key in a deployment pipeline, created by an engineer who has since moved teams. It carries that engineer's permissions into every build, and nobody can say what it is used for without turning it off.
Field noteA restriction query is configured for one team's role during an onboarding and not for the others. That team now sees only its own logs. Every other role still reads everything, that team's logs included, and the model looks complete from the inside.
Field noteSAML is enabled, and the local username and password login is left on beside it. The identity provider removes the leaver. Datadog still accepts the password.
Fewer administrators, keys with owners, and a leaver who loses access the same day
We start with a Datadog HealthScan. It is read-only and fully automated. It reports the roles and their member counts, the Admin list, and whether SAML and local login are on. It lists keys with no scope or no recent use, and which restriction queries exist. Nothing changes until that report is read. Then the sequence reduces before it adds.
- List who has what. Every user, role and key, against the organisation chart and the questionnaire's question, so the gap is specific before anything is changed.
- Design the roles. Custom roles from the permission list, named for the job rather than the team, with Admin reduced to the few people who administer the organisation.
- Configure SAML with group mapping. Groups in the identity provider mapped to the roles from step two, and local login disabled once the mapping is verified.
- Scope the data. Restriction queries per role for logs, and resource-level restrictions on the dashboards and notebooks that carry sensitive views.
- Govern the keys. Application keys scoped to their purpose, and service accounts for automation rather than personal keys. API keys inventoried against the Agents that use them, and the unused ones revoked.
- Hand over, in writing. The role matrix, the SAML mapping, the key inventory with owners, the restriction queries, and the procedure for reviewing all of them.
Access is admin on the Datadog organisation. We hold it while the work is done and reduce it afterwards to the role the monthly review needs. We also need read access to the identity provider's group configuration, arranged with your identity team. We operate and evidence the runtime controls that support your compliance obligations.
The access review, done monthly, as Runtime Evidence
People join, move and leave. Keys are created for a migration and kept. A group mapping is widened for a project and never narrowed. Managed Observability reviews the access model every month and records what it found, so the evidence exists before anyone asks for it.
Every month, the role matrix is checked. Who holds Admin, who joined which role, and whether the SAML mapping still matches the identity provider's groups. Additions get a reason or a removal.
Keys are kept honest. Application keys without scope, keys unused for a period, and API keys created by accounts that no longer exist are listed and, with the owner's agreement, revoked.
Leavers are verified. Accounts disabled in the identity provider are confirmed disabled in Datadog, and the application keys they created are confirmed revoked.
The questionnaire is answered from the record. The role matrix, the key inventory and the Audit Trail export are the evidence, produced on request, rather than a statement of policy.
We operate the stack. You own the product.
Access control is the part of the Datadog estate an auditor reads. We implement it to be read: a role matrix with reasons, a key inventory with owners, and a monthly review that is written down. The roles, the mapping and the keys live in your Datadog organisation and your identity provider, and you can take the review in-house whenever you choose.
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 access control, answered plainly
How is Datadog access control billed?
It is not metered. Datadog lists access control among the platform's built-in features, and its pricing list carries no meter for roles, restriction queries or API and application keys. SAML single sign-on is listed on every Infrastructure Monitoring plan, with multiple SAML providers and IP allowlists on Enterprise. We do not publish prices. The work is in the design of the roles and the discipline of the review, not on the invoice.
What is the difference between a Datadog API key and an application key?
An API key belongs to the organisation and is what the Agent and integrations use to send data in. An application key belongs to the user or service account that created it and is what programmatic access uses to act in Datadog with that user's permissions, unless it is scoped to fewer. When a user is disabled their application keys are revoked, but API keys they created stay valid, which is why API keys need an inventory of their own.
Can we restrict which logs a team can see in Datadog?
Yes. A restriction query attached to a role limits the logs that role can read, usually by a team or service tag applied at ingestion. Each role takes one restriction query, and permissions are additive, so a user who needs several teams' logs is given several roles. Roles on the unrestricted list bypass the queries, and that list is the one to keep short.
Should we use SAML single sign-on with Datadog?
Yes, wherever an identity provider exists. SAML with group mapping moves joining, role changes and leaving into the identity provider, so Datadog follows the organisation rather than being administered separately. The two checks that matter are that the group mapping grants the right roles rather than Admin by default, and that local password login is disabled once SAML is verified.
What does Critical Cloud do with access control every month?
Managed Observability reviews the role matrix and the Admin list, and confirms the SAML mapping matches the identity provider. It lists unscoped and unused keys and revokes them with the owner's agreement. It verifies leavers are disabled and their application keys revoked, and it produces the evidence a questionnaire or an audit asks for. We operate and evidence the runtime controls that support your compliance obligations.
- Datadog products: every product, and how we implement and run each one
- Audit Trail: the record of every role, key and login change, archived to your storage
- Teams: the ownership the roles and the routing are built around
- Datadog HealthScan: roles, members, keys and sign-on state read without changing anything
Who can change the monitoring. A short list, and a true one.
Tell us what the questionnaire asks. We will show you who can do what in your Datadog organisation today, and what it takes to make the answer short.