Chain-of-custody is a foundational concept in regulated industries: the ability to prove, at any point, what happened to a specific piece of data — who had access to it, when it moved, and whether it arrived intact. Inside a single cloud environment, this is straightforward. Across cloud boundaries, it is not.

The single-cloud assumption.

Within a single CSP environment, chain-of-custody is well-supported. Telemetry is centralized. IAM events are logged in a single system. Storage access records reference the same object identifiers. An auditor asking about a specific event gets a coherent, single-source answer.

Cloud providers are designed to operate this way. Their logging, monitoring, and compliance tools assume that the data they are protecting starts and ends within their boundary.

What happens at the boundary.

A dataset containing protected health information needs to move from an AWS environment to a GCP research platform. The transfer is authorized, encrypted, and logged — on both sides.

AWS records that data departed. GCP records that data arrived. The two records live in different systems, use different formats, and have no cryptographic relationship to each other.

Nothing failed. The architecture was simply never built to preserve continuous evidence across boundaries.

The compliance consequence.

For healthcare organizations, this gap is an audit risk. An auditor asking for evidence of chain-of-custody for a specific file receives two log excerpts — one from each CSP — and a manual reconciliation exercise to connect them.

For federal agencies, this gap is a control gap. NIST 800-53 AU-16 requires coordination of audit information across organizational boundaries. Two disconnected CSP logs do not cleanly satisfy that requirement.