How VaultMe protects migration data

This article describes how VaultMe protects customer data during a migration, at the level of detail a security or privacy review asks for.

How does VaultMe protect migration data?

A migration means reading content from a source and writing copies of it into a destination, so that content has to pass through VaultMe on the way across. Everything in VaultMe's security model follows from keeping that passage narrow, encrypted, automated, and short-lived.

• Migration is the only purpose. VaultMe processes customer content to run the migration that was configured and to produce the migration report for it. There is no secondary use: no advertising, no third-party analytics, no AI training, no profiling, and no sale of customer data.
• Content is encrypted the whole way. Customer data is encrypted in transit between VaultMe and the source and destination providers, and encrypted at rest wherever VaultMe stores it, including backups.
• Processing is cloud-only and stays in the United States. VaultMe runs entirely in its own cloud environment on Amazon Web Services (AWS), in a single US region. There is no agent, browser extension, or local installation involved, and no content is read from or written to anyone's computer or local storage.
• Access exists only because the customer granted it. VaultMe can reach a user account only after that account, or the environment holding it, was connected to VaultMe. Nothing is reachable before that, and the customer can withdraw access at any time.
• Migration runs are automated. Batches are executed by automated components inside VaultMe's cloud environment. Migration content is not routed to employee workstations, end-user devices, or third-party processing systems, and employees do not read customer content in order to run a migration.
• Nothing is taken away from the source. VaultMe creates copies in the destination; it does not modify, reorganize, or delete content in the source. It also does not delete content in the destination, and it offers no feature for deleting content in a connected account.
• Only what the migration scope selects is processed. Content types and accounts outside the configured scope are not read, indexed, or migrated, even where the underlying authorization would technically allow it.
• Data is kept only as long as it is needed. Temporary migration data, the migration index, and operational logs are held for short, defined windows after a migration finishes. Beyond those windows, only high-level records about the migration itself remain.
• Every customer gets the same posture. VaultMe is a single-version, multi-tenant cloud application, and the security model, data-handling rules, and retention windows described here apply uniformly. There is no separate hardened deployment with different rules for some customers, and customers are logically isolated from one another by application-level controls and cloud identity and access controls.

Two of these carry more weight in practice than the rest. The migration scope decides what VaultMe reads at all, and the connections the customer grants decide whether VaultMe can reach anything in the first place — which is why both stay under the customer's control from beginning to end.

Is customer data encrypted in transit and at rest?

Yes, in both states. Encryption applies to all customer data VaultMe transmits and all customer data it stores, and it is not something a customer configures or can switch off.

In transit, customer data moving between VaultMe and the source and destination providers is encrypted using TLS. That covers the reads VaultMe performs against the source, the writes it performs against the destination, and the traffic between a browser and the VaultMe app, where TLS is terminated at the edge of VaultMe's environment. Traffic between VaultMe's own internal components stays inside AWS's private network rather than crossing the public internet.

At rest, customer data stored by VaultMe is encrypted with AES-256. This applies to every place migration data comes to rest, including items staged temporarily while they are being written to the destination, the migration index, migration reports, and the database that holds connection tokens and credentials. Backups of the databases holding migration-related data are encrypted in transit and at rest under the same controls as primary storage.

Key management sits behind both of those:

• Keys are managed by AWS's key management service. It uses cryptographic modules validated against the FIPS 140-2 and FIPS 140-3 standards.
• Key access is restricted to a small set of designated people. Encryption keys are not available to VaultMe staff in general; only a few designated people can access them.

Which categories of data are stored, and how long each one is kept, are covered in "Where migration data is stored and how long it is kept".

Where does migration processing happen?

All processing on VaultMe's side happens in VaultMe's own cloud environment on AWS. VaultMe's website, web app, and the systems that run migrations are hosted there in a single region in the western United States — us-west-2, whose data centers are in Oregon.

That gives a data path with three stops: content is read through the source provider's APIs, processed inside VaultMe's AWS environment, and written through the destination provider's APIs. A few consequences follow from it:

• Customer data hosted by VaultMe stays in the United States. Under VaultMe's AWS configuration, customer data is processed and stored in the US region only and does not travel to or get stored in AWS regions elsewhere. Backups are replicated across geographically distributed AWS facilities, and that replication also stays within VaultMe's US footprint. Backups are never copied to media outside AWS or shipped to physical off-site locations.
• There are no customer-selectable regions. VaultMe does not currently offer a choice of hosting region or in-region storage outside the United States, so a data-residency requirement that rules out US processing cannot be met by configuration.
• No end-user device is ever in the data path. Migration processing does not touch end-user computers, admin laptops, local mail clients, or local storage, and it needs no agent, browser extension, or on-premises component. An admin needs only a browser to set up and oversee a migration.
• Content also passes through the connected providers. Every read and write goes through the source and destination providers' own APIs, so their infrastructure processes that content as well. Where each provider processes or replicates data is governed by that provider and is outside VaultMe's control.

Hosting, processing locations, and provider transit are covered in more detail in "Where migration data is stored and how long it is kept".

Is VaultMe's backend publicly accessible?

No. The only parts of VaultMe reachable from the public internet are the ones that have to be: the website and the web app. The systems that actually run migrations sit behind them and are not directly reachable from the internet at all.

• Public-facing interfaces sit behind protected entry points. Externally accessible web interfaces are served through load balancers protected by a web application firewall, with TLS terminated there before traffic goes any further.
• The systems that run migrations are network-isolated. Internal components, storage, and databases run in a private network segment that is separated from the web tier and not directly reachable from the public internet. Traffic between those components stays on the private network.
• Customer-data stores are not exposed. The databases and object storage that hold migration data are not published on the public internet; access is limited to authorized internal components operating inside the private network.
• Connection tokens and credentials never leave that boundary. They are stored inside the private network and are not exposed on the public internet.
• Production is separated from everything else. Cloud identity and access controls separate the production environment from non-production environments and limit which of VaultMe's own systems can reach which data stores.

How does VaultMe connect to source and destination accounts?

VaultMe has no standing access to anything. It can read from a source or write to a destination only after that source or destination has been connected to VaultMe. Each connection is for a specific role: a source connection to read, a destination connection to write.

Where the provider supports it, connecting uses OAuth 2.0 — in practice, the provider's own "Sign in with Google" or "Sign in with Microsoft" flow. The person connecting the account signs in on the provider's own page and approves the permissions VaultMe asks for, and VaultMe receives a provider-issued token scoped to that connection, which it stores encrypted at rest. Those tokens have provider-defined lifetimes, after which access is denied until the account is reconnected.

Compared with sharing a password, OAuth has three advantages:

• Passwords are never given to VaultMe. Sign-in happens on the provider's own page. VaultMe receives a provider-issued token, not the account password, and it does not store passwords for OAuth-connected accounts.
• Permissions are granted precisely. VaultMe requests the minimum the role requires — read permissions for a source connection, read and write for a destination connection — and the provider shows that set before anyone approves it. A shared password carries no such limit.
• Access can be revoked at any time. The account holder, or an admin authorized to act for the account, can withdraw VaultMe's access from the provider side without resetting the password and without going through VaultMe.

There are two ways to connect source and destination accounts, and the security-relevant difference between them is how broad the resulting access is:

• Admin authorization connects a whole environment at once. An admin of a Google Workspace organization or a Microsoft 365 tenant connects that environment to VaultMe once, and the user accounts inside it are then reachable without per-account authorization. The grant is environment-wide and all-or-nothing: the admin approves the full permission set VaultMe requests, with no per-permission picking at connection time. This is what makes the method practical for batches, and it is also the part reviewers ask about most.
• Resource-level authorization connects one account at a time, with permissions limited to what that single account's migration role requires. It is typically done by sending a connection link to the account holder, who completes the connection themselves; an admin can also complete it directly if they can pass that account's multi-factor challenge.

The breadth of an environment-wide grant is not the breadth of what VaultMe actually reads. Even when the underlying authorization could technically reach every account and every item in a connected environment, VaultMe reads and processes only the accounts and content inside the configured migration scope; everything else in that environment is not read, indexed, or migrated. That boundary is enforced by VaultMe's own application logic together with the scope the admin configured, and it is spelled out in "What data VaultMe processes during migration".

