Category: blog
Continuity
A backup is one control within a business continuity plan.
It does not define:
- Which systems must be restored first
- How much downtime is acceptable
- How much data can be lost
- Who makes recovery decisions
- How employees continue operating
- How customers and vendors are notified
- Whether recovery procedures work
A complete plan connects business operations, technology, people, vendors, facilities, communications, and testing.
The U.S. Small Business Administration recommends business continuity planning as part of ongoing risk management. SMBs can apply the same principles with a smaller, focused plan built around critical processes.
1. Identify critical business functions
Start with operations rather than technology.
List the functions required to continue business activity:
- Sales and customer service
- Accounting and payroll
- Order processing
- Production or service delivery
- Email and collaboration
- File access
- Website and online forms
- Voice communications
- Vendor and payment systems
- Regulatory and customer records
For each function, document:
- Business owner
- Supporting applications
- Required data
- Internal dependencies
- External dependencies
- Manual fallback process
- Maximum acceptable downtime
This process is a business impact analysis
A business impact analysis establishes priority. It prevents recovery decisions from being based only on which server failed first.
2. Set RTO and RPO targets
Recovery objectives must be defined for each critical system.
Recovery Time Objective
Recovery Time Objective or RTO defines the maximum acceptable time a system can remain unavailable.
Examples:
- Accounting system : 4 hours
- Line-of-business application : 2 hours
- File storage : 4 to 8 hours
- Email and collaboration : 4 hours
- Public website : 24 hours
An RTO is not a preference.
It is a measurable requirement. If the target is four hours, recovery procedures and infrastructure must support restoration within four hours.
Recovery Point Objective
Recovery Point Objective or RPO defines the maximum acceptable amount of data loss.
Examples:
- Critical transaction data : 30 minutes
- Accounting data : 1 hour
- Shared files : 4 hours
- Website content : 24 hours
An RPO of one hour requires backups or replication at least every hour.
Daily backups do not support a one-hour RPO.
Document the objectives
Create a system inventory with:
| System | Business function | RTO | RPO | Recovery owner |
|---|---|---|---|---|
| Accounting platform | Financial operations | 4 hours | 1 hour | Finance |
| File storage | Internal documents | 4 hours | 4 hours | IT |
| Email platform | Communications | 4 hours | 1 hour | IT |
| Phone system | Customer and internal calls | 4 hours | Not applicable | Operations |
| Website | Public information | 24 hours | 24 hours | Marketing |
Targets must reflect business impact, staffing, contractual requirements, and available recovery resources.
3. Build a backup strategy that supports recovery
A backup strategy must match the defined RPO.
The standard starting point is the 3-2-1 model:
- Three copies of important data
- Two storage types or locations
- One off-site copy
Critical systems should also include:
- Immutable backup storage
- Restricted backup credentials
- Offline or logically isolated copies
- Encryption in transit and at rest
- Retention policies
- Backup alerting
- Failed-job remediation
- Cloud application data protection
Production data should not be the only source.
Backups for Microsoft 365, Google Workspace, databases, file servers, endpoints, and SaaS applications must be reviewed separately. Cloud availability does not automatically provide independent backup coverage.
Backup status must be monitored. Failed jobs must be investigated. Retention must be verified. Restore capability must be proven.
4. Document disaster recovery procedures
Disaster recovery is the technical component of business continuity.
Each critical system requires a recovery procedure with enough detail for execution during an incident.
Include:
- System name and business owner
- Recovery priority
- Backup location
- Required credentials
- Recovery tools
- System dependencies
- Restore sequence
- Validation steps
- Expected recovery time
- Escalation contacts
- Temporary workaround
Recovery order is important.
For example:
- Restore network connectivity
- Restore identity and authentication services
- Restore core infrastructure
- Restore databases
- Restore line-of-business applications
- Restore file services
- Validate endpoints and user access
- Resume normal operations
Dependencies must be documented.
An application may depend on a database, DNS, authentication, storage, licensing, or network services. Restoring the application alone may not restore the business function.
5. Include people and communications
Technology is only one part of continuity.
Document who is responsible for:
- Declaring an incident
- Contacting the IT provider
- Approving emergency spending
- Communicating with employees
- Communicating with customers
- Managing vendors
- Contacting insurance providers
- Coordinating legal or regulatory notifications
- Approving return to normal operations
Maintain current contact information for:
- Employees
- Leadership
- IT support
- Internet and telecommunications providers
- Cloud providers
- Hardware vendors
- Building management
- Insurance contacts
- Key customers and suppliers
Prepare communication templates for:
- Network outages
- Ransomware incidents
- Email compromise
- Facility loss
- Extended internet outages
- Data restoration delays
Communications should be controlled by designated personnel. Technical staff should not be required to manage customer messaging while performing recovery work.
6. Plan for alternate operations
Business continuity requires operational alternatives when the primary office or systems are unavailable.
Review:
- Remote access
- Secondary internet connectivity
- Mobile hotspots
- Alternate work locations
- Laptop availability
- VPN capacity
- Multifactor authentication
- Cloud application access
- Temporary phone routing
- Manual order and payment procedures
- Alternate vendors
A remote-work policy is not automatically a continuity plan.
Remote access must be tested under real conditions. Devices must be available. Credentials must work. Authentication systems must remain accessible. Staff must know which applications and procedures to use.
Voice systems require separate planning. If an on-premise phone system is unavailable, call forwarding, cloud failover, or temporary mobile routing may be required.
7. Test the plan
Untested recovery procedures are assumptions.
Use a layered testing schedule.
Monthly
- Review backup job results
- Restore a random file
- Verify file integrity
- Confirm backup access
- Review alert escalation
Quarterly
- Restore a noncritical system
- Test a critical application in an isolated environment
- Conduct a tabletop exercise
- Review contact lists
- Validate manual workarounds
- Measure restoration time
Annually
- Perform an end-to-end disaster recovery test
- Operate critical systems from the recovery environment
- Validate RTO and RPO results
- Test employee communications
- Review vendor response procedures
- Update the complete plan
Testing should simulate realistic events:
- Ransomware affecting file servers
- Hardware failure
- Cloud service disruption
- Internet outage
- Building damage
- Power failure
- Lost administrator credentials
- Key vendor failure
Record:
- Start time
- Detection time
- Notification time
- Restoration time
- Data recovery point
- Failed procedures
- Unavailable contacts
- Required changes
A test that exposes a gap has provided useful information. The gap must then be assigned, corrected, and retested.
8. Apply cybersecurity controls
Continuity planning must account for attacks that target backups and recovery systems.
Required controls include:
- Multifactor authentication
- Privileged account separation
- Endpoint detection and response
- Patch management
- Email security
- Network segmentation
- Backup immutability
- Offline recovery copies
- Least-privilege access
- Security awareness training
- Incident response procedures
- Log monitoring
Ransomware recovery requires more than restoring encrypted files.
The environment must be assessed before restoration. Compromised accounts must be disabled. Persistence mechanisms must be removed. Systems must be patched. Credentials must be rotated. Restored data must be validated.
Recovery into an unchanged environment can recreate the incident.
9. Use managed continuity services
SMBs may not have dedicated personnel for backup monitoring, recovery testing, infrastructure management, and incident coordination.
X-Tek managed continuity services can support this operational model through:
- Managed IT support plans
- Server maintenance and repair
- PC and Mac maintenance
- Google Cloud support
- Microsoft Cloud support
- Network design and maintenance
- Website security
- Managed DNS
- VOIP systems
- Backup and security monitoring
- On-site and remote support
The X-Tek business solutions page lists available business IT, cloud, VOIP, web, and infrastructure services.
Managed continuity support can include:
- System inventory maintenance
- Backup monitoring
- Failed-job response
- Recovery documentation
- Restore testing
- Patch and endpoint management
- Security alert escalation
- Vendor coordination
- Infrastructure review
- Continuity plan updates
Service scope should be aligned with documented RTO and RPO targets.
If a system requires a two-hour RTO, the agreement, tools, staffing, access, and recovery environment must support that target.
Continuity checklist
Use this as a starting point:
- Critical business functions are documented
- A business impact analysis is complete
- RTO and RPO are assigned per system
- Backups match RPO requirements
- Off-site and immutable copies are available
- SaaS data is included
- Recovery procedures are documented
- System dependencies are recorded
- Employee and vendor contacts are current
- Manual workarounds are defined
- Remote access has been tested
- Monthly restore tests are scheduled
- Quarterly tabletop exercises are scheduled
- Annual disaster recovery testing is scheduled
- Cybersecurity controls protect recovery systems
- The plan is reviewed after changes or incidents
Next step
Business continuity planning should be treated as an operating process.
Systems change. Employees change. Vendors change. Threats change. Recovery procedures must be reviewed and tested as those changes occur.
X-Tek can help assess current infrastructure, define recovery priorities, review backup coverage, and build a continuity plan for critical business systems.
Request business solutions information through the X-Tek business solutions information request.
Contact Information
Business Solutions Information Request:
https://xtekit.com/business-solutions-information-request/
815-516-8075