Lurking in the nightmares of CIOs is the insecurity that their disaster recovery/business continuity (DR/BC) plans will not protect them when a real disaster strikes.
Yet most DR/BC plans focus only on the primary event -- the natural or man-made disruptions -- and fail to include safeguards and defenses against the aftershocks. For many, the legal aftershocks can be the most destructive, burying a company in litigation over broken contracts, fines, penalties and attorney fees that economically cripple the business far more than the disaster's damage.
The Sarbanes-Oxley and Health Insurance Portability and Accountability acts, as well as emerging corporate governance legal standards, all have the potential to create significant legal adversity if a disaster disrupts the availability or integrity of your business records. Yet a 2007 Symantec Corp. international survey reports that nearly half of corporate tests of DR/BC plans result in failure. Imagine how a pack of lawyers could consume your company's reputation, brand and image if your DR/BC plan does not stand up against the disaster. Yet, that same survey reported nearly 77% of CEOs still fail to take an active role on their DR/BC committees.
Most company CIOs have plans in place with some level of formal approval, but sometimes that commitment is less than total in terms of monies and attitude. Regardless of your situation, here are five key strategies for improving your plan and enabling your company to better survive the legal aftershocks.
1. Conduct -- and document -- a detailed business impact analysis. Each business faces a unique portfolio of disruptive risks; an inquisitive and demanding analysis to identify those risks, their impact on the IT assets and operations and the criticality with which those assets and operations are restored is essential to the planning process.
But many companies overlook the legal importance of documenting and preserving the records of their analysis -- those records become vital in demonstrating after the fact the care with which the enterprise has acted in designing its plan. Your records should demonstrate, among other items, the organization of your analysis, who was interviewed, industry reports, external input (auditors and lawyers), historical incident reports and the decisions taken to include or exclude specific adversities against which the plan will be developed.
2. Capture -- and document -- all of the external requirements for any DR/BC plan. Regulated companies -- particularly in financial services, health care and industries with vulnerability to terrorist acts -- already face regulatory mandates for DR/BC plans. The plans enable the company to better assure the availability of business records legally required to be preserved.
But many companies, particularly nonpublic companies, overlook contract-based requirements obligating the company to continue operations despite adverse events. Even more companies fail to make sure their contracts contain DR/BC-related terms and conditions that will excuse performance for all of the events for which a plan has been devised.
Smart CIOs will focus on not just physical and IT assets and their exposure to disasters. They will also insist that the business impact analysis fully account for all regulatory and contractual requirements, and make sure those requirements are documented. The analysis needs to take account of contracts that require amendment in order that disasters for which the plan is implemented do not create unexpected legal adversity. For example, if an embedded virus contaminates your electronic fulfillment center, how do you avoid liability for the affected shipping contracts?
All of these records should be incorporated into the core risk analysis -- the contracts, the legal analysis and, of course, the importance to the company of protecting against those kind of adversities. The CIO cannot rely on others to do so; ultimately, the CIO is responsible for the overall adequacy of the planning process.
3. Test, measure and validate the DR/BC plan's effectiveness. One of the most important services to incorporate into any DR/BC plan is the periodic and rigorous testing and measurement of its effectiveness. Plans have to include continuous management -- scenarios have to be practiced, secondary sites have to be activated, people need to be relocated to alternative offices. Validating that the plan produces the correct results -- and revealing where corrections are needed in the plan's details -- helps improve responsiveness in the event of an actual adverse event.
Creating and retaining good records of the testing program is essential to proving the legal reasonableness of the plan. When you have the records that demonstrate the plan was tested and was working, you are much better protected against later challenges.
A common DR/BC legal aftershock is the need to defend the company against claims from third parties -- e.g., customers that lost sales because of the company's inability to supply them with new inventory. The adequacy of the BC/DR plan is often the focus of those claims. The CIO who can prove the BC/DR plan was responsive to identified risks can be a hero in the courtroom.
4. Design records availability into the BC/DR plan. Most plans focus on restoring operations that need immediate access to operational data (the essential purpose of backup tapes). But plans -- even good ones -- will often overlook the continuing duties of the business to maintain the availability of business records essential to support audits, regulatory reports and contractual obligations. Disasters that destroy or disrupt the availability of those records can have significant legal aftershocks. Most experts believe there is no "safe harbor" when companies are unable to meet their duties to produce required records following a disastrous event.
A good DR/BC plan will emphasize preserving the availability of essential records, including the documents that relate directly to the plan itself. Many companies create good documentation of their plans (in other words, they have complied with items one through three above), but do not recognize the importance of those records. Within records management programs, the DR/BC plan and all related documents are vital records and should be provided suitable protection.
5. Amend your "legal controls" to reflect the DR/BC plan. CIOs build DR/BC plans by developing controls that respond to prioritized risks. However, contracts and governance procedures are also important "legal controls" to be used in implementing a plan. A CIO needs to follow through by making sure the legal controls are properly amended. For example:
- Regulated businesses -- including midmarket companies that service regulated businesses --
should communicate the existence of their plan to the appropriate regulatory authorities.
- CIOs should insist their legal teams evaluate existing contracts and pursue suitable amendments
that align the company's legal obligations with the DR/BC plan.
- Future contracts should routinely include attention to DR/BC issues. One useful step is to make sure, through contracts, that your suppliers have appropriate DR/BC plans in place. You want to make sure they can live up to your requirements for continuing operations in the face of natural or human-caused disasters.
There is little question that CIOs will be on the front line when it's time to defend the company against the inevitable legal aftershocks of a disaster. Be prepared for when -- not if -- you have to defend your DR/BC plan after a disaster. Here is a more complete project map of these strategies.
Following these strategies and taking real steps to make sure your company is truly ready for the next business interruption could make it easier to sleep at night. At the very least, your dreams won't morph into nightmares featuring chaotic disaster recovery scenarios.
Jeffrey Ritter, Esq., is CEO of Waters Edge Consulting LLC in Reston, Va. Waters Edge offers strategic consulting services to develop improved information governance. For comments and questions on this column, write to him at firstname.lastname@example.org.
This was first published in September 2008