Providers that do not support OAuth are the exception. For an IMAP-compatible mail system, the credentials that protocol requires may have to be supplied at connection time; VaultMe stores them encrypted at rest under the same key-management controls as everything else. This is the exception rather than the default, and it does not extend to OAuth-capable providers.

Whichever method is used, VaultMe does not act on anyone's behalf inside a connected account beyond what the migration itself requires — it does not send email, post to groups, modify calendar invitations, or otherwise interact with content it is not migrating. How the two connection methods compare as a planning decision, including what each costs in practice, is covered in "Choosing a connection method". How a connection works as a channel — what it carries, what it can reach, and what a drop does — is covered in "How VaultMe authentication works".

Can VaultMe's access be revoked?

Yes, at any time, and the customer does not need VaultMe's cooperation to do it. Revocation is done with the provider's own tools: the environment's administration console for an environment-level connection, or the individual account's security settings for an account connected on its own. VaultMe has no in-app control for withdrawing access.

Once access is revoked, VaultMe can no longer read from or write to that account. A migration that is running does not fail — it pauses and waits until the connection is restored. If access is revoked after the initial migration has finished, a sync-up migration (delta migration) cannot be started until the account is reconnected.

One thing revocation does not do is remove data. It ends VaultMe's future access to the account; it does not delete the copies already written into the destination, the migration report, or the high-level records VaultMe keeps about the migration. Deleting migration-related data earlier than the normal retention window is a separate request, covered in "Where migration data is stored and how long it is kept".

Who can access customer data inside VaultMe?

Migration content and migration metadata are processed by automated components inside VaultMe's AWS environment. They are not routed to employee workstations and not sent to third-party processing systems, and employees do not browse, read, or copy customer migration content in order to run a migration. Nor is there an interface that would make it possible: VaultMe does not give employees a way to browse or export customer migration content for non-operational purposes.

Around that baseline sit three separate boundaries.

• Isolation between customers. VaultMe is a multi-tenant application, and logical isolation between customer workspaces is enforced by application-level access controls. No one working in one customer's workspace can reach another customer's migrations, reports, indexes, or connected-account information through the app. Cloud identity and access controls add a second layer, separating production from non-production environments and limiting which VaultMe systems can reach which data stores.
• Internal access controls. Access to production systems is restricted to a small number of designated people under cloud identity and access management policies and the principle of least privilege. Encryption-key access is narrower still: keys are not available to VaultMe staff in general, only to a few designated people. Administrative actions on infrastructure are logged and reviewed, access to privileged accounts is reviewed quarterly, and all employees complete information-security and privacy training at onboarding and at least annually thereafter.
• What support and operations staff can do. Human involvement is possible only for narrowly scoped operational work: responding to a support request the customer raised, resolving an operational issue that automation cannot resolve, or meeting a security or legal obligation. That work is subject to the same access controls and logging as anything else, and it is scoped to the minimum needed for the task at hand. It is not a general path into customer content.

Access on the customer's own side of the app has its own controls. Signing in to VaultMe uses OAuth through the user's identity provider, Google or Microsoft, so password complexity, multi-factor requirements, and password resets are governed by that provider rather than by VaultMe, and VaultMe stores no password for those accounts. Sessions expire after 30 days of inactivity.

Is migration processing automated?

Yes. Once a batch starts, it is executed by automated components running in VaultMe's AWS environment, and it runs unattended.

Automation covers the whole run. VaultMe builds an index of the discoverable items in the source account at the start, then works through the indexed items, copying each one into the destination with the most precise representation the destination allows, placing it according to the content organization method chosen for that account, and recording the outcome. At the end it assembles the migration report. None of those steps involves a person handling content.

VaultMe aims to provide a smooth, automated migration experience. People are involved only on an exception basis, if something goes wrong that automation cannot resolve — at whatever level that is. When people are involved, it can be at various levels, and it is done with the same respect for privacy and the same access controls described everywhere else in this article. They are involved only as far as required to resolve the issue; where deeper involvement is necessary, it is coordinated with the customer.

