SOC 2 Email Migration: What Auditors Actually Check

A SOC 2 email migration is not a separate kind of migration. It is the same IMAP, OAuth, and folder-mapping work you would do anyway, with the controls visible and the evidence collected. The difference between a clean audit and a finding is rarely the migration itself. It is whether you can show, six months later, exactly who moved which mailbox, when, with whose approval, and what got verified before you cut DNS. This post walks you through what your auditor will look for and how to set up the move so the evidence drops out of the work for free.

Why SOC 2 cares about an email migration#

Mailboxes hold the things SOC 2 cares about most: customer communications, contracts, access credentials, vendor security questionnaires, incident records, and sometimes payment data sitting in PDF attachments. Moving them between tenants or providers touches every layer of your control environment at once. You change where data lives, who can read it, how it is backed up, and how it is logged. That is a lot of control surface to disturb in one project.

Your auditor will not test the migration tool. They will test your process around the migration. They expect to see the change being managed, access being granted and revoked on time, monitoring picking up anomalies during the cutover, and an evidence trail they can pull samples from.

If you are starting from zero on the compliance side, the SOC 2 email migration controls overview sits inside the wider email migration compliance guide which is worth reading first. This post assumes you already know what SOC 2 is and which trust services criteria your report covers.

The five trust services criteria, applied to a migration#

SOC 2 reports cover one or more of the trust services criteria (TSC): Security (always), Availability, Confidentiality, Processing Integrity, and Privacy. Not every criterion will be in scope for your report. Look at your last audit opinion to confirm. The migration touches at least Security; most of the time it touches Confidentiality too, and often Availability and Processing Integrity.

Security: who could do what, and did they#

Security is the common criteria set (CC) that every SOC 2 report includes. For a migration, the relevant controls cluster around CC6 (logical access), CC7 (system operations and monitoring), and CC8 (change management).

The questions your auditor will ask:

• Who had administrative access to the source and destination tenants during the migration window?
• Was that access granted with approval, time-bound, and revoked when the work finished?
• Was the migration tool installed on a workstation that meets your endpoint baseline?
• Were credentials and OAuth tokens stored according to your secrets policy?

If you are using a desktop migration tool, the workstation it runs on becomes part of scope for the duration of the project. That sounds heavy. In practice it means using a managed admin workstation with full-disk encryption, MDM, EDR, and your normal patching baseline. The migration tool itself does not need special hardening if it stores credentials in the OS keychain rather than on disk in plaintext.

Availability: was email up when it needed to be#

Availability comes up if your SOC 2 report includes it (A1 series). Email is rarely a system covered by an availability commitment in your service description, but if it underpins customer support or transactional notifications, your auditor may sample it.

For the migration, availability evidence looks like:

• Maintenance window scheduled and communicated in advance.
• Rollback plan documented before cutover.
• Monitoring in place during the window (mail flow, delivery latency, bounce rate).
• Incident response triggered if anything breached your stated SLO.

Confidentiality: did anyone see data they should not have#

Confidentiality (C1 series) is where most migrations get scrutinized. Mailboxes contain customer confidential data by default, and the migration tool by design reads every byte.

Auditors will sample for:

• Access to the migration tool restricted to named admins.
• Data in transit encrypted (TLS 1.2+ for IMAP, HTTPS for OAuth, encrypted SMB or local-only for any intermediate storage).
• No long-lived intermediate copies. If the tool caches messages locally during the move, the cache should be encrypted and deleted at the end of the job.
• Confidentiality agreements signed by any contractor or MSP involved.

This is where local-first migration tools have a structural advantage. When mailbox content never leaves your admin workstation and your network, the scope of the confidentiality exposure shrinks to the workstation itself. That is much easier to document than a cloud relay that holds your data for an indeterminate window.

Processing Integrity: did the data arrive intact#

Processing Integrity (PI1 series) is about whether system processing is complete, valid, accurate, timely, and authorized. For an email migration, this maps almost exactly to your post-migration validation: per-folder message counts, attachment byte counts, flag fidelity, and timestamp preservation.

