Amplitude User Management

Amplitude permissions are controlled at the organization and project level. Use this playbook to keep the collaborator onboarded, updated, and removed without breaking audit trails or SSO syncs.

How Amplitude Organizes Users

Amplitude uses a dual-layer access model combining organization-wide roles with project-specific permissions. Understanding both layers is essential for secure collaborator management.

Organization-Level Roles

Organization roles grant global capabilities across all projects and administrative functions.

Owner:

• Full administrative control over the organization
• Manage billing, subscription plans, and invoices
• Configure SSO, SCIM, and security settings
• Create, archive, and delete projects
• Add, remove, and modify all users
• Access all projects regardless of project-level permissions
• Transfer ownership to another user

Admin:

• Create and manage projects
• Add and remove organization members
• Modify user roles and project access
• Configure integrations at the organization level
• Cannot access billing or transfer ownership
• Access all projects by default

Manager:

• Limited administrative capabilities
• Can be granted permission to manage specific projects
• Add users to projects they manage
• Cannot create new projects or modify organization settings
• Project access must be explicitly granted

Member:

• Standard user role with no organization-level privileges
• Project access must be granted explicitly
• Cannot invite or manage other users
• Cannot create projects
• Ideal default role for collaborators

Project-Level Roles

Project roles control what users can do within individual analytics workspaces.

Admin:

• Full control over project settings and data
• Manage project team members
• Configure data taxonomies and governance rules
• Create and manage data integrations
• Set up destinations and cohort syncs
• Delete the project (with appropriate org role)
• Edit tracking plans in Govern (if enabled)

Manager:

• Create and edit charts, dashboards, and cohorts
• Share content with team members
• Manage saved queries and templates
• Cannot modify project settings or team membership
• Cannot configure integrations or destinations
• Can approve/reject events in Govern workflows (if granted)

Member:

• View and create personal charts and dashboards
• Build cohorts for analysis
• Cannot share content organization-wide
• Cannot edit shared dashboards
• Cannot access Govern or administrative features
• Suitable for analysts who consume insights

Viewer:

• Read-only access to shared dashboards and charts
• Cannot create charts or perform queries
• Cannot build cohorts or segments
• Use for stakeholders who need visibility without analysis capabilities
• Minimal licensing cost (if applicable to plan)

Govern and Experiment Add-Ons

Amplitude's Govern and Experiment products layer additional permissions on top of project roles.

Govern permissions:

• Data Manager: Create and edit event schemas, approve/block events, manage data quality
• Consumer: View tracking plans and event documentation, cannot edit
• Grant Govern roles separately from project roles when the collaborator manages data quality

Experiment permissions:

• Experiment Admin: Create experiments, define variants, configure targeting, deploy flags
• Experiment Analyst: View experiment results, analyze data, cannot deploy changes
• Required when the collaborator manages feature flags or A/B tests

Document which add-on permissions the collaborator receives. These often have separate licensing implications and should align precisely with scope of work.

Role Hierarchy and Permissions Matrix

Account Types and Capabilities

Organization Administrators

Organization Owners and Admins manage global settings and have broad access.

Use Org Owner for:

• Primary client contact responsible for the Amplitude account
• Finance team member handling billing
• Limit to 1-2 people maximum

Use Org Admin for:

• IT administrators managing SSO integration
• Platform team lead responsible for Amplitude governance
• Senior collaborator contact if they manage multiple projects and users (rare)

Grant to collaborators when:

• Collaborator is implementing Amplitude from scratch and needs to create projects
• Collaborator manages a large team requiring user administration
• Statement of work explicitly includes platform administration
• Document admin access in DPA and review quarterly

Avoid granting to collaborators when:

• Work is scoped to specific projects
• Analysis and implementation don't require org-level controls
• Billing visibility is restricted by policy

Project Administrators

Project Admins have full control within assigned projects but no organization-level access.

Use Project Admin for:

• Collaborators implementing tracking for specific apps or properties
• Analytics leads managing a single brand or product line
• Data engineers configuring integrations and destinations
• Govern administrators defining event taxonomies

Scoping considerations:

