Disasters happen in the world, some of which may directly affect your organization. Preparing for disasters, whether they be hurricanes, tornadoes, terrorists, hackers, power outages, fires, or earthquakes, means thinking about: (a) how your business operates today, (b) how your business would likely operate in the event of a disaster, (c) and developing some kind of testable plan for recovering from a variety of disasters that is practical but well-designed. Preparedness is also a commitment to ongoing planning and the investment of a certain amount of resources each budget period to the process, because your plan will evolve with the extent and scope of your business as it changes over time.
In Maryland, there are not specific ethics rules that require lawyers to prepare for disasters, though common sense would tell an attorney that missing a deadline because of a disaster is still a missed deadline, and the loss or inadvertent disclosure of confidential client information is still a loss whether or not caused by a natural disaster or simple human error. Both circumstances can lead to an ethics complaint from a disgruntled client. For attorneys, there are a number of resources available from the ABA to help firms do a better job of preparing for a disaster.
Doctor’s offices that are joining the electronic health record system revolution because of the incentives under ARRA, also will need to have a plan for disaster recovery. The HIPAA security regulations include standards for preparing for recovering from disasters (45 CR § 164.308(a)(7) is addressed specifically to contingency planning for covered entities and business associates). The security regulations are cloaked in terms of “reasonableness,” which means that a covered entity’s disaster recovery planning efforts should be commensurate with the amount of data and resources it has. So, a practice of two physicians that sees 8,000 patient visits a year is not expected to have its data available in three DR hot sites. But, if you are a major insurance carrier, three DR hot sites might not be enough for your operation. However, in neither case is no plan an acceptable answer. Nor is a plan that has never been tested.
Risk Assessment
So where do you start? The logical starting point is a risk assessment of your existing systems and infrastructure (also required of covered entities under the HIPAA security rules in section 164.308(a)(1)). A risk assessment will guide you through gathering an inventory of your existing systems, and help to identify known and potentially unknown risks, along with the likelihood that such a risk will be realized and what you are doing now (if anything) to mitigate that risk. The risk assessment will also help you to categorize how critical a system is to your operations, and will also identify severe risks that remain unmitigated. This resulting list helps you to come up with a starting place for the next step: doing something about it.
The Disaster Plan
In parallel, you can also use the inventory of your existing systems and risks to develop a disaster recovery plan. First, you now have a list of your critical systems which are your highest priority to recover in the event of a failure. Second, you also have a list of likely risks to those systems with the likelihood based in part on your past experience with a particular disaster. These lists help you to identify what you need to protect and what you need to protect from. The other two questions you need to ask for each system are: (a) how much data can I stand to lose in the event of a disaster? and (b) how long can I wait to have my system restored to normal operations?
This analysis of your existing systems, risks, and business requirements will help lead the practice to a plan that includes procedures for how to function when systems are unavailable, and how to go about restoring an unavailable system within the business requirements of the practice. Once you have your plan, and have implemented the systems or policies required by the plan, your next step is to test the plan. Table top exercises allow you, in a conference room, to walk through the staffing, procedures, and possible issues that may arise as a result of a particular disaster scenario. Technical testing permits your IT staff to make sure that a disaster recovery system works according to the expected technical outcomes. Full blown testing is to actually simulate a disaster, perhaps during non-business hours, and actually run through the disaster plan’s procedures for operations and IT.
Hypothetical
As an example, suppose that you have an electronic health record system. This is a critical system based on the risk assessment. In the last five years, you have had a virus that partially disabled your records system causing an outage for two business days, and you have had your database crash, causing you to lose a week’s worth of data. You have implemented two mitigations. The first is anti-virus software that regularly updates for definitions and regularly scans the system for viruses and removes them. The second is a backup system that makes a backup of your system’s data on a weekly basis and stores the data in a separate storage system.
Based on interviews with the practice staff and owner, the records system is used as a part of patient care. During normal business hours, an outage of the system can result in patients being re-scheduled, and also creates double work to document kept visits on paper and again in the record system when it becomes available. The practice has indicated that the most it can be without the system is a single business, and the most data that it can lose from this system is the most recent 4 hours of data entry (which can be reconstructed by the clinical staff that day).
You then evaluate the mitigations in place today that allow for a system recovery in the event of a likely disaster (virus or database crash based on the past experience of the practice). The backup system today only runs once per week, which means that a crash of virus that occurred later in the week would result in more than 4 hours of lost data. Recovery from the backup device to a new server also appears to require more than a business day, because the practice has no spare server equipment available. So you would have to start over with the existing server (installing the operating system, database software, and then restoring the data from the backup), or purchase a new server and have it delivered to complete the restore.
The conclusion here is that while there is an existing mitigation for recovery from a likely disaster, the mitigation does not meet the business requirements of the practice.
Budget for New Sufficient Mitigations
Once you have your list of unmitigated or insufficiently mitigated risks, the next step is to look for mitigations that you could implement on your network. A mitigation might be a disaster recovery system or service, or it might be some other service or product that can be purchased (like anti-virus software, a hardware warranty, a staff person, etc.). At this point, the help of a technical consultant may be required if you don’t have your own IT department. The consultant’s role here is to advise you about what you can do and what the likely costs are to purchase and implement the solution which will meet your business requirements based on your likely risks for disasters.
Once sufficient solutions have been identified, the next step is to purchase a solution and implement it. From there, testing is key as noted above. An untested plan is not much of a plan.
Faith At Law LLC 