Privacy and security

This article explains how customer data is handled while a VaultMe migration runs, at the level of detail an admin needs to plan a project and answer questions about it. The "Security and privacy" section of this Knowledge Center covers the same ground at the depth a formal security or legal review calls for.

How does VaultMe approach privacy and security?

A migration only works if VaultMe can read content out of the source and write copies of it into the destination. That means real customer content — messages, documents, calendar events, contacts — passes through VaultMe, and the fair question to ask is what happens to it in between.

The answer is a posture rather than a catalog of controls, and it comes down to a few principles:

• A single, narrow purpose. VaultMe processes customer content to carry out the migration that was configured and to produce the migration report that accounts for it. There is no secondary use — no advertising, no third-party analytics, no AI training, no profiling.
• Encryption in transit and at rest. Everything VaultMe exchanges with the source and destination providers is encrypted in transit using TLS, and everything VaultMe stores is encrypted at rest using AES-256, under keys held in Amazon Web Services (AWS) and reachable only by a small set of named officers.
• Automated processing. Migration runs are carried out automatically. Customer content is not routed to employee workstations or to third-party processing systems, and nobody at VaultMe browses or reads it as part of a normal run.
• Only what is needed, only for as long as it is needed. VaultMe reads and processes only what the selected migration scope requires, and deletes temporary migration data once the need that justified keeping it ends.
• One posture for every customer. VaultMe is a single, centrally hosted, multi-tenant application, so the same security model, data-handling rules, and retention windows apply to everyone. There is no separate hardened deployment for some customers and a looser one for the rest.

This article stays at that altitude. Each principle is documented in more depth in the "Security and privacy" section, starting with "How VaultMe protects migration data", which answers these questions the way a security questionnaire asks them.

What kinds of data does VaultMe handle during a migration?

The practical question behind this one is what VaultMe actually sees. It is easier to answer by category than by field, because the categories are not treated alike.

The first and most sensitive category is migration content: the items copied from the source into the destination, meaning email messages, files and documents, calendar events, and contacts. VaultMe handles only the content types included in the migration scope you select — a content type left out is not read, indexed, or migrated. Within a content type that is in scope, VaultMe works with the items the source provider makes available to it.

Everything else VaultMe handles exists to make that copying work, to verify it, or to account for it:

• Item metadata. To place each copy correctly and confirm it arrived, VaultMe processes identifying and structural information about each item: item names and message subjects, folder and label structure, timestamps, sizes, content type, and the source and destination email addresses involved.
• Connection credentials. Where a provider supports it, VaultMe holds an OAuth token — a provider-issued key scoped to one connection — rather than a password. Providers without that support, such as IMAP-based mail systems, require the credentials their protocol calls for, which is the exception rather than the norm. Either kind is stored encrypted.
• Operational logs. VaultMe records what its own systems did: connection events, token uses, and migration-run events. Logs carry identifiers such as the migration ID, email addresses, and timestamps, but not message bodies or file contents.
• Migration reports. The report produced at the end of a run lists every discovered item with its outcome, so it can show item names, message subjects, file paths, and folder or label names. It does not contain the items themselves.
• High-level migration records. For each migration, VaultMe keeps a summary: the migration ID, when the run started and finished, the source and destination email addresses, how many items and how much data were requested and successfully migrated, and what was paid.

Held separately from all of this is what VaultMe needs in order to operate a customer's account with it: contact details, and transaction records for paid migrations. Payment card details never reach VaultMe's systems at all; they are entered directly into VaultMe's payment processor, which returns only a transaction reference.

One boundary is worth stating outright, because breadth of authorization is easily mistaken for breadth of processing. When an admin connects an entire environment — a Google Workspace organization or a Microsoft 365 tenant — the underlying authorization can technically reach every user account in it and everything inside them. What VaultMe actually reads and processes is still only the user accounts and content selected for migration; the rest is not read, indexed, or migrated. Shared drives, shared mailboxes, and other kinds of resources fall under the same boundary. The full inventory of what VaultMe does and does not process is in "What data VaultMe processes during migration".