• Grant Admin on staging/QA projects where the collaborator needs configuration freedom
• Consider Manager or Member role on production projects to reduce risk
• Separate "implementation admin" accounts from "analysis member" accounts for the same collaborator team

Security boundaries:

• Project Admins can export all data from their projects
• Can modify data pipelines and destination configurations
• Cannot access other projects unless explicitly granted

Standard Users (Manager, Member, Viewer)

Most collaborator engagements use these roles for day-to-day analysis and reporting.

Manager role best for:

• Senior analysts building dashboards for client stakeholders
• Data scientists creating cohorts and performing deep analysis
• Collaborators who need to share insights across teams

Member role best for:

• Junior analysts exploring data
• Collaborators who create personal insights but don't publish
• Team members still learning the platform

Viewer role best for:

• Client stakeholders who consume dashboards
• Compliance or audit teams needing read-only verification
• Temporary access for demos or reviews

Cost implications: Some Amplitude plans meter by "query-running users" vs. viewers. Confirm with your account team whether Viewers count against your license.

Service Accounts and API Users

Amplitude supports programmatic access through API keys and service accounts.

Service account patterns:

• Create a dedicated organization member for API integrations
• Use a service account email (e.g., amplitude-api@client.com)
• Grant minimal project access required for the integration
• Store API keys in secure vaults (AWS Secrets Manager, HashiCorp Vault)

API key scoping:

• Project API keys grant access to specific project data
• Organization API keys (rarely needed) access multiple projects
• Govern API keys control data taxonomy programmatically

For collaborator integrations:

• Provide project-scoped API keys only
• Rotate keys when the collaborator engagement ends
• Monitor API usage through Amplitude's analytics on analytics
• Document which integrations use which keys for offboarding

Access Control and Data Governance

Project-Based Data Segmentation

Amplitude isolates data at the project level. Use project structure to enforce data minimization.

Single-project strategy:

• All app/web data in one project
• Use cohorts and filters to segment in analysis
• Simpler to manage, fewer projects to maintain
• Risk: Collaborators see all data if granted access

Multi-project strategy:

• Separate projects per brand, region, or sensitivity level
• Grant collaborators access only to relevant projects
• Clearer compliance boundaries
• More complex: tracking plans, schemas, and settings must be synced

Hybrid approach for collaborators:

• Production project with limited collaborator access (Manager/Member roles)
• Staging/dev project with broader access (Admin role) for testing
• Reporting project that receives filtered data via cohort syncs

Cohort and Segment Sharing

Collaborators can build cohorts (user segments) for analysis or activation.

Cohort visibility:

• Personal cohorts: Only visible to creator
• Shared cohorts: Visible to all project members
• Cohort syncs to destinations (Braze, Iterable, warehouses): May expose PII

Governance controls:

• Review what user properties collaborators can query
• Restrict cohort sync permissions to Project Admins only
• Audit shared cohorts quarterly to detect over-exposed segments
• Document if collaborators are allowed to export cohort membership lists

Blocking Sensitive Properties

Amplitude allows hiding user and event properties from specific roles.

Property-level permissions:

• Configure in Project Settings → Govern → Properties
• Hide PII (email, phone, address) from collaborators who don't need it
• Restrict revenue/conversion properties for traffic-focused analysts
• Hidden properties don't appear in query builders or exports

Implementation steps:

1. Audit which properties contain sensitive data
2. Navigate to Govern → Data → Properties
3. For each sensitive property, configure visibility rules
4. Test with a collaborator account to verify restrictions work
5. Document restrictions in your access tracker

Limitations:

• Property hiding requires Govern add-on
• Restrictions apply at project level, not per-user
• Hidden properties are still collected and stored, just not queryable

Team and Organization Structure

Workspace Organization Strategies

Centralized model:

• One organization, multiple projects
• Shared SSO, billing, and user management
• Easier to move users between projects
• Best for collaborators managing multiple properties

Federated model:

• Multiple organizations (rare, usually for acquired companies)
• Separate billing and SSO configurations
• Complete data isolation between orgs
• Collaborators need separate accounts for each org

For most collaborator engagements: Use a centralized model with project-level access control.

Groups for Bulk Access Management

