Cloud logging has matured significantly. Every major CSP offers centralized telemetry, tamper-evident storage, and detailed access records. Inside a single cloud environment, audit readiness feels solved. But regulated data does not stay in one place — and the moment it crosses a cloud boundary, the picture changes completely.

The assumption that breaks down.

Inside a single CSP environment, the logic holds: cloud logging equals audit readiness. Telemetry is centralized, controls are inherited, and the evidentiary trail is coherent. An auditor asking about a specific event gets a single, authoritative answer from a single system.

What actually happens at the boundary.

Each cloud provider produces logs in its own format, with its own timestamp source, covering only what happens inside its own boundary. When data moves from AWS to GCP, you are left with two partial records and no unified narrator.

AWS logs that data left. GCP logs that data arrived. But there is no single record that covers the journey between them — no cryptographic link between the source event and the destination event, no unified timestamp, no authoritative statement from a single party that witnessed both ends.

The IAM problem compounds it.

Each cloud has its own identity and access management system. Service accounts get provisioned on both sides — often with more privileges than necessary, because debugging cross-cloud IAM failures is one of the most time-consuming problems in cloud engineering. When the transfer completes, those credentials often persist. Nobody revokes them because nobody owns the cleanup.

What an auditor actually receives.

When a compliance auditor asks for evidence of a specific cross-cloud transfer, the answer is: two log excerpts from two separate systems, in different formats, with different timestamp conventions, requiring manual reconciliation to tell a coherent story. The logs are all there. They are just fragmented across systems that were never designed to tell a unified story.