A successful backup report can confirm that information was copied.
It does not confirm that the organization can restore the correct information within an acceptable amount of time, using the people, credentials and documentation that would be available during an incident.
That difference matters most when the original system is unavailable.
The main point
A backup is not complete until recovery has been tested.
CISA recommends maintaining offline, encrypted backups of critical information and regularly testing their availability and integrity in a disaster-recovery scenario.
CISA’s Cybersecurity Performance Goals call for recurring backup and recovery testing at least once a year. Annual testing should be treated as a minimum baseline, not a universal schedule.
Critical systems and rapidly changing information may require more frequent testing.
Backup, synchronization and archive are different
Synchronization
A synchronization service makes the same files available across devices or locations.
It may also synchronize:
- Deletion
- Corruption
- Unwanted changes
- Encrypted files
- Mistakes
Synchronization can support productivity, but it should not automatically be treated as an independent backup.
Archive
An archive preserves information for long-term retention.
It may be designed for compliance, historical records or infrequently accessed information. It may not be designed to restore an active system quickly.
Backup
A backup is a protected copy intended for recovery.
A complete information-management plan may use synchronization, archives and backups. One should not be assumed to replace the others.
Define what recovery must accomplish
Before selecting or evaluating a backup system, answer two plain-language questions.
How much recent work could the organization afford to lose?
This answer helps define how frequently information must be backed up.
The formal term is the recovery point objective, or RPO.
How long could the organization operate without the system?
This answer helps define how quickly recovery must occur.
The formal term is the recovery time objective, or RTO.
Different systems may need different targets.
Payroll, client records, email, shared files, cloud applications, servers and archived documents do not necessarily need the same backup frequency or recovery speed.
Test more than one file
File recovery
Restore representative files and confirm that they:
- Open correctly
- Contain the expected information
- Come from the expected date
- Retain required permissions or metadata
Folder and account recovery
Test whether a larger group of information can be restored to the correct location and made available to the correct people.
This may include a deleted user account, mailbox, shared folder or project directory.
System recovery
For servers, applications and critical infrastructure, confirm that configurations, databases, services and dependencies can be restored together.
Restoring files alone may not restore a working business system.
Cloud-service recovery
Review what the cloud provider retains and what the organization can restore independently.
Test recovery for supported items such as:
- Deleted files
- Previous versions
- Mailboxes
- User accounts
- Application information
- Shared workspaces
Do not assume that a cloud subscription includes every recovery capability the business expects.
Recovery access
Confirm that approved people can reach the backup during an outage.
Recovery should not depend on:
- One unavailable administrator
- One computer
- One security key
- Credentials stored only inside the failed environment
- Documentation stored on the unavailable system
Keep recovery instructions and approved emergency access available through a protected, independent method.
Documentation and timing
Record:
- The steps performed
- The people involved
- The credentials or approvals required
- The systems and dependencies restored
- The actual recovery time
- Any errors or missing information
A test that succeeds only because one technician remembers an undocumented step is not a repeatable recovery process.
Use layered protection
Backup copies should not all be exposed to the same:
- Account
- Device
- Network
- Administrator credentials
- Physical location
The appropriate combination of encryption, separation, retention, monitoring and offline or otherwise isolated copies depends on the organization’s risks and recovery requirements.
The goal is to prevent one compromised account, failed device or ransomware event from reaching every recovery copy.
Review backup alerts without overtrusting them
Backup alerts and dashboards are useful. They are not proof that recovery will work.
A green status may confirm that a scheduled task completed. It may not confirm:
- The right information was included
- The copy is usable
- Credentials are available
- Retention meets the requirement
- A complete system can be restored
- Recovery will finish within the required time
Schedule test restores, document the results, correct failures and repeat testing after major system changes.
Include business decision-makers
Recovery may require more than IT.
A realistic test may involve:
- Leadership
- Operations
- Finance
- Legal or compliance
- Communications
- Vendors
- Department owners
These participants may need to decide which systems return first, how employees continue working and what clients or partners should be told.
What to avoid
Do not:
- Keep every backup permanently connected to the systems it protects.
- Assume synchronized files are a complete backup.
- Assume cloud information is protected in the expected way.
- Depend on one person to understand recovery.
- Store every recovery credential inside the protected environment.
- Wait for an emergency to test access or restoration.
- Treat a successful backup alert as proof of recovery.
Ransomware and compromised administrator accounts may reach any backup that remains accessible through the same environment.
When to involve IT
Involve IT when:
- Defining recovery priorities
- Selecting backup methods
- Protecting recovery credentials
- Testing systems and applications
- Documenting dependencies
- Reviewing cloud-service coverage
- Correcting failed tests
Professional planning is essential when downtime could affect safety, regulated information, financial operations or essential client services.
The purpose of backup is not to create another copy. It is to restore the organization when the original is no longer available.
Not sure whether your backups can support a real recovery? Book a consultation.