Amplitude supports user groups for bulk permission management.

Creating groups:

1. Navigate to Settings → Organization Settings → Groups
2. Create a group (e.g., "Collaborator-Analytics-Team")
3. Add members to the group
4. Assign the group to projects with specific roles

Benefits:

• Add/remove collaborators from projects by changing group membership
• Clearer audit trail (changed group assignment vs. individual permissions)
• Easier to document "who has access to what" in compliance reviews

SSO/SCIM sync:

• Groups can be synced from your IdP (Okta, Azure AD)
• Map IdP groups to Amplitude groups for automated provisioning
• Document group mappings in your access tracker

Portfolio Feature for Multi-Org Management

Amplitude Portfolio allows managing multiple organizations from a single pane.

When relevant:

• Your company acquired another company with separate Amplitude orgs
• You manage Amplitude for multiple legal entities
• Consolidating reporting across subsidiaries

For collaborators:

• Portfolio access is rare for external collaborators
• Use only when the collaborator manages analytics for multiple entities
• Document Portfolio permissions separately

SSO and SAML Integration

Supported Identity Providers

Amplitude integrates with SAML 2.0 identity providers for single sign-on.

Verified IdPs:

• Okta
• Microsoft Azure AD / Entra ID
• OneLogin
• Google Workspace (G Suite)
• PingFederate
• Auth0
• Any SAML 2.0 compliant provider

Setup requirements:

1. Configure Amplitude as a SAML application in your IdP
2. Obtain SSO metadata from Amplitude (Settings → Organization Settings → SSO)
3. Configure attribute mappings (email, first name, last name)
4. Test with non-production user before enforcing SSO
5. Enable "Enforce SSO" to require SAML authentication for all users

SCIM Provisioning

Amplitude supports SCIM 2.0 for automated user lifecycle management.

What SCIM automates:

• User creation when added to IdP groups
• User deactivation when removed from IdP groups
• Profile updates (name, email changes)
• Group membership sync

Implementation pattern:

1. Enable SCIM in Amplitude (Settings → Organization Settings → SCIM)
2. Generate SCIM bearer token
3. Configure SCIM in your IdP with Amplitude's endpoint and token
4. Map IdP groups to Amplitude groups
5. Assign projects to Amplitude groups with desired roles
6. Add collaborators to IdP groups to auto-provision

Collaborator workflow:

• Create IdP group: "amplitude-client-project-analysts"
• Map to Amplitude group: "Client Project Analysts"
• Assign group to "Client Production" project as Members
• Add collaborator to IdP group → automatically provisioned in Amplitude

Cautions:

• SCIM changes can override manual changes in Amplitude
• Always modify IdP groups, not Amplitude directly
• Document SCIM mappings so future admins understand the automation
• Test deprovisioning workflow to ensure collaborators are removed correctly

Just-In-Time (JIT) Provisioning

Alternative to SCIM: Amplitude can create users automatically on first SSO login.

How JIT works:

• User authenticates via SSO
• If user doesn't exist in Amplitude, account is created automatically
• User is assigned default organization role (configurable)
• Project access must still be granted manually or via group mapping

Use JIT when:

• Your IdP doesn't support SCIM
• You want SSO without full automated provisioning
• Manual project assignment is acceptable

For collaborators:

• Set default JIT role to "Member" (not Admin or Owner)
• Pre-create collaborator accounts with correct project access before their first login
• Alternatively, use group-based JIT to auto-assign project access

API Access and Authentication

API Key Types

Amplitude offers several API key types for different use cases.

Project API Keys:

• Scope: Single project
• Use for: Sending events, querying analytics, managing project resources
• Located in: Project Settings → General
• Rotate: Annually or when collaborators change

Organization API Keys:

• Scope: Organization-wide access
• Use for: User management, project creation via API (rare)
• Located in: Settings → Organization Settings → API Keys
• Grant to collaborators: Only if managing multiple projects programmatically

Govern API Keys:

• Scope: Tracking plan and taxonomy management
• Use for: Automated schema validation, event blocking rules
• Required add-on: Govern
• Grant to collaborators: When they manage data quality tooling

Secret API Keys:

• Scope: High-security operations (export API, cohort downloads)
• Use for: Bulk data exports, warehouse syncs
• Storage: Must be stored securely, never committed to code
• Grant to collaborators: Only when exports are explicitly in scope

Authentication Methods

API Key authentication:

• Include API key in HTTP headers or query parameters
• Simple but less secure (keys are long-lived)
• Best for server-side integrations

OAuth (Coming Soon):

• Amplitude is rolling out OAuth for user-delegated API access
• Check latest documentation for OAuth availability
• Preferred for third-party integrations requiring user context

API Rate Limits

Amplitude enforces rate limits to protect platform stability.

Standard limits:

• Event Ingestion: 1,000 events/second per project (higher with Growth plan)
• Analytics Query API: 360 queries/hour per user
• Export API: 5 concurrent requests per project
• Govern API: 100 requests/minute per project

For collaborator integrations:

• Implement exponential backoff on 429 errors
• Cache query results to reduce API calls
• Use batch APIs when available (event upload supports batching)
• Contact Amplitude support if you need higher limits

Monitoring:

• Review API usage in Amplitude Analytics (track your own product analytics)
• Alert on anomalous patterns (sudden spike could indicate runaway script)
• Log API calls from collaborator integrations with distinct identifiers

Programmatic User Management

Amplitude's Management API allows user and project administration via API.

Use cases:

• Automate collaborator onboarding/offboarding
• Sync Amplitude access with internal IAM systems
• Bulk update project permissions

Key endpoints:

• POST /api/2/organizations/{org_id}/members (invite user)
• DELETE /api/2/organizations/{org_id}/members/{user_id} (remove user)
• POST /api/2/projects/{project_id}/members (grant project access)

Security best practices:

• Use organization API keys only for management operations
• Store API keys in secrets management systems
• Log all programmatic access changes
• Implement approval workflows for automated user provisioning

Audit Logging and Monitoring

Activity Logs

Amplitude tracks user actions across the platform.

What's logged:

• User logins and authentication events
• Project access and permission changes
• Dashboard and chart creation/modification
• Data exports and cohort syncs
• API key creation and usage
• SSO and SCIM configuration changes

Accessing activity logs:

1. Navigate to Settings → Organization Settings → Activity Log
2. Filter by user, action type, project, or date range
3. Export to CSV for compliance archival
4. Integrate with your SIEM if available (requires API or manual export)

Retention:

• Amplitude retains activity logs for 2 years (varies by plan)
• Export quarterly for long-term compliance storage
• Include in SOC 2, ISO 27001, or GDPR documentation

Audit Requirements for Collaborators

Before granting access:

• Document which projects the collaborator will access
• Record expected start and end dates
• Note which team members from the collaborator's organization will have accounts
• Capture Data Processing Agreement (DPA) consent

During the engagement:

• Review activity logs monthly for unexpected actions
• Monitor data export volumes (unusual spikes may indicate exfiltration)
• Verify SSO logins succeed and MFA is enforced (if configured)
• Check for dormant accounts (no logins in 60+ days)

After removing access:

• Export final activity log showing the collaborator's last actions
• Confirm no API keys remain active
• Verify SCIM/SSO group memberships removed
• Archive all audit evidence with the engagement records

Data Export Monitoring

Collaborators may export data for offline analysis or reporting. Monitor exports to detect anomalies.

Export types:

• CSV downloads from charts (limited to chart data)
• Cohort exports (full user lists with properties)
• Export API (bulk raw event data)
• Warehouse integrations (continuous sync)

Governance controls:

• Restrict Export API keys to Project Admins only
• Review cohort sync destinations monthly
• Alert on large cohort exports (>1M users) for investigation
• Document which collaborators are authorized for bulk exports

Compliance documentation:

• Log what data was exported, when, and by whom
• For GDPR/CCPA: Maintain records of data shared with collaborators
• Include export logs in Data Processing Impact Assessments (DPIAs)

Access Requests at a Glance

• Follow Add User Access when a new engagement begins or a new project needs to be shared.
• Use Update Access & Roles to adjust scopes, such as enabling Govern or Experiment modules, or adding Amplitude Data admin rights.
• Reference Remove User Access when work wraps and the service account should be deprovisioned.

