How to Destroy Keys Before Disk Disposal: Cloud KMS > Key Versions

To meet ISO 27001 control 7.14, you must verify that sensitive data is removed or made permanently unrecoverable before equipment or storage media is disposed of or reused. You can cloud kms destroy key versions before disk disposal by encrypting Google Compute Engine disks with customer-managed encryption keys (CMEK), then scheduling destruction of the specific Cloud KMS key version that encrypted the retired disk and confirming that its state becomes DESTROYED.

What must be true before you destroy a Cloud KMS key version?

Cloud KMS destruction is permanent after a short recovery window. When a key version is destroyed, Google Cloud can no longer decrypt any disk, snapshot, image, backup, or other resource encrypted with that version. This is useful for disposal, but only if you know exactly what the version protects.

For a small business, the safest approach is to use a separate Cloud KMS key for each disposal group, such as one key for a retired server and its snapshots. Do not use one broadly shared key for every disk in your project; destroying an old key version could make active systems unavailable.

How do you configure Google Cloud disks for Cloud KMS key-version destruction?

These steps use Google Cloud Console and Google Cloud KMS. Perform them with an account that has permission to administer Cloud KMS keys and Compute Engine disks. If you are the owner of a small Google Cloud project, you may already have these permissions; if not, ask the person who manages the project to assign them.

1. Create a dedicated key ring. In Google Cloud Console, open Navigation menu > Security > Key Management. Select the correct project, then select Key Rings > Create key ring. Set Key ring name to a clear value such as retirement-keys. Choose the same location as the disks you intend to protect, such as us-central1, and select Create.
2. Create a dedicated symmetric encryption key. Open the new key ring and select Create key. Use a name that identifies the asset group, such as finance-server-retire-2026. Set Protection level to Software unless your policy specifically requires HSM protection. Set Purpose to Symmetric encrypt/decrypt. Leave Rotation period unset for a short-lived retirement key so automatic rotation does not complicate your disposal record. Select Create.
3. Give Compute Engine permission to use the key. Open the key you created, then select the Permissions tab and choose Grant access. Add the Compute Engine service agent in this format: service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com. Assign the role Cloud KMS CryptoKey Encrypter/Decrypter, then select Save. Replace PROJECT_NUMBER with the numeric project number shown under IAM & Admin > Settings.
4. Create the disk with customer-managed encryption. Go to Navigation menu > Compute Engine > Disks, then select Create disk. Choose the disk’s Region or Zone, disk type, and size. Under Encryption, select Customer-managed encryption key (CMEK). Select the retirement-keys key ring and the dedicated key you created. Select Create.
5. Use the encrypted disk only for the intended system or disposal group. Attach it from Compute Engine > VM instances, select the VM, choose Edit, then use the Additional disks section. Keep a simple record showing which VM and disk use which Cloud KMS key.
6. For an existing disk, migrate rather than assuming its encryption changed. An existing persistent disk using Google-managed encryption is not converted merely by creating a Cloud KMS key. Create a snapshot or replacement disk using the required CMEK options, restore the workload to the new CMEK-protected disk, test it, and then securely retire the old disk according to your disposal process.
7. Before retirement, create a new key version if the old version is primary. Go to Security > Key Management > Key Rings, open your key ring, and select the key. On the Key versions tab, select Create new version. After it is created, use the version actions menu to select Set as primary version. Do not do this if the old version still protects data you need to keep available.
8. Schedule destruction of the retired version. On the same Key versions tab, select the old version used by the retired disk. Open the version actions menu and select Destroy, then confirm the warning. Cloud KMS changes the version to DESTROY_SCHEDULED and starts a 24-hour recovery period. After that period, the version becomes permanently DESTROYED.

How do you verify that Cloud KMS destroyed the correct key version before disk disposal?

Verification has two parts: prove the disk used your CMEK, then prove the exact key version is permanently destroyed. In Cloud Console, open Compute Engine > Disks, select the retired disk, and review the Encryption section. It should identify a customer-managed key rather than a Google-managed key.

Next, return to Security > Key Management > Key Rings, open the key, and select Key versions. The retired version must show Destroyed, not merely Scheduled for destruction. Do not send physical equipment for disposal while the version remains in the 24-hour recovery period if your process requires irreversible destruction first.

If you use Google Cloud CLI, this command gives you a clean, repeatable verification record:

gcloud kms keys versions describe 1 \
  --key=finance-server-retire-2026 \
  --keyring=retirement-keys \
  --location=us-central1 \
  --format="yaml(name,state,destroyEventTime)"

For a completed destruction, the output should show state: DESTROYED. If it shows DESTROY_SCHEDULED, wait until the destruction time has passed and run the command again.

What evidence should you retain for an ISO 27001 assessor?

ISO 27001 practice 7.14 requires verification, so retain evidence that connects the retiring asset, its encryption key, the destruction event, and the final disposal action. An assessor should be able to follow the evidence without relying on your memory.

• A screenshot or exported disk details page showing the disk name, project, zone, and Customer-managed encryption key.
• A screenshot of the Cloud KMS key’s Key versions tab showing the version number and final DESTROYED status.
• The Google Cloud CLI output from the version verification command, saved as a dated text file.
• A Cloud Audit Logs export showing who scheduled the destruction and when. In Logging > Logs Explorer, use this query:

log_id("cloudaudit.googleapis.com/activity")
protoPayload.serviceName="cloudkms.googleapis.com"
protoPayload.methodName="google.cloud.kms.v1.KeyManagementService.DestroyCryptoKeyVersion"

• A disposal record containing the asset ID, disk or server name, key name, key version, approver, destruction completion time, and disposal vendor certificate or internal disposal confirmation.
• If licensed software was installed on equipment you own, evidence that licenses were removed, transferred, or deactivated before reuse or disposal.

Where does Cloud KMS fall short of ISO 27001 control 7.14?

Using Cloud KMS to destroy key versions before disposal is strong cryptographic sanitization for data encrypted under that key, but it does not physically overwrite media, remove software licenses, or protect data stored outside the encrypted Google Cloud resource. It also does not cover local downloads, exported snapshots, database dumps, unmanaged backups, USB drives, or a laptop’s internal drive.

For Google Compute Engine persistent disks, Google operates the underlying hardware; your practical disposal steps are to delete the retired disk and its snapshots after confirming retention requirements, retain the Cloud KMS destruction evidence, and rely on your Google Cloud service agreement for provider-managed media handling. For equipment your business physically owns, add a documented sanitization method such as secure overwrite, cryptographic erase, or destruction through a qualified vendor, and retain that vendor’s certificate.

Next step: create one dedicated CMEK-protected test disk this week, destroy its test key version after the 24-hour window, and save the evidence package as the template for your real disposal process.