Traditional IAM tools struggle to keep pace with the speed and complexity of modern infrastructure, leaving security teams with limited visibility into excessive standing privileges and orphaned accounts across cloud environments. Trustle reduces this risk by providing Just-in-Time access and Zero Standing Privileges. It gives teams clearer insight into entitlements across multi-cloud environments and SaaS, and automates access workflows so permissions are granted only when needed and removed when they’re not.
This document describes the measures Trustle has implemented to protect customer data and maintain a secure operating environment. It is intended for security leaders and IT decision-makers evaluating Trustle's security posture as part of their vendor assessment process.
How Trustle Handles Customer Data
Trustle is designed with a data minimization philosophy, collecting and storing only the information necessary to deliver its core functionality: providing visibility into access entitlements and enabling Just-in-Time access workflows.
Data Collected and Storage
Trustle stores identity and access management metadata from connected systems, including user identifiers, email addresses, group memberships, role assignments, and permission entitlements. In some cases, organizational data, such as manager relationships, is stored to support approval workflows. Trustle does not store customer passwords for connected cloud providers or SaaS applications.
All data transmitted between customer systems and Trustle is encrypted using TLS 1.2 or higher. Data at rest is encrypted using AES-256 encryption, consistent with Google Cloud's default encryption standards. Encryption keys are managed by Google Cloud by default, though Trustle supports customer-managed encryption keys through Google Cloud Key Management Service (KMS) for organizations that require the ability to bring their own keys (BYOK).
Integration Credential Security
Trustle requires integration API credentials to connect to customer systems and retrieve entitlement data. Given the sensitivity of these credentials, Trustle implements envelope encryption—a defense-in-depth approach recommended by Google Cloud for protecting high-value secrets.
Envelope encryption uses a two-tier key hierarchy. When Trustle stores an integration credential, it first encrypts the credential using a unique data encryption key (DEK) generated specifically for that secret. The DEK itself is then encrypted—or "wrapped"—by a key encryption key (KEK) that resides in Google Cloud Key Management Service. The wrapped DEK is stored alongside the encrypted credential, while the KEK never leaves Google Cloud KMS.
Rather than storing credentials in a traditional database, Trustle uses Google Cloud Secret Manager as its secure storage layer. Secret Manager provides a purpose-built environment for sensitive data, with secrets logically separated by organization and integration. This architecture ensures strict tenant isolation at the secret storage level. Secret Manager also provides a granular audit trail, recording every access to stored credentials for security monitoring and compliance purposes.
The KEKs used to wrap DEKs are protected at the Hardware Security Module (HSM) level within Google Cloud KMS. HSM protection ensures that key operations are performed within FIPS 140-2 Level 3 certified hardware, providing strong assurances against key extraction or tampering. KEKs are rotated automatically every 90 days, ensuring that cryptographic material is refreshed regularly without manual intervention or disruption to service.
This architecture provides several security benefits. Each credential is protected by its own unique DEK, limiting the blast radius if any single key were compromised. The KEK that protects all DEKs is managed within HSM-backed infrastructure, where it benefits from hardware-level security, strict access controls, and comprehensive audit logging. Because the KEK never leaves KMS, an attacker who gained access to Secret Manager would obtain only encrypted data—without access to the KEK inside Google Cloud KMS, this data is unreadable.
Data Isolation and Access Controls
Trustle operates a multi-tenant architecture with logical separation of customer data at the database level. Each customer's data is isolated and inaccessible to other tenants.
Trustle employees do not have routine access to customer data. Database access is restricted to break-glass scenarios for troubleshooting purposes and requires explicit authorization. All such access is logged and subject to review.
Data Retention, Deletion, and Backup
Customers may request deletion of their data at any time by contacting Trustle support. Upon receiving a deletion request, Trustle will remove customer data from production systems in accordance with the agreed-upon timeline.
Customer data is backed up to support disaster recovery and point-in-time restoration. Backups are encrypted using the same standards as production data and are retained for 90 days.
Compliance
Trustle maintains rigorous security standards and undergoes independent validation to provide customers with confidence in the platform's security posture.
Trustle has achieved SOC 2 Type II certification, which validates that the platform meets the Trust Services Criteria for security, availability, and confidentiality. This certification is issued following an independent audit that evaluates not only the design of security controls but also their operating effectiveness over time. The SOC 2 Type II audit examines Trustle's policies, procedures, and technical controls to ensure they are consistently applied and functioning as intended. Customers may request a copy of Trustle's SOC 2 Type II report by contacting Trustle.
In addition to SOC 2 certification, Trustle performs an independent third-party penetration test at least annually. These assessments identify potential vulnerabilities and validate the effectiveness of Trustle's security controls. Findings are remediated promptly and verified in subsequent testing cycles.
Authentication
Trustle uses Google Firebase to manage customer access to the platform. Firebase provides a secure, scalable authentication infrastructure that supports industry-standard protocols and integrates with enterprise identity providers.
For organizations that require centralized identity management, Trustle supports Single Sign-On (SSO) through Google, Microsoft Entra ID, and Okta. SSO integration allows customers to enforce their existing authentication policies, including multi-factor authentication requirements, session controls, and conditional access rules. By delegating authentication to the customer's identity provider, Trustle ensures that access to the platform is governed by the same security standards applied across the organization's other business applications.
