Share PHI with a third-party HIPAA consultant when there's no portal

Your BAA with the external HIPAA consultant has a line in it that says, at termination of the engagement, all PHI must be "returned to Covered Entity or destroyed, and the Business Associate shall certify in writing that no copies have been retained." Your consultant is finishing up their gap assessment next week. They've been working off a folder of de-identified-but-not-really audit samples — claims data, an EHR export your CIO pulled for them in February, two incident reports with patient names in them. The clock is ticking, and the only thing your compliance officer has from the consultant is an email that says "all files deleted, see attached affidavit." That email is not enough, and you already know it.

This post is about how to close that BAA clause cleanly when there is no shared portal, no enterprise file-sharing tenant the consultant has access to, and no realistic path to getting one stood up in the two weeks left in the engagement.

Why "we'll just SFTP it" and "we'll use encrypted email" both fail the BAA test

Both of those tools move bytes from A to B. Neither produces evidence of destruction. That is the gap.

SFTP transports the file. Once it lands on the consultant's workstation, your hospital's IT has no visibility into what happens next — whether they copied it to a Dropbox folder, whether their laptop got backed up to a personal iCloud account that night, whether the file got pulled into a working document that they then synced to OneDrive. Your auditor will eventually ask, "How do you know the consultant destroyed the PHI?" and the honest answer is, "They told us they did."

Encrypted email has the same problem with one additional wrinkle: most encrypted email products (Virtru, Microsoft Purview Message Encryption, Proofpoint Encryption) are designed for recipient-side decryption and reading, not for ephemeral delivery. The decrypted plaintext lives in the recipient's mailbox. Some products give you a cryptographic "revoke access" — Virtru's revoke, for example, is real cryptographic key revocation that prevents future decryption even of saved copies. The catch is the same for every product in the category: once the consultant has copy-pasted the plaintext contents into a separate Word doc, the revocation can't reach the copy.

The BAA clause you signed says "destroyed, and certify in writing." Your auditor and your CISO want the same two things:

1. The PHI is provably gone from the consultant's environment.
2. You have something more durable than the consultant's word.

The right shape for this workflow is a delivery channel that destroys itself on read OR download cap OR time-expiry, AND emits a signed, third-party-verifiable artifact saying that destruction happened.

The workflow we recommend

Here is the shape we recommend for one-off PHI handoffs to outside consultants when neither side has access to the other's enterprise file-sharing tenant. It is not the only shape that works, but it is the one we see clean-up the fastest.

Step 1: Decide what's actually leaving your perimeter

Before any file moves, your compliance officer and the engagement lead agree on the minimum data the consultant needs. This is the de-identification or minimum-necessary conversation that should have happened at the start of the engagement — but if it didn't, it has to happen now. Pull only what the consultant's scope of work actually requires.

For a gap assessment, that's usually a representative sample of records, not the whole population. For an incident review, that's the timeline and the affected record set, not the entire EHR export. For a risk analysis, that's the system inventory and access logs, not the underlying data.

The smaller the payload, the easier everything that follows.

Step 2: Send the file with destruction built in

This is where a zero-knowledge encrypted link sharing tool earns its place in your stack. The consultant gets a link. The link decrypts client-side in their browser. Your servers — and the link tool's servers — never see the plaintext. The link burns itself after a download cap, a view cap, a passphrase failure, or a time window you pick at send-time. For a one-shot consultant handoff, we typically recommend: 1 download, 24 hours, and a passphrase you share over a separate channel (your existing phone call, Signal, whatever you already use for credentials).

The consultant downloads the file once. The download cap closes. The ciphertext on the server is destroyed at the storage layer. The link's audit trail records the timestamp, the IP the recipient downloaded from, and the burn event.

This is the part most security teams already understand. The next two steps are where the BAA evidence story gets closed.

Step 3: Anchor the destruction to a tamper-evident audit chain

Every state-changing event on every CIPH4 drop — created, viewed, burned, revoked, expired — gets written into a hash-chained audit log. Each row's hash includes the prior row's hash. If anyone tried to alter a single row after the fact, every row that came after it would have a hash that no longer verifies.

For a HIPAA workflow, this matters because the burn event itself becomes part of a chain that is mathematically provable. Your compliance officer doesn't have to trust the engineer who wrote the audit code. They can run the public audit chain verifier themselves and confirm that the chain hasn't been tampered with.

When the consultant downloads the file and the drop burns, you have a signed timeline:

