As we begin to approach tax season here in the United States, many IT professionals begin to think about government regulation and how it will impact technology in their organizations. You are probably aware of regulatory and compliance laws such as those that govern how the organization must report profits and losses, as well as safeguard and store sensitive information (Sarbanes-Oxley, Gramm-Leach-Bliley, HIPAA). As IT budget numbers are considered, you must remember to earmark funds that cover the hardware and software required to keep your organization in compliance with this variety of regulations.
It is important to remember too, that just because the company suffers a digital disaster, it's not off the hook for compliance. There are two key components to how regulations impact your Disaster Recovery (DR) planning. First is making sure you understand the regulations well enough to know how they will affect your DR plan, and second is making sure you can continue to remain in compliance after a disaster strikes.
Depending on the particular law or laws that govern your organization's type of data, there may be specific minimum requirements regarding solutions that will keep you in compliance. For example, Federal banking laws here in the U.S. nearly always mandate that data must be restored within 24 hours for critical reporting systems. In order to meet the requirements, you'll need to be able to show that the relevant systems are able to restore the data within that time frame, no matter what. Of course, no system is foolproof, but you'll need to be able to show a reasonable potential for successful restoration. There's no telling if you'll ever get called on the carpet for an audit, but if it happens you had better be prepared to show that you're ready to meet or exceed the regs.
After a disaster, not only do you have to get back up and running within the time constraints set forth by regulatory compliance, but you're going to have to continue to ensure that you can meet or exceed standards. This is especially true for privacy regulations like HIPAA, which do not go away just because you're on alternate servers in another location. Quite the contrary, failing over or restoring to new systems is a red flag that you might not be in compliance anymore. In order to prove that the disaster has not destroyed your organization's ability to protect data, you will have to ensure that security and encryption protocols are being enforced at the DR site, and that compliance-software implementations are performing the same tasks at the alternate site as they do at the production site.
Chances are that you could get away with a certain amount of laxness regarding compliance, but that is a gamble that you don't want to take, now that heavy penalties are being levied against some businesses and individuals. I'll spend the next few weeks looking at some of the specific requirements for DR solutions in current compliance laws.