The key takeaways
- Start with business priorities and system dependencies.
- Protect backup access and validate the recovery design.
- Record test evidence and assign corrective actions.
Identify the services the business needs first
Ask business owners which activities must return first and what makes them possible. A finance application might depend on a database, identity service, network configuration and a specific supplier. Map these dependencies before writing a restore order. The most visible system is not always the first component that needs to be recovered.
Agree acceptable data loss and downtime
Recovery point objective describes the amount of data loss a business is prepared to accept, measured in time. Recovery time objective describes the target time to restore a service. These are design requirements to discuss with business owners, not values to promise before testing. They affect backup frequency, architecture, connectivity, recovery resources and cost.
Separate the risks to production and backup
Review who can change or delete backups, where recovery credentials are held and what would happen if a production administrator account was compromised. CISA’s ransomware guidance emphasises protected backup copies and testing. The right combination of access separation, offline copies or immutability depends on the workload and the recovery design. Configuration and operational ownership still matter.
Plan for the disruption you actually face
For a South African organisation, a recovery discussion should consider the location’s connectivity, power arrangements, access to equipment and supplier availability. An intact cloud backup is not enough if nobody can connect to the recovery environment. Document practical alternatives and who can approve them. Review whether the proposed approach still works when several dependencies fail together.
Test a business service, not only a file
A file restore is a useful first check, but it does not establish that an application will operate correctly. A scoped recovery exercise can validate access, databases, application services and the sequence of work. Use an agreed test environment, protect production and record the actual result. Involve someone who can confirm that the recovered service supports the business activity.
Turn the findings into a maintained plan
Record what was tested, how long it took, what failed and what needs to change. Assign corrective actions and schedule a review after significant system or supplier changes. Keep recovery instructions accessible during an outage, with clear escalation and communication responsibilities. A modest plan that is owned and exercised is more useful than an ambitious document that cannot be followed.
Further reading
Backup & recovery for your organisation.
Protect the information your organisation depends on and plan how essential services will return. We combine backup design, monitoring, recovery procedures and practical restore testing.
Explore the service