Every Business Continuity Management (BCM) “standard” uses RP0 (Recovery Point Objective) as a key metric, and nearly every BCM program includes that metric – but few understand it, and even fewer know what to do about it. Should you care?
By definition, RPO is the maximum targeted period in which data might be lost from an IT service due to a disruptive incident. While RTO (Recovery Time Objective) is the minimum amount of time required to recover or restore an IT service or application, RPO is really a measurement of what amount of data might be lost due to that disruption. RPO is wholly dependent upon the frequency of data backup. If, for example, data is backed up in the cloud or in onsite storage every hour, then the RPO is 1 hour. If data is instantly replicated (in the cloud or storage) the RPO might be a matter of seconds. On the other hand, if data is backed up nightly (to tape or other media) the RPO could be 24 hours or longer.
The data replication scheme (including frequency) is managed by IT. If a particular Business Process requires an RPO of less than 10 minutes (perhaps because data is added with every incoming phone call to Customer Service or every online transaction) close coordination with IT is essential to assure that those needs are integrated in the backup scheme.
A disconnect occurs when a Business Process (or ‘function’) expects IT will meet its RPO target – without acknowledgement from IT that it meets the expectation. Unless and until there are conversations between IT and the BCM Team (or between IT and the Business Process itself), expectation of RPO delivery is an assumption – not a fact that can be relied upon in a Business Continuity Plan.
Let’s suppose that conversation has taken place, or at least that IT has made its Recovery Point Capability (RPC) known to the Business Processes. Capability is a measurement of what Recovery Point IT believes it can deliver (you might be tempted to use Actual in lieu of Capability, but I’d argue that – unless the restore had been tested under adverse conditions, ‘Actual’ is an unknown). The Business Process may desire a 1 hour RPO, but IT can deliver a 4 hour RPC. There’s a 3 hour gap.
The resulting task for the Business Process is to figure out how they’ll recovery the original input lost during that 3 hour gap; or how they will deal with the loss if they can’t. That effort may require ingenuity. Recovery may be impossible. Both of the possibilities are at the heart of Business Continuity planning.
Should you care about RPO? The answer is yes. But more importantly, you need to understand its implications (relative to Business Process recovery requirements) and plan to deal with those ramifications.
