We are currently in the process of obtaining our SOC 2 credential and expect to be SOC 2 Type 2 compliant by Q1 2027. In the meantime, all of our architecture and proprietary tools are deployed exclusively through Google Cloud Platform (GCP), which is fully SOC 2 compliant, and we maintain rigorous internal security standards to ensure continuous compliance and infrastructure security.

Yes. We comply with GDPR, as well as Google’s specific policies regarding Sensitive and Restricted scopes and Limited Use requirements.

An internal security audit is performed whenever relevant changes occur (such as infrastructure updates, API design changes, or framework updates). Even if no major changes occur, we conduct an internal security audit at least once every calendar year.

Management has designated our internal Security Team to be responsible for managing our information security and privacy program, as well as reviewing and auditing service providers and subcontractors.

By default, all data remains strictly within the United States throughout the migration process. However, because our architecture is built on Google Cloud Platform (GCP) and utilizes our ISO-certified migration partner CloudM, we have full geographic control over our infrastructure. For international clients or those with strict GDPR requirements, we can explicitly provision migration servers and databases within specific global regions (e.g., Europe, UK, Asia-Pacific). We guarantee that no data is routed through or stored outside of the mutually agreed-upon region, and we document the exact infrastructure locations for your compliance records.

Depending on the project, we may process emails, documents, tasks, calendars, and contacts, all of which are subject to Personally Identifiable Information (PII). To speed up migrations, we cache information in databases before transferring it; however, direct access to this data by engineers is not possible. Engineers only see aggregated metadata and reports to monitor progress and errors.

No. Data is only stored temporarily while the project is in progress and is kept for a maximum of 1 week before it is completely deleted. CloudM automatically deletes all temporary metadata upon completion, and any virtual machines or custom scripts we create for your project are fully decommissioned ("nuked"). Exceptional extensions for retention are only made if a client requests extra time to compare source and destination environments post-switch.

Usually, no. However, in specific Google Workspace to Google Workspace migrations, if you wish to retain the link IDs of shared drives and external sharing settings, the process acts as a move rather than a copy, which will remove them from the source environment.

We operate on a Zero Trust security model. We maintain strict "Blast Radius Containment" by separating our corporate domain (cloudasta.com) from our highly privileged customer reseller environment (reseller.shuttlecloud.com). No internal applications, compute engines, or third-party servers are hosted directly inside the reseller environment. If an internal tool were ever compromised, the attacker is contained within our corporate environment and cannot access customer data.

We utilize GCP Secret Manager for all sensitive credentials, including encryption keys and external API keys. We strictly prohibit uploading sensitive keys to code repositories like GitHub.

Yes. All user information stored at rest in Google Cloud MySQL instances is encrypted using AES-256 encryption by default. Information in transit is strictly transmitted over HTTPS/SSL connections, preventing eavesdropping.

In addition to the logging tools built into our migration platforms, we heavily leverage Google Logging and Google Monitoring to oversee our infrastructure.

Cloudasta enforces automated tests prior to deployment, utilizes immutable container images for reliability, and maintains clear separation between development, staging, and production environments.

An assigned individual is responsible for reviewing subcontractors. Furthermore, written contracts require all outsourcing providers, vendors, and subcontractors to agree to clauses that assert strict security and privacy requirements for any confidential information they might access.

We require a dedicated, temporary Super Admin user account in both the source and destination Google Workspace tenants. This account should be created specifically for the migration, its usage is strictly limited to the project timeline, and we instruct clients to permanently delete or suspend the account immediately upon project completion.

Our team members access client environments exclusively through secure, cloud-based virtual machines hosted in GCP. We never use domain-wide delegation unless absolutely necessary; instead, we interact with APIs using dedicated Service Accounts with the minimum required permissions.

Yes. Any API-based access (such as via Google Apps Manager) uses time-bound tokens. Access is not persistent and is fully revoked upon project completion. IP whitelisting can also be configured upon request.

Yes. Single Sign-On (SSO) is mandatory for all internal tools using Google Workspace as our Identity Provider. Furthermore, 2-Step Verification (2SV) is strictly enforced and mandatory for all Cloudasta employees.

