💡 Still using the classic Drata experience? Refer to Connections overview for the original UI.
Overview
Connections allow Drata to collect evidence, monitor compliance signals, and reduce manual work by integrating with the systems your organization already uses.
This article explains what connections are, why they matter, and how to think about them before you configure anything.
The Connections page is where you integrate Drata with third-party applications. Connections automate evidence collection, reduce manual work, and help maintain continuous compliance.
The Connections page includes:
Active tab: Integrations your organization has already enabled. Edit, refresh, or disconnect them as needed.
Available tab: All integrations your organization can add, organized by category.
Manage Account pages: These pages let you view and manage which accounts are included in ongoing monitoring and evidence collection. For the following connection categories:
Access Reviews: Used to manage accounts synced through the User Access Review connection
Background Checks: Used to manage connected background check providers
Infrastructure: Used to manage connected cloud or infrastructure accounts
Observability: Used to manage connected monitoring and logging accounts
Version Control: Used to manage connected repositories and organizations
How connections are grouped
Connections in Drata are organized into categories based on the type of system they integrate with.
Each category represents a different type of compliance signal, such as identity data, infrastructure configuration, or operational activity.
Common connection categories include:
Automation tools
Background check
Codebase
Communication
CRM
CSPM
Custom
Cyber insurance
Digital signature
EDR
Enterprise SSO
External policy
HRIS
Identity
Infrastructure
MDM
Observability
Security reviews
Security training
Ticketing
User access review
Version control
Vulnerability
You may see additional or fewer categories depending on your plan and frameworks. Learn more at Unlock the Power Of Compliance Automation.
You do not need to connect every possible system to be compliant.
Recommended connection order
Most customers connect systems in this general order:
Identity provider
Infrastructure
Version control
Ticketing
This sequence helps establish access, asset scope, and operational workflows early. For a guided onboarding flow, see the Quick Start Guide (New Experience).
What you typically need to connect a system
Most connections in Drata require read-only access to an external system so Drata can collect evidence without making changes. In many cases, this access is provided through a service account or a dedicated integration user created in the source system.
A service account:
Is used by Drata, not an individual employee
Remains active even when team members change roles or leave
Is limited to only the permissions needed to collect evidence
Depending on the system you’re connecting, you may need:
Admin or elevated permissions to create the service account within the 3rd party system
Drata Admin role
Approval from IT or Security teams
API access or authentication tokens
Drata does not require full administrative access to your systems, but exact permissions vary by integration. When you’re ready to connect a system, the setup guide for that integration lists the specific requirements. Learn more about Connections setup guides.
Why connections matter for compliance
Most compliance requirements depend on signals that live outside Drata, including:
Who has access to systems
Which employees are in scope
How infrastructure is configured
Whether policies and processes are being followed
Connections generally allow Drata to:
Pull information directly from source systems
Validate requirements continuously instead of at a point in time
Surface gaps or risks as they occur
Without connections, Drata can still function, but more evidence must be collected and maintained manually.
How connections relate to frameworks, controls, and tests
Connections support your compliance structure but do not define it. In general:
Frameworks define what standards you’re meeting
Controls define how requirements are satisfied
Tests and evidence validate that controls are operating as intended
Connections supply the system data that tests and evidence rely on
This is a useful mental model to keep in mind as you configure integrations.
Automated vs. manual evidence
Connections primarily support automated evidence collection, but automation is not required for every requirement. If a system is not connected:
Evidence may be required to be uploaded manually
Some tests may rely on periodic review instead of continuous monitoring
Certain controls may use attestations rather than system data
Connecting a system generally increases automation, but compliance outcomes depend on how the system is used, not just whether it’s connected.
Learn more
Identity connections
Infrastructure connections
Version control connections
Ticketing connections