Disaster Recovery Journal Spring 2025

objective (RPO) as controls and targets designed to restore application function ality and data availability within periods aligned with our business users’ key per formance requirements. Both objectives include the restoration of historical data as a component of the process, with an asso ciated time cost for completion. Users are typically asked to identify the acceptable times for these objectives based on their business needs as part of a business impact analysis (BIA) and as a part of business continuity planning. However, RTO and RPO miss the opportunity to serve business users who rely on an application where the avail ability of historical data is secondary to the primary advantage of having the tool available to capture and record current information in real time. This presumes no transactional accuracy factor is linked to the unavailability of historical informa tion. Sometimes, there is a big business advantage to just having the application functionally restored and usable, regard

less of the presence of historical data. For example, automated timecard/ punch clock applications can provide tremendous value to management in col lecting real-time attendance and payroll tracking information without the imme diate need for yesterday’s, last week’s, or last month’s data from the moment it is returned to service following a disruption. In this situation, there is good business reason to separate the restoration of func tionality from the availability of historical data as combined requisites to releasing the tool for use by users. The working theory here is: get it working to perform its primary function, get it back in service, and worry about catching up the prior data later. A necessary understanding associated with this strategy is whether the applica tion of interest can tolerate a “data payload free” recovery. Some applications will not recover without risking data corruption if new transaction data, meant to be either unique or sequential to historical infor

mation, is processed without full records content serving as a guide to file naming and storage conventions. This condition is an important aspect that should drive a feasibility discussion between the busi ness continuity practitioner and IT and DR professionals supporting the application to determine whether this strategy is techni cally possible. We can execute a measure of continual improvement by formalizing this concept and designing a business continuity strat egy and DR technical procedure around it to save the amount of time it takes to recover backup data before getting the app back in service. Let’s refer to this new service option as the “recovery operabil ity objective” (ROO), defined as: “The period of time between the occurrence of a technology application disruption and the functional return to service of that tech nology without associated historical data.” See Figure 1 for a graphical representa tion of the working relationships between ROO, RTO, and RPO.

DISASTER RECOVERY JOURNAL | SPRING 2025 33