What are RTO and RPO?

The recovery time objective is how long a function can be unavailable before the impact is unacceptable. The recovery point objective is how much data, measured in time, you can afford to lose. Set them per function with the business, then design backups, replication and recovery processes to meet them, and test that they do.

Does APRA CPS 230 apply to us?

CPS 230 applies to APRA-regulated entities such as banks, insurers and superannuation trustees, and commenced on 1 July 2025. It requires them to manage operational risk, maintain critical operations within tolerance levels through disruptions and manage material service providers. If you supply software to such entities, expect their CPS 230 requirements to flow into your contracts.

How often should we test backups?

Restore tests should be regular and realistic, for example quarterly for important systems, and after significant changes. A backup that has never been restored is an assumption. Test restoring a whole system, not just individual files, and measure how long it takes against your recovery time objective.

Can we guarantee no downtime or data loss?

No. Good continuity planning reduces the likelihood and impact of disruptions and makes recovery predictable, but some risk always remains. Be honest with customers: publish what you have designed for and tested, not guarantees you cannot measure.

Web Development5 min read

Business Continuity for Digital Products in Australia: Backups, Recovery Objectives and Continuity Exercises

Business continuity for digital products in Australia: dependency mapping, RTO and RPO, backups, restore tests, roles, exercises and APRA CPS 230.

How should you plan continuity for a digital product?

Identify the product's critical functions and everything they depend on, agree with the business how long each can be down (RTO) and how much data it can lose (RPO), design backups and recovery to meet those targets, keep backups separate from production, assign roles, and run restore tests and continuity exercises regularly. For APRA-regulated entities, CPS 230 sets formal operational resilience requirements. No plan eliminates outages or data loss; the aim is predictable recovery.

This guide is for product owners, CTOs and operations leads. For what to do during a security incident, see cyber incident response planning; for store-specific recovery, ecommerce disaster recovery.

Key takeaways

Start from critical business functions, not from servers.
Map dependencies, including suppliers, SaaS tools, DNS, payments and identity.
Set RTO and RPO per function with the business.
Keep backups separate from production credentials and networks; test restores.
Plan alternative arrangements for key suppliers.
Exercise the plan and fix what exercises reveal.

Step 1: Critical functions and dependencies

List the functions customers and the business rely on, such as sign-in, ordering, payments, bookings, reporting, and map their dependencies: application services, databases, cloud regions, third-party APIs, payment providers, email and SMS, DNS, identity providers, and the people and runbooks needed to operate them. Single points of failure become visible quickly.

Step 2: Recovery objectives

Function	Example RTO	Example RPO	Implications
Checkout and payments	Short	Near zero	Replication, tested failover, payment provider fallback
Customer accounts	Short to moderate	Small	Frequent backups or replication
Internal reporting	Longer	Moderate	Daily backups may be enough
Marketing site	Moderate	Moderate	Static hosting and CDN help

Worth noting

The values above are placeholders to show the method; set real objectives with your business owners. Tighter objectives cost more.

Step 3: Backup strategies

Back up databases, file storage, configuration and infrastructure definitions.
Keep at least one copy separate from production accounts and credentials, immutable or offline where possible.
Protect backup systems with MFA and least privilege; attackers target backups.
Encrypt backups and know where they are stored (APP 8 if overseas).
Match backup frequency and retention to RPO and legal retention needs.
Regular backups are one of ASD's Essential Eight mitigation strategies.

Step 4: Restore tests and exercises

Restore a full system to a separate environment regularly and time it against the RTO. Run continuity exercises for realistic scenarios: a cloud region outage, ransomware encrypting a database, a payment provider outage, a bad release that corrupts data, or loss of a key supplier. Record what worked, what took too long and what was missing, then fix it.

Step 5: Roles and communications

Name who declares a continuity event, who leads recovery, who communicates with customers and who liaises with suppliers. Keep contact lists and runbooks available offline. Prepare status page and customer message templates. If an event involves a cyber incident, follow your incident response plan, including reporting obligations such as the Notifiable Data Breaches scheme and, for businesses over A$3 million turnover, ransomware payment reporting (Home Affairs).

APRA CPS 230 for regulated entities and their suppliers

APRA's Prudential Standard CPS 230 Operational Risk Management commenced on 1 July 2025 for APRA-regulated entities (APRA). It requires entities to identify critical operations, set tolerance levels for maximum disruption time, data loss and minimum service levels, maintain a credible business continuity plan and manage material service providers. Software suppliers to these entities should expect continuity, testing and notification requirements in contracts.

Common mistakes

Backups that share credentials with production.
No restore test, so recovery time is unknown.
Ignoring third-party dependencies such as DNS and identity providers.
Recovery objectives set by engineers without the business.
Promising customers uptime the system cannot measure.

For related guides, see API integration reliability, application monitoring, DevOps for growing businesses, maintenance contracts and payment gateway integration for payment provider fallbacks.

Conclusion

Business continuity for digital products is about knowing what matters, what it depends on and how fast you can recover, then proving it through restore tests and exercises. Keep backups out of attackers' reach, plan for supplier failures, and be honest about what you have designed and tested for.

Can you recover your product quickly?

ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on resilient web applications and mobile apps. If it would help to map dependencies and recovery objectives, we are happy to talk it through.

Start a Project

FAQ

Common questions.

It is the planning and capability that keeps a digital product's critical functions available, or restores them within acceptable limits, when something fails: a cloud outage, a ransomware attack, a broken release, a supplier failure or a data corruption. It combines dependency mapping, recovery objectives, backups, alternative arrangements, roles and regular exercises.