Ixxerja permezz ta’


Security Control: Backup and recovery

Backup and Recovery covers controls to ensure that data and configuration backups at the different service tiers are performed, validated, and protected.

BR-1: Ensure regular automated backups

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
11.2 CP-2, CP-4, CP-9 N/A

Security principle: Ensure backup of business-critical resources, either during resource creation or enforced through policy for existing resources.


Azure guidance: For Azure Backup supported resources (such as Azure VMs, SQL Server, HANA databases, Azure PostgreSQL Database, File Shares, Blobs or Disks), enable Azure Backup and configure the desired frequency and retention period. For Azure VM, you can use Azure Policy to have backup automatically enabled using Azure Policy.

For resources or services not supported by Azure Backup, use the native backup capability provided by the resource or service. For example, Azure Key Vault provides a native backup capability.

For resources/services that are neither supported by Azure Backup nor have a native backup capability, evaluate your backup and disaster needs, and create your own mechanism as per your business requirements. For example:

  • If you use Azure Storage for data storage, enable blob versioning for your storage blobs which will allow you to preserve, retrieve, and restore every version of every object stored in your Azure Storage.
  • Service configuration settings can usually be exported to Azure Resource Manager templates.

Azure implementation and additional context:


AWS guidance: For AWS Backup supported resources (such as EC2, S3, EBS or RDS), enable AWS Backup and configure the desired frequency and retention period.

For resources/services not supported by AWS Backup, such as AWS KMS, enable the native backup feature as part of its resource creation.

For resources/services that are neither supported by AWS Backup nor have a native backup capability, evaluate your backup and disaster needs, and create your own mechanism as per your business requirements. For example:

  • If Amazon S3 is used for data storage, enable S3 versioning for your storage backet which will allow you to preserve, retrieve, and restore every version of every object stored in your S3 bucket.
  • Service configuration settings can usually be exported to CloudFormation templates.

AWS implementation and additional context:


GCP guidance: For Google Cloud Backup supported resources (such as Computer Engine, Cloud Storage, and Containers), enable GCP Backup and configure the desired frequency and retention period.

For resources or services not supported by Google Cloud Backup, use the native backup capability provided by the resource or service. For example, Secret Manager provides a native backup capability.

For resources/services that are neither supported by Google Cloud Backup nor have a native backup capability, evaluate your backup and disaster needs, and create your own mechanism as per your business requirements. For example:

  • If you use Google Storage for backup data storage, enable storage versioning for your object versioning which will allow you to preserve, retrieve, and restore every version of every object stored in your Google Storage.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

BR-2: Protect backup and recovery data

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
11.3 CP-6, CP-9 3.4

Security principle: Ensure backup data and operations are protected from data exfiltration, data compromise, ransomware/malware and malicious insiders. The security controls that should be applied include user and network access control, data encryption at-rest and in-transit.


Azure guidance: Use multi-factor-authentication and Azure RBAC to secure the critical Azure Backup operations (such as delete, change retention, updates to backup config). For Azure Backup supported resources, use Azure RBAC to segregate duties and enable fine grained access, and create private endpoints within your Azure Virtual Network to securely backup and restore data from your Recovery Services vaults.

For Azure Backup supported resources, backup data is automatically encrypted using Azure platform-managed keys with 256-bit AES encryption. You can also choose to encrypt the backups using a customer managed key. In this case, ensure the customer-managed key in the Azure Key Vault is also in the backup scope. If you use a customer-managed key, use soft delete and purge protection in Azure Key Vault to protect keys from accidental or malicious deletion. For on-premises backups using Azure Backup, encryption-at-rest is provided using the passphrase you provide.

Safeguard backup data from accidental or malicious deletion, such as ransomware attacks/attempts to encrypt or tamper backup data. For Azure Backup supported resources, enable soft delete to ensure recovery of items with no data loss for up to 14 days after an unauthorized deletion, and enable multifactor authentication using a PIN generated in the Azure portal. Also enable geo-redundant storage or cross-region restoration to ensure backup data is restorable when there is a disaster in primary region. You can also enable Zone-redundant Storage (ZRS) to ensure backups are restorable during zonal failures.

Note: If you use a resource's native backup feature or backup services other than Azure Backup, refer to the Microsoft Cloud Security Benchmark (and service baselines) to implement the above controls.

Azure implementation and additional context:


