Using Azure Site Recovery to Replicate VMs for Disaster Recovery

ISO 27001 control 7.5 requires the organization to design and implement protection against physical and environmental threats, including natural disasters that can make infrastructure unavailable. You can use azure site recovery replicate vms disaster recovery capabilities to maintain recoverable copies of critical Azure virtual machines in a separate Azure region, test their recovery, and retain evidence that the recovery design operates as intended.

How do azure site recovery replicate vms disaster recovery settings support ISO 27001 control 7.5?

For a mid-market firm, the practical objective is not merely to turn on replication for every server. The compliance outcome is to identify in-scope workloads, define an acceptable recovery point objective (RPO) and recovery time objective (RTO), replicate those workloads to a geographically separate Azure region, and prove that the organization can recover them following a regional outage or other physical disruption.

Azure Site Recovery (ASR) supports this outcome by continuously replicating managed disks for Azure virtual machines to a selected target region. It also creates recovery points, supports application-consistent snapshots, and provides test failover and recovery-plan functions. Record the approved RPO, RTO, application dependencies, target region, and recovery owner in the organization’s disaster recovery procedure before enabling replication.

How do you configure Azure Site Recovery for Azure virtual machines?

1. Confirm the source and recovery architecture. In the Azure portal, open Virtual machines and identify the production VMs covered by the ISO 27001 scope. Select a recovery region that is sufficiently separated from the source region and can meet business, contractual, data-residency, and customer commitments.

   Create or confirm the target resources before replication: a target resource group, target virtual network, appropriate subnets, network security groups, DNS approach, and sufficient regional quota for compute and managed disks. Do not use the production virtual network as the test-failover network.

2. Create a Recovery Services vault. Go to Azure portal > Recovery Services vaults > + Create. Select the production subscription and a resource group used for recovery services, then enter a controlled name such as rsv-dr-eastus2-prod. Select the vault region accepted by the Azure Site Recovery deployment wizard and document both the vault location and recovery target region in the DR design.

   After deployment, open the vault and go to Settings > Properties. Record the vault name, resource ID, subscription, and location in the asset inventory. Limit access using Azure role-based access control; recovery administrators need operational access, while compliance personnel normally need read-only access.

3. Create or review the replication policy. In the Recovery Services vault, go to Site Recovery infrastructure > Replication policies. Select the Azure-to-Azure policy used by the workload, or select + Replication policy where the portal offers that option.

   Set policy values approved by the system owner. A realistic baseline for a business-critical line-of-business VM is shown below. These values must be adjusted when the documented RPO requires more frequent recovery points or the application has higher write volume.

   Azure Site Recovery setting	Example value	Compliance purpose
   RPO threshold	60 minutes	Creates an alert threshold when replication lag exceeds the approved recovery objective.
   Recovery point retention	24 hours	Provides multiple recovery points if the newest replica is unsuitable.
   App-consistent snapshot frequency	4 hours	Creates recoverable points suitable for supported application workloads.
   Multi-VM consistency	Enable only for dependent application tiers that require coordinated recovery	Helps preserve consistency for tightly coupled workloads, while avoiding unnecessary performance impact elsewhere.

4. Enable replication for the selected VMs. In the vault, go to Site Recovery > Enable replication. Under Source, select the source Azure region and subscription containing the production VMs. Under Virtual machines, select only the approved in-scope VMs.

   Under Replication settings, select the Target location, Target subscription, Target resource group, and Target virtual network. Choose the approved replication policy. For each disk, confirm the target managed disk type, such as Premium SSD for transaction-heavy systems or Standard SSD for lower-priority application servers. Select Enable replication to start initial synchronization.

   If Azure requests a cache storage account, use an approved storage account in the source region with access limited to the recovery service. Document the storage account name and the data classification of the replicated disks.

5. Configure the recovered VM settings. After replication begins, go to Site Recovery > Replicated items, select the VM, and open Compute and Network. Confirm the target VM size, availability options, target subnet, private IP addressing, public-IP requirement, network security group, and availability zone settings.

   For most production workloads, do not assign a public IP address by default. Recovery access should use the organization’s approved VPN, ExpressRoute, jump host, or privileged access process. This prevents an emergency failover from creating an unintended internet-exposed server.

6. Create a recovery plan for dependent systems. Go to Site Recovery > Recovery plans > + Recovery plan. Select the source and target regions, choose Azure virtual machines, and add VMs in recovery order. For example, place database servers in the first group, application servers in the second group, and web servers in the third group.

   Add documented manual actions for steps Azure cannot perform automatically, such as updating private DNS, enabling an application maintenance page, rotating credentials, validating payment integrations, or informing business owners. This turns Azure Site Recovery replication into an executable recovery procedure rather than an isolated infrastructure feature.

How can you verify that Azure Site Recovery replication is working?

Verification should show both that the VM is protected and that it can be started safely in the recovery environment. In the Recovery Services vault, go to Site Recovery > Replicated items and confirm each in-scope VM displays Replication health: Healthy and Protection state: Protected. Open the VM and review Latest recovery points, replication lag, target region, and the policy assigned.

At least quarterly, or at the frequency established by the risk assessment, perform a non-production test. Select the replicated VM or recovery plan, then choose Test failover. Select Latest app-consistent when it is available, and select an isolated test virtual network. Validate that the VM starts, required disks are attached, the operating system is reachable, and the application passes its documented health checks.

When validation is complete, select Cleanup test failover from the replicated item or recovery plan. Enter a meaningful note such as Q3 FY26 ISO 27001 DR exercise completed; application owner approved. Cleanup is important because it removes temporary test resources while preserving the test job history.

What evidence should a compliance officer capture for an assessor?

Store the evidence package with the control record for ISO 27001 control 7.5, including the test date, participating staff, test scope, actual recovery time, recovery-point age, exceptions, remediation owner, and target completion date. A screenshot without a date, system identity, or reviewer conclusion is weak evidence; pair portal captures with the signed DR test record.

Where does Azure Site Recovery fall short of ISO 27001 control 7.5?

Azure Site Recovery reduces the availability impact of a regional infrastructure loss, but it does not itself protect physical premises, prevent flooding or fire at an office, provide alternate work locations, or guarantee that every application dependency will recover. It is also not a substitute for backup: replication can reproduce accidental deletion, ransomware-encrypted data, or application-level corruption unless a suitable earlier recovery point exists.

Close these gaps with a documented business continuity and disaster recovery plan, Azure Backup with retention appropriate to the risk, tested restore procedures, supplier assurance for Azure-hosted services, physical security controls for any on-premises infrastructure, and dependency plans for DNS, identity, telecommunications, SaaS providers, and third-party integrations. The organization should also review target-region capacity, Azure subscription quotas, privileged access during an emergency, and communications procedures before treating the Azure Site Recovery DR configuration as sufficient evidence of resilience.

Schedule a recovery-plan test for the highest-impact replicated application and add its results, exceptions, and remediation actions to your next ISO 27001 control review.