When an important IT system fails, two questions have immediate consequences for your business operations. How much data could be lost, and how long can it take before employees can resume their work? The answer varies between organisations, but also between business processes. An administrative system being unavailable for a few hours may be inconvenient. In a production environment, logistics process or order processing operation, the same few hours can cause considerable disruption.
In IT, these limits are referred to as RPO and RTO. The terms have technical origins, but the choices behind them are primarily business decisions. They determine which recovery provisions are necessary, which investments are justified and which risks an organisation consciously accepts.
RPO
RPO (Recovery Point Objective) describes the maximum acceptable data loss following a disruption.
RTO
RTO (Recovery Time Objective) describes the maximum time a system or business process may remain unavailable.
Both values must be determined on the basis of the consequences for business operations. Only then can an assessment establish whether backups, recovery procedures and other technical provisions are sufficient to achieve these objectives in practice.
RPO: how much data can you afford to lose?
Suppose your organisation backs up its administrative system every day at midnight. If that system fails the following afternoon and only the latest backup can be restored, all changes made since midnight could be lost. These might include orders entered, financial postings, changes to customer details or other transactions.
The RPO specifies the maximum data loss the organisation considers acceptable, expressed in time. With an RPO of four hours, it must be possible to restore data to a recovery point that is no more than four hours old when an incident occurs. A daily backup is generally insufficient for this. More frequent backups, transaction logs or other forms of data protection may be needed.
Not every system requires the same RPO. A longer period may be acceptable for a document archive that changes very little. For a system that continuously records orders or production results, even an hour of data loss can have significant consequences. This is not just about the amount of data, but above all about whether lost information can be re-entered and what consequences this has for customers, employees and business processes.
RTO: how long can your business operations remain at a standstill?
The RTO concerns the time available to make a system or process usable again following a disruption. When the RTO for a business-critical application is four hours, this means the organisation expects it to be operational again within four hours of a disruption.
This involves more than restoring a backup. An application may depend on servers, databases, network connections, identity services and external services. Even when all the data is available, employees may still be unable to work if one of these components is missing. Recovery time must therefore be assessed in the context of the entire business process, rather than solely in terms of the technical task of restoring data.
Here too, the priorities vary by process. An internal reporting environment may be able to remain unavailable for a day without serious consequences. A system needed for production planning, warehouse operations or customer orders may need to be recovered much sooner. The shorter the required recovery time, the greater the need will generally be for additional provisions, preparation and investment.
Backup frequency does not guarantee recovery
In practice, RPO and RTO are sometimes derived from the technical provisions already in place. For example, a backup is made daily, so it is assumed that no more than one day's worth of data can be lost. Or it is assumed that a server can be restored within a few hours, without checking whether the associated business process will also function again at that point.
This reasoning reverses the proper sequence. First, the consequences of data loss and downtime for the organisation need to be established. Appropriate objectives can then be determined, along with whether the existing IT environment can support them. A backup can be technically successful while the actual recovery time turns out to be much longer than expected.
In addition, recovery under normal circumstances may differ from recovery following a security incident. When systems may have been compromised, it is first necessary to establish which components can be used safely. Restoring an untrustworthy environment too quickly can cause another disruption. A realistic RTO therefore also allows for investigation, checks and the conditions for safely bringing systems back into use.
What happens when orders are lost?
A trading business processes orders in an ERP system throughout the working day. A backup is made every night. On a busy afternoon, the database becomes corrupted and recovery turns out to be possible only from the previous night's backup. The organisation therefore has a usable copy of its data, but is missing all the orders and changes from that day.
Technical recovery is only part of the problem. Employees need to establish which orders are missing, which customers have already received confirmation and which deliveries may no longer match the records. Some of the information can be reconstructed from emails and other systems, but this takes time and introduces new errors.
If the organisation had established in advance that no more than one hour's worth of order data could be lost, the existing backup provision would have been assessed as insufficient. And if order processing needs to resume within four hours, it would also be necessary to investigate whether the entire ERP environment can be recovered within that time. The value of RPO and RTO lies precisely in revealing these gaps before a disruption occurs.
Four steps towards realistic recovery objectives
RPO and RTO only become useful when business expectations, technical capabilities and responsibilities have been aligned. Four steps are important in achieving this.
- Business impact: Which processes are critical, and what are the consequences of data loss and downtime?
- Recovery objectives: What are the maximum acceptable data loss and recovery time for each process?
- Technical feasibility: Can the current provisions, dependencies and suppliers support these objectives?
- Testing and adjustment: Do recovery tests show that the objectives are achievable, and do they remain appropriate as the organisation changes?
Establishing these values requires collaboration between those responsible for business processes and those who manage IT. Management or the process owner can indicate which consequences are acceptable. IT can then assess what is technically possible, which dependencies are involved and which measures are needed to support the required recovery time and permitted data loss.
When the desired objectives cannot be achieved with the available resources, this must be discussed explicitly. Sometimes additional investment is necessary. In other cases, the organisation may decide to accept a longer recovery time or put temporary working procedures in place. What matters most is that this trade-off is made consciously and does not come to light only during an incident.
From an objective to demonstrable recovery capability
An agreed RPO or RTO does not in itself prove that recovery is possible within those limits. This requires an examination of how backups, infrastructure, applications and recovery procedures are actually configured. The availability of suppliers and employees also plays a role. When recovery depends on a single specialist or an external party without clear agreements, an objective that looks achievable on paper may still prove unattainable in practice.
Recovery tests reveal how long the various steps actually take and whether the data is sufficiently up to date. It is important to check not only whether a system starts, but also whether employees can carry out the necessary work. A database that is technically available has limited value if the application cannot connect to it or essential integrations are missing.
RPO and RTO therefore belong in a broader recovery plan. This sets out the recovery sequence, dependencies, responsibilities and decision-making arrangements. Regularly testing and updating these arrangements provides a more realistic picture of the continuity the IT environment can actually offer.
Do you know what recovery time your organisation needs?
Many organisations know that backups are being made, but have not established how much data loss or downtime is acceptable for their most important processes. This leaves it unclear whether the provisions in place match the actual business risks. RPO and RTO help turn that uncertainty into concrete, testable agreements.
Malenco assesses recovery capabilities in the context of the business processes that depend on them. We look not only at data availability, but also at the technical and organisational conditions for safely resuming work.
Would you like to know whether your recovery provisions meet your organisation's needs? Malenco helps you understand realistic RPO and RTO objectives and the measures needed to support them.
