Businesses often think about disaster recovery only after something goes wrong.
A ransomware attack. A failed server. A corrupted database. An application outage. A regional disruption.
But business continuity is much broader than responding to a single type of incident.
At BPS, we believe organizations should start with a more fundamental question:
If a critical workload becomes unavailable tomorrow, how quickly can the business recover, and how confident are we that the recovery process will actually work?
Having a backup is not the same as having a business continuity strategy.
A backup gives you a copy of data.
A resilient Business Continuity and Disaster Recovery, or BCDR, strategy defines how the organization protects workloads, limits data loss, restores critical services, validates recovery, and continues operating when disruption occurs.
Microsoft Azure provides powerful capabilities for this through services including Azure Backup and Azure Site Recovery, but technology alone is only part of the solution.
The real objective is to create a repeatable and tested recovery capability.
Business Continuity Starts With Business Impact
One of the most common mistakes in disaster recovery planning is beginning with technology.
For example:
“We need to replicate all our virtual machines.”
The better starting point is:
“Which business services need to be recovered first, and how long can the business operate without them?”
Not all workloads have the same importance.
Consider an organization running:
- ERP
- Customer portal
- Active Directory
- File servers
- SQL databases
- Internal applications
- Development environments
- Reporting systems
If these systems experience an outage simultaneously, recovering them alphabetically or according to VM size would make little sense.
Recovery priorities should reflect business dependency and business impact.
This requires organizations to classify workloads and establish two critical objectives.
Recovery Time Objective (RTO)
How quickly must the service be restored?
If an ERP application has an RTO of four hours, for example, the recovery architecture and operational procedure need to support restoration within that requirement.
Recovery Point Objective (RPO)
How much data can the organization afford to lose?
A workload with an RPO of one hour requires a substantially different protection strategy from an archive system where losing the previous 24 hours of changes might be acceptable.
Microsoft’s current ransomware-resilient backup architecture similarly recommends setting backup schedules according to the required RPO rather than basing them only on retention or compliance requirements. Design a Ransomware-Resilient Backup Architecture by Using Azure Backup
The first step in BCDR should therefore not be configuring a vault.
It should be understanding the business.
Backup and Disaster Recovery Solve Different Problems
Backup and disaster recovery are sometimes treated as interchangeable.
They are not.
Backup
Backup primarily provides recovery points that enable organizations to restore data or workloads following scenarios such as:
- Accidental deletion
- Data corruption
- Ransomware
- Administrative mistakes
- Application problems
- Infrastructure failure
Azure Backup provides centralized protection for supported Azure and hybrid workloads.
Disaster Recovery
Disaster recovery focuses on restoring the availability of a service or workload, potentially in another location.
Azure Site Recovery can replicate supported workloads to a secondary location and orchestrate failover and recovery.
An effective BCDR design may use both.
A customer could, for example, use Azure Site Recovery to achieve rapid recovery of an application while retaining Azure Backup recovery points for longer-term data recovery.
The important question is not:
“Should we use backup or disaster recovery?”
Instead ask:
“What combination of recovery capabilities is required to meet this application’s RPO, RTO and business requirements?”
Ransomware Changed the Backup Conversation
Historically, organizations often thought about backup primarily as protection against infrastructure failure or accidental deletion.
Ransomware changed that assumption.
Attackers may attempt to compromise not only production workloads but also the recovery mechanisms organizations depend on.
Microsoft’s Azure Architecture Center specifically warns that ransomware attacks can target both production and backup systems. Microsoft’s ransomware-resilient architecture therefore emphasizes recovery data that cannot be deleted or modified, can be recovered independently of production, crosses administrative and regional boundaries where appropriate, and can be regularly tested. Design a Ransomware-Resilient Backup Architecture by Using Azure Backup.
This leads to an important principle:
Your recovery platform must be designed under the assumption that the production environment or a privileged administrative identity could become compromised.
That changes how backup security should be approached.
Protect the Recovery Platform, Not Just the Workload
A resilient Azure backup strategy involves several layers of protection.
1. Isolate Backup Data
Azure Backup stores protected data inside Azure backup infrastructure using resources such as Recovery Services vaults and Backup vaults.
Microsoft notes that applications and guests don’t have direct access to the backups stored within these vaults, helping isolate backup data from production workloads. FAQ – Protect backups from Ransomware with Azure Backup
This isolation becomes particularly valuable when the production workload itself is compromised.
2. Use Role-Based Access Control
Not every administrator should have unrestricted control over backups.
Azure Role-Based Access Control, or Azure RBAC, allows organizations to separate responsibilities and grant administrators only the permissions required for their jobs.
Microsoft also recommends using Microsoft Entra Privileged Identity Management to provide time-limited and approval-based activation of privileged access for backup administration. FAQ – Protect backups from Ransomware with Azure Backup.
This follows an important security principle:
Compromising one administrator account should not automatically give an attacker unrestricted control over every layer of the recovery environment.
3. Protect Critical Backup Operations
Particular care should be taken with operations capable of weakening or deleting recovery protection.
Azure Backup supports Multi-user authorization (MUA) using Resource Guard to add authorization requirements around critical backup operations. Microsoft recommends MUA as protection against scenarios involving a rogue or compromised administrator. FAQ – Protect backups from Ransomware with Azure Backup.
This changes the security model from:
One administrator can make a destructive change
to a model where:
Critical operations can require authorization through an additional security boundary.
For highly sensitive workloads, that separation can be extremely important.
Immutability Should Be Part of the Conversation
One of the most important developments in modern backup security is immutability.
An immutable recovery point is protected against operations that would otherwise result in its loss.
Azure Backup supports an Immutable Vault capability designed to block operations that could cause the loss of recovery points.
Once the vault’s immutability setting is locked, Microsoft states that the setting becomes irreversible and uses WORM, or Write Once Read Many, storage where supported to prevent malicious actors from disabling immutability and deleting backups. Concept of Immutable Vault for Azure Backup.
This capability should not simply be enabled without planning, however.
Microsoft explicitly recommends understanding the implications before locking immutability because the lock is irreversible. Organizations should verify that backup policies, retention requirements and compliance needs are correct before applying the lock. Manage Azure Backup Immutable Vault Operations.
That illustrates a broader principle:
Security controls are strongest when they are incorporated into the architecture and operational processes, not enabled as an afterthought.
Soft Delete Provides Another Safety Net
Accidental and malicious deletion deserves separate consideration.
Azure Backup supports soft delete, which gives organizations an opportunity to recover deleted backup data before permanent deletion.
Microsoft’s current secure-by-default guidance states that the standard soft-delete retention period is 14 days, and it can be extended up to 180 days. Secure by Default with Soft Delete for Azure Backup.
This can protect against situations where:
- An administrator accidentally deletes a protected item
- Backup protection is incorrectly stopped
- A malicious actor attempts to delete recovery data
However, soft delete should be regarded as one layer of a defense-in-depth strategy.
A mature design combines appropriate identity controls, RBAC, privileged access management, authorization controls, immutability, monitoring and tested recovery processes.
A Backup That Has Never Been Restored Is Only an Assumption
Perhaps the most important part of a BCDR strategy is also one of the easiest to overlook:
Testing.
A dashboard can indicate that a backup job completed successfully.
That does not necessarily prove that:
- The application can be restored correctly
- Dependencies are understood
- Administrators know the procedure
- Networking will function after recovery
- DNS changes are documented
- Authentication will work
- Recovery meets the required RTO
- The recovered application is usable
- The business knows what to do following failover
This is why BPS recommends moving from backup monitoring toward recovery validation.
Microsoft also emphasizes regular recovery testing as a characteristic of ransomware-resilient architecture. Design a Ransomware-Resilient Backup Architecture by Using Azure Backup.
A technically successful backup should therefore be considered only the beginning.
DR Testing Should Be a Routine Operational Process
Disaster recovery should not be a document stored somewhere and reviewed only during an audit.
Organizations should establish scheduled DR exercises.
A typical exercise might include:
Step 1: Select the workload
Choose a critical application or representative workload.
Step 2: Define the scenario
For example:
Primary application infrastructure is unavailable and cannot be recovered.
Step 3: Execute the recovery procedure
Perform test failover or restore procedures according to the documented recovery plan.
Step 4: Validate the application
Confirm:
- VM/application availability
- Database connectivity
- Authentication
- Network connectivity
- Application functionality
- Data consistency
- Security controls
Step 5: Measure recovery
Compare the actual recovery time and recovery point achieved against the required RTO and RPO.
Step 6: Record gaps
Capture any:
- Manual dependencies
- Configuration errors
- Missing permissions
- Documentation problems
- Unexpected delays
Step 7: Improve the recovery plan
Update the runbook and architecture based on lessons learned.
This creates a continual improvement cycle:
Protect → Monitor → Test → Recover → Review → Improve
That is significantly more mature than simply checking whether last night’s backup completed.
Regional Resilience Requires Business Context
Another common assumption is:
“If the workload is in Azure, it is automatically disaster-proof.”
Cloud platforms provide powerful resilience capabilities, but the customer architecture still matters.
Workload resilience depends on decisions involving:
- Azure regions
- Availability Zones
- Backup redundancy
- Replication
- Application architecture
- Database architecture
- Networking
- Identity dependencies
- DNS
- Recovery procedures
For highly critical workloads, organizations might also require recovery data across different administrative or regional boundaries.
Microsoft’s ransomware-resilient reference architecture, for example, describes a pattern where critical recovery data can use independent immutable copies across different subscriptions and regions. Design a Ransomware-Resilient Backup Architecture by Using Azure Backup.
Not every workload requires that design.
The level of resilience should be determined by business impact, regulatory requirements, data residency requirements, RTO, RPO and acceptable cost.
Business Continuity Is Also About Cost
Maximum resilience has a cost.
Replicating every workload continuously and retaining large numbers of recovery points indefinitely would rarely be commercially sensible.
This makes workload classification extremely important.
Consider a simple tiering model:
| Workload Tier | Example | Recovery expectation |
| Tier 1 | ERP, transactional databases, customer-facing platforms | Highest availability and aggressive RPO/RTO |
| Tier 2 | Business applications, important internal services | Moderate recovery targets |
| Tier 3 | Development, test and lower-criticality workloads | Longer recovery targets may be acceptable |
The actual targets should always come from the customer’s business-impact assessment.
This allows investment to be concentrated where downtime or data loss creates the greatest impact.
BCDR is therefore both a technology decision and a business risk decision.
The BPS Approach to Azure Business Continuity
At BPS, we believe effective BCDR should be managed as a lifecycle.
Assess
Identify critical workloads, dependencies, business requirements and current recovery capabilities.
Define meaningful RPO and RTO targets.
Design
Determine the appropriate combination of:
- Azure Backup
- Azure Site Recovery
- Availability Zones
- Regional architecture
- Backup retention
- Immutability
- Identity and access controls
- Monitoring and alerting
Protect
Implement the agreed architecture and establish backup, replication and security policies.
Monitor
Continuously monitor protection status, failed jobs, security conditions and operational exceptions.
Test
Perform planned recovery and DR exercises instead of waiting for a real incident to validate the architecture.
Improve
Review test results, operational incidents, changing business requirements and Azure capabilities, then improve the environment accordingly.
This transforms BCDR from an infrastructure configuration into an ongoing managed resilience practice.
Seven Questions to Ask About Your Current BCDR Strategy
Organizations assessing their Azure resilience should start with these questions:
1. Which applications are truly business-critical?
If everything is classified as critical, nothing is prioritized.
2. What are the agreed RPO and RTO for each critical workload?
Targets should come from business requirements rather than infrastructure assumptions.
3. Can administrators delete our backup recovery points?
Understand the controls around privileged identities, RBAC, Resource Guard, MUA and immutable vaults.
4. What happens if privileged credentials are compromised?
The recovery design should consider attacks against administrators as well as attacks against servers.
5. When did we last restore a production workload from backup?
Successful backup jobs do not replace recovery testing.
6. When did we last perform a DR test?
Test failover and recovery procedures regularly and record the actual recovery results.
7. Does the business know what happens during a disaster?
Technology teams, application owners and business stakeholders should understand recovery priorities and responsibilities.
If these questions cannot be answered confidently, the organization may have backups, but it may not yet have a mature business continuity strategy.
The Bottom Line
Ransomware attracts attention because of the potential severity of an attack.
But resilient organizations prepare for more than ransomware.
They prepare for:
Infrastructure failure.
Human error.
Data corruption.
Application failure.
Security incidents.
Regional disruption.
And scenarios they did not predict.
The objective should therefore not simply be to back up systems.
It should be to create a secure, measurable and regularly tested capability to recover the business.
Microsoft Azure provides powerful building blocks through Azure Backup, Azure Site Recovery, immutable vaults, soft delete, Resource Guard and other security and resilience capabilities.
But the technology delivers its greatest value when it is combined with clear recovery objectives, workload prioritization, operational monitoring and regular testing.
At BPS, we believe business continuity is not an insurance policy that sits unused until disaster strikes. It is an operational capability that should be continuously monitored, tested and improved.
Because when a real incident occurs, the most important question is no longer:
“Do we have a backup?”
It becomes:
“Can we recover the business?”