• 2026-05-15 09:14 UTC: Share created by alice@yourhospital.org
• 2026-05-15 09:47 UTC: Share opened by recipient (IP recorded, device recorded)
• 2026-05-15 09:48 UTC: File downloaded, download limit reached, share destroyed
• 2026-05-15 09:48 UTC: Destruction event written to the tamper-evident audit log

That timeline, verifiable end-to-end, is harder for anyone to dispute than the consultant's affidavit.

Step 4: Capture the Proof-of-Deletion Receipt

On Enterprise plans, the destruction event also generates a signed Proof-of-Deletion Receipt. It's a small portable artifact that says, in a form your auditor's tools can verify: this share (referenced by its opaque ID) was destroyed at this UTC moment, and the destruction is anchored to a specific row in the tamper-evident audit log. CIPH4 publishes the public half of the signing key on a fixed URL — your compliance team can verify the receipt's signature without trusting us, and without even reaching us. We could go out of business tomorrow and the receipt would still verify.

Hand that receipt to your compliance officer. They drop it in the engagement file alongside the consultant's destruction affidavit. Now you have two independent attestations: the consultant says they destroyed their copy, and the share itself attests that the delivery channel destroyed its copy. The combination satisfies most auditors and a fair number of OCR-engagement attorneys we've talked to.

What this doesn't do — be honest with your CISO

You should be honest with your CISO and your compliance officer about what this workflow does and doesn't do.

It does NOT prove that the consultant deleted their LOCAL copy of the file after downloading it. Once bytes hit a recipient's laptop, you cannot enforce destruction on that endpoint without DRM and an agent installed on their machine. That's a different control. The consultant's signed destruction affidavit is what covers their side of the BAA.

What this workflow DOES prove is:

• The delivery channel itself destroyed its copy of the ciphertext at a specific moment.
• That destruction is mathematically anchored to a hash chain that can be independently verified.
• The receipt is cryptographically signed by a key whose public half is published.

You are closing the gap between "we sent the file" and "we have evidence the file was destroyed somewhere in the chain of custody." You are not closing the gap between "the consultant downloaded the file" and "the consultant's hard drive no longer contains it." Be precise about the difference when you brief your auditor. It builds credibility, and it's accurate.

What this looks like during an OCR audit

If you have ever sat in front of an OCR auditor, you know they don't actually want every artifact — they want to see that you have a documented process and that the process produces artifacts when it's run.

The auditor's job is to find a gap between your policy and your evidence. Your job is to close every gap before they get there.

The PHI handoff process we recommend documenting in your HIPAA workbook looks like this:

1. Compliance officer + engagement lead agree on minimum-necessary payload.
2. Sender uses zero-knowledge link share with 1-download cap, 24-hour expiry, passphrase out-of-band.
3. Consultant confirms receipt.
4. Drop burns at download or expiry.
5. Proof-of-Deletion Receipt captured and filed.
6. Consultant signs destruction affidavit at engagement close.
7. Both artifacts filed in the engagement folder.

When the auditor asks "how do you handle PHI delivery to third parties outside your portal?" you hand them the workbook page and a sample receipt from a recent engagement. That's the conversation done.

A word on email and the "we always do it this way" inertia

Most healthcare security teams we talk to are using encrypted email for consultant handoffs because it's what's been in place for five or ten years and nobody wants to introduce another tool. The problem is that encrypted email was designed for a different threat model — confidentiality in transit and at rest, not destruction. The BAA destroy-or-return clause keeps getting written into engagements, and the encrypted email product keeps not having an answer for it.

If your CISO is reading this and thinking "but the consultant will push back, they'll want us to use SFTP" — push back gently. The consultant is also exposed to the BAA clause. They also want a clean way to attest destruction. A workflow that closes their side of the clause is a workflow they will adopt. We have seen this transition go smoothly enough that consultants now ask their hospital clients to use it.

For a deeper dive on the healthcare provider security posture we recommend for ongoing third-party engagements — not just the one-off consultant case — there's more detail on the industry page. For the compliance team's purchase brief including the workbook templates, that lives on the compliance persona page.

Practical next steps

Pull the active list of third-party HIPAA consultants your team is engaged with right now and look at the next two delivery handoffs on the calendar. Pick one — the smaller one — and run it through the workflow above as a pilot. The Proof-of-Deletion Receipt you get back goes in the engagement folder; show it to your compliance officer and your auditor of record before the bigger handoff lands.

If your BAA clause says "destroyed, and certify in writing," your destruction certification just got a co-signer that nobody can argue with.