Add, Update, Remove at a Glance

• Add: Invite the collaborator's service account, pick the org role, then explicitly tag every project that should be visible. Include Govern/Experiment toggles if the statement of work covers them.
• Update: Revisit project lists when new apps ship or when scope narrows. Move the org role up or down only after confirming SSO mapping won't immediately overwrite your change.
• Remove: Strip project access first, then drop the org role to No Access or delete the user. If SCIM is enabled, remove the IdP group mapping to prevent re-provisioning.

Platform Notes and Practical Steps

• Org + Project pairing matters: Amplitude's permissions always combine the organization role with per-project roles. When you add someone, set the organization role first, then walk through each project so staging, sandbox, and production match the engagement scope.
• Modules are additive: Govern and Experiment switches sit on the invite screen. Document why you enabled them and whether they should sunset at the end of the engagement so renewals don't creep in silently.
• SSO/SCIM overwrites happen fast: If access is managed through an IdP group, update the group before you adjust Amplitude roles so your changes aren't reversed on the next sync.
• Evidence to save: After any add, update, or removal, export the Access Logs and screenshot the Members & Groups view showing the collaborator's role and project list. Attach both to the access ticket so audits have a clear paper trail.

Roles to Maintain

• Organization Admins: Manage SSO, billing, and project creation. Keep at least two client admins plus one the collaborator's contact.
• Project Managers/Analysts: Day-to-day users with edit rights to charts, cohorts, and dashboards. Scope the collaborator to only the projects in play.
• Data Governors: Optional role for teams that expect the collaborator to help with Tracking Plans or Govern approvals.

Best Practices for Team Access Management

Start with Least Privilege

Grant the minimum organization and project roles required for the collaborator's work.

Decision framework:

1. Review the statement of work to identify deliverables
2. Map deliverables to Amplitude actions (create charts, configure integrations, export data)
3. Select the narrowest role that permits those actions
4. Grant access only to required projects (not all projects)

Common over-provisioning mistakes:

• Granting Org Admin when the collaborator only needs Project Admin
• Providing access to production and staging when work is only in staging
• Enabling Govern/Experiment when not in scope

Use Groups for Scalability

Create groups for common collaborator patterns.

Example group structure:

• "Collaborator-Analytics-Viewers" → Viewer on production projects
• "Collaborator-Implementation-Admins" → Admin on staging, Manager on production
• "Collaborator-Data-Governors" → Manager + Govern permissions on all projects

Benefits:

• Onboard new collaborators by adding to group
• Change group's project access to update all members
• Clearer documentation ("members of X group can do Y")

Separate Staging and Production Access

Grant broader permissions in non-production environments.

Pattern:

• Staging/Dev projects: Project Admin for collaborators (freedom to experiment)
• Production projects: Project Manager or Member (guard against accidental changes)
• Reporting projects: Viewer (read-only dashboards for stakeholders)

Time-Bound Access Reviews

Set calendar reminders to review collaborator access.

Review cadence:

• Monthly: Check for dormant accounts (no logins in 30+ days)
• Quarterly: Verify project access aligns with active contracts
• Annually: Audit all organization roles and downgrade where possible

Automated options:

• Use IdP group expiration features if available
• Build a script that queries Amplitude's API for last login dates
• Integrate with your IAM platform for unified access reviews

Common Access Issues and Solutions

Issue: Collaborator Can't See Expected Project

Symptoms:

• User logs in but project doesn't appear in project dropdown
• "You don't have access to this project" message

Resolution steps:

