Backup and Disaster Recovery Services: What Business Continuity Coverage Should Include

Your backup dashboard says every job was completed successfully. But if a critical system went down tomorrow, could your team say how long it would take to restore, how much recent data might be lost, and who would lead the recovery?

That is the difference between having backups and being able to recover. Even if a business has current copies of its data, it could still experience long downtimes if a SaaS platform were excluded, application dependencies were not considered, recovery credentials were unavailable, or the restoration process had never been tested.

Backup and disaster recovery services should be integrated with data protection and a plan to get systems back up and running. The service needs to define what is included, which systems need to be restored first, what recovery targets are, and how responsibilities are split between internal teams, service providers, and software vendors.

This guide explains what complete coverage should include, how to assess whether an existing arrangement is sufficient, and what evidence a provider should be able to produce before the business has to rely on the plan.

Backup, Disaster Recovery and Business Continuity Are Different

Backup, disaster recovery and business continuity support the same goal, but they serve different purposes.

A backup is an additional copy of data or system information. It may have files, databases, virtual machines, application configurations and cloud data that can be restored if the original is deleted, damaged or compromised.

Disaster recovery is the technical procedures used to bring systems back to a usable state. It defines the restoration sequence, identifies dependencies and assigns leadership and management of recovery.

Business continuity is the disruption side of operations. It looks at how staff will communicate, serve clients, approve transactions and continue priority work until all systems are back up.

The NIST Cybersecurity Framework 2.0 includes recovery as one of its six core functions. Its guidance on recovery is oriented toward the implementation and sustaining of processes that allow for the timely restoration of systems affected by an incident.

If businesses cannot answer all three questions with confidence, a Disaster Recovery & Backup Assessment should be undertaken to review their current arrangements. The review is to look at the whole recovery process, not just one backup product or one storage location.

What Backup and Disaster Recovery Services Should Include

The best backup and disaster recovery services are built around the systems an organization needs to function. The scope should be documented, monitored and tested and not inferred from a software license or a general statement that everything is backed up.

A Complete Inventory of Systems and Data

At first, the provider needs to identify the technologies supporting the critical business functions. This is much more than just local servers and shared folders.

• Physical servers and virtual machines
• Databases and line-of-business applications
• File storage and employee collaboration systems
• Microsoft 365, Google Workspace and other SaaS applications
• Public, private and hybrid cloud workloads
• Identity and authentication systems
• Network and application configurations
• Encryption keys and recovery credentials

The inventory should describe what is protected, where the backup is saved, how long copies are kept, and what recovery method is used.

This is important as a business that has full backup coverage might be missing a small piece of the puzzle which is preventing the larger system from running. Restoring an application server is not useful if the database, the identity service or the required configuration is still not available.

Recovery Targets Based on Business Impact

The backup schedule should match business usage of each system. A single backup frequency and restoration approach may be too expensive for less important workloads and not enough for mission-critical ones.

• Which services must return first
• How long each service can remain unavailable
• How much recent data the business can afford to lose
• Which systems must be recovered together
• Whether temporary infrastructure is required
• What level of service can be maintained during recovery

These decisions should then drive the frequency of backups, backup storage, backup replication, failover planning and testing.

A provider that promises quick recovery without describing the systems involved, their dependencies, or the recovery environment available is making a guess, not a validated recovery commitment.

Separate Protection for Cloud and SaaS Data

When you shift a workload into the cloud, its location changes. It does not remove the need to review retention, recovery, and continuity requirements.

Business has to be clear on what their cloud and SaaS services are defending against. Ask about single files, deleted accounts, emails, shared data, application settings and long term storage.

• Which SaaS platforms are included
• What data can be restored
• How far back recovery can go
• Whether individual records and user accounts can be recovered
• How long a large restoration may take
• Whether the backup copy is stored separately from the production account

Without this documentation, the organization would find out too late that a platform’s default retention features do not meet its operational needs.

Secure, Offsite and Ransomware-Resilient Copies

Backup systems must be protected from the very events they are meant to help address.

The Canadian Centre for Cyber Security suggests organizations regularly back up critical business information to a secure location outside the organization, restrict access to it and ensure the systems for restoring data work. Its baseline controls link backup protection to recovery from ransomware, equipment failure, theft and natural disasters.

• Encrypted backup data
• Offsite copies
• Offline or immutable storage
• Separate administrative credentials
• Multifactor authentication
• Restricted backup-management access
• Segmentation between production and backup systems
• Protected recovery documentation

Not every account with access to production systems should be able to edit or remove backups. An attacker who gains access to privileged accounts may attempt to delete the associated backup files prior to encrypting the primary environment.

The Cyber Centre’s Ransomware Playbook notes that attackers could delete available backups and recommends to “check backup data for malware prior to restoration.

Backup security should be considered as part of a broader cybersecurity assessment. Recovery controls will not help if you have poor identity management, exposed admin accounts or poor network segmentation.

Want to learn more about this section of the recovery strategy? Check out Arcadion’s guide to backups vs ransomware.

Monitoring, Escalation and Useful Reporting

A managed service should be more than running scheduled backup jobs. It should detect failures, investigate recurring problems and verify that newly added systems are in the backup scope.

• How failed jobs are identified
• How quickly failures are investigated
• Who receives alerts
• When unresolved issues are escalated
• How storage capacity is monitored
• How changes to the environment are added to the service
• Which reports are provided to the client

A monthly report detailing percentages of successful jobs might look good but doesn’t say if all critical systems are covered. Useful reporting spots missed systems, failed restores, overdue tests, capacity issues, and outstanding recovery risks.

Tested Recovery Procedures

Testing proves whether backup data can support a usable recovery. A test should verify more than the presence of files in a repository.

