You could win a FREE BCM Program Evaluation.
For details go to www.stone-road.com. Good Luck!!
In simple terms, the Recovery Point Objective (RPO) is the maximum tolerable period in which data may be lost from an IT service/system outage or disruption, as caused by a disaster or other incident. For example, if you take overnight backups, the recovery point objective will often be the end of the previous day’s activity. This means that when a disaster occurs, business units can either agree to have some level of data loss, which is what will happen, or choose to have no data loss what so ever. If the latter is the case and no data loss is acceptable, then Technology Restoration & Recovery Plans and related strategies must be developed to meet that need.
Too often, the RPO is identified in the BIA and is captured as a question asked of business unit representatives; what is your expected loss tolerance or what is your RPO? I’ve never met a single department manager that didn’t say they could tolerate any data loss. In fact, it’s almost a given that business units won’t allow for any data loss, even when systems are not available under dire situations. Business units can request a desired RPO – usually at not loss or 0 hours – but the business unit isn’t the one to drive this…at least not at first.
I’ve stated before in other posts that the Technology department should go through the BIA process, as they aren’t immune to outages due to disasters, pandemics and other crises. It’s the technology department that should be identifying the RPO, as it currently stands. Business Units may state what they want the RPO to be but it’s the IT department that states what it is. IT is responsible to take stock of the current technology restoration and recovery procedures and provide the corporation with the RPO; what it would be if a disaster occurred that day.
Identifying the RPO can expose some misconceptions with the expectations many have and what the corporation believes to be in the TRP. If you ask most business managers, they assume that data and systems will be available when they need it. Sure, IT performs backups of systems and data and when a user accesses a system to obtain information, it will be there – and it’s always current. That may be true but that means that backups are performed in real-time, which is rarely the case. Only the multi-national corporations that have money to spend can build mirrored systems and built-in redundancy – though that’s becoming something rare these days based on the current economic climate.
If a disaster occurs and backups are only performed once every 24 hours, then during a disaster the data that is recovered is only as good as the last completed – and accessible – backup. That means an entire day can go by where data is manipulated and updated by users but if a disaster occurs, all that data will have been lost because the backup hadn’t occurred yet. So even though the business unit wants zero loss in data, they will automatically be set back by 24 hours – will have lost 24 hours of work. The RPO is 24 hours based on the current technology strategy.
If that is the case and business is unwilling to accept the RPO – and loss of data, then technology must request resources to amend the strategy. Then appropriate actions are taken. This could be to reconfigure current technology restoration and recovery strategies by acquiring new (or more) equipment; reducing the time of backups from once every 24 hours to 12 hours (or less) and other strategy implementations. All intended to meet the accepted and approved RPO.
No one wants too loss data. No one wants to experience a disaster. Still, when a disaster occurs, the RPO (and related Recovery Time Objectives (RTOs)) is what the corporation is going to use to build business continuity plans, technology recovery plans and any crisis management (especially PR and Media plans).
The point when data and systems are expected is the point upon which the corporation will be judged. If they aren’t up and running by the time they’ve stated and have data available when they expect it – and haven’t lost any of it – the public and any partnerships will consider the corporation to be untrustworthy and unable to manage negative situations. The RPO isn’t just the point at which data is last available or the point at which it is current but it’s also the point the point that a corporation must be able to do business – on some level. This is because client will want to know that their information is safe and hasn’t been compromised – or lost – because of the disaster. If it has, the negative perceptions of the corporation will begin.
The BIA helps identify the gaps here and if lucky, the IT department will get some extra funding to ensure that RPO’s and RTO’s can be met. So always remember, the RPO is more than just a point in time; it’s a time that makes a point.
“Heads in the Sand: What Stops Corporations From Seeing Business Continuity as a Social Responsibility” and “Made Again Volume 1 – Practical Advice for Business Continuity Programs”
by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3