Where does the data live and what path does it take?

VaultMe runs entirely on Amazon Web Services, in a single United States region, with data centers in Oregon. Customer data that VaultMe holds stays inside that US footprint, including the encrypted backups AWS replicates across its own facilities. VaultMe does not currently offer a choice of hosting region, or storage outside the United States.

The path each item takes is short. VaultMe reads it from the source through the source provider's API, holds it briefly in its own AWS environment while the destination accepts it, and writes it in through the destination provider's API. Nothing along that path touches an end-user device, an admin laptop, or local storage, and there is nothing to install — no agent, no browser extension, no on-premises component. The operational side of that arrangement is described in "How VaultMe works".

The part of the path VaultMe does not control is the providers' own side. Content is read and written through their APIs, so it is handled by their infrastructure too, and where a provider processes or replicates data on its side is governed by that provider rather than by VaultMe.

In practice, this is a cloud-to-cloud migration in the plainest sense: content is copied out of one provider's cloud and into another's, through resources that were deliberately connected, and VaultMe's leg of the journey happens on its own cloud infrastructure rather than on customer hardware. Where each category of migration data is hosted, and for how long, is set out in the hosting chapter of "Where migration data is stored and how long it is kept".

How long does VaultMe keep migration data?

The retention rule follows from the purpose. VaultMe keeps what it needs to run a migration, verify it, support it, report on it, and meet its legal obligations, and deletes the rest once that need ends. Different categories are needed for different lengths of time, so each has its own window.

The distinction that matters is between two groups:

• Temporary migration data. Items staged while they are being written to the destination, the index VaultMe builds to record what went where, operational logs, and migration reports all belong here. Each is kept for a defined period tied to the migration and deleted when that period ends.
• Long-retained records. Once the temporary data is gone, VaultMe keeps a high-level record of the migration itself, for as long as it needs to keep VaultMe running, comply with applicable law, respond to lawful requests, and enforce its terms.

Migration reports belong to the first group. A report stays downloadable from the VaultMe app for one year from the end of the run that produced it, and it is worth downloading and filing wherever project records are kept — it is a record of what a migration did, not an archive of what it copied.

The mental model worth correcting is the idea that VaultMe accumulates a copy of everything it has ever migrated. It does not. What remains long term is a summary of the migration — its identifier, start and completion times, the source and destination email addresses, item counts and data volumes, and the amount paid. None of it includes message bodies, file contents, message subjects, file names, or folder and label names.

Exact retention windows for each category, how deletion is carried out, and how to request earlier deletion are covered in "Where migration data is stored and how long it is kept".

Who can access migration data?

Normal migrations run without anyone watching them. Content is read, briefly stored, and written by VaultMe's own automated systems inside AWS, and it is not routed to employee workstations or to third-party processing systems. Nobody at VaultMe browses or reads customer migration content as part of a run, and there is no internal tool for browsing or exporting it.

Separation between customers is logical rather than physical. VaultMe is a multi-tenant application, and application-level access controls keep each customer's workspace to itself: one customer's admins and users cannot see another's migrations, reports, or connected resources. Underneath, AWS identity and access controls separate production from everything else and limit which of VaultMe's own systems can reach which data stores.

Access inside VaultMe is deliberately narrow. Production systems are reachable by a small number of named people under least-privilege policies, administrative actions are logged and reviewed, and access to encryption keys is narrower still, restricted to named officers. Staff complete information-security and privacy training when they join and at least once a year after that.

Human involvement does happen, but only in specific operational situations: handling a support request a customer raised, resolving an operational issue that automation cannot resolve, or meeting a security or legal obligation. Work of that kind is scoped to the minimum needed to resolve the case in front of it and is subject to the same logging and access controls as everything else. It is not a general path into customer content.

The plainest limit on access is that VaultMe has none until it is given some. It can reach a source or destination only because that resource or environment was connected to it, and the authorization is bound to what was connected and to the role it was connected for — source or destination. It can be withdrawn at any time, either from inside the VaultMe app or from the provider's own controls. Once it is, VaultMe can no longer read from or write to that resource, and a migration in progress pauses rather than failing, waiting until the connection is restored.

