DRAFT

Version 9: 4/24/18

Based on Final Security Rule

HIPAA COW

SECURITY NETWORKING GROUP

CONTINGENCY PLANNING WHITE PAPER

Disclaimer

HIPAA Collaborative of Wisconsin (“HIPAA COW”) holds the Copyright © to thisContingency Planning Whitepaper(“Document”). HIPAA COW retains full copyright ownership, rights and protection in all material contained in this Document. You may use this Document for your own non-commercial purposes. It may be redistributed in its entirety only if (i) the copyright notice is not removed or modified, and (ii) this Document is provided to the recipient free of charge. If information is excerpted from this Document and incorporated into another work-product, attribution shall be given to HIPAA COW (e.g., reference HIPAA COW as a resource). This Document may not be sold for profit or used in commercial documents or applications. This Document is provided “as is” without any express or implied warranty. This Document is for educational purposes only and does not constitute legal advice. If you require legal advice, you should consult with an attorney. Unless otherwise noted, HIPAA COW has not addressed all state pre-emption issues related to this Document. Therefore, this Document may need to be modified in order to comply with Wisconsin/State law.

Table of Contents

I.Introduction

A.What is Contingency Planning?

B.Why Develop a Contingency Plan?

C.Objectives of a Contingency Plan

II.Definitions

III.What Needs to be Included in a Contingency Plan

A.Creation and Administration of Contingency Plan

B.Disaster Recovery Coordinator (DRC) Responsibilities

C.Disaster Recovery Team and Delineated Responsibilities

D.Disaster Recovery Team Contact Information

E.Disaster Recovery Sites

F.Recovery Center/Alternative Site

G.Layout and/or Schematic of Backup/Alternative Sites

H.Disaster Recovery Site Equipment/Inventory Needs

I.Prioritized List of Components of System

J.Current Inventory List

K.Contact Lists

L.System/Vendor Contact Information

M.Contacts for Replacement Hardware/Equipment

N.Law Enforcement/Government Agency Contact Information

IV.Plan Maintenance

A.Testing

B.Maintenance and Revision

C.Responsibility

D.Staff Education and Training

E.Examples of Plans

F.How to Find Appropriate Vendors

G.References and Resources

APPENDIX 1: IS DISASTER RECOVERY TEAM STATUS REPORT – SAMPLE TEMPLATE

APPENDIX 2: SAMPLE INFORMATION SECURITY INCIDENT REPORT FORM

Note: This information has been developed to address information systems (IS) contingency planning/disaster recovery as a separate issue. It is important that the organization’s IS contingency planning/disaster recovery processes can be carried out as a stand-alone process for an isolated IS disaster incident, as well as a complementary component of the organization-wide contingency planning/disaster recovery process. Covered entities should consider reviewing and integrating elements of their Risk Analysis and Security Incident Response (SIR) policies into their Contingency Plans (refer to the HIPAA COW Risk Analysis & SIR policies at .)

  1. Introduction
  1. What is Contingency Planning?

Contingency planning anticipates worst-case disaster scenarios and decides how best to react to them while ensuring the confidentiality, integrity, and availability of ePHI. It looks at what could happen if your data center (or other significant portions of an organization’s infrastructure external or internal to the organization) is partially or totally destroyed or otherwise unavailable and what your organization would need to do to recover from that. It considers what might happen in the case of an epidemic that either quarantines a large number of individuals away from the organization or produces more patients than are routinely handled. It considers natural disasters like a hurricane or fire that destroy much of the infrastructure around the organization. It also looks at lesser problems, loss of individual servers or network components and plans to react to the loss and to recover systems to normal functioning within an optimal period of time, so as to minimize disruptions to the organization’s healthcare functions.

  1. Why Develop a Contingency Plan?

Contingency planning is not an information systems-driven project, but rather it is driven by the business needs of the organization. For example, hospitals plan for disasters because they need to continue to take care of their patients, regardless of circumstances, as long as they have patients. The HIPAA Security Rule requires covered entities and business associates to develop a contingency plan. The Joint Commissionalso requires accredited organizations to have a disaster planning team. The information systems contingency plan should be created in conjunction with that team. All data security contingency plans must be a subset of the organization’s contingency plans and should reference them wherever appropriate.