AWS guidance: Use AWS IAM access control to secure AWS Backup. This includes securing the AWS Backup service access and backup and restore points. Example controls include:

  • Use multi-factor authentication (MFA) for critical operations such as deletion of a backup/restore point.
  • Use Secure Sockets Layer (SSL)/Transport Layer Security (TLS) to communicate with AWS resources.
  • Use AWS KMS in conjunction with AWS Backup to encrypt the backup data either using customer-managed CMK or an AWS-managed CMK associated with the AWS Backup service.
  • Use AWS Backup Vault Lock for immutable storage of critical data.
  • Secure S3 buckets through access policy, disabling public access, enforcing data at-rest encryption, and versioning control.

AWS implementation and additional context:


GCP guidance: Use dedicated accounts with the strongest authentication to performing critical backup and recovery operations, such as delete, change retention, updates to backup config. This would safeguard backup data from accidental or malicious deletion, such as ransomware attacks/attempts to encrypt or tamper backup data.

For GCP Backup supported resources, use Google IAM with roles and permissions to segregate duties and enable fine grained access, and set up a private services access connection to VPC to securely backup and restore data from Backup/Recovery appliance.

Backup data is automatically encrypted by default at the platform level using Advanced Encryption Standard (AES) algorithm, AES-256.

Note: If you use a resource's native backup feature or backup services other than GCP Backup, you should refer to the respective guideline to implement the security controls. For example, you can also protect specific VM instances from deletion by setting the deletionProtection property on a VM instance resource.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

BR-3: Monitor backups

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
11.3 CP-9 N/A

Security principle: Ensure all business-critical protectable resources are compliant with the defined backup policy and standard.


Azure guidance: Monitor your Azure environment to ensure that all your critical resources are compliant from a backup perspective. Use Azure Policy for backup to audit and enforce such controls. For Azure Backup supported resources, Backup Center helps you centrally govern your backup estate.

Ensure critical backup operations (delete, change retention, updates to backup config) are monitored, audited, and have alerts in place. For Azure Backup supported resources, monitor overall backup health, get alerted to critical backup incidents, and audit triggered user actions on vaults.

Note: Where applicable, also use built-in policies (Azure Policy) to ensure that your Azure resources are configured for backup.

Azure implementation and additional context:


AWS guidance: AWS Backup works with other AWS tools to empower you to monitor its workloads. These tools include the following:

  • Use AWS Backup Audit Manager to monitor the backup operations to ensure the compliance.
  • Use CloudWatch and Amazon EventBridge to monitor AWS Backup processes.
  • Use CloudWatch to track metrics, create alarms, and view dashboards.
  • Use EventBridge to view and monitor AWS Backup events.
  • Use Amazon Simple Notification Service (Amazon SNS) to subscribe to AWS Backup-related topics such as backup, restore, and copy events.

AWS implementation and additional context:


GCP guidance: Monitor your Backup and Disaster Recovery environment to ensure that all your critical resources are compliant from a backup perspective. Use Organizational Policy for backup to audit and enforce such controls. For GCP Backup supported resources, Management Console helps you centrally govern your backup estate.

Ensure critical backup operations (delete, change retention, updates to backup config) are monitored, audited, and have alerts in place. For GCP Backup supported resources, monitor overall backup health, get alerted to critical backup incidents, and audit triggered user actions.

Note: Where applicable, also use built-in policies (Organizational Policy) to ensure that your Google resources are configured for backup.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

BR-4: Regularly test backup

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
11.5 CP-4, CP-9 N/A

Security principle: Periodically perform data recovery tests of your backup to verify that the backup configurations and availability of the backup data meets the recovery needs as per defined in the RTO (Recovery Time Objective) and RPO (Recovery Point Objective).


Azure guidance: Periodically perform data recovery tests of your backup to verify that the backup configurations and availability of the backup data meets the recovery needs as defined in the RTO and RPO.

You may need to define your backup recovery test strategy, including the test scope, frequency and method as performing the full recovery test each time can be difficult.

Azure implementation and additional context:


AWS guidance: Periodically perform data recovery tests of your backup to verify that the backup configurations and availability of the backup data meets the recovery needs as defined in the RTO and RPO.

You may need to define your backup recovery test strategy, including the test scope, frequency and method as performing the full recovery test each time can be difficult. AWS implementation and additional context:


GCP guidance: Periodically perform data recovery tests of your backup to verify that the backup configurations and availability of the backup data meets the recovery needs as per defined in the RTO and RPO.

You may need to define your backup recovery test strategy, including the test scope, frequency and method as performing the full recovery test each time can be difficult.

GCP implementation and additional context:


Customer security stakeholders (Learn more):