%201.svg)
<div class="tg-coc-wrap">…</div> block and its <style> into the /chain-of-custody Webflow page. Every class is prefixed tg-coc-, all CSS variables live on .tg-coc-wrap, and the scoped reset never touches anything outside the wrapper — no body{}, no :root, no bare element selectors. The embedded CoC diagram (§5) uses the tg-coc-dg- sub-namespace. Remove this yellow note before publishing.
Transfer General produces a cryptographically signed chain-of-custody record for every object that crosses a cloud boundary. Automatically. At transfer completion. Before anyone asks.
Moving regulated data between clouds isn't the hard part. The hard part is what happens before and after: validating the transfer, assembling proof from two sets of cloud logs, and producing a defensible record for your auditor. This is engineering work that doesn't ship product.
Custom scripts, hash verification harnesses, retry logic, log scraping. Each cross-cloud migration project is a small bespoke build.
Pulling source logs from one cloud, destination logs from another, reconciling them by timestamp, packaging the result for the auditor. Quarter after quarter.
When the evidence package doesn't satisfy the auditor, engineers stop their roadmap to produce supplementary records. Weeks lost per finding.
Cloud providers do record transfer events within their own boundaries. AWS records ETags and checksums. GCP records crc32c and MD5 hashes. Azure records its own metadata. These records exist because the cloud provider needs them to operate the service — not because they're built to satisfy your auditor.
Three problems make these logs unsuitable as cross-cloud chain-of-custody evidence:
They're not designed to be evidence. Cloud audit logs capture what their own services need for diagnostics and billing. They aren't structured around the questions an auditor will ask, and they aren't signed in a way that proves they haven't been altered after the fact.
They're not immutable by default. Most cloud audit logs can be deleted, redacted, or have their retention shortened by a privileged user. An auditor evaluating evidence asks "could this have been edited?" — and for default cloud logs, the answer is yes.
Nothing links source to destination across the cloud boundary. The source cloud knows it sent something. The destination cloud knows it received something. No single record cryptographically connects the two — proving they're the same object, byte for byte, under the same encryption keys, signed by an independent party.
Built for diagnostics and billing. Mutable by default. Two separate systems on two separate clouds, with no single record linking them. Format and retention vary by provider — may or may not satisfy an auditor.
Built for evidence. Cryptographically signed by Server General. Written to immutable storage. Covers the full cross-cloud journey in a single canonical payload, independently verifiable against the cloud provider's KMS.
Transfer General produces a single cryptographically signed attestation per transferred object. Source and destination paths, hashes proving byte-for-byte integrity, the encryption keys used, the cloud accounts involved, the time of transfer, and Server General's signature certifying the transfer was complete and intact.
View the full sample reportTransfer General runs two paths in parallel. The data path moves the object. The evidence path captures everything that happens to it. They meet at one cryptographic event — and that event is what makes the chain hold.
The object moves through four buckets in three hops. Each hop is confirmation-gated; once the next bucket confirms receipt, Transfer General deletes the object from the prior bucket. The pipeline is serverless. The object is encrypted with your DEK from the moment it leaves Source — and Server General never has plaintext access while it's in transit.
At every meaningful event — read, hash, encrypt, transfer, decrypt, verify, write — Transfer General writes a record to immutable storage in real time. At the Landing bucket, the object is decrypted and the hash is recomputed inline. The hash comparison is the gate that permits the Destination write. After the write confirms, Transfer General signs the final attestation with its Attestation Signing Key.
Every attestation can be verified two ways. The portable method works offline using standard cryptographic libraries. The authoritative method uses the cloud provider's own KMS to confirm the signature — producing a cloud-issued verification receipt suitable for formal compliance proceedings.
Use the bundled PEM and Server General's published public key. Verify with any standard library — openssl dgst -sha256 -verify, Python cryptography, Java Signature. Works without contacting Server General.
Suitable for long-term archival. Each verifier independently establishes trust in the published public key before relying on the verification.
Call the cloud provider's KMS Verify API against the attestation's signing key ID, with the canonical payload. Produces a cloud-issued verification receipt that is independent of Server General.
Legally defensible. Required for formal compliance proceedings and regulatory inquiries.
Chain-of-custody attestation maps directly to the integrity, audit, and verification controls in the major compliance regimes regulated organizations operate under.
The HIPAA Security Rule requires covered entities to implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. The signed attestation is that mechanism — cryptographic evidence that ePHI moved between clouds byte-for-byte intact.
Federal systems require integrity verification of information being transmitted. The hash-match verification at the Landing bucket, combined with the FIPS 140-2 Level 2 signing operation, satisfies the integrity verification requirement at the technical level required for ATO.
SOC 2 evaluates whether system processing is complete, valid, accurate, timely, and authorized. The hash-match proves completeness and accuracy. The signed attestation, with timestamps and authorization metadata, demonstrates the rest.
Talk to an engineer about your cloud configuration, or open the sample attestation to see the exact record your team will hand off.
If you are representing one of our partners, please log into your account to access hidden resources or request an invitation to sign up for the account.
.png)
