Drata User Management Guide

• Model type: role-based
• Description: Drata uses a fixed set of built-in roles (Administrator, Owner, Auditor, Employee/Personnel). Roles are assigned per user at the platform level. Object-level ownership (controls, policies) is assigned separately within the platform. No custom role builder is available in the UI.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level only; no field-level or resource-level permission overrides outside of object ownership assignment.

1. Log in to Drata as an Administrator.
2. Navigate to Settings → User Management (https://app.drata.com/settings/users).
3. Click 'Invite User' or 'Add User' button.
4. Enter the user's email address.
5. Select the appropriate role (Administrator, Owner, or Auditor).
6. Click 'Send Invite'. The user receives an email invitation to set up their account.
7. User accepts the invitation and completes account setup (password or SSO login depending on configuration).

Required fields: Email address, Role selection

Watch out for:

• Invitation emails can land in spam; advise new users to check junk folders.
• If SSO is enforced, users must authenticate via the configured IdP; password-based login may be disabled.
• Personnel (employees) are synced via HR integrations (e.g., BambooHR, Rippling, Workday) or added manually in the Personnel section, not through the User Management invite flow.
• Adding platform users (Administrators, Auditors) does not automatically add them as tracked Personnel/FTEs, and vice versa.

• Can delete users: No
• Delete/deactivate behavior: Drata does not permanently delete user accounts from the platform UI. Administrators can deactivate users, which revokes login access and removes them from active user counts, but the user record and associated audit history are retained for compliance record-keeping purposes.

1. Log in to Drata as an Administrator.
2. Navigate to Settings → User Management (https://app.drata.com/settings/users).
3. Locate the user to be deactivated.
4. Click the options menu (ellipsis or action button) next to the user.
5. Select 'Deactivate' or 'Remove User'.
6. Confirm the deactivation in the prompt.

Watch out for:

• Reassign control and policy ownership before deactivating a user to avoid orphaned compliance tasks.
• If SCIM provisioning is active (Enterprise plan), user deactivation should be managed in the IdP; manual deactivation in Drata may be overridden by the next SCIM sync.
• Deactivated users cannot log in but their historical activity and evidence submissions remain in audit logs, which is intentional for SOC 2 and ISO 27001 audit trails.
• There is no bulk deactivation option in the UI; each user must be deactivated individually.

• Where to check usage: Settings → User Management shows active platform users. Personnel count is visible under the Personnel section of the Drata dashboard.
• How to identify unused seats: Review last login dates in Settings → User Management. Users who have never logged in or have not logged in for an extended period after invitation may indicate unused seats. No automated idle-user report is available in the standard UI.
• Billing notes: Drata pricing is contract-based and not publicly listed per seat. FTE count is the primary driver of plan tier. Platform user (admin/auditor) seat counts are typically negotiated at contract time. Exceeding contracted FTE limits or adding frameworks beyond plan scope may trigger upsell conversations. Audit firm access (Auditor role) is typically handled outside standard seat billing.

SCIM provisioning is gated to the Enterprise tier, so teams on Foundation ($7,000–7,500/year) or Advanced ($15,000/year) plans must manage every app user invite, role change, and deactivation by hand. There is no bulk deactivation option; each user must be processed individually.

Auditor accounts have no automated expiry, so creating and tearing down access per audit engagement is a recurring manual task.

Personnel (employees) are tracked separately from platform users and are typically synced via HR integrations such as BambooHR, Rippling, or Workday - not through the standard invite flow. Confusion between 'platform users' and 'tracked Personnel/FTEs' is a documented source of duplicate or mismatched records.

FTE count, not named-user seats, drives plan tier eligibility, so headcount growth can trigger an upsell conversation independent of how many Administrators or Auditors are active.

Practitioners consistently flag the absence of bulk user operations as a friction point - role changes and deactivations must be done one record at a time.

Invitation emails are reported to land in spam with enough frequency that re-invitation is a known support pattern; advising new users to check junk folders is a practical mitigation.

The split between platform users and Personnel records is a recurring source of confusion: adding an Administrator does not automatically create a tracked Personnel entry, and vice versa.

Teams that rely on HR integrations for Personnel sync report that mismatches between IdP-sourced records and manually added platform users require periodic reconciliation.

Common complaints:

• Custom pricing can be high for larger orgs.
• No bulk deactivation or bulk role-change option; user management must be done one at a time for platform users.
• SCIM provisioning is restricted to Enterprise tier, requiring manual user management on lower plans.
• Personnel sync via HR integrations can create confusion between 'platform users' and 'tracked employees', leading to duplicate or mismatched records.
• Auditor role access setup and teardown is a manual process with no automated expiry or time-limited access feature.
• Users report that invitation emails are sometimes not received, requiring re-invitation.
• No granular permission customization; organizations needing read-only access for internal stakeholders must use the Auditor role, which was designed for external auditors.

Manual user management in Drata is workable for small, stable teams on Foundation or Advanced plans where headcount and role changes are infrequent. The fixed role set covers the core compliance use cases - Administrator, Owner, Auditor, Employee - without requiring configuration overhead.

For organizations with regular onboarding and offboarding volume, the absence of bulk operations and SCIM below Enterprise tier creates compounding overhead. Teams should weigh the per-engagement cost of manual Auditor provisioning and the FTE-count sensitivity of plan tiers before committing to a lower plan.

If automated lifecycle management across every app is a requirement, the Enterprise tier with IdP-based sync is the only supported path within Drata.

Bottom line

Drata's manual user management is straightforward for low-change environments but does not scale gracefully: no bulk actions, no custom roles, no automated Auditor expiry, and SCIM locked to Enterprise. The platform/Personnel record split requires deliberate process design to avoid compliance gaps.

Teams expecting frequent role changes or headcount growth should factor the Enterprise upgrade cost into their evaluation, since the Foundation and Advanced tiers leave the full provisioning burden on administrators.