Category: Tech Law

Starbucks is a well known, international purveyor of coffee products, with thousands of stores throughout the world.  Starbucks v. Wolfe’s Borough Coffee, Inc., No. 01 Civ. 5981 (LTS)(THK), 2005 U.S. Dist. LEXIS 35578 (S.D.N.Y. Dec. 23, 2005) (Starbucks I).  Starbucks Corporation was formed in 1985 in Washington State, after the original founders had been in business for themselves since 1971 in the Seattle Pike’s Place Market.  Id. at 3. Under a traditional trademark analysis, Starbucks has spent a substantial amount of money to market its coffee products worldwide (over one hundred thirty-six million dollars worth from 2000-2003).  Id. at 5.  One should not use a trademark similar to “Starbucks” without expecting trouble.

In 2004, Wolfe’s Borough Coffee, a small coffee manufacturer that distributes its brands in a store in New Hampshire and through some New England supermarkets, was sued by Starbucks in the southern district of New York for trademark infringement and dilution under the Lanham Act and state law.  Id. at 6.  Wolfe’s Borough Coffee was trading with two allegedly infringing names: “Mr. Charbucks” and “Mister Charbucks,” both similar to the trademark “Starbucks” used by the famous coffee house of the same name.  Starbucks v. Wolfe’s Borough Coffee, Inc., 559 F. Supp. 2d 472 (S.D.N.Y. June 5, 2008) (Starbucks III).  Yet, Starbucks lost in district court on all of its claims.  Starbucks I, 2005 U.S. DIST LEXIS 35578 at 29.  Starbucks appealed, the second circuit reversed in 2007 because of a change to the Lanham Act in 2006 by Congress through the Federal Trademark Dilution Act, and the trial court affirmed its prior decision in favor of the defendant in 2008.  Starbucks v. Wolfe’s Borough Coffee, Inc., 477 F.3d 765 (2nd Cir. 2007) (Starbucks II); 15 U.S.C. §§ 1125(c), 1127 (2008); Starbucks III.

Starbucks Claims
Starbucks sued Wolfe’s under federal and state law, alleging trademark infringement under sections 1114 and 1125(a) of the Lanham Act, trademark dilution under sections 1125(c) and 1127 of the Lanham Act and also under New York law, and unfair competition under state common law.  15 U.S.C. §§ 1114(1), 1125(a) (2008); Id. at §§ 1125(c), 1127; N.Y. Gen. Bus. Law § 360-1 (1999).  This case note will focus on the allegation of trademark dilution.

In order to prove trademark dilution, the plaintiff must demonstrate that (a) the plaintiff’s mark is famous, (b) the defendant is using commercial use of the famous mark, (c) the defendant’s use came after the plaintiff’s use, and (d) the defendant’s use of the plaintiff’s mark dilutes the plaintiff’s mark.  Starbucks I, 2005 U.S. DIST LEXIS 35578 at 22.  The defendant had conceded the first three elements leaving only the last element of the rule in dispute.  Id.

Moseley v. Victoria’s Secret Catalogue, Inc., 537 U.S. 418, 433 (2003) requires a plaintiff to prove actual dilution rather than a likelihood of dilution in order to prevail under the Lanham Act anti-dilution section.  New York law is less stringent than federal law in this area, and the court reasoned that if the plaintiff could not prevail under state law, it also could not prevail under federal law.  Starbucks I, 2005 U.S. DIST LEXIS 35578 at 25.  The court examined the likelihood that the defendant’s use of its marks would either blur or tarnish the plaintiff’s marks, and concludes that plaintiff could not prevail under either standard.  Id. at 30.  Blurring occurs when a defendant uses the plaintiff’s mark to identify defendant’s products, increasing the possibility that the plaintiff’s mark will no longer uniquely identify plaintiff’s products.  Id. at 25.  Tarnishment occurs when a plaintiff’s mark is associated with products of a shoddy or unwholesome character.  Id. at 26.

The court’s review of the record caused it to conclude that the plaintiff had failed to demonstrate actual or likely dimunition “of the capacity of the Starbucks Marks to serve as unique identifiers of Starbucks’ products…” because the plaintiff’s survey results did not show an association with the defendant and the mark “Charbucks,” only that respondents associated the term “Charbucks” with “Starbucks.”  Id. at 27.  The court also held that the plaintiff’s survey results did not substantiate that the mark “Charbucks” would reflect negatively on the Starbucks brand.  Id.  Plaintiff therefore lost on its dilution claims.

