The Backup Tape That Carries Its Own Key

Why encryption failed

The tape header contains the plaintext 256-bit key. Anyone who has the tape has both the ciphertext and the key, so confidentiality is zero. AES-256-GCM is strong, but key management is the control that failed. The courier loss is therefore a plaintext data loss, not a contained encrypted-media incident.

Exposure

12,000 policyholder records may include names, addresses, dates of birth, policy numbers, and possibly health or claims data. Under many breach laws, encrypted data is exempt only if the key was not compromised and is not reasonably available. Here the key was on the tape, so the exemption likely does not apply. Assume disclosure and involve legal/privacy counsel promptly; notification deadlines may be short. Also consider regulatory notification and credit monitoring depending on data elements.

Aggravating factors

Key escrow is a manually updated spreadsheet on a file share, so there is no reliable record of which key encrypted which tape, who accessed it, or whether other copies leaked. Five-year rotation means a long-lived key population. The lack of dual control makes insider misuse plausible. The lost tape should be treated as a potential targeted theft until the courier investigation says otherwise.

Envelope design

• Generate a random DEK per tape, encrypt the tape with AES-256-GCM using a unique nonce, and wrap the DEK with a KEK held in a cloud KMS/HSM.
• Write only the wrapped DEK, key ID, nonce, and format version to the tape header. The KEK never leaves the KMS.
• Use separate KEKs per environment and region; enforce IAM so backup operators can request unwrap but not export keys. Require dual approval for bulk unwrap.

Restore within four hours

• Pre-provision a restore role that can call KMS unwrap, with break-glass credentials in a sealed process. Test a full tape restore quarterly and measure the KMS path.
• Cache no plaintext DEKs on disk; hold them in memory and zeroize after restore.
• Keep an escrow copy of wrapped DEKs in a second region so a KMS outage does not block restore. Escrow the wrapped DEKs, not the KEK.

30 tapes per week

Automate key generation, wrapping, and metadata logging. A manual spreadsheet cannot keep pace or provide audit. Log each unwrap with tape ID, operator, ticket, and time. Reconcile tape inventory to key records weekly.

Rotation

Rotate the KEK annually and re-wrap DEKs in the catalog; do not re-encrypt old tapes. Retain old KEK versions for the tape retention period.

Lost tape

• Preserve courier records, chain-of-custody, and the tape serial. Notify legal and privacy officers; assume the key is compromised because it traveled with the tape.
• Do not wait for proof of access. Evaluate notification duties based on the data elements and jurisdiction.
• Monitor for misuse of the 12,000 records and prepare a public response if required.

Existing tapes

The old tapes still have plaintext keys in their headers. You cannot re-key a tape that is offsite without recalling it. Prioritize:

1. Inventory all old-format tapes and rank by data sensitivity and regulatory exposure.
2. Recall and re-encrypt the highest-risk tapes first under the envelope scheme; for the remainder, restrict physical access, strengthen vault controls, and set a destruction schedule.
3. Stop writing new tapes in the old format immediately; that is the one change fully within your control.
4. Retain the old keys only as long as needed to restore old tapes, in a controlled escrow with access logging, then destroy them.

The spreadsheet should be replaced by a key catalog with audit, not merely copied to a new share.