A key reference when developing a contingency plan is NIST 800-34. This document is available on the NIST web site. It is readable, concise, and provides templates that can be used for developing a contingency plan.

  1. Objectives of a Contingency Plan

The objectives of the contingency plan should be developed by the organization’s senior leadership in conjunction with the Information Systems Department. The contingency plan should be documented, maintained and updated as necessary.Sample objectives may include:

i.To provide the organization with a viable and documented IS contingency plan or Disaster Recovery Plan (DRP) which, when executed, will support a timely and effective resumption and recovery of all interrupted clinical and business operations.

ii.To minimize possible adverse financial, business, and/or clinical outcomes (as applicable) to the organization as a result of an interruption of normal business operations.

iii.To reduce operational effects of an information systems disaster on the organization’s time-sensitive business operations and functions by providing a set of pre-defined and flexible guidelines and procedures to be used in directing resumption and recovery processes.

iv.To meet the needs of the organization’s patients, workforce members, and other stakeholders and communities reliant on the organization’s ability to provide services during and following a disaster situation.

v.To protect the public image and credibility of the organization.

Each organization will need to determine appropriate contingency planning objectives appropriate to its needs.

  1. Definitions(may need to be supplemented or revised based on the organization's specific policy).
  1. Business Continuity Plan: The process of developing and documenting advanced arrangements and procedures that enable an organization to respond to an event in such a manner that critical business functions continue with planned levels of interruption or essential change.
  1. Criticality Level:

i.Mission Critical: Any lack of availability of data has a significant and immediate impact on the treatment of patients. Examples include electronic health records, imaging systems, medical transcription, utilities, or communication channels.

ii.Essential: Required for normal day-to-day operations, but do not directly affect patient care. Examples include materials management, billing, or accounts payable.

iii.Important: Required for operations, but will not prevent patient care or long term functioning. Examples include messaging systems or management reporting systems.

iv.Low: Useful but not essential. Examples include marketing, volunteer check-in, or web sites. Note that each organization must determine its own classification because a payer may find that messaging is a mission critical application where a provider would rate this much lower.

  1. Disaster (Information System): An event that makes the continuation of normal information system functions impossible; an event which would render the information system unusable or inaccessible for a prolonged period of time (may be departmental or organization-wide).
  1. Disaster Recovery Coordinator (DRC): Individual assigned the authority and responsibility for the implementation and coordination of IS disaster recovery operations.
  1. Disaster Recovery Plan (DRP): The document that defines the resources, actions, tasks, and data required to manage the business recovery process in the event of a business interruption. The plan is designed to assist in restoring the business process and loss of data within the stated disaster recovery goals.
  1. Recovery Facilities:

i.Cold Site: A basic facility with adequate space and infrastructure (electrical power, telecommunications connections, environmental controls) to support the organization’s information systems recovery activities. The site would not contain information technology or office equipment.

ii.Warm Site: A partially equipped facility containing all or some of the system hardware, telecommunications and power sources. The site would be maintained in operational status ready to receive relocated staff. The site may exist as a normal operational facility for another system or function, or it may need to be prepared to receive relocated staff and equipment.

iii.Hot Site: A fully equipped facility ready to support system requirements and configured with the necessary system hardware, supporting infrastructure and support staff. The site may be staffed 24/7. Hot site staff is available to begin preparing for system arrival as soon as they are notified.

iv.Mobile Site: A self-contained, transportable shell custom-fitted with specific tele-communications and information technology equipment necessary to meet the organization’s systems requirements; available for lease through commercial vendors. The facility is often contained in a tractor-trailer and may be driven and set up at a desired alternative location.

v.Mirrored Site: A fully equipped facility that replicates the organization’s operations in real-time: identical to the original site in every respect.

  1. Recovery Point Objective (RPO): The point in time to which systems and data must be recovered after an outage, as determined by the responsible business unit(s). RPO is measured in hours or days, as an answer to the question, ‘How many (hours or days) old can the recovered data be?’ or “How recent (hours or days) must the recovered data be?’ or ‘How much data are you willing to lose?’ RPO is the point in time to which data must be restored in order to resume processing.
  1. Recovery Time Objective (RTO): The number of hours or days in which you want to recover a resource or resume a business activity. The Business Continuity Plan is designed to meet the RTOs the company chooses. For example, you might determine that customer service must be functioning again after an interruption within one (1) day. The RTO is one (1) day. You might decide, on the other hand, that the RTO for your email system is four (4) hours. In some Internet businesses, an RTO might be measured in minutes. RTO is the amount of down time before outage threatens survival of the organization/mission critical processes.
  1. Security Incident: Security Incident has the same meaning as the term is used in 45 C.F.R. 164.304. This could include a violation or imminent threat of violation of information security policies, acceptable use policies, or standard security practices; an adverse event whereby some aspect of computer security could be threatened; an IS Disaster would be considered a security incident.
  1. What Needs to be Included in a Contingency Plan

When developing a contingency plan, assign a Criticality Level for systems, data sets, applications, servers, hardware, etc., as applicable. Similar to the risk impact analysis, list the critical functions and determine the organization’s recovery point objective (RPO) and recovery time objective (RTO) for each. Identify the interdependencies/interoperability on other systems, applications, servers, etc. and develop a recovery plan for each. Rank them in order of critical functions and recovery order. Have this approved by the leaders of the organization so the DRC is aware of what to recover first, second, third, should multiple systems be down/damaged. Refer to the “Prioritized List of Components of System” section of this whitepaper for a sample matrix.

Also identify which critical systems, if not all systems, are supported at alternate sites. Are there resources available to support all systems, or only critical ones? Test the sites to verify they support the systems (with backed-up data), should your main facilities be down on an ongoing basis.

  1. Creation and Administration of Contingency Plan

i.Chain of Command: The organization should establish clearly written policies that designate a chain of command, listing names, duties and emergency contact information. The chain of command should provide an order in which authority and power in an organization is maintained and delegated from top management to every member of the organization at every level of the organization. Instructions flow downward along the chain of command and accountability flows upward.

If a chain of command is not already in place in the organization, consider starting with snow emergency or other emergency “code” (i.e. tornado, severe weather, etc.) plans that exist as a starting point to develop a chain of command. Refer to NIST, SANS, TJC, NIMS and other accrediting/licensing agencies, federal, and/or state disaster recovery plansfor guidance.

ii.Communication Strategies: The organization should identify and develop needed communication strategies to use during a disaster. Ideas for communication may address:

  1. IS Disaster Recovery Team Status Report: The DRC will determine the need to complete status reports. The Disaster Recovery Team and all other disaster recovery support team leaders will be responsible for completing the report when requested by the DRC. The DRC will compile information from the status report(s) to use in communicating to senior administrative leadership, corporate resources, and other external contacts and stakeholders (a blank template of this form is available as an attachment to this plan – Appendices 1 and 2).
  2. Administration: The Contingency Plan should identify the administrative leader assigned to the disaster recovery process who shall act as a liaison between the DRC/Team and administration (i.e., the "incident commander"). The incident commander will be responsible for communicating disaster recovery activities on an as needed basis.
  3. Leadership and Workforce Member/Stakeholder Notification: The incident commander, in consultation with the DRC, will determine whether to notify senior leadership, IS staff, and/or others with a need to know. Senior leadership shall be notified of any disaster/security incident that:
  4. Results in adverse patient care outcomes or impacts operational functions;
  5. Requires additional resources and support beyond the scope of the local organization’s resources;
  6. Results in significant financial impact to the organization;
  7. Impacts more than one organization or facility;
  8. Results in critical/key ePHI systems being down for more than (one hour);
  9. Results in denial of physical access to rooms, departments, or buildings;
  10. May result in legal action and/or require preservation of evidence;
  11. Requires involvement with local, state or federal law enforcement agencies; and
  12. Results in adverse publicity and requires media relations skills.

The DRC may also request assistance from other affiliated organizations or other resources. The incident commander or designee may contact the organizations directly or request assistance in coordinating supporting services and resources from the other organizations.

  1. Media/Public Relations: All IS disaster related information (spoken or written) shall be coordinated and issued to members of the media by a designated media relations contact. If no designated media relations contact exists, the organization should assign an individual such as a Communications Coordinator or a member of senior leadership to serve in that role. Certain types of information security incidents may generate the attention of the news media, and there are instances in which the organization may also choose to initiate contact with the news media. For example, local radio and television stations may be utilized to report closings or new hours of facilities. All communications should be made in accordance with internal media relations policies.When feasible, communications to the media should be reviewed by legal counsel prior to release.

The organization’s designated media relations contact should serve as a liaison between the organization and the news media (or a single point of contact for the news media). This will eliminate the need to involve the Disaster Recovery Team members and leaves them free to manage the security incident. The DRC, IS leader or other member of the Disaster Recovery Team should be prepared to share information with the media relations contact. Key considerations when working with the media relations contact person or the news media include:

  1. Ensuring that the contact has a clear understanding of the technical issues so that they may communicate effectively and accurately with the press. False or misleading information may ultimately cause more damage to the organization’s reputation.
  2. Contacting the organization’s legal counsel to discuss legal issues.
  3. Keeping the level of technical detail low – do not provide attackers with information.
  4. Being as accurate as possible.
  5. Avoiding speculation.
  6. Ensuring that any details about the incident that may be used as evidence are not disclosed without the approval of investigative agencies.
  7. Contacting the Privacy Officer and/or HIS Director should information released to media (need to) contain patient specific information to ensure required authorizations are in place prior to the release.
  1. Disaster Recovery Coordinator (DRC) Responsibilities

A sample position description/job action sheet for the Disaster Recovery Coordinator may include the following information as provided in this sample.

Disaster Recovery Coordinator (DRC)
Position Description/Job Action Sheet
Position Assigned To: / IS Leader or Designee
Position Reports To: / President/CEO, CIO, or Designee
Authority Level: / To Be Determined
Mission/Responsibility: / Implement, organize and direct information systems disaster recovery operations. Retrain and test the contingency plan as required by organization policy.
Criticality Level / Job Actions Following IS Disaster Determination
Immediate
(0-6 Hours) / □Review DRC Job Action Sheet and IS DRP
□Identify Disaster Recovery Command Center/Assembly Site
□Notify Disaster Recovery Team Members (see team member examples)
□Assemble Team at Command Center
□Assemble Resources (See Checklist)
□Determine other Resources Needed and Obtain
□Set Up SecureCommand Centers
□Provide Team Briefing/Document Information Provided at Briefing
□Review Tasks to Be Performed and Assign Personnel
□Notify Other Key Leaders/Workforce Members/Incident Commander/Locations Internally as Necessary
□Notify Vendors/Stakeholders/Law Enforcement Agencies and Emergency Government Services as Necessary
□Contact Corporate IS Resources
□Determine Need for Additional Support Teams and Assign Team Leader/Members
□Provide Teams with Status Report Forms
□Request Team Facilitators to Track Resource Utilization on Status Report Form
□Determine Need for Media Communication
□Designate Media Contact; Instruct; All Others Not to Make Statements to Media
□Prepare Media Statement Proactively if Felt Needed
Intermediate
(6-12 Hours) / □Assess Continued Staffing Needs/Staff Relief/Resources
□Follow up on immediate job actions as necessary
Ongoing / □Review updated Status Report Form(s) (see Appendix 1)
□Damage Assessment
□Assess Recovery Priorities
□Communicate IS Disaster Recovery Status with Administration
□Assess Resource Needs for Operations
□Approve Expenses Related to Recovery Processes
Extended
(>12 Hours) / □Assess Need for Staff Relief/Additional Resources
Follow-Up
(Following Disaster) / □Facilitate “post mortem” evaluation of IS disaster and recovery processes
□Revise IS DRP and Processes as necessary
□Train and educate staff on IS DRP Revisions
□Consider conducting new risk analysis to comply with Security Rule
  1. Disaster Recovery Team and Delineated Responsibilities

The organization will need to identify members and determine the scope of its Disaster Recovery Team based on organizational need. Responsibilities are specific to the recovery of information systems; consider the organization’s overall disaster recovery processes when developing these responsibilities. Roles and responsibilities of the IS Disaster Recovery Team members in a medium to large size organization may include: