Tolerance for critical application downtime is rapidly dwindling in the mid-market. Today, in fact, a tolerance of less than fifteen minutes is not uncommon. With availability requirements like that, there’s simply no excuse for not building an IT disaster recovery plan—and doing it right.
And, to get it right requires active participation across all business units, so that everyone at the table has a clear understanding of both data risk and expectations for recovery.
Sure, you have to have the right resources and technology to deliver against recovery objectives, but without this foundational knowledge, you’ll simply be making a guess that could be catastrophic to the livelihood of the organization.
So, where do you begin?
Let us walk you through some key elements of the disaster recovery planning process.
Set recovery expectations
Unfortunately for IT teams, we live in a world where end users have become "iPhone-ified." They expect data and applications to be available anytime, anywhere—and with touch-of-a-button ease. Furthermore, there’s an expectation that if something goes wrong, recovery can happen swiftly—and without data loss.
That, obviously, is not always the case—and it’s a conversation you should be regularly engaging in with other business units. It’s crucial that everyone understands the gap between what the organization wants—and what can actually be delivered.
Sometimes, tough choices have to be made.
Document business objectives and availability requirements
Next up, you need to fully document both business objectives and the criticality of the data and applications you’re protecting. And, these are business decisions—not IT decisions.
In other words—if you want to do good BCDR, you really need to know your business before you can determine an acceptable level of IT risk. You simply can’t begin to approach discussions about infrastructure, services, or software without that understanding, first.
So, again, bring everyone to the table and ask your various business units: What is the actual amount of downtime we can sustain for each application we—and our customers—touch?
Then, identify interdependencies to ensure no single piece of the disaster recovery puzzle has been neglected.
That means mapping out how data flows from one application to the next, enabling you to gain a clearer picture of what needs to be protected — and with what level of availability. Because, if an app in the value chain can’t be recovered with the speed necessary to support another critical app, you’re dead in the water.
Think beyond costs—thoughtfully consider ROI
You’ve ensured both sides of the equation—IT and other business units—have a clear understanding of RPOs and RTOs for each application within your environment.
Now comes the tricky part.
Getting buy-in for infrastructure improvements, given the competing demands for business investment dollars.
That’s why it’s really crucial to discuss the huge discrepancy between the cost of your disaster recovery solutions, which are a recurring costs — and your loss expectancy should your systems go down for an extended time, or you lose them entirely.
All it takes is one catastrophic failure for your investment to be fully recouped, right?
Consider the impact of a manufacturer’s lengthy ERP system outage on the global supply chain. Or, the loss of potential donations when a non-profit loses the server that hosts its Raiser’s Edge application. More damaging, consider the threat to patient health when electronic medical records are encrypted.
The point is, you can't look at the improvement of your IT infrastructure as a cost, you have to consider it as an ongoing investment in the health of your organization.
Invariably, things will happen — people will lose data, you’ll be infected by ransomware, servers will blow up, you could even find yourself in the path of a massive natural disaster.
Test the reliability of your disaster recovery solution
So, how often are you testing the recoverability of your critical apps?
Because, you should be testing them all the time.
Disaster recovery testing really needs to be an ongoing effort, so you have confidence in the actual recovery points and recovery times you can achieve.
And, that’s where a backup and recovery solution that offers automated, application-level testing capabilities and reporting comes in — confirming SLAs and giving your IT team and other stakeholders confidence in your RTOs and RPOs.
Test the disaster preparedness of your people
Of course, automated testing covers the technical component of your IT disaster recovery plan, which is great, but it would be unwise to rely solely on automated reports.
The value of a full disaster recovery drill is that you get to see how people behave and identify which processes work—and which don’t. It also allows you the opportunity to verify whether or not your processes have been fully-documented. In both cases, you’ll gain the insight you need to improve your human response—before disaster strikes.
Of course, you should also consider more catastrophic scenarios in your DR plan review.
For example, in the event of a forced evacuation due to a natural disaster, a gas leak, or the like, who will be running the data center?
Carefully consider your contingency plan, should your on-site IT team be unable to perform its disaster recovery responsibilities.
Is your IT disaster recovery plan up to the task?
Granted, ransomware only represents one of many threats you need to take into account when creating your IT disaster recovery plan, but the likelihood of infection—a near certainty now—is changing the game.
As risks of ransomware infection escalate, the importance of a thorough, effective, and rehearsed IT disaster recovery plan has never been more crucial.
Are you ready?
