RTO and RPO: start with the business decision
Turn downtime and data-loss concerns into recovery objectives that service owners and technical teams can assess together.
Read article : RTO and RPO: start with the business decision
BACKUP & DISASTER RECOVERY
A backup is a copy. Recovery is a capability.
Protect the information you depend on—and prove there is a practical route back to work. Connect recovery copies, business priorities and tested restoration into one plan.
START WITH THE OUTCOME
The job completed. Can the business restart?
What a backup can tell you
A job report can show that a configured process copied data. It can help you identify failures, capacity problems and missed schedules. That evidence is useful, but its meaning depends on the workload and the checks behind it.
It does not, by itself, establish that an application can start, that dependencies are available or that staff can resume a critical task.
What recovery needs to demonstrate
A usable recovery point, the right infrastructure, working identity and network services, necessary keys and licences, and people who know the restoration sequence.
A meaningful test follows the service through to an agreed business check. The result should say what worked, how long it took and which assumptions still need attention.
TWO QUESTIONS. TWO DIFFERENT TARGETS.
How long can you wait? How much can you lose?
Recovery objectives are business decisions, not numbers to copy from a backup product. Agree them for each important service, then compare the targets with what your recovery process can actually demonstrate.
RTO
Recovery time objective
The target time to restore the agreed service after disruption. Include the work needed to make it usable, not just the time spent transferring files.
DISRUPTION
Restore · Validate
SERVICE AVAILABLE
Example discussion: how long could order processing be unavailable before an agreed workaround is no longer enough?
RPO
Recovery point objective
The target limit on data loss, usually expressed as time. It influences the required recovery points and how transactions created after a restore point would be handled.
RECOVERY POINT
Potential data gap
DISRUPTION
Example discussion: how much recent order information could the team reconstruct accurately from another source?
These are planning targets, not guaranteed recovery times or a promise of zero data loss.
RECOVER A SERVICE, NOT AN ISOLATED SERVER
The right order matters.
A restored application may still be unusable if the people, systems or services it depends on are missing. Build a dependency map before the pressure of an outage.
01
Establish access
Trusted administrators, recovery credentials, keys and an agreed communication route.
02
Restore foundations
Required identity, network, name resolution and supporting infrastructure.
03
Bring back the workload
Application, configuration, database and an appropriate recovery point.
04
Validate the service
A business owner checks representative work before wider use resumes.
Illustrative dependency sequence. The actual order must reflect your systems and the incident; some steps can run in parallel.
PROTECT THE ROUTE BACK
Recovery copies need their own defences.
An attacker who can reach production systems may also try to delete backups, shorten retention or take over the backup console. Review how recovery copies are separated from everyday administration and which identities can change their protection.
Offline storage, immutable retention and access isolation address different risks. The right combination depends on the platform, operating model and threat scenario. Confirm what a setting protects, who can override it and whether the recovery process has been tested.
Include encryption keys, backup catalogues, recovery documentation and emergency access. A protected copy is not useful if the team cannot find it or unlock it when normal systems are unavailable.
REHEARSE BEFORE YOU RELY ON IT
Test the return to work. Not just the restore button.
Start with a representative service and agree a safe test environment. Define what the test can change, who can authorise it and what a successful result looks like. Avoid connecting an unverified restoration to production simply to see whether it works.
Measure the whole process: access to the recovery system, selection of the recovery point, restoration, dependencies and business validation. Record manual steps and unexpected delays as useful findings.
A rehearsal should produce decisions. Assign the gaps to owners, agree changes and repeat the parts needed to establish that the improvement works.
DEFINE WHAT SUCCESS MEANS
Five checks worth recording.
Data
Can the right records be opened and reconciled?
Check representative records and the age of the recovery point against the agreed objective.
Application
Can the service complete a useful task?
Use a representative transaction or workflow, not only a successful startup screen.
Dependencies
Can the restored service reach what it needs?
Validate identity, network, integrations and permissions in the agreed test scope.
People
Can the team follow the runbook?
Record missing steps, unavailable credentials and decisions that depend on one person.
Time
How long did the whole exercise take?
Compare measured stages with the objective and explain exclusions or test constraints.
A limited test supports a limited conclusion. Record what was outside scope and which failure scenarios remain untested.
DIFFERENT EVENTS. DIFFERENT DECISIONS.
Choose the disruption you need to plan for.
Recovery should account for the event, not assume every outage has the same cause. Explore these planning scenarios with your service owners.
A file or database is accidentally deleted
Identify the affected records, a suitable recovery point and the effect of restoring over current data. Coordinate with the owner so valid changes made since the backup are considered.
Planning question: Can you recover the required item without unnecessarily rolling back the wider service?
A site, device or infrastructure platform fails
Consider where the workload will run, what capacity is available and how users will reach it. An off-site copy does not provide replacement infrastructure on its own.
Planning question: Which external providers, network changes and approvals are required to make the alternative usable?
Ransomware affects production systems
Coordinate recovery with incident response. Containment, investigation and confidence in the recovery environment matter alongside the availability of copies. Backups do not resolve data theft or every persistence mechanism.
Planning question: How will the team assess recovery points and avoid reintroducing the cause of compromise?
A cloud application becomes unavailable
Understand the provider’s responsibilities, your export or backup options and what can realistically be restored elsewhere. Check whether the available data can support a temporary business process.
Planning question: What will staff do if data is available but the usual application is not?
TURN ASSUMPTIONS INTO A WORKABLE PLAN
Start with one critical service.
We can discuss an assessment of your recovery arrangements, a focused restoration rehearsal or improvements to an existing plan. Work is scoped around your environment, business priorities and the people responsible for implementation.
Understand the starting point
Identify the service, its owners, existing copies and recovery objectives. Review dependencies, access arrangements and the scenarios the business needs to withstand.
Build an evidence-based view
Examine agreed settings and records. Where testing is included, agree the environment, safety limits, validation criteria and the people who need to participate.
Leave with clear next steps
Document gaps, priorities, accountable owners and validation work. Deliverables may include a dependency map, recovery runbook improvements and a test record, according to the agreed scope.
RECOVERY QUESTIONS, ANSWERED
Know what you can rely on.
Is backup the same as disaster recovery?
No. Backup creates recovery copies. Disaster recovery connects those copies with infrastructure, applications, access, people and a sequence for restoring an agreed service. A useful plan explains how the business returns to work and how that result will be checked.
Do immutable backups guarantee recovery from ransomware?
No. Immutability can protect retained data against certain changes or deletion, depending on the implementation. Recovery also needs suitable recovery points, usable data, keys, access, dependencies and a trustworthy restoration environment. It does not reverse data theft.
Can you work with our existing backup platform?
We can discuss a review of your current arrangements rather than assume a platform replacement is needed. Scope depends on the workloads, provider capabilities, evidence available and the responsibilities agreed with your team or service provider.
How often should we test restoration?
Set a schedule based on business criticality, change frequency and risk. Significant application, infrastructure or provider changes can justify additional tests. A small file restore and a full service rehearsal answer different questions; use both where appropriate.
How do we choose RTO and RPO?
Start with business impact, acceptable workarounds and the ability to reconstruct information. Agree objectives with service owners, then evaluate technical feasibility, cost and measured test results. Different services may need different targets.
Will a recovery test interrupt live systems?
A test should have an agreed scope, environment and safety limits. Some exercises can use isolated infrastructure; others may require a planned service window. Production changes and any expected disruption must be agreed before the work begins.
Are cloud applications automatically covered by our backups?
Do not assume they are. Review each service’s retention, restoration and export capabilities, your subscription and the backup scope you actually operate. Check which data, permissions and configuration can be recovered and what still depends on the original provider.
What should we prepare for an initial discussion?
Bring a list of important services, existing backup arrangements, any recovery targets and recent test results. Mention concerns about access, retention or restore failures. A high-level description is enough to start; do not send credentials or confidential backup contents through the form.
FROM THE RANSOM SECURE BLOG
Make the next recovery decision a better-informed one.
A restore test should end with a business check
Plan a recovery rehearsal that checks data, dependencies and a useful workflow—not simply a successful backup console message.
Read article : A restore test should end with a business check
Your first access review: start with the accounts that matter
A practical way to review people, privileged accounts and applications without turning the exercise into an unmanageable spreadsheet.
Read article : Your first access review: start with the accounts that matterContinue with the backup readiness checklist or recovery objectives planner. For a suspected compromise, see incident response.
Further reading: CISA: #StopRansomware Guide. Artwork, diagrams and scenarios on this page are illustrative.
MAKE READINESS SOMETHING YOU CAN DEMONSTRATE
Know your route back. Before you need to take it.
Tell us which service matters most. We will discuss the recovery questions, evidence and next steps for an appropriate review.