Two limits on that automation are worth stating explicitly. First, it acts only within the configured migration scope: application logic keeps automated processing to the accounts and content types selected for migration, so breadth of authorization does not translate into breadth of reading. Second, none of it runs anywhere but VaultMe's cloud environment — no part of the work is dispatched to an employee workstation, an end-user device, or a third-party processing system. The end-to-end picture of what happens during a run is in "How VaultMe works".

Do VaultMe employees manually handle customer content?

Not as the way a migration runs. Processing is automated, and people at VaultMe are involved only when an issue cannot be resolved automatically, as described above. Content is never routed out to employee workstations, and there is no standing path into customer content.

When people are involved, it is in three operational situations:

• A support request the customer raised. Answering a question about a specific migration sometimes requires looking at that migration.
• An operational issue that automation cannot resolve. When something cannot be finished automatically, it is escalated so staff can work out what to do.
• A security or legal obligation. Investigating a security event or responding to a legally binding request can require staff involvement.

In each case the work is bounded by the same controls that apply everywhere else: least-privilege access to production systems, logging of administrative actions, and a scope limited to the minimum the task requires. There is no interface for employees to browse or export customer migration content outside these cases, so none of this amounts to standing access to customer content.

Which third-party services does VaultMe use to run migrations, and why?

The list is deliberately short. Customer migration content flows only through the services strictly required to host VaultMe and to read from and write to connected accounts; nothing else is in that path.

• Amazon Web Services hosts everything VaultMe runs: the website, the web app, the internal systems that execute migrations, the databases, object storage, monitoring, and key management. All VaultMe-side storage and processing of customer data happens inside VaultMe's AWS environment, and AWS supplies the underlying compute, storage, networking, encryption at rest, and infrastructure-security capabilities. For infrastructure-level assurance, VaultMe relies on the compliance certifications and audit reports AWS publishes.
• Google APIs serve two roles for Google Workspace and consumer Google accounts. Google's OAuth 2.0 and OpenID Connect implementations are how those accounts are connected, and Google's Workspace APIs — Gmail, Drive, Calendar, Contacts, and the Directory API where it applies — are how VaultMe reads from Google source accounts and writes to Google destination accounts. Migration content passes through these APIs as part of every read and write.
• Microsoft APIs play the equivalent role for Microsoft 365 and consumer Microsoft accounts. Microsoft's OAuth implementation, through Microsoft Entra ID, is how those accounts are connected, and Microsoft Graph and related Microsoft 365 APIs are how VaultMe reads from and writes to them. Migration content passes through these APIs in the same way.
• Other provider APIs and protocols are used for the remaining supported providers, each through its own official API or a supported protocol such as IMAP.
• Braintree processes payments for paid migrations. Card details are entered into Braintree's hosted payment fields and are not stored by VaultMe, which keeps only the payment-transaction reference Braintree returns. Braintree has no access to migration content or migration metadata.
• Analytics tools for the VaultMe app and website, including Google Analytics and Mixpanel, collect aggregated signals about how people use the VaultMe interface itself. They have no access to migration content, migration metadata, or items inside connected accounts, and their use is governed by the Privacy Policy rather than by the migration data-handling rules described here.

VaultMe assesses the third-party services it depends on against industry-standard security frameworks and prefers vendors holding a current SOC 2 attestation or equivalent, under a vendor-management policy that governs how those services are selected, contracted, and reviewed. Contracts with VaultMe's infrastructure providers include data-handling and breach-liability provisions.

VaultMe does not share customer data with anyone outside that list. It does not share migration content with any third party other than the source and destination providers required to perform the migration, does not share migration metadata with advertisers, data brokers, marketing partners, or AI-training providers, and does not sell customer data. The same ground, framed for a reviewer assembling a vendor list, appears in "Privacy and legal review".

How does VaultMe handle security incidents affecting customer data?

VaultMe maintains documented incident-response and business-continuity processes covering detection, containment, investigation, customer notification, and post-incident review, and its monitoring and response capability operates around the clock.

