Americas

  • United States

Asia

Oceania

Contributor

Workarounds without data?

Opinion
Apr 06, 20122 mins
Cloud SecurityDisaster Recovery

A big part of business continuity planning is making sure we have manual processes or other workarounds in place.  They act as interim bandages to keep business processes moving forward.  Many organizations, especially those required to do so by regulation, have documented processes sitting in a file server somewhere waiting for a server, system, or data center event.  Sitting on a file server?

In addition to the risk of not placing up-to-date documentation in the recovery bin at the off-site storage location, there is one glaring piece of the recovery puzzle missing: the data.  What good is a workaround if employees can’t access customer information, product availability, payment processing information, etc.   We sometimes forget when building our response plan that it’s still all about the data.

Data is on tape or cloud-based backup?  Excellent.  How long will it take to get it on a new server and available to business  users?  The time it takes to reconnect business users with data is also process downtime.  Whether your data is quickly available or, as with many traditional DR plans, available within 24 hours, should depend on management’s understanding of maximum tolerable downtime (MTD).  While the MTD of payroll might be 24 hours, how acceptable is having order entry and shipping systems down that long… or longer?

In years past, it was usually cost-prohibitive to ensure almost immediate access to data when a business continuity event occurred.  That is no longer true.  Cloud vendors provide reasonably priced  solutions for data storage, system hosting, etc.  Choosing one that is secure with recovery of data access within two or three hours should not be out of reach for most organizations.  For larger organizations, building a second, backup, data center just for the most critical systems is another option.

Like all security planning, how you meet this challenge depends on a risk assessment and business impact analysis.  Just keep in mind that users today are less forgiving than they were in the olden days when you tell them to call back because the computer’s down…

Contributor

Tom Olzak is an information security researcher and an IT professional with more than 34 years of experience in programming, network engineering and security. He has an MBA and a CISSP certification. He is an online instructor for the University of Phoenix, facilitating 400-level security classes.

Tom has held positions as an IS director, director of infrastructure engineering, director of information security and programming manager at a variety of manufacturing, healthcare and distribution companies. Before entering the private sector, he served 10 years in the U.S. Army Military Police, with four years as a military police investigator.

Tom has written three books: Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide. He is also the author of various papers on security management and has been a blogger for CSOonline.com, TechRepublic, Toolbox.com and Tom Olzak on Security.

The opinions expressed in this blog are those of Tom Olzak and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.