Send your SOC 2 evidence pack to an auditor who won't accept email

Your SOC 2 evidence collection is finally in good shape. Drata or Vanta has been pulling control evidence for nine months, your CISO signed off on the system description, and your auditor is scheduled to start fieldwork in three weeks. Then they send the engagement letter. Buried on page two: "Please transmit evidence via your secure portal or encrypted file transfer. Email attachments will not be accepted for any evidence containing customer data, access lists, or system configuration."

You stare at the line for a minute. Drata has the evidence. Drata does not have a "send to auditor" button. Now what?

The handoff gap nobody talks about in the demo

Drata, Vanta, Secureframe, Sprinto, Thoropass — every modern GRC platform is excellent at the part where you collect evidence and map it to controls. They integrate with your IdP, your cloud, your HRIS, your ticketing system. They generate the control narrative. They flag drift. They host the auditor portal.

What they don't do is send evidence to auditors who refuse to use their portal.

And there are more of those auditors than the GRC vendors will tell you. The big four firms have their own evidence intake systems. Mid-market regional firms often use a generic secure file share their IT team rolled out in 2019 that requires the auditor to download to a Citrix VM and then email you a checksum to confirm. Boutique audit shops sometimes don't have a portal at all and will ask you to share via "your preferred secure method." Specialty auditors for HITRUST, FedRAMP 3PAO, ISO 27001 surveillance, or PCI QSA work usually run their own intake outside the SOC 2 platform you bought.

So your beautifully-collected evidence pack — the access review export, the change management ticket sample, the incident response runbook, the encryption key inventory — has to leave your GRC platform and travel to a third party. That trip is the part everyone underplays.

"We use Drata. The auditor uses ShareFile. The handoff was the messiest part of the engagement and it never showed up in either vendor's demo." — Compliance director, 400-person SaaS company, mid-engagement

Why the obvious answers don't hold up

Let's run through the options a compliance lead actually considers when the engagement letter lands. None of them survive a second look.

Email it. This is what most engagements still do. It violates your own data classification policy on day one of the audit. The auditor will note it. Some auditors will explicitly flag it as a control gap. You will then have to write a remediation memo explaining why your own SOC 2 evidence was transmitted via a channel that fails your CC6.7 (transmission and disposal of confidential information) control.

Use the auditor's portal. Sometimes great. Sometimes a Citrix-published browser that times out after 15 minutes, won't accept files over 100MB, breaks on Safari, and requires every team member who uploads to get a separate login provisioned by the auditor's IT team — a process that takes four business days each. The bigger the audit firm, the worse this tends to be.

Use your shared drive with a one-time link. Google Drive, OneDrive, Dropbox. The link is "anyone with the link can view." Your DLP doesn't fire because the auditor's domain isn't on the watchlist. You can't tell when they downloaded it. You can't tell if they re-shared it internally to three associates. The link expires "eventually" — in most defaults, never, because nobody set the expiry. Three months later the file is still live and Google's audit log says it was accessed from an IP you don't recognize.

Use a secure transfer product your security team already bought. This is the right shape — but every product in that category was built for one of two adjacent jobs: large-file inter-company collaboration (Smartfile, MOVEit, ShareFile) or B2B secure messaging (Virtru, Echoworx, Zix). They work, but they're priced and provisioned for departments that send hundreds of transfers a month. Your compliance team sends two during the audit and zero for the rest of the year. The license cost is wildly out of proportion to the use case, and you usually have to file an IT ticket to get the auditor provisioned as an external user.

You can see why the email thing keeps happening.

What the missing step actually looks like

The missing step is a thin layer: a way to take the evidence package Drata or Vanta produced and hand it to the auditor with three properties that none of the options above give you cleanly.

1. The auditor doesn't need an account. They click a link, open the file, done. No portal login, no Citrix, no provisioning ticket.
2. You see exactly when, where, and by whom it was opened. Not "shared with auditor@firm.com" — actual recipient confirmation, IP, timestamp, user-agent string. This is the trail your own auditor needs you to produce next year when they ask how you transmitted Q3 evidence.
3. The evidence destroys itself on a defined trigger. View count hits cap, time window expires, or you revoke from your side. After that, there is no copy on the recipient's machine that they can resurface six months later because they forgot to clean it up.

That's the gap. It's not a new category of product. It's a specific shape of secure share with auditor-grade trail. Tools like CIPH4 are built for exactly this transfer.

The reason most teams haven't found it is that they're searching for "secure file sharing" — a category dominated by collaboration suites for ongoing work. What they actually need is the opposite of collaboration: one-shot delivery with a sharp end. A drop, not a folder. See the security-team buyer view and the underlying DevOps integration story for how the workflow stitches in next to your existing tooling.

The audit-trail recursion that auditors quietly love

Here is the part the GRC vendors don't sell because it sounds too on-the-nose.