Your auditor will not check every mailbox. They will sample, usually three to ten, and ask to see the validation evidence. Per-mailbox source and destination counts, side by side, with reconciliation notes for any deltas, is the format that works.

Privacy: only if your scope includes it#

Privacy (P1–P8) is in scope only if your SOC 2 report explicitly covers it. If your customers are also EU data subjects, the GDPR email migration considerations apply in parallel and largely reinforce each other. Document your lawful basis for processing, your data subject notification approach, and your retention decisions.

Change management: the part that fails most audits#

CC8.1 is the change management control. It is the single most common finding around any migration, including email. Auditors want to see a defined change request, a documented risk assessment, approvals from the right people, a tested implementation plan, and a post-implementation review. Most teams do all of this. Few of them document it consistently.

A workable change record for a SOC 2 email migration includes:

• Change title and ID that match what shows up in your ticketing system.
• Risk classification (usually medium or high; email touches everyone).
• Scope: which tenants, how many mailboxes, what date range.
• Approvers: at minimum the system owner, security team, and (often) the customer-facing function lead.
• Implementation plan: the runbook you will actually follow.
• Rollback plan: how you would restore service if cutover fails. For email, this is usually "revert MX records and resume the source mailbox".
• Communication plan: who tells the end users what, when.
• Post-implementation review: what you verified, what surprised you, what you would do differently.

Tie every batch you run to the change ticket. The simplest way is to put the change ID in the migration tool's job name. The job log then carries the change ID forward and your evidence assembles itself.

Access controls during the cutover window#

CC6 covers logical access. During a migration you typically create or elevate at least three sets of privileges:

1. Source tenant: a global admin or migration-scoped service account.
2. Destination tenant: same.
3. Migration tool credentials: app passwords, OAuth refresh tokens, or service principal secrets.

Each of these is a control point your auditor will look at.

Time-bound, role-based, logged#

Grant the privileges in your normal identity system, not by giving someone the master admin password. Document the grant in your access request workflow with the change ticket as justification. Revoke at the end of the project; auditors love seeing access revocation tickets dated within a day or two of the change closure.

If your provider supports just-in-time elevation (Microsoft Entra PIM, Google Workspace temporary roles), use it. Auditors treat short-lived elevated access far more favourably than persistent admin assignments.

OAuth refresh tokens and app passwords#

OAuth refresh tokens are credentials. Treat them that way. Store them encrypted at rest, scoped narrowly (read for source, read-write for destination), and revoke them at project end. Many providers let you list and revoke active OAuth grants from the admin console; do that as part of project closure and screenshot the result.

App passwords (still used for legacy IMAP on Yahoo, iCloud, some Gmail setups) are even worse from a control standpoint because they bypass MFA. If you must use one, document the exception, scope it to the migration window, and disable it the moment the move is done.

Monitoring and anomaly detection#

CC7.2 covers monitoring for anomalies. During a migration, your normal baseline noise level on the destination tenant goes up dramatically. A user account suddenly fetching tens of gigabytes from an IMAP endpoint will look exactly like a data exfiltration attempt to a tuned SIEM, because it is structurally identical.

Two things matter here:

1. Pre-announce the activity to whoever runs your SIEM and detection rules. Tell them which accounts will be active, from which source IPs, in which time window. Otherwise they will rightly open an incident, and you will spend an afternoon explaining the migration to the security team.
2. Keep monitoring on for genuine anomalies. Do not blanket-suppress alerts for the migration account. If the migration tool starts hitting endpoints it should not, you want to know.

A reasonable compromise is to add the migration source IP to an allow-list for high-volume IMAP reads only, and leave all other detections live.

Evidence collection: what to gather as you go#

The lowest-stress way to handle a SOC 2 audit is to collect the evidence during the project rather than reconstruct it afterwards. The auditor will sample, but they will sample from a population you describe. If your population is "every mailbox moved between 1 March and 14 March", they will pick three to five mailboxes and ask to see the controls operating for each one.

