Quick Answer: Test Critical Backups Quarterly and the Full Recovery Plan Annually
A financial firm should test the recovery of critical data and systems at least quarterly and conduct a broader disaster-recovery exercise at least once per year. Backup jobs should be monitored every day, failures should be investigated promptly, and important systems should have documented recovery time and recovery point objectives.
For a 25–50 employee financial organization, a practical schedule is:
- Daily: Review backup failures and security alerts
- Monthly: Confirm backup coverage, storage capacity, and protected devices
- Quarterly: Restore representative files, email, databases, and critical systems
- Annually: Conduct a full disaster-recovery or business-continuity exercise
- After major changes: Retest affected systems, applications, or infrastructure
A backup is not proven until data has been restored successfully. Financial firms should combine protected backups with documented recovery procedures, cyber incident planning, and business continuity services.
The 5-Part Backup and Recovery Testing Framework
| Stage | Primary objective | Recommended frequency |
|---|---|---|
| 1. Verify coverage | Confirm that every critical system and data source is protected | Monthly |
| 2. Restore data | Prove that files, email, and application data can be recovered | Quarterly |
| 3. Recover systems | Test whether servers and critical applications can be restored | Quarterly or semiannually |
| 4. Exercise the plan | Test responsibilities, communications, priorities, and decisions | Annually |
| 5. Improve and document | Correct gaps and update procedures after each test | After every test |
1. Verify That Every Critical System Is Actually Backed Up
Backup failures are not always caused by broken software. Important systems may be excluded because they were added after the original backup plan was created, an employee stored data in an unapproved location, or a cloud application was assumed to include complete recovery.
A monthly backup review should confirm protection for:
- File servers and shared drives
- Microsoft 365 email
- OneDrive, SharePoint, and Teams data
- Accounting and tax applications
- Portfolio or wealth-management platforms
- Document-management systems
- Databases
- Virtual servers
- Critical employee laptops
- Cloud-hosted business applications
- Network and firewall configurations
- Written policies and compliance documentation
The review should compare the current technology inventory against the backup inventory. Any system containing business-critical or sensitive information should have a documented protection and recovery decision.
Ask these five coverage questions
- What business systems would stop operations if they became unavailable?
- Where does each department store important information?
- Which cloud applications are not covered by the provider’s standard backup?
- What data exists only on employee computers or mobile devices?
- Which new systems have been added since the last backup review?
2. Test File, Email, and Application Data Restores Quarterly
A quarterly restore test should recover representative information from each important backup source. The test should prove that the firm can locate the correct version, restore it within an acceptable timeframe, and confirm that the recovered data is usable.
Quarterly testing may include:
- A recently deleted file
- An older version of a modified document
- A mailbox message or folder
- A OneDrive or SharePoint file
- A database record or application export
- A complete employee folder
- A file stored before the most recent backup cycle
- Data belonging to a departed employee
Do not always test the same file or system. Rotate the sample so that the firm validates different backup sources throughout the year.
Document the result
Each restore test should record:
- The date of the test
- The system or data source tested
- The requested recovery point
- The person performing the test
- The time required to locate and restore the data
- Whether the restored information opened correctly
- Any errors or missing data
- Required corrective actions
3. Test the Recovery of Critical Servers and Applications
Restoring a single document is different from recovering an entire server, application, or business process. Financial firms should periodically test whether critical systems can be rebuilt or activated in an alternate environment.
System-level tests may include:
- Recovering a virtual server
- Starting a backup copy in an isolated environment
- Restoring an application database
- Validating user access after recovery
- Confirming that integrations still function
- Testing secure remote access
- Verifying application vendor support
- Measuring the time required to resume operations
High-priority systems should be tested quarterly or semiannually based on the firm’s risk, recovery requirements, and technical complexity. Less critical systems may be tested annually.
Do not test recovered systems on the production network without a plan
A recovered server can create conflicts if it is connected to the live environment incorrectly. System tests should be performed in an isolated environment or according to a documented procedure that prevents duplicate systems, data corruption, or unintended access.
4. Conduct an Annual Disaster-Recovery Exercise
An annual exercise tests more than technology. It evaluates how leadership, employees, IT providers, cybersecurity specialists, vendors, insurers, legal counsel, and other parties respond to a disruption.
A useful exercise can be completed as a tabletop discussion or as a controlled technical simulation. The scenario should be realistic enough to force participants to make decisions.
Example scenarios
- Ransomware encrypts a server and several employee computers
- Microsoft 365 email is unavailable during a critical deadline
- A failed server makes a financial application inaccessible
- A compromised administrator account alters cloud data
- A power or internet outage closes the office for two days
- A cloud vendor experiences an extended outage
- A fire, flood, or other local event makes the office unavailable
- A key employee is unavailable during a recovery event
The exercise should answer seven questions
- Who declares the incident?
- Who has authority to shut down systems or isolate devices?
- Which systems are restored first?
- How will employees continue working?
- How will clients and vendors be contacted?
- When should legal counsel, insurance carriers, or regulators be involved?
- How will decisions and recovery actions be documented?
5. Correct Gaps and Update the Recovery Plan
A recovery test provides value only when the organization acts on the findings. Every test should result in a short improvement plan with assigned owners and deadlines.
Common findings include:
- A system was not included in the backup
- The requested recovery point was unavailable
- A restore took longer than expected
- Credentials or encryption keys were missing
- Application dependencies were undocumented
- Vendor contact information was outdated
- Employees did not know where to report the problem
- The recovery order did not match business priorities
- Cloud data was assumed to be protected but was not
- The restored system could not communicate with another application
Update the recovery documentation immediately after the test while the findings are still clear. Record what changed, who approved it, and when the corrected process will be retested.
What Are RTO and RPO?
Two numbers help leadership define acceptable recovery performance:
- Recovery Time Objective, or RTO: The maximum acceptable time a system can remain unavailable.
- Recovery Point Objective, or RPO: The maximum acceptable amount of recent data that can be lost, measured in time.
| Example system | Example RTO | Example RPO |
|---|---|---|
| Microsoft 365 email | 2–4 hours | 1–4 hours |
| Critical financial application | 2–8 hours | 15 minutes–4 hours |
| Shared document storage | 4–8 hours | 1–4 hours |
| Archived records | 24–48 hours | 24 hours |
| Noncritical internal application | 24–72 hours | 24 hours |
These are examples rather than universal requirements. Each firm should set objectives based on operational impact, client obligations, regulatory expectations, cost, and risk tolerance.
Why the difference matters
A firm may require an application to return within four hours but accept losing up to one hour of recent data. That would produce an RTO of four hours and an RPO of one hour. Backup frequency, replication, infrastructure, and staffing must be designed to support both objectives.
How Frequently Should Each Backup Activity Occur?
| Activity | Suggested frequency | Purpose |
|---|---|---|
| Automated backup jobs | Daily or more frequently | Protect recent data according to the required RPO |
| Backup failure review | Daily | Identify and correct failed or incomplete jobs |
| Backup inventory review | Monthly | Confirm that new systems and data sources are protected |
| File and email restore test | Quarterly | Prove that representative data can be recovered |
| Critical server recovery test | Quarterly or semiannually | Validate recovery of essential infrastructure |
| Full recovery exercise | Annually | Test technology, people, communication, and decisions |
| Plan review | Quarterly and after major changes | Keep procedures and contacts accurate |
| Post-incident test | After significant changes or failures | Confirm that remediation worked |
What Should a Financial Firm Back Up?
A backup strategy should protect the information and configurations required to resume business operations. That often includes more than servers.
Business data
- Client documents
- Financial records
- Tax files
- Contracts
- Payroll information
- Internal procedures
- Compliance documentation
- Employee records
Cloud data
- Microsoft 365 email
- OneDrive
- SharePoint
- Teams-related files
- Cloud application exports
- Hosted databases
Systems and configurations
- Servers and virtual machines
- Application databases
- Firewall configurations
- Network device configurations
- Security policies
- Encryption keys
- Administrator documentation
Some cloud vendors protect their infrastructure but place responsibility for deleted, altered, or retained customer data on the client. Review each vendor’s recovery capabilities and contract rather than assuming protection is included.
Use the 3-2-1 Backup Principle
A commonly used backup principle is to maintain:
- 3 copies of important data
- 2 different storage types or platforms
- 1 copy isolated from the primary environment
The isolated copy is especially important for ransomware resilience. Attackers may attempt to encrypt or delete connected backups after compromising administrator credentials.
Modern environments may extend this concept by adding an immutable or offline copy and requiring verification that backup data is free from errors. The exact architecture should reflect the firm’s systems, risk, and recovery objectives.
How Should Backups Be Protected From Ransomware?
Backup systems are valuable targets because disabling recovery increases the attacker’s leverage. Protection should include:
- Separate backup administrator accounts
- Multi-factor authentication
- Unique credentials not used elsewhere
- Restricted network access
- Encrypted backup data
- Immutable or protected retention where appropriate
- Alerts for deletion or configuration changes
- Independent monitoring
- Limited access for vendors and technicians
- Documented recovery credentials
The firm should verify that a compromised Microsoft 365 administrator or local server account cannot automatically delete every backup copy.
How Long Should a Financial Firm Retain Backups?
Retention requirements depend on business needs, legal obligations, contracts, regulatory requirements, storage costs, and the type of data involved. A practical backup schedule may include:
- Daily recovery points retained for several weeks
- Monthly recovery points retained for several months
- Annual or archival copies retained according to policy
Long retention is not always better. Retaining sensitive information longer than necessary can increase exposure, cost, and legal complexity. The firm should coordinate backup retention with its records-retention policy and qualified legal or compliance guidance.
What Evidence Should Be Saved After a Recovery Test?
Financial firms may need to demonstrate that backup and recovery procedures are operating. Preserve evidence such as:
- Backup job reports
- Failure and remediation records
- Restore-test results
- Screenshots or system logs showing successful recovery
- Recovery time measurements
- Test scenarios and participant lists
- Problems discovered
- Corrective-action plans
- Management review and approval
- Updated recovery procedures
Store this evidence securely and make it available for audits, insurance applications, client reviews, or internal risk assessments as appropriate.
Who Should Participate in an Annual Recovery Exercise?
The exercise should include more than the IT provider. Participants may include:
- Owners or executive leadership
- Operations management
- Internal IT personnel
- The managed IT provider
- Cybersecurity specialists
- Finance or accounting leadership
- Human resources
- Legal counsel
- Compliance personnel
- Insurance contacts
- Communications or client-service leaders
Not every participant must attend the entire technical test. Each person should understand the decisions, communications, and responsibilities relevant to their role.
Backup Testing Scorecard
| Requirement | Yes | No | Needs improvement |
|---|---|---|---|
| All critical systems are listed | |||
| Each system has an assigned RTO and RPO | |||
| Backup failures are reviewed daily | |||
| Microsoft 365 data is protected | |||
| An isolated or protected backup copy exists | |||
| Quarterly restore tests are documented | |||
| Critical servers have been recovered successfully | |||
| Recovery credentials are secured and available | |||
| An annual recovery exercise is completed | |||
| Test findings are assigned and corrected |
Any “No” response should be treated as a documented gap with an owner and target completion date.
Common Backup and Recovery Mistakes
- Relying on successful job notifications. A completed backup does not prove that recovery will work.
- Testing only individual files. The firm may still be unable to restore an application or server.
- Ignoring Microsoft 365 and cloud data. Cloud availability does not guarantee unlimited recovery.
- Keeping every backup connected. Ransomware may reach and delete accessible copies.
- Using the same administrator credentials. One compromised account may expose production and backup systems.
- Failing to define recovery priorities. Technicians may restore less important systems before essential ones.
- Setting unrealistic recovery objectives. The backup architecture may not support the promised timeline.
- Allowing documentation to become outdated. Old contacts, passwords, and procedures delay recovery.
- Testing only during normal business conditions. Real incidents may occur when key employees or vendors are unavailable.
- Failing to correct test findings. Repeating the same unresolved issue creates false confidence.
A Practical Example: Ransomware at a 35-Employee Financial Firm
Consider a 35-employee financial firm that discovers ransomware on a file server early Monday morning. Employees cannot access shared client documents, and several computers show suspicious activity.
The firm’s recovery plan defines:
- A four-hour RTO for the file server
- A one-hour RPO for recently modified documents
- The managed IT provider as the technical incident lead
- The owner as the business decision-maker
- Legal and insurance contacts for escalation
- An isolated backup copy protected from the production environment
The provider isolates affected devices, validates a clean recovery point, restores the server in an isolated environment, verifies the data, and returns access in priority order. Because the recovery process had been tested quarterly, the team already knew where credentials were stored, which server should be restored first, and how employees would be notified.
Without testing, the same firm might discover during the emergency that backups were incomplete, recovery credentials were unavailable, or the estimated restore time was unrealistic.
10 Questions to Ask Your IT Provider
- Which systems and cloud services are currently backed up?
- Which important systems are not covered?
- How frequently does each backup run?
- Where are backup copies stored?
- Can ransomware or a compromised administrator delete every copy?
- When was the last successful file restore?
- When was the last successful server or application recovery test?
- What are our documented RTO and RPO targets?
- How long would it take to restore our most critical system today?
- What evidence will leadership receive after each test?
Ask for written answers and recent test results rather than verbal assurances.
A 90-Day Backup and Recovery Improvement Plan
Days 1–30: Inventory and Assess
- List every critical system and data source
- Review current backup reports
- Identify missing systems and cloud applications
- Confirm backup ownership and administrator access
- Define preliminary RTO and RPO targets
- Review retention and storage locations
- Identify outdated recovery documentation
Days 31–60: Protect and Test
- Correct failed or missing backups
- Strengthen backup administrator security
- Create or verify an isolated backup copy
- Test file, email, and cloud-data restores
- Recover a critical server or application in an isolated environment
- Measure actual recovery times
- Document problems and corrective actions
Days 61–90: Exercise and Improve
- Conduct a tabletop disaster-recovery exercise
- Confirm executive and vendor contacts
- Update recovery priorities
- Finalize RTO and RPO targets
- Revise the written recovery plan
- Present test results and remaining risks to leadership
- Schedule the next four quarterly tests
How 911 IT Helps Financial Firms Prepare for Recovery
911 IT helps financial organizations reduce the operational impact of ransomware, hardware failure, cloud disruption, and other incidents through:
- Secure local and cloud backup solutions
- Backup monitoring and failure remediation
- Microsoft 365 backup and recovery
- Disaster-recovery planning
- Recovery testing
- Business continuity documentation
- Cybersecurity monitoring and incident response
- Microsoft 365 and cloud management
- Technology inventories and documentation
- Strategic risk and budgeting reviews
Explore 911 IT’s business continuity services, cybersecurity services, and specialized IT support for financial firms.
Take One Action This Week
Ask your IT provider to restore one important file from a backup created at least 30 days ago. Record how long the recovery takes, whether the correct version is available, and whether the file opens successfully.
Then request the date and result of the most recent full server, application, or Microsoft 365 recovery test. If no documented test exists, schedule one before assuming your firm can recover from a serious disruption.
Schedule a Backup and Disaster-Recovery Assessment
A useful recovery assessment should identify what is protected, what is missing, how quickly critical systems can return, how much recent data could be lost, and whether recovery has been proven through testing.
Schedule a discovery call with 911 IT to review your backup coverage, Microsoft 365 data, recovery objectives, retention requirements, ransomware protection, and current testing schedule.
