# Ensure AWS Backup recovery point is encrypted at rest - Source: https://support.icompaas.com/support/solutions/articles/a_179329223451314-ensure-aws-backup-recovery-point-is-encrypted-at-rest - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that every recovery point stored in an AWS Backup vault is encrypted at rest. Recovery points of resources that are fully managed by AWS Backup are encrypted with the backup vault's AWS KMS key. Recovery points of other resource types, such as Amazon EBS snapshots and Amazon RDS snapshots, take their encryption from the source resource, so a backup of an unencrypted source resource is also unencrypted. **Rationale** An unencrypted recovery point can be read or copied by anyone who gains access to the backup vault or the underlying snapshot, allowing data theft and offline analysis. Restores from tampered or unprotected backups can also disrupt recovery operations. Encrypting all recovery points with AWS KMS, preferably with customer managed keys, and applying least privilege to keys and vaults protects backup data in the same way as the production data. **Impact** - Protects backup data at rest and limits access to principals allowed to use the KMS key - Helps meet compliance requirements for encrypting backups - Encrypting an existing unencrypted source resource (for example, an EBS volume or RDS database) usually requires creating an encrypted copy and switching to it, which may need a maintenance window - Existing unencrypted recovery points cannot be encrypted in place and remain until they are deleted or expire **Default Value** Recovery points of resource types that are fully managed by AWS Backup are always encrypted with the vault's KMS key. For other resource types, the recovery point is encrypted only if the source resource is encrypted. **Pre-Requisites** - IAM permissions: backup:ListBackupVaults, backup:ListRecoveryPointsByBackupVault, backup:DescribeRecoveryPoint and backup:DeleteRecoveryPoint - Permissions to encrypt the affected source resources (for example, EBS or RDS permissions and access to the KMS key) - Confirmation of which unencrypted recovery points are still needed for retention or compliance purposes **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the AWS Backup console and select **Backup vaults** in the left menu. 3. Select a backup vault and review its **Recovery points**. 4. Select each recovery point and check whether it is shown as encrypted. 5. Repeat for each backup vault in each region in use. 6. If any recovery point is not encrypted, follow the implementation steps. **CLI:** List the backup vaults in a region: aws backup list-backup-vaults --region --query "BackupVaultList\[\].BackupVaultName" Show the encryption status of the recovery points in a vault: aws backup list-recovery-points-by-backup-vault --backup-vault-name --region --query "RecoveryPoints\[\].\[RecoveryPointArn,ResourceType,ResourceArn,IsEncrypted\]" --output table A recovery point fails if IsEncrypted is false. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Use the Test Plan output to identify the source resource (ResourceArn) of each unencrypted recovery point. 3. Encrypt the source resource in its own service so that new recovery points are encrypted, for example: - for an EBS volume, create an encrypted copy of a snapshot and create a new volume from it, - for an RDS database, copy a snapshot with encryption enabled and restore the database from the encrypted copy. 4. Make sure the backup plan protects the new, encrypted resource. 5. Make sure each backup plan targets a backup vault that uses the KMS key you want (preferably a customer managed key). 6. After new encrypted recovery points exist and the old ones are no longer needed, open the backup vault, select each unencrypted recovery point and choose **Delete**. 7. Repeat for each affected recovery point in each region in use. **Backout Plan** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. If a source resource was replaced with an encrypted copy, point the applications back to the original resource, as long as it has not been deleted. 3. If a backup plan's resource assignment was changed, set it back to the original resource. Note: deleted recovery points cannot be restored. Keep unencrypted recovery points until you are sure they are no longer required. **Reference** - [https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) - [https://docs.aws.amazon.com/securityhub/latest/userguide/backup-controls.html](https://docs.aws.amazon.com/securityhub/latest/userguide/backup-controls.html) - [https://docs.aws.amazon.com/cli/latest/reference/backup/list-recovery-points-by-backup-vault.html](https://docs.aws.amazon.com/cli/latest/reference/backup/list-recovery-points-by-backup-vault.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.