Change in Dilution Act
Prior to 2006, dilution of a famous mark required that the plaintiff demonstrate actual dilution to prevail under section 1125(c) of the Lanham Act.  Moseley, 537 U.S. at 433.  However, Congress amended the applicable statute to only require that the defendant’s use was “likely to cause dilution.”  Starbucks II, 477 F.3d at 766.  The second circuit held it was not clear if the amended Lanham Act’s prohibition of dilution of famous marks was coextensive with New York law, the latter being the basis for the trial court not finding dilution of Starbucks’ marks.  Id.  Therefore, the appeals court vacated the trial court’s judgment and remanded for further proceedings.  Id.

On Remand
The district court took back up the Starbucks case under the amended anti-dilution statute.  To demonstrate blurring of a famous mark, the amended Lanham act requires a court to consider all relevant factors including: “(i) the degree of similarity between the mark or trade name and the famous mark; (ii) the degree of inherent or acquired distinctiveness of the famous mark; (iii) the extent to which the owner of the famous mark is engaging in substantially exclusive use of the mark; (iv) the degree of recognition of the famous mark; (v) whether the use of the mark or trade name intended to create an association with the famous mark; and (vi) any actual association between the mark or trade name and the famous mark.”  Starbucks III, 559 F. Supp. at 476 (citing 15 U.S.C. § 1125(c)).

Degree of Similarity
The district court held that a plaintiff must demonstrate under this element that the marks are very or substantially similar.  The court pointed out that the defendant’s marks appear on packaging that is very different from the plaintiff, and the defendant used the rhyming term “Charbucks” with “Mister,” where Starbucks appears alone when used by the plaintiff, therefore the court found this factor to weigh against the plaintiff.  Id. at 477.

Distinctiveness of Starbucks Mark
Given the extent of the use of the Starbucks mark by plaintiff and the amount of money expended by the plaintiff in its marketing program, the court found this factor favored the plaintiff.  Id.

Exclusive Use by Starbucks
The fact that the plaintiff polices its registered marks, and the amount of money spent on using the mark both led the court to weight this factor in favor of the plaintiff.  Id.

Degree of Recognition of Starbucks’ Mark
Again, given the longevity and number of customers that visit Starbucks stores, the court found this factor to favor the plaintiff.  Id.

Defendant’s Intent to Associate with Starbucks’ Mark
The court finds that while the defendant intended to allude to the dark roasted quality of Starbucks brand coffees, the fact that the marks are different and the defendant had not acted in bad faith led the court to weigh this factor in favor of the defendant.  Id. at 478.  The court reasoned that the defendant used this mark to distinguish its own lines of coffee products, with the Mr. Charbucks brand being the dark roasted coffee as compared to other Wolfe’s Borough/Black Bear coffees.  Id.

Actual Association with Starbucks’ Mark
Here, the court found that while there was an association with the Starbucks’ mark to some respondents to the survey conducted by Starbucks, this association alone is not enough to find dilution.  Id.  Instead, the court found that the defendant’s marks would not cause customers to confuse the defendant’s products with the plaintiff’s.  Rather, customers would tend to see the playful reference to a quality of Starbucks’ coffee – the dark roast – to distinguish one kind of Wolfe’s Borough brand coffees from other Wolfe’s Borough brand coffees.  Id.

Tarnishment Analysis
The amended Lanham Act also provides a specific definition for dilution by tarnishment: “an association arising from the similarity between a mark or trade name and a famous mark that harms the reputation of the famous mark.”  15 U.S.C. § 1125(c)(2)(C) (2008).  The court held that the plaintiff’s survey evidence could not support a finding of dilution by tarnishment, because the plaintiff’s survey was susceptible to multiple and equally likely interpretations.  Starbucks III, 559 F. Supp. at 480.  In addition, the court found that the defendant’s coffee products were not of actual poor quality, so any actual association between the defendant’s coffees and Starbucks would not likely be damaging to Starbucks.  Id.

As a result, Starbucks lost its case on remand for trademark dilution.  One might almost say that Starbucks has become so synonymous with quality dark roasted coffees that their brand name can’t be diluted by other quality coffee brands.  Instead, the Starbucks mark is a victim of its own success in the world.  Add that to the list of reasons why a Starbucks on every street corner is not a good idea.

In 2009, Massachusetts become the first state to mandate that those storing personal information of residents of Massachusetts comply with specific security practices as required  under 201 CMR § 17.00.  These standards went into effect on January 1, 2010.  The following is an analysis of how the Massachusetts legislation lines up with the existing HIPAA security standards that are described in detail in 45 CFR § 164 as promulgated in 2003 and effective in 2005.

Scope
Section 17.01(2) applies the Massachusetts regulations to any persons that “own, license, store, or maintain personal information about a resident of the Commonwealth.”  201 C.M.R. § 17.01(2).

The HIPAA security regulations apply to “covered entities,” which are health plans, clearinghouses, and health care providers that transmit health information in electronic form.  45 C.F.R. § 164.104.

The HIPAA security regulations are national in scope, but limited to health care entities, where the Massachusetts regulations apply to any entity that may store personal information on a resident of Massachusetts.

Section 17.02 defines “personal information” as a Massachusetts resident’s first and last name, or first initial and last name, in combination with a social security number, driver’s license number, or financial account number.  201 C.M.R. § 17.02.

The HIPAA security regulations are applicable to “protected health information,” which is defined as “individually identifiable health information.”  This definition has been interpreted to include a patient’s name, social security number, date of birth, and other patient identifiers, along with clinical diagnostic information or other data that might be stored in a health care provider’s records related to patient care.  45 C.F.R. § 160.103.

The information to be protected by the two regulatory schemes is overlapping but distinguishable; the Massachusetts regulations are aimed at protecting financial information like credit card account numbers, where HIPAA is aimed at protecting health information.  However, an health care provider that provides services to Massachusetts residents would be obligated to comply with both regulatory programs.

Designee to Maintain Security Program
Section 17.03(3)(1) requires that an employee be designated to maintain the security program of the organization.  201 C.M.R. § 17.03(3)(1).

The HIPAA security regulations require that a person be designated who is responsible for developing organizational policies to support compliance.  45 C.F.R. § 164.308(a)(2).

Risk Assessment
Section 17.03(3)(2) requires a risk assessment of security risks to both paper and electronic systems containing personal information. 201 C.M.R. § 17.03(3)(2).

The HIPAA security regulations require that a risk analysis and risk management process be implemented at the covered entity.  45 C.F.R. § 164.308(a)(1)(ii).

Policy on Information Transport Off Business Premises
Section 17.03(3)(3) requires the development of an organizational policy on the transport of personal information off business premises. 201 C.M.R. § 17.03(3)(3).

There is no specific provision under the HIPAA security regulations that would require a specific policy on transporting protected health information.

Disciplinary Policy
Section 17.03(3)(4) requires the imposition of a disciplinary policy for violations of the security program. 201 C.M.R. § 17.03(3)(4).

The HIPAA security regulations require that a sanction policy be developed for violations of the security policies of the covered entity.  45 C.F.R. § 164.308(a)(1)(ii)(C).

Terminated Staff
Section 17.03(3)(5) requires that the security access of terminated staff be immediately terminated through a deactivation of the user’s account. 201 C.M.R. § 17.03(3)(5).

The HIPAA security regulations require that a procedure be implemented to terminate access for separated staff, but the regulation does not require “immediate” termination of access.  45 C.F.R. § 164.308(3)(ii)(C).

Third Party Service Providers
Section 17.03(3)(6) requires that entity’s that have personal information and relationships with third parties take measures to ensure third party compliance with the security regulations.  201 C.M.R. § 17.03(3)(6).

The HIPAA security regulations require that covered entities enter into business associate contracts with third parties that may have access to electronic protected health information of the covered entity.  See 45 C.F.R. § 160.103; 45 C.F.R. § 164.314(a).

The American Recovery and Reinvestment Act of 2009 (ARRA) went further with regards to business associates; section 13401 requires that business associates specifically comply with the HIPAA security regulations found in 164.308, 164.310 and 164.312.  ARRA § 13401.

Limiting Data Sets
Section 17.03(3)(7) requires that the minimum data set be collected by an entity that collects personal information.  201 C.M.R. § 17.03(3)(7).

The HIPAA security regulations do not specifically address this requirement.

System Identification
Section 17.03(3)(8) requires that an entity identify what records or systems contain personal information, so that these records or systems can be handled in compliance with the security policies of the organization.  201 C.M.R. § 17.03(3)(8).

The HIPAA security regulations do not specifically address, but such a system by system identification would likely occur within the risk analysis conducted by the covered entity under section 164.308(a)(ii)(A).  45 C.F.R. § 164.308(a)(ii)(A).

Physical Access
Section 17.03(3)(9) requires reasonable restrictions on physical access to paper records to prevent unauthorized disclosure of personal information. 201 C.M.R. § 17.03(3)(9).

The HIPAA security regulations do address physical access to the covered entity’s facilities, but do not address how paper records should be secured.  See 45 C.F.R. § 164.310.

Monitoring
Section 17.03(3)(10) requires monitoring of the security program to ensure effectiveness. 201 C.M.R. § 17.03(3)(10).

The HIPAA security regulations require regular monitoring of the security program to ensure that protected health information remains secure.  45 C.F.R. §§ 164.306(e), 164.316.

Review
Section 17.03(3)(11) requires the at least annual review of the security program. 201 C.M.R. § 17.03(3)(11).  The Massachusetts rules also contemplate review of the security program when an entity substantially materially changes its business practices.

The HIPAA security regulations do not specify a minimum review period for the security programs of covered entities, however, the typical practice for risk analysis and review is to conduct such a review on an annual basis.  See 45 C.F.R. § 164.308(a)(ii)(A).

Documentation and Incident Reporting
Section 17.03(3)(12) requires the documentation of an entity’s response to security incidents. 201 C.M.R. § 17.03(3)(12).

The HIPAA security regulations do require a covered entity to implement a policy for reporting and responding to security incidents, and the regulations provide for a requirement that activities taken under the security program be documented.  45 C.F.R. §§ 164.308(a)(6), 164.316.

Secure User Authentication
Section 17.04(1) requires a detailed secure user authentication process that controls user logins, passwords, restricting access to only active users, and locking accounts after a number of unsuccessful login attempts.  201 C.M.R. § 17.04(1).

The HIPAA security regulations address the issue of user authentication more generally by requiring that a policy be developed to grant access to users based on prior authorization.  See 45 C.F.R. § 164.308(a)(4).  In addition, the regulations require a policy on managing passwords, but are not specific on how the details of how passwords are to be managed or created.  45 C.F.R. § 164.308(a)(5)(ii)(D).

Access Control
Section 17.04(2) requires a detailed access control process that restricts access to personal information and requires unique usernames and password combinations assigned to each user with access to personal information.  201 C.M.R. § 17.04(2).

The HIPAA security regulations require unique user identification under section 164.312(a)(2)(i).

Encryption
Section 17.04(3) requires the encryption of all personal information that is transmitted over a wireless or public network.  201 C.M.R. § 17.04(3).

Section 17.04(5) specifically requires that personal information on laptops or other portable devices be encrypted.  201 C.M.R. § 17.04(5).

The technical safeguards of the HIPAA security regulations address generally the need to encrypt electronic protected health information, but do not address specifically when this information must be encrypted.  45 C.F.R. § 164.312(a)(2)(iv).  The transmission security section only requires that security measures be implemented to “guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.”  45 C.F.R. § 164.312(e).  Wireless, however, is not specifically addressed in the HIPAA security regulations, as this technology was still nascent when the original regulations were written in the late 1990’s.

The HIPAA security regulations do not specifically require that the contents of laptops or other portable devices  be encrypted.

Monitoring
Section 17.04(4) requires monitoring of unauthorized access of systems.  201 C.M.R. § 17.04(4).

The HIPAA security regulations also require the recording and examination of activity in information systems.  45 C.F.R. §§ 164.312(b), 164.308(5)(ii)(C).

Systems Connected to the Internet
Section 17.04(6) requires a firewall and up-to-date operating system patches for any system connected to the internet that contains personal information.  201 C.M.R. § 17.04(6).

The HIPAA security regulations do not address these specifics, though most security experts would agree that a firewall is a minimum security feature for controlling unauthorized access to protected systems from the internet.  The issue of operating system patches is not addressed either, but, at least for Windows systems, the patching of security threats is also now a minimum feature of any organizational network.  Other operating systems and applications also regularly release patches that ought to be applied, but most of the game is in securing your Windows systems.

Anti-virus Software
Section 17.04(7) requires up-to-date anti-virus software be in use.  201 C.M.R. § 17.04(7).

