How to Evaluate Offboarding and Exit for an On-Prem GPU Pod

The pilot ends. The vendor sends a one-line email: disks wiped. The ISSM asks which method was used, whether keys were destroyed, whether snapshots remain, who still has the weights, and who signed the certificate. Nobody can produce the pack.

Define exit evidence before workloads arrive. This is not the 30-day pilot checklist. This is the close-out: a verifiable account of what was removed, what was destroyed, what was returned, and who signed off.

Build an exit-state map for the pod

Start with every place a Supermicro HGX B300 pod can still hold customer data after the last job. Include NVMe devices, shared storage, OS volumes, checkpoints and weights, container or model registries, snapshots and backups, logs, dumps, support bundles, admin workstations, and removable media.

For each location, record owner, media type, whether the copy is encrypted, who can still read it, and the intended end state: returned, sanitized, cryptographically erased, physically destroyed, or retained under a written exception. If a location is missing from the map, it will be missing from the certificate.

Evaluate the map alongside on-prem GPU infrastructure for CUI and ITAR. Pacific Intelligent Technologies, Inc. does not make a customer CMMC certified. An exit map is evidence of a close-out, not a certification claim.

Sanitize by media and by required outcome

“Wipe the disks” is not a method. Use a published framework such as NIST SP 800-88 and name the outcome: clear, purge, or destroy. Then map that outcome to the media you actually have—NVMe, HDDs if any, shared arrays, removable devices—and to the reason you chose it.

Cryptographic erase and physical destruction are different outcomes. Cryptographic erase can be the right purge when keys were customer-held, wrap was verified, and no residual key copy remains. Physical destruction is the right outcome when the media cannot be trusted, failed, or must not leave the boundary intact. Do not treat them as synonyms.

Write the failed-drive path before a drive fails. A device that cannot complete a purge still needs an exception: hold, destroy, or return under chain of custody, with a named approver. A failed drive that “will be handled later” is an open residual.

Separate key destruction from data deletion

Deleting files does not destroy keys. Destroying a volume does not destroy a KMS copy, an HSM clone, a vendor escrow, or a recovery share. If wrapped backups, snapshots, or support copies still exist, deleting the primary objects is incomplete.

Require a key-destruction record for every class that could unwrap remaining media: disk keys, dataset keys, weights keys, backup keys, and any vendor recovery material. Then search for residual snapshots, backups, registry tags, and support-bundle copies. Teams comparing architectures can keep the mothership comparisons index in view while this review stays on close-out evidence.

Assemble the evidence pack before hardware moves

Do not let crates leave until the pack exists. The pack should include an inventory with serials, the sanitization method and result per device or volume, the key-destruction record, a residual-data review, written exceptions, chain of custody for anything that leaves or is destroyed, a signed certificate, and customer acceptance.

Name who signs. Vendor operations can attest to the method they ran. The customer security owner accepts or rejects the pack. A one-line “disks wiped” email is not a certificate, and a certificate the customer never accepted is not a close-out.

Include support bundles in the residual review. Bundles, dumps, and screenshots taken during the engagement are customer data until they are destroyed or returned under the same rules. This is the same boundary seriousness used when teams evaluate reserved GPU capacity: the engagement is not over when the GPUs power off.

If you are evaluating an on-prem GPU pod and want to walk an exit-evidence pack with Pacific, book 30 minutes with Harper. Bring the intended media list, the sanitization outcomes, and who will sign. Do not put controlled details in a website form.

FAQ

Is cryptographic erase the same as physical destruction?

No. Cryptographic erase depends on key destruction and the absence of leftover unwrap material. Physical destruction removes the media. Choose the outcome from the media, the program, and whether a failed device can still be purged. Do not let a vendor use the words interchangeably.

What happens if a drive fails during sanitization?

Use the exception path you wrote before the engagement: hold, destroy, or return under chain of custody, with a named approver and a residual entry in the pack. A failed drive without an exception is an open exit item.

Should support bundles be in the exit pack?

Yes. Bundles, dumps, logs, and screenshots can contain hostnames, job metadata, or workload fragments. Treat them as residual copies until they are destroyed or returned under the same evidence rules as the disks.

Who should sign the exit certificate?

The vendor attests to methods and results. The customer security owner accepts the pack. If only one side signs, you have an assertion, not a close-out. Evaluate that ownership before production data arrives. Start from Pacific Intelligent Technologies, Inc. if you need the broader infrastructure model behind the pod.

The evaluation rule is straightforward: map every residual location, sanitize by media and outcome, destroy keys separately from files, and refuse hardware movement until the evidence pack is signed. A one-line wipe email is not an exit.