By Sungard AS
Your company is prepared. You have your disaster recovery (DR) plan written and available on an externally-hosted website. Your contracts are in place; your backups are verified and off-site. Your critical data is replicated to your DR provider. You have plans for all your people if the disaster impacts them and your facility. Bring on the zombie apocalypse: you are ready!
Umm … maybe you'd better hope those zombies stay in their graves a little while longer. You see, when I consult with clients, I always ask a certain question … and it usually punctures their self-congratulatory bubble. Ready? Here it is:
"Have you tested your external connections under disaster recovery conditions?"
You know … the external connections to key applications like your Customer Relationship Management (CRM) software, payroll, human resources, SAP, etc. The applications that, in large part, keep your business in business.
The first response I usually get is, "Oops! We didn't think about that." The next one I get is the defensive, "There's no problem if our primary facility goes down because those applications are hosted!"
Well, I hate to disillusion you, but you need to think about this; it doesn't matter that the applications may be hosted. Here's why.
Please, validate me.
Here's the situation: a disaster closes down your primary facility. You failover to a secondary facility, or potentially have people work from home. Suddenly, your people can't log into their critical applications! Why not? Because getting to those applications isn't simply a matter of typing in a URL and poof! there you are. Many applications demand validation before they let users in.
This validation happens behind the scenes. Simply put, the external application is expecting users from your company to be coming from specific IP address ranges against a certain copy of your Active Directory.
If login attempts begin coming from different IP addresses and/or the Active Directory cannot be accessed, the application will not validate them. It assumes that a hacker is attempting to get in under your identity! The result: your people are locked out.
This could be a problem. A big problem. Just imagine not being able to access SAP at a critical juncture. The effect might be worse than all those zombies running around loose!
Fortunately, the fix is relatively easy. You simply need to have your security guys tell your externally-hosted applications that "Hey, 98% of the time, our people will be logging in from these IP ranges and against this Active Directory. But if your system can't validate us there, look at this alternative set of IP ranges and secondary Active Directory copy." Make sure that both possibilities can be validated.
May I serve you?
It's not only your people who can have validation problems if you fail to test your external connections. Your servers are also at risk.
Say that your systems send daily or weekly feeds to third-party vendors. If your primary location is out of commission, you might be able to send files, but your vendors may not be able to receive them because their system won't validate data coming from your failover server! Conversely, your vendor might send you a feed, but if it is directed to your primary location (rather than your failover location), you may never get it.
Again, get your security guys involved. Let them know the various permutations of where data may need to come from and go to. They can take it from there so that you can be confident your servers will continue to serve your needs.
Don't forget the hardware.
Here's another scenario: some services you use may require a physical appliance at your site. Perhaps your email or your cloud services, etc. You may be outsourcing the service, but it still might require a piece of hardware to function.
Have you accounted for any such required devices in your failover plan? Who will pay for the second device? Who will maintain it, both from a hardware and code level standpoint? How will it be tested? The answers to these questions can make or break your resiliency in a time of crisis.
Go back to the original question …
Your external connections are critical to your internal operations. There's no question of that. But let's assume that you do your homework in each of these areas and all your external connections have been verified to work perfectly in a disaster recovery situation. Can you check that off your list permanently?
By no means. Remember my original question? "Have you tested your external connections under disaster recovery conditions?" As with all components of your DR plan, you need to test your external connections regularly. Why? Because in our IT world today, it is very, very easy to add applications, change servers, make adjustments, and otherwise throw your DR plans out of whack. Testing ensures that in a crisis, you won't have to make one more crisis call to your vendors about your external connectivity.
Now, you're ready. Bring on the zombies!
Related Business Solution: Disaster Recovery as a Service (DRaaS)