The HIPAA security regulations also require some kind of protection from malicious software.  45 C.F.R. § 164.308(5)(ii)(B).

Education
Section 17.04(8) requires education and training on best security practices for all personnel that use information systems.  201 C.M.R. § 17.04(8).

The HIPAA security regulations require that covered entities provide security awareness training for all staff in the organization, and require “periodic security updates.”  45 C.F.R. § 164.308(a)(5).

Summary
Much of the Massachusetts requirements for personal information correspond to the protections mandated under the HIPAA security regulations, however, there are some specific threats which have occurred more recently that the Massachusetts regulations respond to, particularly laptop and portable device security, and the specific and ongoing threat to Windows-based computer systems.  Need help managing your technical security?  Give us a call for help.

The Health Insurance Portability and Accountability Act (HIPAA) granted the Secretary of Health and Human Services the power to establish regulations for covered entities, including the information security policies of the entity.  An important aspect of the security regulations is regularly assessing risks to the entity’s information systems and infrastructure under section 164.308(a)(ii)(1) of the security regulations.  For those of you attempting to qualify for meaningful use incentives, risk assessments are a part of the core 15 metrics, making documented risk assessments mandatory.

The regulation specifically requires a covered entity to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.”  Id.  This analytical process is helpful to the organization for several reasons.  First, doing an inventory of the information systems in use in the organization helps to categorize the extent of exposure of the organization to security threats.  Second, spending time on identifying known problems or vulnerabilities helps to clarify what should be budgeted for mitigating these problems.  Third, all risk assessment methodologies require an organization to balance the potential impact of the risk against available mitigations, and to choose a reasonable mitigation (one which costs less than the adjusted risk to the organization of loss).

However, the contents of a risk analysis are not defined with the security regulations, and such an analysis is not self-defining. There are a wide variety of analytical tools available today to help a provider assess risk to his business organization.  For example, the Centers for Medicaid and Medicare (CMS) created a risk assessment document that aids a provider in categorizing existing information systems, evaluating what risks exist to those systems, what mitigations are in place to reduce risk, and what risks remain that are sufficiently great that either additional mitigations are required or the business owner must accept them in order to continue to operate the system.   See Centers for Medicare & Medicaid Services (CMS) Information Security Business Risk Assessment Methodology, version 2.1 (May 11, 2005).

The CMS methodology also provides a guide to evaluating a specific risk by estimating the likelihood of the risk’s occurrence, and if left unmitigated, what impact the risk would have on business operations.  Those risks of a certain risk level or higher are those that require mitigation, helping an organization to prioritize which identified mitigations should be implemented first.  Id.  For example, risks to a payroll system, while critical to an organization’s efforts to operate, may not be critical as a health record system because the organization may only provide paychecks every other week, whereas the organization’s staff access the health record system for each patient visit on a daily or hourly basis.  Alternatively, the data in the payroll system may be at less risk overall (either because the system has fewer vulnerabilities or has less overall data) as compared to an electronic health record system.  Following this qualitative methodology helps organizations to reason through their relative risks and identify potential mitigations.

An alternative methodology follows a similar process, but instead utilizes estimates of the value of systems to the business, the likelihood that the risk will be realized, and a calculated value to the organization of potential mitigations of that risk for a particular period (for example, one year).  See Shon Harris, All-In-One CISSP, 73 (3rd ed. 2005) McGraw Hill/Osborne.  For example, if a the provider operates an electronic health record system, and the value of that system to the organization is 500,000, the provider could then identify various risks that exist to the data in that system and their relative likelihood of occurring, thus calculating the maximum value of an effective mitigation of that risk.  For example, if the risk identified is a computer virus, the analyst would take into consideration how many computer viruses are written for the system platform, what kind of damage a typical virus could do to the system, the history of virus infection of the systems in place in the organization, and other factors that impact virus infection.  In addition, the analyst would examine what efforts would be required to restore the infected information system to normal operations, and what data could be lost as a result to calculate the percentage of the system’s base value that would be affected by the risk.  Multiplying the base value of the system by the likelihood of the threat’s realization and by the scope of the risk’s impact on the base value gives an annualized risk value.  “Reasonable” mitigations of this risk should therefore cost less than this annualized risk value.

This quantitative approach is helpful for estimating risk and valuing mitigations, especially where the covered entity can identify the costs of mitigations (such as an anti-virus solution or disaster recovery system).  Something very unlikely to happen should usually not be mitigated with a very expensive solution.  Need help performing a risk assessment?  Give us a call for assistance.