The controls themselves, the two connection methods and what each one grants, and what revocation does at each stage are covered in "How VaultMe protects migration data".

What does VaultMe not do with customer data?

Some questions are best answered as a flat no. These are the ones that come up most:

• VaultMe does not use customer content for anything except the migration. Content is processed to carry out the configured migration and produce its report, and for nothing else — not advertising, not third-party analytics, not AI training, not profiling.
• VaultMe does not sell customer data. It also does not share migration content with third parties beyond the source and destination providers a migration has to go through, and it does not pass item names, subjects, paths, or folder and label names to advertisers, data brokers, marketing partners, or AI-training providers.
• VaultMe copies rather than moves. A migration creates copies in the destination and leaves the source as it was: nothing there is modified, reorganized, or deleted, and it remains usable during the migration and after it. How that copying works is described in "How VaultMe works".
• VaultMe does not delete content. It writes migrated copies into the destination and does not delete what is already there, and it offers no feature for anyone to delete content in a connected resource through VaultMe. Clearing out a source afterwards is customer-side work, done with the provider's own tools.
• VaultMe does not act on anyone's behalf beyond what a migration requires. It does not send email, post to groups, modify calendar invites, or otherwise interact with a connected resource in ways the migration does not call for.
• VaultMe does not reach outside the migration scope. Content types left out of the scope, and user accounts and other resources left out of the migration, are not read, indexed, or migrated, even where an environment-level connection could technically permit it.

The same boundaries, taken one question at a time, are in "What VaultMe does not do with customer data".

Where to find more detail for legal or security reviews?

For planning a migration, this article is usually enough. It stops being enough as soon as someone else has to sign off — a legal or privacy team, procurement, or information security — because those reviews run on documents they can cite rather than on explanations.

What VaultMe can put in front of them comes in three layers:

1. Published legal documents. The Terms of Service and the Privacy Policy are public and carry the contractual and privacy framework: customer ownership of migrated content, the restrictions on VaultMe's use of it, and VaultMe's positions on GDPR, CCPA, and other applicable privacy laws.

2. The "Security and privacy" section of this Knowledge Center. These articles are the product-specific layer, documenting how that framework is applied to an actual migration — what is processed, where it is hosted, how long it is kept, who can reach it, and what VaultMe will not do.

   • "How VaultMe protects migration data" covers encryption, where processing runs, how the source and the destination are authorized and revoked, who inside VaultMe can reach customer data, and how incidents are handled.
   • "What data VaultMe processes during migration" accounts for each category of data VaultMe processes during a migration, and for the data it leaves alone.
   • "Where migration data is stored and how long it is kept" states where each category is hosted and processed, and how long it is kept before it is deleted.
   • "What VaultMe does not do with customer data" states, one question at a time, what VaultMe will not do with customer data.
   • "Privacy and legal review" is the guide to a formal review: what is published, what can be requested, what does not exist, and who to contact.

3. Materials available on request. VaultMe maintains a current response to the Higher Education Community Vendor Assessment Toolkit (HECVAT), itself a comprehensive vendor security and privacy questionnaire, and provides it as a package together with the supporting documents referenced inside it, such as the data flow description, the information security policy, and the business continuity, disaster recovery, and incident response plans. Individual documents from that package can be requested on their own, and VaultMe also completes customer-supplied security and privacy questionnaires.

It is worth setting expectations about what does not exist. VaultMe does not run a trust center or a public compliance portal, does not publish a security whitepaper or penetration-test reports, has not completed a SOC 2 audit, and does not maintain a published data processing addendum.

Everything runs through a single channel. Questionnaires, requests for the HECVAT package or for one document from it, standard contractual clauses, questions about a data processing addendum or custom contractual terms, and anything else a reviewer needs go to support@vaultme.com, which routes them to the right people internally.

The full guide to taking VaultMe through a review — what is published, what can be requested, what does not exist, and how privacy-law and international-transfer questions are handled — is "Privacy and legal review".