The auditor is, by their own engagement letter, evaluating how you handle sensitive data transfer. They will ask you for evidence of CC6.7 (transmission of confidential information). You will hand them a list of controls. Then you will transmit the evidence pack itself.

If you transmit it via email, you have just produced a control failure under CC6.7 (transmission and disposal of confidential information) inside the audit evidence itself. If you transmit it via your GRC portal and the auditor never logs in, you have produced an evidence-delivery failure that has to be reconciled with a side-channel. If you transmit it via a drop that emits a signed Proof-of-Deletion Receipt (CIPH4 Enterprise) verifiable at the public receipt verifier, plus a tamper-evident chain, you have just handed the auditor a live demo of your CC6.7 control working correctly — on the very evidence that proves it.

Auditors love this. It compresses three things into one artifact:

• The evidence itself (the access review, the change log, the runbook).
• A working example of your transmission control protecting that evidence.
• A signed cryptographic receipt that the transmission completed and the copy was destroyed when it should have been.

Some auditors will accept the receipt as additional evidence for the transmission control. Some won't because their playbook predates that as an option. Either way, the recursion is real: the way you ship the SOC 2 evidence is itself SOC 2 evidence.

"The drop receipts ended up in our evidence pack the next year. The auditor asked how we transmitted last year's evidence pack, and the answer was 'here, look at the receipt for that transmission.' It collapsed two months of back-and-forth into a one-page artifact." — VP of compliance, healthcare SaaS, year-two engagement

For the architecture-level story on why receipts are cryptographically meaningful — not just "we logged that you clicked download" — see the security architecture overview and the public receipt verifier, which is the page you'd actually walk an auditor to when they want to confirm a receipt was signed by us, not just claimed by us.

A walk through the actual handoff

Here's the shape of how this looks in practice during a real engagement. The compliance lead is named Priya. Her auditor is named Marcus. They're three weeks into fieldwork.

Marcus emails: "Can you send me the privileged access review for Q3, the change tickets from October 14 and October 27, and the encryption key rotation evidence for the customer database?"

Priya pulls the artifacts from Drata. Two are PDFs from the access review module. One is a screenshot bundle from the change management integration. The fourth is a JSON export from the cloud provider's KMS history. Total: 47MB.

In the old workflow, Priya zips it, sets a password, emails the zip to Marcus, and texts him the password — violating her own classification policy in two channels simultaneously.

In the new workflow, Priya creates a drop. The bundle uploads. She sets it for two views (Marcus might open it once and then re-open later in the same week), seven-day expiry, and the recipient identity binding tied to Marcus's email. She copies the link and pastes it into her reply.

Marcus clicks. The browser asks him to confirm his email, sends a magic link to his inbox, he clicks it, the file decrypts in his browser, and he downloads. (Recipient identity binding via magic-link is a Teams+ feature; Priya's org is on Enterprise.) Priya's dashboard shows the open: which IP, which city, which timestamp. When Marcus opens it again on Friday, that shows too. After the second open the drop self-destructs, the dashboard logs the destruction event, and on Enterprise plans the destruction event produces a signed Proof-of-Deletion Receipt.

Priya pastes the receipt link into her evidence-of-transmission folder in Drata. Six weeks later, in the closing meeting, Marcus asks how the evidence packs were transmitted. Priya pulls up the receipts. He nods, makes a note, and moves on. The transmission control is documented.

That's the whole flow. About 90 seconds for the sender. Zero account setup for the auditor.

Where this fits in your existing stack

You don't replace Drata. You don't replace Vanta. You don't replace ShareFile if your IT team likes it for the long-running B2B work it was bought for. You add the thin handoff layer for the specific moment when evidence has to leave your GRC platform and land on the auditor's machine.

A few practical points the compliance team view covers in more depth:

• The handoff layer should be procurement-friendly: short DPA, SCCs in place, no surprise sub-processors. Your auditor is going to ask about the vendor itself.
• The architecture should be zero-knowledge — meaning the platform you're using cannot itself read the evidence it's transmitting. This is the question your security team will ask, and the honest answer matters.
• Receipts should be cryptographically signed, not just logged. A log entry that says "downloaded at 14:32" is a vendor's claim. A signed receipt is a verifiable artifact that holds up if the vendor disappears tomorrow.
• The trail you produce for your auditor should also be the trail you produce internally for your own next-year audit. One artifact, two purposes.

What to do next

If you're three weeks out from fieldwork: pilot the handoff on one piece of evidence the auditor has already requested, before the rest of the pack lands. Get the auditor's UX confirmed before you depend on it.

If you're between audits: this is the quiet quarter to wire the workflow in and update the section of your control narrative that describes how confidential information is transmitted. Next year's auditor will read that paragraph in week one. The same handoff pattern carries over to CMMC Level 2 evidence packages going to a C3PAO assessor, to HITRUST submissions, and to most other audit regimes that ask for transmission controls — the terminology shifts, the artifact doesn't.