The Health Insurance Portability and Accountability Act (HIPAA) 42 U.S.C. § 1320(d-1)(b) empowered the Secretary of Health and Human Services to promulgate standards for health care providers that “shall be consistent with the objective of reducing the administrative costs of providing and paying for health care.” Under Section 1320(d-2)(d), Congress empowered the Secretary to establish regulations for the security of health information. Under that grant of power, the Secretary promulgated rules on technical security in 45 C.F.R. section 164. Section 164.308(a)(7)(ii)(B), under the heading “disaster recovery plan,” requires that a covered entity establish “procedures to restore any loss of data.” The next section requires that the covered entity be able to operate its critical business processes during an emergency while still protecting the security of its protected health information.

Recovering from a disaster is a relatively complicated matter for most health care providers that have implemented a sufficiently robust system or network. This is because many health care providers regularly use a system for email, a system for managing appointments and billing, a different system for accounting for expenses and payroll, another system for managing health records, and other supporting systems (such as a Windows domain controller, file and print sharing, and other administrative servers). In some cases, rather than hosting these servers in-house, some providers have contracted with outside vendors that provide hosting services, or application service provider (ASP)-models for specific applications used by the provider.

The complexity of a recovery is increased by the nature and number of disasters that could occur to a provider’s information systems. For example, disasters include uncontrollable events such as hurricanes or floods, fires, and other natural disasters, but could also include technical failures such as a widespread and uncontrolled computer virus, or concerted terrorist activities that disrupt electrical power or harm human life.Each risk presents a different set of issues for a health care provider.

The other part of the recovery equation is what the organization’s expectation is for the time to recover from a system failure, and the relative tolerance of the organization for an outage. Some health care providers that operate all the time (like an emergency room) may not be able to tolerate long outages in order to provide care effectively for patients. Smaller providers may not be able to tolerate a long outage because of the financial impact on their practice. However, some systems may be less critical for recovery because their loss will not immediately stop a practice from seeing patients. Sorting out the complexity of recovery requires planning before a disaster hits.

Risk Analysis

Section 164.308(a)(1)(ii)(A)-(B) of the regulations require that all covered entities engage in regular risk analysis and risk planning and take action on this analysis to reduce risks to electronic protected health information. This analytical process is helpful in guiding the development of a disaster recovery plan because the risk analysis identifies all systems and data in use in the business organization, and helps to guide the organization to those systems that are sufficiently critical to require disaster recovery. Of those critical systems, some may require a more complicated or expensive disaster recovery plan in order to make them available more quickly in a disaster. For example, a payroll system, while critical to an organization’s efforts to operate, may not need to be available as quickly as a health record system because the organization may only provide paychecks every other week, whereas users access the health record system for each patient visit on a daily or hourly basis.

Developing A Recovery Plan

Once the organization has assessed its risks, the organization can develop a plan to manage those risks, which includes setting expectations for recovery time, describing particular disaster scenarios and the organization’s response to those scenarios, and identifying the resources needed to effectively recover from particular disasters. The organization’s plan can also identify when an organization will re-open for business following a disaster, whether or not the provider anticipates having to operate during a disaster (such as an emergency room staying open during a bioterrorism event), what the chain of command will be to respond to a disaster, and a communication plan for letting customers and staff know the status of the organization during and after an event.

The systems team can use this high level plan to examine in more detail the individual systems in play in the organization, and can evaluate what methods for recovery can be cost-effectively implemented to meet organizational requirements. For example, a weekly digital tape backup may be adequate for less critical systems that change little from week to week, whereas a real-time replication system may be required for highly critical data.

Testing and Making Plan Changes

Once a systems recovery plan has been developed, testing the plan is absolutely essential to ensure that the plan on paper will actually work in a real disaster. Practice is important for several reasons. First, systems staff that participate in testing will have a better idea of what to expect if a system failure occurs and will be more capable of responding to it. Second, testing helps to identify missing steps or pieces of the plan which can be addressed by the systems department before the next round of testing. Third, testing helps to identify how much training will be required for systems staff to be able to effectively respond to a failure. And finally, involving the end users in the testing cycles helps to set expectations appropriately should an actual disaster occur.

Keeping Up With System Changes

