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.