• A single deleted file
• An employee account or mailbox
• A database
• A virtual machine
• A full business application
• Several dependent systems in the correct order
• A workload in alternate infrastructure

The Canadian Centre for Cyber Security’s IT recovery planning guidance notes that a recovery plan should identify critical data, applications, and processes, and then describe how the organization will recover the technology supporting its operations.

The test should document what the team restored, how long it took, what problems they encountered, and whether the result met the agreed recovery target. When tests fail or are delayed, the corrective actions assigned should be generated, not disappear in a technical rep

RTO and RPO: The Recovery Questions Leaders Need to Answer

The Recovery Time Objective and the Recovery Point Objective help to translate business requirements into technical requirements.

Recovery Time Objective, or RTO, is the length of time a system can remain in recovery before the outage begins to cause unacceptable operational harm.

Recovery Point Objective, or RPO, identifies the point in time to which data must be restored. It determines how much recent information may need to be recreated after an interruption.

Let us say a business gets customer orders throughout the day. If the order platform is restored with the data from the previous evening, staff may have to reenter a whole day’s worth of transactions. This lets the organization select a short RPO for that system.

Requirements for an archival records repository may be different. If it is not changed very often, and employees can work without it for a day, the organization may be willing to accept a longer RTO and RPO.

The focus should be on operational impact, not on assumptions about what the technology can do.

A Practical RTO and RPO Discussion

Different systems have different recovery methods. A critical platform can require frequent replication and prepared failover capacity. Once critical services have been restored, a low-priority archive can be retrieved from a regular backup.

Targets to document and test. A stated RTO of four hours is meaningless if the provider has never restored the whole system in that time.

Where Recovery Plans Commonly Break Down

An incomplete scope, out-of-date information, or unclear responsibility are often the cause of recovery problems rather than a complete lack of backup data.

Let’s take a business that uses a cloud accounting platform, Microsoft 365, an on-premises file server, and an industry application hosted by a third party. The file server is backed up by the managed IT provider. Microsoft 365 has default retention settings. The accounting vendor runs its own platform, and the industry application provider claims it has redundant infrastructure.

Each supplier appears to cover part of the environment. No one has documented how the complete business will recover after a serious disruption.

• Microsoft 365 data was never included in a separate backup
• The third-party application agreement does not cover client-level data restoration
• Recovery credentials are stored inside the unavailable network
• The file server can be restored, but the process takes longer than expected
• The latest recovery instructions refer to retired infrastructure
• No supplier has accepted responsibility for coordinating the full response

The business had several safeguards in place, but no tested recovery strategy in place.

What to Ask a Backup and Disaster Recovery Provider

A provider should be able to explain the service without resorting to vague assurances or software jargon.

Which Systems and Data Are Covered?

Ask for a present stock. It should include servers, cloud workloads, applications, SaaS platforms and key configurations. It should say what is not included.

“Everything is backed up” is not an acceptable answer.

How Were Our Recovery Targets Established?

The provider should be able to relate backup frequency and recovery design to the operational needs of the organization.

Ask who approved each RTO and RPO, when they were last reviewed and if testing has shown they are achievable.

What Happens When a Backup Job Fails?

Response must include: Monitoring, Investigation, Escalation, Client Communication Ask how long an issue can remain unresolved before it is escalated to a senior technical resource or the customer.

Dashboard notifications are not the same as active service management.

How Often Is Recovery Tested?

Ask what systems are tested, what type of restoration is done and are results documented. Restoring a single file doesn’t prove that an application, database or virtual environment can be brought back online.

Please send me the latest recovery-test report for one of your organization’s critical systems.

How Are Backups Protected From Ransomware?

The provider should discuss access controls, credential separation, encryption, immutable or offline copies and the process used to verify restored data is clean.

Security claims need to be in line with the actual backup architecture and not based on a product label.

Who Leads the Recovery?

The contract or recovery plan should state who can declare an incident, who can initiate the recovery process, who can contact vendors and who can report progress.

This is especially important when more than one organization is involved.

Internal system owners should validate that restored applications and data are appropriate for business use. The contracts in place will determine the final task. What is important is that the duties are validated before an incident.

For organizations using fully-managed IT services, the way recovery oversight is integrated into the ongoing management of infrastructure, cloud, and security needs to be reviewed.

What Evidence Indicates That the Service Works?

Useful evidence may include:

• Backup coverage reports
• Failed-job and incident records
• Restore-test results
• Recovery duration
• Unresolved risk items
• Changes made after testing
• Confirmation that new systems were added to scope

They should be able to show when a critical system was last restored and whether the result met its recovery target.

When Should Recovery Coverage Be Reassessed?

Backup and recovery arrangements should be reviewed after any meaningful change to the business or its technology.

• Adding a major cloud or SaaS application
• Moving offices or data centres
• Replacing servers or network infrastructure
• Changing managed IT, cloud or software providers
• Acquiring another company
• Opening a new location
• Introducing new contractual or regulatory obligations
• Experiencing a failed restore
• Responding to a ransomware or other cyber incident
• Adding enough users or data to affect recovery time

Recovery plans should change with the environment. A process written before a cloud migration or system replacement may no longer reflect the technology employees use.

Reach Out to Arcadion to Review Your Recovery Readiness

A reliable backup and disaster recovery service should tell the business what is protected, how recovery will go, who is responsible, and whether the process has been proven through testing.

Without those answers, the organization may have backup copies, but no complete recovery strategy.

Arcadion enables organizations to evaluate the extent of recovery coverage in infrastructure, cloud, and SaaS environments. This review looks at recovery objectives, backup architecture, documentation, testing, and ransomware protections and then identifies the gaps that need to be addressed.

Review your recovery readiness with Arcadion before a disruption places the current strategy under pressure.