Doing a risk analysis, creating a recovery plan and testing the plan is most of the preparation for recovering from a disaster, but the systems that belong to the plan will change with time. All systems have patches and upgrades that need to be applied each year. In addition, organizations routinely add new systems, which may present new challenges for recovery planning. And, of course, personnel trained to perform recoveries will change with time, which will require that new staff that join the team be trained on system recovery. Do not underestimate the time and effort required to include additional systems in the testing and recovery plan.

Mitigating Disasters

Mitigations, like anti-virus software, automatic patching and control systems, firewalls and other border control devices, organizational policies on system account controls, robust permissions, and other mitigations are also absolutely essential to any disaster recovery process. As any systems veteran will tell you, avoiding a systems recovery is a systems department’s top priority. But mitigations are not an excuse for not having a disaster recovery plan, because no mitigation will be one hundred percent effective at preventing all system failures. Being prepared is always the best policy.

Need help getting your systems department prepared for disasters? Give us a call or send us an email.

Being able to recover from a major system failure is essential for most businesses today. The key to recovery, beyond implementing technology that supports disaster recovery, is to practice for disasters. That means periodically meeting with members of the organization to review the process an IT department will go through in order to, step by step, bring critical systems back from an uncontrolled virus attack, hurricane, or major hardware failure. The table top exercise described below is a relatively inexpensive way for an organization to discuss scenarios for systems recovery and identify issues in the current disaster recovery plan.

Pre-Meeting Setup
The exercise will be most effective if ahead of time a network diagram is created that provides the following details for the existing information system:

• Local network geographic locations
• Workstations, network switches, routers, servers, phone systems, and related equipment
• Local and Wide area network connections, speeds, and carriers
• Existing contracts for business continuity services
• Matrix of existing IT staff and areas of expertise

Where possible, the network diagram should identify the high level systems in place in the organization, and degree of criticality of each system to continued business operations in the event of a disaster. The criticality of a system determines its priority in a recovery effort.

In addition, if the organization has a policy on systems availability or the operations of the organization during particular disasters, this policy should be available to staff in the meeting. This policy may identify disasters where the organization will continue to operate, the chain of command to respond to system disasters, and organizational expectations for recovery time objectives.

Meeting Content
With the network diagram, the IT/IS department should meet with its leadership and senior staff, and some representatives from the business units served by the information systems for approximately two hours. A member of the meeting should be designated to take notes on the course of the meeting, and a different member should be designated as moderator. Notes taken should be organized by disaster, and should identify which staff resources were available during each scenario, potential issues with recovery that were identified during the discussion, and open questions about configuration or recoverability.

Meeting Process
During the meeting, the following activities should take place:

1. A disaster scenario for discussion should be identified which will impact business operations.
2. Members of the team should identify what systems will be unavailable, the estimated length of the interruption to service, what IT resources will be available to respond to the disaster, and what impact the unavailable systems will have on continued business operations.
3. Members of the team should then work through the stated policy on Disaster Recovery for the organization, and identify the operational and technical steps required to recover the affected system or systems.
4. The group should come prepared to discuss experience with similar recoveries, and identify potential issues with performing a timely recovery of data. Relevant to the discussion is the fact that such a recovery has not been previously tested, or other known resource limitations on performing a recovery based on the scenario.
5. A member of the team should be identified as the note keeper for the discussion, and will be responsible for distributing notes of the meeting to all participants.

The process above should be repeated so that the group can address two to three disaster scenarios during the meeting. The total length of the meeting should be limited to two hours.

Post-Meeting Review
Following the meeting, a list of issues to be addressed should be created which should form the basis for a project or work plan. Where necessary, a budget for capital and/or ongoing expenses and resources should be developed based on the work plan. Research may need to be conducted on potential technical solutions or workarounds to identified issues during the exercise. In addition, the policies of the organization may need to be reviewed or modified in order to reflect actual practice in responding to disasters, or based on feedback from the team meeting. A technical testing plan may also be required based on the findings or proposed technical solutions to a systems failure.

A follow-up table top exercise should then be scheduled, based on the estimated time required to be able to appropriately address the issues identified in the previous table top exercise. Results from successive table top exercises can be used to demonstrate progress in preparedness for disasters.

For more details or information on how to conduct a table top exercise, see The National Institutes of Standards and Technology, special publication 800-84, section 4-1. Need help organizing or facilitating a table top exercise? Contact us for more information.