For each sampled mailbox they typically want:

• The change ticket that authorised the move.
• The access request that granted whoever ran the migration their admin privileges.
• The migration tool's job log showing start time, completion, and per-folder counts.
• The post-migration validation report (counts matched, deltas reconciled).
• Evidence that the user was notified of the change.
• Evidence that access was revoked on project closure.

A migration audit log that captures per-message, per-mailbox, and per-batch detail makes most of this trivially exportable. The companion post on the email migration audit log goes deep on log formats and retention.

Vendor management if you outsource the migration#

If an MSP runs the migration for you, that MSP becomes a subservice organization or vendor in your control environment for the duration of the engagement. Common controls auditors look for:

• A current vendor due diligence file (their SOC 2, ISO 27001, or equivalent).
• A signed engagement letter or MSA that includes confidentiality terms.
• A defined scope of work tied to the change ticket.
• Named individuals from the vendor side with access during the project.
• Termination of vendor access at project close.

The same applies if you use a contractor or a temporary admin. The tenant-to-tenant migration playbook covers the operational side; what your auditor wants is the paper trail of who was in your tenants and why.

The post-implementation review#

CC8.1 expects a post-implementation review (PIR) after any significant change. Many teams skip this for migrations because everyone is exhausted by the end. Do it anyway, even briefly. A PIR for an email migration should answer:

• Did we move everything we said we would move?
• Did anything fail? What did we do about it?
• Were there security incidents during the window?
• Did we close out access correctly?
• What would we change for the next one?

Twenty minutes in a meeting and a short document attached to the change ticket is enough. Skipping it is one of the easier findings for an auditor to write.

Regulated industries on top of SOC 2#

If you also need to satisfy HIPAA, you are running two compliance programs in parallel during the migration. The healthcare email migration HIPAA considerations layer on top of SOC 2 cleanly because the underlying controls overlap heavily. The big additions are the business associate agreement (BAA) with anyone touching PHI and stricter logging around access events.

If you handle EU personal data, GDPR sits alongside. The control overlap is again significant, but you need to add a lawful-basis statement and, depending on the data, a data protection impact assessment.

A worked example: how a clean migration looks on paper#

To make it concrete, here is how a small, well-documented migration project shows up to an auditor:

1. Change ticket CHG-2026-0341 opened on 1 March. Risk medium. Approvers: CTO, Head of Security, Head of Customer Success. Scope: 220 mailboxes from old tenant to new tenant. Window: 8 March, 6pm to 10 March, 6am local.
2. Access request AR-2026-1102 granted three named admins temporary global admin in both tenants. PIM activation logged with start and end times.
3. Migration tool installed on dedicated admin workstation WS-IT-04. Workstation already in MDM with FDE, EDR, and patch baseline current.
4. Pre-migration test batch of 5 internal mailboxes on 6 March. Validation passed. Counts and bytes recorded in spreadsheet attached to CHG-2026-0341.
5. Production cutover overnight on 8–9 March in batches of 30. Per-batch logs exported daily and attached to the ticket.
6. Post-migration validation completed 10 March. 219 mailboxes match. One mailbox has a 6-message delta investigated and resolved (deleted items folder not selected in source filter).
7. End-user comms sent 9 March 7am. Help desk staffed at 1.5x normal for two business days.
8. Access revocation tickets closed 11 March. OAuth grants revoked in both tenants and screenshots attached.
9. PIR meeting held 13 March. Notes attached to CHG-2026-0341.

When the auditor samples three mailboxes from this project, every artifact they need is one click away from the change ticket. That is what "auditable" actually looks like.

The full migration playbook#

If you want the operational steps in addition to the compliance scaffolding, the complete email migration guide covers the technical sequence end to end. Pair it with this post and the compliance guide and you have most of what you need to run a migration that survives any SOC 2 audit cycle.