Two Numbers Every Business Owner Should Know
If your IT systems went down right now — server failure, ransomware attack, flood in the server room — how long could your business operate before the impact became critical? And how much data could you afford to lose? These two questions define the most important metrics in disaster recovery planning: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
Most Australian business owners cannot answer these questions. Many have never been asked. Yet RTO and RPO should drive every decision about your backup and disaster recovery strategy — from the technology you use to the amount you invest.
Recovery Time Objective (RTO)
RTO answers the question: How quickly do we need to be back up and running? It is the maximum acceptable amount of time your business can be without its IT systems before the impact becomes unacceptable.
RTO is not a technical specification — it is a business decision. A law firm preparing for a court deadline might have an RTO of 2 hours. A retail business during its peak season might need systems back within 4 hours. A business with manual fallback processes might tolerate 24 hours of IT downtime.
The key is that RTO must be defined before a disaster happens, because the technology and processes required to meet a 2-hour RTO are fundamentally different (and more expensive) than those needed for a 24-hour RTO. If you wait until your systems are down to think about recovery time, you have already lost control of the situation.
What Determines Your RTO?
Several factors influence what your RTO should be. Revenue impact — how much money does your business lose per hour of downtime? For businesses that rely on IT for sales, service delivery, or operations, this number can be substantial. Contractual obligations — do your SLAs with clients specify uptime guarantees? Regulatory requirements — some industries have specific requirements for system availability. Reputation — how would extended downtime affect customer confidence and your market position? Staff productivity — how many people are sitting idle waiting for systems to come back?
Recovery Point Objective (RPO)
RPO answers a different question: How much data can we afford to lose? It defines the maximum acceptable age of the data you recover from backup. In simpler terms, RPO is how far back in time you go when you restore from backup.
If your RPO is 24 hours and you back up once per day at midnight, then in a worst-case scenario (failure at 11:59 PM), you could lose up to 24 hours of work. If your RPO is 1 hour, you need backups running at least every hour to ensure you never lose more than 60 minutes of data.
What Determines Your RPO?
The right RPO depends on how quickly your business creates data and how painful it would be to recreate lost work. A business processing hundreds of financial transactions per hour cannot afford to lose even 15 minutes of data. A business that primarily works with documents stored in Microsoft 365 (where OneDrive and SharePoint provide near-continuous sync) might tolerate a longer RPO for their on-premises systems. Businesses with manual data entry processes need to consider how many hours of work would need to be re-entered if data is lost.
The Cost Equation
Here is the reality that makes RTO and RPO uncomfortable conversations: tighter objectives cost more money. A 4-hour RTO requires different technology than a 24-hour RTO. An RPO of 15 minutes requires more frequent backups (and more storage) than an RPO of 24 hours.
The relationship looks roughly like this. For a 24-hour RTO / 24-hour RPO, a standard nightly backup to local storage and cloud is typically sufficient. Cost is modest. For an 8-hour RTO / 4-hour RPO, you need more frequent backup snapshots, faster restore capabilities, and likely a standby server or cloud recovery environment. Cost increases moderately. For a 2-hour RTO / 1-hour RPO, you are looking at near-continuous data replication, hot standby systems, and automated failover capabilities — disaster recovery as a service (DRaaS). Cost increases significantly but so does your resilience. For a near-zero RTO / near-zero RPO, real-time replication with automatic failover to a secondary site. This is enterprise-grade high availability and is typically only justified for mission-critical systems.
The right approach for most Australian SMBs is not a single RTO/RPO for everything, but a tiered strategy. Your email and core business applications might need a 4-hour RTO, while your file server might be acceptable at 24 hours. Your financial system might need a 1-hour RPO, while your marketing files can tolerate 24 hours.
How to Define Your RTO and RPO
The process starts with a Business Impact Analysis (BIA) — a structured assessment of how IT downtime and data loss would affect each part of your business. For each critical system, you determine what happens if it is unavailable for 1 hour, 4 hours, 1 day, or 1 week. The answers reveal your actual tolerance for downtime and data loss, which directly maps to your RTO and RPO requirements.
This analysis should involve business stakeholders, not just IT. The operations manager knows the impact of losing access to the job management system. The finance team understands the implications of losing a day’s worth of transaction data. The sales team can quantify the cost of losing access to the CRM. IT alone cannot make these assessments accurately.
Testing Your Recovery Capabilities
Defining RTO and RPO is only valuable if your disaster recovery solution can actually meet them. This is where testing comes in. At minimum, you should conduct quarterly restore tests to verify backup integrity and measure actual restore times. Annually, you should run a full disaster recovery simulation — pretend a real disaster has occurred and execute your recovery plan end-to-end, measuring whether you can actually meet your defined RTO and RPO.
TechAssist includes regular DR testing as part of our managed IT services. We define RTO and RPO targets with you, implement the appropriate technology, and verify through testing that your recovery capabilities match your business requirements.
If you have never defined your RTO and RPO — or if you are unsure whether your current backup solution can meet them — contact TechAssist to schedule a business impact analysis. Knowing these numbers before a disaster strikes is the difference between a controlled recovery and a crisis.
Related reading: backup design | managed services | business resilience