1. Verify the user accepted the Amplitude invitation email
2. Check that the user is explicitly added to the project (Organization role alone doesn't grant project access)
3. Confirm the user wasn't added to a group that was later removed from the project
4. If using SCIM, check IdP group membership and sync status
5. Look for typos in the user's email address

Prevention: After adding users, have them log in while you watch to verify visibility. Use groups to reduce individual assignment errors.

Issue: SSO Login Fails

Symptoms:

• "Authentication failed" error
• Redirect loop between Amplitude and IdP
• User lands on Amplitude password login instead of SSO

Resolution steps:

1. Verify the user's email domain matches a domain claimed in Amplitude SSO settings
2. Check IdP application configuration (ACS URL, Entity ID, attribute mappings)
3. Confirm the user is assigned to the Amplitude SAML application in your IdP
4. Review IdP logs for SAML assertion errors
5. Test with a known-working account to isolate user-specific vs. configuration issues
6. Verify SSO is not enforced if you're trying to use a non-SSO account

Prevention: Document SSO configuration and test with new users in a non-production environment first.

Issue: SCIM Sync Fails or Doesn't Update Users

Symptoms:

• User remains in Amplitude after being removed from IdP group
• New IdP group members don't appear in Amplitude
• "SCIM sync failed" error in IdP logs

Resolution steps:

1. Verify SCIM bearer token is still valid (they can expire)
2. Check network connectivity between IdP and Amplitude SCIM endpoint
3. Review IdP SCIM logs for specific error messages
4. Confirm IdP group mappings to Amplitude groups are correct
5. Test with a single user add/remove to isolate bulk vs. individual issues
6. Contact Amplitude support if errors persist (may be platform issue)

Prevention: Set up monitoring alerts for SCIM sync failures. Test sync behavior in a non-production organization first.

Issue: User Can't Export Data or Create Cohort Syncs

Symptoms:

• Export buttons greyed out or missing
• "You don't have permission to export" error
• Cohort sync fails to save

Resolution steps:

1. Verify the user has Manager or Admin project role (Members can export charts but not cohorts)
2. Check if organization-level export restrictions are enabled
3. Confirm the user has API keys if using Export API (not needed for UI exports)
4. For cohort syncs, verify the user has Admin role (required for destination configuration)
5. Check plan limits (some exports require paid plans)

Prevention: Document which roles can perform which export types. Grant Admin role explicitly when collaborators need cohort syncs.

Issue: Govern/Experiment Features Not Visible

Symptoms:

• Tracking Plan menu missing
• Experiment feature flags don't appear
• "Feature not available" message

Resolution steps:

1. Verify Govern/Experiment is included in your Amplitude subscription
2. Check that the feature is enabled at the project level (Project Settings → Add-ons)
3. Confirm the user's project role includes Govern/Experiment permissions
4. Verify the user is accessing the correct project (features may be enabled on some but not all)
5. Clear browser cache and cookies

Prevention: Document which projects have Govern/Experiment enabled. Communicate add-on availability clearly during onboarding.

Issue: API Calls Return 401 or 403 Errors

Symptoms:

• API authentication fails
• "Unauthorized" or "Forbidden" errors
• API calls succeed from some environments but not others

Resolution steps:

1. Verify the API key is correct and hasn't been rotated
2. Check that you're using the right API key type (project vs. organization vs. secret)
3. Confirm the API key has permissions for the requested resource
4. Review IP allowlist settings if configured
5. Check rate limits (429 errors indicate throttling, not auth failure)
6. Verify the project ID in the API request matches the project the key belongs to

Prevention: Store API keys in secure vaults with clear labeling. Document which keys are used for which integrations.

Security Recommendations

Enforce Multi-Factor Authentication

Amplitude supports MFA for enhanced account security.

MFA configuration:

1. Navigate to Settings → Organization Settings → Security
2. Enable "Require multi-factor authentication"
3. Users must set up MFA (TOTP via authenticator app) on next login
4. SMS-based MFA available depending on plan

For collaborators:

• Enforce MFA before granting access to production projects
• Verify MFA is enabled during onboarding
• SSO users may satisfy MFA through IdP (no separate Amplitude MFA needed)
• Document MFA status in access tracker

Use SSO Instead of Password Authentication

SSO provides stronger security and easier lifecycle management.

Benefits for collaborator access:

• Centralized authentication through your IdP
• MFA enforced at IdP level
• Automatic deprovisioning when removed from IdP
• Audit logs in both Amplitude and your IdP

Migration path:

• Claim your email domain in Amplitude
• Configure SAML integration
• Test with pilot users
• Enable "Enforce SSO" to prevent password logins
• Revoke any existing password-based sessions

Rotate API Keys Regularly

API keys are long-lived credentials that require active management.

Rotation schedule:

• Project API keys: Rotate annually or when collaborators change
• Secret API keys: Rotate every 6 months or per your security policy
• Organization API keys: Rotate quarterly (higher privilege)

Rotation process:

1. Generate new API key in Amplitude
2. Update collaborator integrations with new key
3. Test integrations to confirm they work
4. Delete old API key
5. Document rotation in your secrets management system

For collaborator engagements:

• Rotate all keys when engagement ends
• Provide new keys through secure channels (not email)
• Monitor for usage of old keys after rotation (indicates missed integration)

Implement IP Allowlisting

Restrict API and UI access to known IP ranges.

Configuration:

1. Gather collaborator office and VPN IP ranges
2. Navigate to Settings → Organization Settings → Security → IP Allowlist
3. Add allowed CIDR ranges
4. Test with collaborators before enforcing
5. Plan for remote work scenarios (home IPs, mobile access)

Limitations:

• May conflict with distributed teams or remote work
• Requires maintenance as collaborators change offices/VPNs
• SSO + MFA may provide sufficient security without IP restrictions

Monitor for Anomalous Behavior

Set up alerts for unusual collaborator activity.

Alert triggers:

• Bulk data exports exceeding normal patterns
• API rate limit errors (may indicate compromised key)
• Failed login attempts (possible credential stuffing)
• Access from unexpected geographic locations
• Changes to SSO or SCIM configuration
• New API keys created

Response workflow:

1. Detect anomaly through activity logs or API monitoring
2. Contact collaborator to verify if activity is legitimate
3. If unauthorized: Immediately revoke access and rotate keys
4. Investigate scope of potential data exposure
5. Document incident and update security controls

Governance Checklist

Before granting access:

• Data Processing Agreement signed and filed
• Collaborator's organization role selected (default to Member)
• Project access explicitly granted with appropriate roles
• Govern/Experiment permissions documented if granted
• SSO/SCIM group mappings configured if applicable
• MFA requirement communicated and verified
• API keys generated and stored securely if needed
• Access expiration date recorded in calendar
• Property visibility restrictions configured if hiding PII

During engagement (quarterly review):

• Confirm project access aligns with active SOW
• Review activity logs for unexpected behavior
• Check for dormant accounts (no logins in 60+ days)
• Verify API usage patterns remain normal
• Export and archive activity logs
• Confirm SSO/SCIM group memberships remain accurate
• Review data export volumes for anomalies

When engagement ends:

• Remove collaborator from all projects
• Delete user or set organization role to "No Access"
• Revoke all API keys (project, secret, organization)
• Remove from SSO/SCIM group mappings
• Export final activity log showing removal
• Verify no cohort syncs or integrations remain active
• Confirm collaborator deleted local data copies per DPA
• Transfer ownership of shared dashboards/cohorts if needed
• Archive access documentation and audit logs

Annual compliance:

• Review all Amplitude access against current contracts
• Audit organization roles for over-provisioning
• Test SCIM sync and SSO integration
• Review API key inventory and rotation schedule
• Update internal documentation for Amplitude feature changes
• Train team on any new Amplitude security features

Related Documentation

• Add User Access - Step-by-step workflow for inviting collaborators and assigning roles
• Update Access & Roles - How to modify permissions and project access during engagements
• Remove User Access - Offboarding process including API key revocation and audit exports
• Amplitude Help Center - Official product documentation
• Amplitude Security Portal - SOC 2, ISO 27001, and security white papers

Additional Resources

• Amplitude Platform: analytics.amplitude.com
• Amplitude Developers: developers.amplitude.com (API documentation)
• Amplitude Community: community.amplitude.com (peer support)
• Amplitude Status Page: status.amplitude.com (platform health)
• Amplitude Security: amplitude.com/security (compliance documentation)

Document which IdP groups grant Amplitude access and confirm the collaborator's membership aligns with contractual scope. Review Amplitude's Access Logs quarterly and export them for compliance storage. Track pending invites to ensure the collaborator's service account accepts within the expected SLA. Keep notes on which projects the collaborator's administers so future cleanup doesn't orphan dashboards or metrics.