• Detection. Continuous monitoring uses the cloud provider's native security capabilities for threat detection, aggregation of security findings, web-tier protection, and mitigation of denial-of-service attacks; network-level and host-level intrusion detection and prevention rely on those managed capabilities across VaultMe's environment. Logs of authentication events, token uses, migration runs, and security-relevant actions are collected and reviewed, and security alerts can trigger automated responses.
• Response. When an incident is identified, an internal response team is formed following VaultMe's documented Incident Response Plan. Response activities include containment, impact assessment, evidence preservation, remediation, and a post-incident review. VaultMe can bring in its insurance and legal advisors where the situation warrants it.
• Customer notification. VaultMe commits to notifying affected customers and institutions as quickly as possible once an incident affecting their data is confirmed, consistent with applicable legal and contractual breach-notification obligations. The first notification carries what is known at that point about scope, impact, and remediation, with further updates as the investigation develops.
• Vulnerability management. Production systems are scanned for vulnerabilities on a recurring basis, and code is scanned by static analysis on every commit. Patching runs to priority-based deadlines — critical patches within 24 hours, high-priority patches within 72 hours, and lower-priority patches within one to two weeks — with interim risk-mitigation controls such as access restrictions, network segmentation, or enhanced monitoring applied while a patch is being prepared. Third-party libraries and dependencies are reviewed as part of change management.
• Continuity and recovery. VaultMe maintains documented business continuity and disaster recovery plans with named owners and an annual testing cadence. Deployments use zero-downtime rollouts where possible, and planned maintenance requiring downtime is scheduled to minimize disruption. Backups, infrastructure-as-code, and cloud-managed redundancy support recovery from a major incident.

VaultMe also undergoes recurring third-party security assessments where partner programs require them, such as Google's annual security assessment for applications that access personal Google accounts. Those assessments and penetration tests are not published as standalone public artifacts, though the Incident Response Plan and related policy documents can be requested — what is available and how to ask for it is covered in "Privacy and legal review". Separately, VaultMe carries cyber-risk insurance with an established commercial insurer, reviewed annually; having that coverage does not reduce its notification obligations or its responsibilities under the Terms of Service and Privacy Policy.

What is the customer's responsibility for keeping migrations secure?

VaultMe's controls cover VaultMe's side of the migration. A handful of things sit on the customer's side by design, because they are decisions and permissions only the customer can hold.

1. Connecting accounts carefully. The connection is the grant. How accounts are connected — which method is used, who completes it, and how broad the resulting access is — is the customer's control over what VaultMe can reach. Admin authorization is environment-wide; resource-level authorization is limited to one account. The two methods and what each implies are covered in "How does VaultMe connect to source and destination accounts?" and in "Choosing a connection method".
2. Choosing an appropriate migration scope. The scope is the strongest control the customer has over what VaultMe reads, since VaultMe processes only the accounts and content types the scope includes. Deciding it deliberately — rather than including everything because it is available — is what keeps processing to what the project actually needs. What that decision governs is set out in "What data VaultMe processes during migration".
3. Handling credentials carefully where a method requires them. For OAuth-capable providers VaultMe never needs an account password, so nothing about the connection requires collecting one. Where credentials are genuinely needed — connecting an IMAP-compatible mail system, or an admin connecting accounts on account holders' behalf — collecting and storing them is sensitive work that belongs to the customer, and the practical trade-offs are covered in "Choosing a connection method".
4. Revoking access when it is no longer needed. Once the migration is finished and no further sync-up runs are expected, disconnecting the accounts or the environment ends VaultMe's access. Migrated content in the destination is unaffected; if migration-related data should also be removed ahead of its normal retention window, that is a separate request.
5. Controlling access inside the VaultMe workspace. Who is in the workspace, and with which role, is the customer's decision, and multi-factor and password policy for those people is governed by their identity provider rather than by VaultMe.

Three other articles in this section carry the detail behind these responsibilities: "What data VaultMe processes during migration" for what VaultMe processes and what it leaves alone, "Where migration data is stored and how long it is kept" for where data lives and how long it is kept, and "What VaultMe does not do with customer data" for the boundaries stated as direct answers. If the migration has to clear a formal legal, privacy, or procurement review, "Privacy and legal review" explains what is published, what can be requested, and who to contact; questions that need a person can go to support@vaultme.com.