How Frequently Community Banks Should Test Recovery
A community bank should monitor backups every day, perform representative file or application restoration tests at least quarterly and conduct a comprehensive disaster recovery exercise at least annually.
Critical systems may require more frequent testing. A bank with online banking, payment processing, lending platforms, Microsoft 365 and multiple branch locations should base its schedule on business impact, recovery objectives, technology changes and unresolved test findings rather than relying on one annual exercise.
For a community bank with 25–50 employees, a practical testing schedule is:
- Daily: Review backup job failures and security alerts.
- Monthly: Verify backup coverage, retention and protected storage.
- Quarterly: Restore representative files, mailboxes, databases or virtual systems.
- Annually: Conduct a complete disaster recovery and business continuity exercise.
- After material changes: Retest affected systems after migrations, upgrades, provider changes or major security incidents.
A successful backup report is not proof that the bank can recover. The institution needs documented evidence that clean, usable information can be restored within the time required to support critical banking operations.
What Is the Difference Between Backup, Disaster Recovery and Business Continuity?
Backup, disaster recovery and business continuity are related but separate capabilities.
| Capability | Primary purpose | Example |
|---|---|---|
| Backup | Creates recoverable copies of systems and information | Restoring a deleted loan document |
| Disaster recovery | Restores technology after a serious outage or cyber incident | Recovering servers after ransomware |
| Business continuity | Keeps critical banking services operating during disruption | Processing essential transactions through alternate procedures |
A bank can have technically successful backups and still experience an unacceptable outage if it lacks a documented recovery order, alternative communications, trained employees or access to required vendors.
The strongest program tests all three questions:
- Can the bank recover its information?
- Can it restore the required technology?
- Can employees deliver critical banking services while recovery is underway?
The Eight-Part Recovery Testing Framework
1. Identify Critical Business Services
The bank should begin with business operations rather than backup software. Technology recovery priorities should reflect the services that customers and employees need most.
Critical services may include:
- Core banking access
- Online and mobile banking
- Wire and payment processing
- Customer account servicing
- Loan operations
- Branch connectivity
- Employee authentication
- Email and internal communication
- Document management
- Fraud monitoring
- Telephone services
- Regulatory and financial reporting
Map Services to Technology
For each business service, identify the systems and dependencies required to operate it.
| Business service | Technology dependency | Other dependency |
|---|---|---|
| Wire processing | Payment platform, identity services and secure network access | Authorized employees and verification procedures |
| Customer document access | Document management, servers or cloud storage | Vendor support and user permissions |
| Branch operations | Internet, firewall, workstations and core connection | Telecommunications and local staff |
| Employee email | Microsoft 365, identity and endpoint access | Internet connectivity and secure devices |
This mapping prevents the bank from restoring systems in a technically convenient but operationally ineffective order.
2. Define Recovery Time and Recovery Point Objectives
The bank should establish a recovery time objective and recovery point objective for each critical service.
Recovery Time Objective
The recovery time objective, or RTO, is the target amount of time for restoring a service after disruption.
Examples may include:
- Critical payment systems: four hours
- Employee email: eight hours
- Shared file access: 12 hours
- Archived records: two business days
Recovery Point Objective
The recovery point objective, or RPO, is the maximum acceptable amount of information that may need to be recreated because of the timing of the last usable backup.
Examples may include:
- Critical transaction data: less than one hour
- Operational documents: four hours
- General file data: one business day
These figures are examples, not universal standards. The bank should establish objectives through a business impact analysis and approve them according to its operational requirements.
Make Objectives Measurable
A statement such as “restore the system quickly” cannot be tested. A useful objective states:
- Which service must be restored
- How quickly it must return
- How much information loss is acceptable
- Who approves the restored service
3. Verify Backup Scope and Coverage
The bank should compare its current technology inventory with the systems protected by backup.
The review should include:
- Physical and virtual servers
- Databases
- File storage
- Microsoft 365 email
- SharePoint and OneDrive
- Cloud applications
- Firewall and network configurations
- Critical employee workstations
- Security platforms
- Application configuration files
Find Unprotected Systems
Backup gaps often occur when:
- A new server is deployed without being added to the backup platform.
- A cloud application is assumed to include long-term recovery.
- An employee stores important information on a local device.
- A legacy system requires a specialized backup method.
- A provider manages data without documenting recovery responsibilities.
- A project changes file locations without updating the backup job.
The bank should reconcile the asset inventory, application inventory and backup platform at least quarterly.
4. Protect Backups From the Production Environment
Ransomware and compromised administrator accounts may allow an attacker to delete or encrypt accessible backups. At least one recovery copy should be protected from routine production access.
Protection may include:
- Immutable storage
- Offline or logically isolated copies
- Separate administrative credentials
- Multifactor authentication
- Restricted deletion permissions
- Independent monitoring
- Encryption in transit and at rest
- Alerts for retention or configuration changes
Ask the Deletion Question
A simple way to evaluate backup resilience is to ask:
If an attacker obtained a production administrator account, could that person delete every usable backup copy?
If the answer is yes, the bank may have a backup system but not a sufficiently resilient recovery capability.
Separate Backup Administration
The same credentials should not provide unrestricted control over production systems and every backup copy. The bank should:
- Use separate backup administrator accounts
- Require multifactor authentication
- Limit the number of authorized users
- Monitor administrative changes
- Review access at least quarterly
- Remove former employee and vendor access promptly
5. Test Restoration at Multiple Levels
A complete testing program should include more than one type of restore.
File-Level Restore
Restore individual files or folders to confirm that common deletion and corruption events can be corrected.
Verify:
- The requested recovery point exists
- The file opens successfully
- Permissions are appropriate
- The restored content is complete
- The recovery time is documented
Microsoft 365 Restore
Test representative recovery of:
- Email messages
- Mailboxes
- OneDrive files
- SharePoint documents
- Teams-related information where included
Cloud service availability does not automatically provide the bank with every retention, restoration or recovery capability it requires.
Application or Database Restore
Restoring files may not be sufficient for an application that depends on a database, configuration records and identity services.
The test should verify:
- Application startup
- Database consistency
- User authentication
- Required integrations
- Representative business transactions
Server or Virtual Machine Recovery
Recover an entire system in an isolated environment and confirm that it can operate securely.
Check:
- Operating system startup
- Application availability
- Network configuration
- Security tools
- Required patches
- Data freshness
- Authentication
Bare-Metal or Alternate-Hardware Recovery
A stronger test evaluates whether a system can be recovered when the original server or storage device is unavailable.
This is particularly important when the bank’s recovery assumptions depend on hardware that could be damaged, encrypted or inaccessible.
6. Conduct a Full Disaster Recovery Exercise
A comprehensive exercise should test the bank’s ability to restore priority services after a realistic disruption.
Potential scenarios include:
- Ransomware affecting servers and workstations
- Failure of a primary server or storage platform
- Loss of a branch internet connection
- Microsoft 365 account compromise
- Cloud service outage
- Critical provider disruption
- Fire, flood or power loss
- Deletion of important data
Define the Exercise Scope
A full test should document:
- The scenario
- Systems being tested
- Business services affected
- Participants
- Approved test boundaries
- Recovery objectives
- Success criteria
- Expected communications
- Required evidence
The exercise should not create unacceptable production risk. Some recovery tests may be performed in an isolated environment, while business continuity procedures can be tested through a structured simulation.
Test the Entire Recovery Chain
- Detection: Identify the simulated outage or incident.
- Escalation: Contact the correct technical and executive personnel.
- Decision: Approve disaster declaration and recovery priorities.
- Restoration: Recover selected systems and information.
- Validation: Have business owners test the restored services.
- Communication: Update employees, leadership and relevant vendors.
- Improvement: Assign corrective actions for identified weaknesses.
7. Test Business Continuity Procedures
The bank should verify how critical work continues while technology remains unavailable.
Business continuity testing may include:
- Using alternative communication methods
- Operating from another location
- Following manual transaction procedures
- Prioritizing customer requests
- Redirecting calls
- Accessing offline contact information
- Coordinating with critical vendors
- Communicating service limitations to customers
Include Nontechnical Employees
A test conducted only by the IT provider does not demonstrate that the bank can continue operating.
Participants may include:
- Executive management
- Branch operations
- Deposit operations
- Lending
- Payments and wires
- Compliance
- Information security
- Communications
- Internal IT
- The managed IT provider
Test Alternative Communications
The bank should not assume email, Teams or normal telephone systems will remain available.
Test access to:
- Printed or offline contact lists
- Emergency telephone numbers
- Alternative conferencing
- Executive contact trees
- Vendor emergency contacts
- Employee notification systems
8. Document Results and Correct Weaknesses
Every recovery exercise should produce a formal record.
The report should include:
- Date and scope
- Participants
- Scenario
- Systems restored
- Recovery points used
- Actual recovery time
- Whether information was usable
- Business validation results
- Problems encountered
- Corrective actions
Compare Results With Objectives
| System | Target RTO | Actual recovery | Target RPO | Result |
|---|---|---|---|---|
| Identity services | 4 hours | 3 hours, 20 minutes | 1 hour | Passed |
| File services | 8 hours | 10 hours | 4 hours | Corrective action required |
| Email recovery | 8 hours | 5 hours | 4 hours | Passed |
Create a Corrective Action Register
| Finding | Action | Owner | Deadline | Validation |
|---|---|---|---|---|
| Recovery credentials were outdated | Update emergency password vault and access procedure | IT manager | 10 business days | Access test |
| File recovery exceeded the RTO | Increase recovery capacity and revise restoration order | MSP | 45 days | Repeat recovery test |
| Vendor contact was unavailable | Add secondary and after-hours contacts | Vendor manager | 15 days | Call-tree test |
A finding should not be closed until the bank verifies that the corrective action worked.
A Practical Backup and Recovery Testing Schedule
| Frequency | Recommended activity |
|---|---|
| Daily | Review failed jobs, missed devices, storage alerts and suspicious backup activity |
| Weekly | Review unresolved failures and confirm critical backup completion |
| Monthly | Reconcile protected systems, review retention and inspect administrator changes |
| Quarterly | Restore representative files, mailboxes, applications or virtual systems |
| Semiannually | Test a higher-risk recovery scenario or critical third-party dependency |
| Annually | Conduct a comprehensive disaster recovery and business continuity exercise |
| After major changes | Retest affected recovery procedures and documentation |
The exact schedule should reflect the bank’s risk assessment, business impact analysis, system importance and recovery objectives.
When Should a Bank Test More Frequently?
Additional testing may be appropriate after:
- A core or major application conversion
- A Microsoft 365 migration
- A backup platform replacement
- A managed IT provider change
- A merger or acquisition
- A new branch opening
- A material cybersecurity incident
- A failed recovery test
- A network or server redesign
- A significant cloud migration
- A change in a critical vendor
- A major policy or recovery objective change
The bank does not need to repeat every exercise after each change. It should retest the systems, dependencies and procedures affected by that change.
How Long Should a Disaster Recovery Test Take?
The duration depends on the test scope and the bank’s recovery objectives.
Examples include:
- A file restoration test may take 30–60 minutes.
- A Microsoft 365 recovery test may take one to three hours.
- A server recovery exercise may take four to eight hours.
- A multi-system disaster recovery exercise may require a full business day.
- A comprehensive continuity exercise may be planned across several sessions.
The goal is not to make the test as long or disruptive as possible. The goal is to gather credible evidence that the bank can meet approved recovery requirements.
Should Recovery Tests Affect Production Systems?
Not necessarily. Many tests can be completed in isolated or alternate environments.
A safe testing plan should identify:
- Whether production data will be copied
- How sensitive information will be protected
- Which network connections must remain disabled
- Who may access the test environment
- How test systems will be removed afterward
- How operational risk will be controlled
Some production procedures may still require validation, such as switching an internet connection, contacting employees or confirming access to an alternate location. Those activities should be scheduled and approved carefully.
What Evidence Should Examiners and Auditors Be Able to Review?
The bank should be prepared to provide organized recovery documentation.
Useful evidence may include:
- Business impact analysis
- Current business continuity plan
- Disaster recovery procedures
- Backup architecture
- Protected-system inventory
- Backup job reports
- Restoration test records
- Disaster recovery exercise reports
- Actual RTO and RPO results
- Management and board reporting
- Corrective action tracking
- Critical vendor recovery information
- Employee exercise participation
The documentation should demonstrate what the bank tested, what happened and how weaknesses were corrected.
Third-Party and Cloud Recovery Responsibilities
A bank may depend on vendors for core banking, online banking, payments, telecommunications, cloud services and document management. That does not eliminate the need to understand recovery.
For every critical provider, the bank should determine:
- Which services the vendor recovers
- Which data the vendor backs up
- Expected recovery times
- How the bank is notified of an outage
- What the bank must do during recovery
- Whether alternate procedures exist
- How recovery claims are tested or validated
Questions to Ask Critical Vendors
- What are your recovery time and recovery point commitments?
- How often do you test disaster recovery?
- Can you provide a summary of recent testing?
- How are backups protected from ransomware?
- How will you notify us of an incident?
- Which responsibilities remain with our bank?
- What alternative service methods are available?
- How do you manage subcontractor dependencies?
A vendor report can support due diligence, but the bank should still test its own procedures for operating when that vendor is unavailable.
Does Microsoft 365 Need a Separate Backup?
A community bank should evaluate whether Microsoft 365’s native retention and recovery capabilities satisfy its specific operational, legal and risk-management requirements.
The decision should consider:
- Required retention periods
- Accidental deletion
- Malicious deletion
- Ransomware or account compromise
- SharePoint and OneDrive recovery
- Ease of restoring individual items
- Administrative access separation
- Recovery reporting
A separate backup platform may provide additional retention, administrative separation or restoration options. The bank should define the required outcome before selecting a product.
911 IT’s cloud services include Microsoft 365 management, security configuration and cloud support.
How Should a Bank Test Ransomware Recovery?
A ransomware recovery exercise should assume that normal production systems and some administrative credentials may be unavailable.
Ransomware Recovery Test Scenario
- A monitoring tool detects encryption behavior on several devices.
- The response team isolates affected systems.
- The bank determines whether backup administration is still secure.
- Critical services are prioritized.
- A clean recovery environment is prepared.
- Representative systems are restored.
- Business owners validate the recovered applications.
- Monitoring is confirmed before production use.
Questions the Exercise Should Answer
- Can the bank access backups without the production domain?
- Are recovery credentials available offline?
- Can an attacker delete every copy?
- How will the bank identify a clean recovery point?
- Can critical systems be restored in the required order?
- How will employees communicate?
- Who contacts the cyber insurance carrier?
- Who approves restored systems for use?
A 90-Day Recovery Readiness Improvement Plan
Days 1–15: Inventory and Priorities
- Confirm critical business services
- Review the business impact analysis
- Document RTOs and RPOs
- Inventory servers, cloud platforms and applications
- Identify critical vendor dependencies
Days 16–30: Backup Coverage Review
- Compare assets with protected systems
- Review retention policies
- Verify encryption
- Review backup administrator access
- Identify missing or unsupported systems
Days 31–45: Security and Resilience
- Implement multifactor authentication
- Separate backup administration
- Verify immutable or isolated copies
- Configure alerts for changes and failures
- Remove inactive vendor and employee access
Days 46–60: Representative Restore Testing
- Restore files
- Restore a Microsoft 365 item
- Recover a representative application
- Recover a server in an isolated environment
- Document actual recovery times
Days 61–75: Continuity Exercise
- Select a realistic scenario
- Test the emergency contact tree
- Review alternate work procedures
- Include business and technical employees
- Document communication gaps
Days 76–90: Remediation and Reporting
- Assign corrective actions
- Prioritize failed recovery objectives
- Update recovery procedures
- Report results to management
- Schedule validation tests
Common Backup and Disaster Recovery Mistakes
Relying Only on Backup Success Emails
A successful job report confirms that software completed a task. It does not prove that the information is complete, clean or usable.
Testing Only One File
A file restore is useful but does not demonstrate that an application, server or business process can be recovered.
Storing Every Copy in One Environment
A single administrator compromise, ransomware event or storage failure may affect every accessible copy.
Using Shared Administrator Accounts
Shared credentials reduce accountability and make it more difficult to remove former employee or vendor access.
Ignoring Microsoft 365 and Cloud Data
The bank should define how cloud data will be retained and restored rather than assuming the provider covers every scenario.
Failing to Involve Business Employees
Technical recovery does not prove that critical banking processes can operate.
Leaving Recovery Objectives Undefined
Without measurable RTOs and RPOs, the bank cannot determine whether a test succeeded.
Keeping the Plan Only Online
Recovery contacts, procedures and credentials may be inaccessible during a cloud or network outage.
Never Retesting Failed Controls
A corrective action should be validated through another restore or exercise.
Assuming the Vendor Is Responsible for Everything
The bank remains responsible for governance, priorities, communication and oversight even when a provider operates the technology.
Questions to Ask a Managed IT Provider About Recovery
- Which systems and cloud services are included in backup?
- How often are critical systems backed up?
- Where are recovery copies stored?
- Can production administrators delete every copy?
- Is multifactor authentication required?
- Who reviews failed backup jobs?
- How quickly are failures escalated?
- How often do you perform restoration tests?
- Will you provide written test results?
- Can you recover systems without the original hardware?
- How do you identify a clean recovery point after ransomware?
- Who manages recovery after hours?
- Which recovery work is included in our monthly fee?
- Which incidents create additional charges?
- Will you participate in our annual continuity exercise?
911 IT’s business continuity services combine monitored backups, disaster recovery, cybersecurity and live 24/7 technical support.
What Financial Organizations Value in a Recovery Partner
Financial organizations need a technology partner that can respond quickly, take ownership and support recovery under pressure.
One 911 IT client described how the team recovered essential data after a serious technical problem, allowing the organization to resume work without losing critical information. The client valued both the successful recovery and the urgency with which the issue was handled.
Another financial-services client described working with 911 IT as having access to an entire IT department without the cost of building an equivalent internal team. The organization valued proactive recommendations and the ability to rely on experienced specialists when complex issues occurred.
A separate financial client emphasized that 911 IT responds promptly, owns support requests and verifies that problems are fully resolved before closing them. That follow-through is essential during recovery because partial restoration can leave employees unable to complete required work.
Clients have also highlighted the value of consolidating backup, cybersecurity, support and vendor coordination under one accountable provider. A single escalation point can reduce delays when an outage involves multiple systems or service providers.
Learn more about 911 IT’s experience providing IT support for CPAs and financial firms.
Frequently Asked Questions
How often should a community bank test backups?
The bank should monitor jobs daily, conduct representative restoration tests at least quarterly and complete a comprehensive disaster recovery exercise at least annually. Critical systems or major changes may justify more frequent testing.
Is one annual disaster recovery test enough?
An annual comprehensive exercise is a practical minimum, but it should be supported by daily monitoring, monthly reviews and quarterly restoration tests.
Does a successful backup mean the system can be recovered?
No. Recovery must be demonstrated by restoring the information or system and confirming that it is complete, secure and usable.
Who should participate in disaster recovery testing?
Participants should include technical personnel, bank management, operations, information security, compliance and relevant vendors. Business owners should validate that restored systems support required work.
Should the board receive recovery test results?
The board or responsible committee should receive reporting appropriate to the bank’s governance structure, including material failures, unmet recovery objectives and management’s corrective plan.
What is an immutable backup?
An immutable backup is designed to prevent stored information from being changed or deleted during a defined retention period. The bank should verify the actual configuration and administrative controls.
Should Microsoft 365 be backed up separately?
The bank should compare Microsoft 365’s native retention and recovery capabilities with its operational, legal and risk-management requirements. A separate solution may provide additional recovery options.
What happens when a recovery test fails?
The bank should document the failure, determine the cause, assign a corrective action and repeat the relevant test after remediation.
Can a bank test recovery without taking production systems offline?
Yes. Many file, application and server restores can be performed in isolated environments. The test plan should protect sensitive data and prevent conflicts with production systems.
How should the bank test a critical cloud vendor?
The bank should review the vendor’s recovery evidence and test its own procedures for operating when the service is unavailable. Vendor testing does not replace the bank’s continuity exercise.
How long should recovery records be retained?
The bank should establish retention according to its policies, legal requirements, regulatory expectations and risk-management needs.
Can an MSP guarantee recovery?
No provider can guarantee recovery under every scenario. A qualified MSP can improve readiness through protected backups, monitoring, documented procedures and recurring testing.
Prove Recovery Before the Bank Needs It
A backup strategy is complete only when the bank can demonstrate that systems and information can be restored within approved timeframes.
The strongest recovery program combines daily monitoring, protected backup copies, quarterly restoration testing, annual disaster recovery exercises and documented corrective action. It also includes the employees, vendors and business procedures required to continue serving customers during an outage.
911 IT provides managed IT, cybersecurity, cloud and business continuity services for organizations in Salt Lake City and throughout Utah. Our local team combines live 24/7 support, monitored backups, tested recovery, local engineers and financial-industry experience under one accountable relationship.
Schedule a 10-minute discovery call to review your bank’s backup coverage, ransomware resilience, recovery objectives and testing schedule. You can also contact 911 IT to request a backup and disaster recovery assessment.
This article provides general educational information and is not legal, regulatory or compliance advice. Financial institutions should consult their primary regulator, legal counsel and qualified compliance professionals regarding requirements that apply to their circumstances.
