Ensure in-use encryption keys are not scheduled for deletion

Depending on the provider and service that you use, check out the following resources:

AWS

• [Deleting AWS KMS keys] (https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html)

Azure

• [Enable soft delete] (https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-change)

Alibaba

• [Remove key material] (https://www.alibabacloud.com/help/en/key-management-service/latest/remove-key-material)

Google Cloud

• [Delete key] (https://cloud.google.com/kms/docs/destroy-restore)

Service-wide remediation

Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.

AWS

Use AWS Organizations guardrails, AWS Config rules or conformance packs where they fit, approved account baselines, and IaC modules so new resources inherit the secure setting.

Azure

Use management group or subscription Azure Policy assignments, remediation tasks where supported, landing-zone standards, and IaC modules so drift is prevented at scale.

Alibaba Cloud

Use Resource Directory guardrails, account baselines, and IaC modules so the secure setting is applied consistently across environments.

Google Cloud

Use organization or folder policies where available, shared project templates, logs and alerting baselines, and IaC modules so new resources inherit the secure setting.

Operational rollout

1. Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
2. Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
3. Re-scan and track approved exceptions with an owner and expiry date.