We enforce strict access controls, requiring complex passwords with an 8-character minimum. Crucially, we mitigate password-based risks by mandating the use of a company-managed enterprise password vault to generate unique credentials, alongside strictly enforced 2-Step Verification (2SV) for all employee accounts.

Yes, fully. All our access is performed through Google Admin, which maintains a full, immutable audit log of every login and action performed. You have 100% visibility into these logs throughout the project.

Cloudasta does not store or have access to any customer payment information. All payment data is processed securely through PCI-certified third-party payment infrastructures like Stripe or PayPal.

We use Google's Workspace API scope (Admin Directory) strictly to check if a user on a customer's account is a Super Admin to allow authorized access to our billing application. Cloudasta never stores OAuth tokens or user passwords.

Cloudasta ensures that service accounts follow the principle of least privilege through strict architectural and access control policies:
‍Minimum Required Permissions: Service accounts are granted only the absolute minimum IAM roles or API permissions necessary to perform their specific functions within the highly privileged reseller environment.
‍Restricting Broad Access: Cloudasta explicitly avoids assigning overly broad, project-level roles such as Editor or Owner. Instead, they utilize minimal, targeted roles like run.invoker, secretmanager.secretAccessor, cloudsql.client, and storage.objectViewer.
‍Strict Service Isolation: Under our Zero Trust security model, each individual service must be assigned its own unique service account. Service accounts are strictly isolated and are never reused across multiple services.
‍Avoiding Domain-Wide Delegation: Applications are required to interact with reseller APIs as the service account itself whenever possible. Domain-Wide Delegation (DwD) is strictly prohibited unless absolutely required, limiting the scope of access to only what the application needs to function.
‍Cross-Domain Architecture: Internal applications operate from the corporate domain (cloudasta.com) and utilize cross-domain authorization to connect to the reseller environment. This ensures that the service accounts acting on behalf of these applications remain restricted and centralized.

Based on internal security guidelines, Cloudasta explicitly prohibits the use of service account keys, classifying them as a security risk. Instead, we enforce the following practices:
‍Authentication without Keys: Applications are assigned a dedicated Service Account native to the corporate GCP environment, which interacts with APIs utilizing cross-domain authorization.
‍Secrets Management: For other sensitive credentials, such as external API keys and encryption keys, Cloudasta mandates the use of GCP Secret Manager. Less sensitive configuration parameters are handled using runtime environment variables.
‍Code Repository Security: Internal guidelines strictly forbid uploading any sensitive keys to code repositories like GitHub.

In the event of an incident involving potential or confirmed data leakage, our protocol mandates immediate containment (e.g., applying hotfixes or shutting down affected components). We identify all affected parts, coordinate with our security team, notify all impacted customers without undue delay—and no later than 72 hours of verification, in strict accordance with GDPR—and provide post-mortem analyses to prevent future occurrences.

Security risks are evaluated on a scale from 1 (Critical, such as a data breach) to 4 (Low risk). Reports are immediately triaged. Critical incidents are escalated immediately to appropriate team members for rapid response.

Security issues and vulnerabilities can be reported directly to our security and compliance team, if you are a client, you have access to our security email info. Otherwise, you can contact us here. We take all reports seriously and will work with you to securely investigate and remediate any findings.

We employ a comprehensive patch management lifecycle across both third-party and internal systems. For Google-developed migration tools, we apply updates as soon as they are released (typically 1–3 times per month). For our internal infrastructure, custom GCP virtual machines, and databases, critical security patches are applied immediately upon verification, and standard operational updates are applied during regular maintenance windows.

Yes. We perform a rigorous hiring process that includes a screening call, interviews with senior-level team members, and background checks for any personnel who will be entrusted with sensitive information.

Yes. All employees (including interns and contractors) who handle Cloudasta-related data are required to complete security training upon hire and at least once a year thereafter. This training covers password best practices, mandatory SSO/2FA usage, and mandatory full encryption of hard drives. Training is also updated whenever important industry changes require it.