White Paper: Contingency Planning

advertisement
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
HIPAA COW
SECURITY ADMINISTRATIVE SAFEGUARD
POLICY/PROCEDURE WORKGROUP
WHITE PAPER: CONTINGENCY PLANNING
Disclaimer
This document is Copyright  2006 by the HIPAA Collaborative of Wisconsin (“HIPAA
COW”). It may be freely redistributed in its entirety provided that this copyright notice is not
removed. It may not be sold for profit or used in commercial documents without the written
permission of the copyright holder. 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.
Table of Contents
I.
Introduction ............................................................................................................................ 2
A. What is Contingency Planning? .......................................................................................... 2
B. Why Develop a Contingency Plan? .................................................................................... 2
C. Objectives of a Contingency Plan ....................................................................................... 3
D. Applicable HIPAA Security Rule Standards ...................................................................... 3
II. Definitions.............................................................................................................................. 3
III. What Needs to be Included in a Contingency Plan................................................................ 5
A. Activation and Administration of Contingency Plan .......................................................... 6
B. Disaster Recovery Coordinator (DRC) Responsibilities .................................................... 8
C. Disaster Recovery Team and Delineated Responsibilities ................................................. 9
D. Disaster Recovery Team Contact Information ................................................................. 10
E. Disaster Recovery Site ...................................................................................................... 11
F. Recovery Center/Alternative Site ..................................................................................... 11
G. Layout (Blueprint) of Backup/Alternative Site................................................................. 12
H. Disaster Recovery Site Equipment/Inventory Needs ........................................................ 12
I. Prioritized List of Components of System ........................................................................ 13
J. Current Inventory List....................................................................................................... 14
K. Contact Lists ..................................................................................................................... 14
L. System/Vendor Contact Information ................................................................................ 15
M.
Contacts for Replacement Hardware/Equipment.......................................................... 15
N. Law Enforcement/Government Agency Contact Information .......................................... 15
IV. Plan Maintenance ................................................................................................................. 16
A. Testing............................................................................................................................... 16
B. Maintenance and Revision ................................................................................................ 16
C. Responsibility ................................................................................................................... 16
D. Staff Education and Training ............................................................................................ 17
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
1
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
E. Examples of Plans ................................................................................................................ 17
F. How to Find Appropriate Vendors ...................................................................................... 17
G. References and Resources.................................................................................................... 17
APPENDIX 1: IS DISASTER RECOVERY TEAM STATUS REPORT – SAMPLE
TEMPLATE .................................................................................................................................. 19
APPENDIX 2: SAMPLE INFORMATION SECURITY INCIDENT REPORT FORM ........... 20
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 www.hipaacow.org.)
I. Introduction
A. 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 also, 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 hurricane
Katrina 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.
B. 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. We plan for disasters because we need to
continue to take care of our patients, regardless of circumstances, as long as we have
patients. Every organization accredited by JCAHO already has 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.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
2
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
A key reference when developing a contingency plan is NIST 800-34. This document is
available at no cost from the NIST web site. It is readable, concise, and provides
templates that can be used for developing a contingency plan (NIST).
C. 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. Sample objectives
may include:
i. To provide the organization with a viable and maintained IS contingency 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 clinical outcomes, as well as financial and business
impacts, 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.
D. Applicable HIPAA Security Rule Standards
i. 45 CFR § 164.308(a)(7) – Contingency Plan
ii. 45 CFR § 164.310(a)(2)(i) – Facility Access Controls/Contingency Operations
iii. 45 CFR § 164.312(a)(2)(ii) – Emergency Access Procedure
II. Definitions
A. Business Continuity Planning: The process of developing 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.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
3
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
B. Data Classification:
i. Mission Critical: Any lack of availability of data has a significant and immediate
impact on the treatment of patients. Examples include clinical systems like medical
transcription, nursing, lab, radiology, or pharmacy
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 systems. 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.
C. 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).
D. Disaster Recovery Coordinator (DRC): Individual assigned the authority and
responsibility for the implementation and coordination of IS disaster recovery operations.
E. Disaster Recovery Plan: 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 within the stated disaster
recovery goals.
F. 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. 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 telecommunications and information technology equipment necessary to meet the
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
4
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
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.
G. 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. (NIST).
H. 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.
I. Security Incident: 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.
III. What Needs to be Included in a Contingency Plan
When developing a contingency plan, assign a data classification for each system,
application, server, hardware, etc. 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
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
5
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
they support the systems (with backed-up data), should your main facilities be down on an
ongoing basis.
A. Activation and Administration of Contingency Plan
i. Chain of Command: The chain of command should already be defined in the
organization’s emergency preparedness/disaster plan. This should be followed in any
situation in which the entire organization is affected. In situations that affect single
systems, the director of the information systems department, Security Officer, or
designee should determine the appropriate response and implement.
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, JCAHO and other accrediting/licensing agencies, federal, and/or state disaster
recovery plans for guidance.
ii. Communication Strategies: The organization should determine the need to identify
and develop needed communication strategies 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 administrative leader assigned to the disaster recovery
process shall act as a liaison between the DRC/Team and administration. The
leader will be responsible for communicating disaster recovery activities on an
as needed basis.
3. Corporate/System Level: The DRC will determine the need for notification of
the corporate oversight structure and/or IS staff. The Corporate Office shall
be notified of any disaster/security incident that:
a. Results in adverse patient care outcomes or impact operational functions;
b. Requires additional IS resources and support beyond the scope of the local
organization’s IS staff;
c. Impacts more than one organization or facility;
d. Results in critical/key ePHI systems being down for more than (one hour);
e. Requires involvement with local, state or federal law enforcement
agencies; and
f. Results in adverse publicity and requires media relations skills.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
6
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
The DRC may also request assistance from other affiliated organizations for IS
support. The Coordinator may contact the organizations directly or request assistance
from corporate IS in coordinating supporting services and resources from the other
organizations.
4. 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 such as a Communications Coordinator or
a member of senior leadership. 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.
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:
a. 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.
b. Contacting the organization’s legal counsel if unsure of legal issues.
c. Establishing a single point of contact (if no official media relations contact
person exists) when working with the news media to ensure that all
inquiries and statements are coordinated.
d. Keeping the level of technical detail low – do not provide attackers with
information.
e. Being as accurate as possible.
f. Avoiding speculation.
g. Ensuring that any details about the incident that may be used as evidence
are not disclosed without the approval of investigative agencies.
h. 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.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
7
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
B. 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:
Position Reports To:
Authority Level:
Mission/Responsibility:
Criticality Level
Immediate
(0-6 Hours)
IS Leader or Designee
President/CEO, CIO, or Designee
To Be Determined
Implement, organize and direct information systems disaster recovery
operations. Retrain and test the contingency plan as required by organization
policy.
Job Actions Following IS Disaster Determination
□ Review DRC Job Action Sheet and IS Disaster Recovery Plan
□ 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 Secure Command Centers
□
□
□
□
□
□
□
□
□
□
□
□
□
Intermediate
(6-12 Hours)
Ongoing
Provide Team Briefing/Document Information Provided at Briefing
Review Tasks to Be Performed and Assign Personnel
Notify Other Key Leaders/Workforce Members/Incident Commander
as Necessary
Notify Vendors/Stakeholders/Law Enforcement Agencies as
Necessary
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
Communicate Key IS Disaster Recovery Information/Contacts/
Locations Internally
Contact External Law Enforcement or Emergency Government
Services as Necessary
Contact External Vendors and Other Business Stakeholders
Contact Corporate IS Resources
□
□
Determine Need for Media Communication
Designate Media Contact; Instruct; All Others Not to Make
Statements to Media
Prepare Media Statement Proactively if Felt Needed
Assess Continued Staffing Needs/Staff Relief
□
Review updated Status Report Form(s)
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
8
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Disaster Recovery Coordinator (DRC)
Position Description/Job Action Sheet
Extended
(>12 Hours)
Follow-Up
(Following Disaster)
□
□
□
□
□
□
Damage Assessment
Assess Recovery Priorities
Communicate IS Disaster Recovery Status with Administration
Assess Resource Needs for Operations
Approve Expenses Related to Recovery Processes
Assess Need for Staff Relief/Additional Resources
□
Facilitate “post mortem” evaluation of IS disaster and recovery
processes
Revise IS Disaster Recovery Plan and Processes as Necessary
Train and Educate Staff on IS DRP Revisions
□
□
C. Disaster Recovery Team and Delineated Responsibilities
The organization will need to identify members and determine the scope of its Disaster
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
Team Members in a medium to large size organization may include:
Title
Disaster Recovery
Coordinator
Position*
 Director of IS
 IS Leader
 Security Officer
 Administrator
Responsibilities
See Disaster Recovery Coordinator Position Description/Job Action
Sheet
Operations
Recovery
Coordinator
Network Recovery
Coordinator

Implement IS disaster recovery processes; facilitate recovery of IS
operations as directed by DRC.
Clinical
Applications
Coordinator

Business
Applications
Coordinator
Communications
Coordinator
Administrative
Leader







IS Leader or
Technical Support
Person
Local or Enterprise
Network
Administrator
IS Clinical
Applications
Coordinator
Nursing Leader
IS Business
Applications
Coordinator
Business Leader
Director of Public
Relations
President/CEO
Senior VP/CIO
Implement IS disaster recovery processes; facilitate recovery of
organization/enterprise network as directed by DRC.
Implement IS disaster recovery processes as necessary in the absence
of IS applications and systems.
Implement IS disaster recovery processes as necessary in the absence
of IS applications and systems. Track costs and obtain financial
resources.
In conjunction with the DRC and Administration, develop and
authorize communications with news media or public regarding
disaster.
Support DRC/activities.
Investigate insurance coverage and resources.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
9
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Title
Facility Services
Coordinator
Human Resources
Position*
 Other Leadership
Team Member
Director of Facility
Services
Director of Human
Resources
Administrative
Assistant
Responsibilities
Facilitate securing critical resources.
Investigate legal issues.
Under the direction of the DRC, assist in recovery/rebuilding of IS
facilities, facilitate supply and food distribution, and maintain safety,
access to, and security of facilities in support of restoration of lost data
and emergency mode operations.
Implement payroll should payroll systems be down, monitor
conditions for employees, contact employee families, and obtain
childcare for employees.
Provide necessary administrative and clerical support to DRC and
support teams.
*Customize Position Titles Locally
D. Disaster Recovery Team Contact Information
Members of the IS Disaster Recovery Team shall be contacted immediately once the IS
DRP has been activated. The following information should be provided at the time of
contact:
i. A Brief Description of the Problem (e.g., Facilities/Systems Down)
ii. Location of the IS Disaster Recovery Command Center
iii. Phone Number of the IS Disaster Recovery Command Center
iv. Identification of Immediate Support Required (e.g., Services, Equipment, Backup
Tapes, etc.)
v. Information Regarding How the Facility Can be Entered (Need for
Badge/Identification)
A sample contact sheet is as follows. It is absolutely critical that the organization ensure
that this information is current.
Position/Department
DISASTER RECOVERY INCIDENT RESPONSE TEAM
Name
Office
After Hours
Extension/#
Contact Information
Pager Number
Cell Phone
Director, Inf. Services
Security Officer
IS Technician
Clinical Operations
Pharmacy
Administrator/President
Purchasing Department
Security/Plant Mgmt.
Privacy Officer
Risk Manager
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
10
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Position/Department
DISASTER RECOVERY INCIDENT RESPONSE TEAM
Name
Office
After Hours
Extension/#
Contact Information
Pager Number
Cell Phone
Human Resources
Legal Counsel
Media Relations
Business Services,
Patient Relations,
Accounting
Emergency
Communications (who
retains cell phones,
walkie-talkies, etc.)
Other
E. Disaster Recovery Site
The organization shall determine appropriate recovery site needs for the IS Disaster
Recovery Command Center. The Command Center should function as the centralized
location for IS disaster recovery processes. The DRC will make the determination as to
the location of the Command Center. The Command Center location must be able to
accommodate the necessary critical resources and equipment required for disaster
recovery. The organization may want to consider an on-site primary location as well as
off-site options. Refer to the site definitions under Recovery Facilities on page 4 for
considerations of the types of back up sites. Document the steps and resources necessary
to bring the alternative site on-line while maintaining the security of ePHI.
Primary Location
Facility Name:
Floor/Room:
Address:
Phone Number:
Fax Number:
Contact Person:
Phone Number:
Alternate Contact:
Security Considerations (e.g., How to Enter Facility):
F. Recovery Center/Alternative Site
The DRC or IS leadership shall make the determination as to whether or not recovery
activities should be relocated to an alternative site. A pre-determined alternative site
should be designated for major disruptions with long-term effects. The alternative site
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
11
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
should allow the organization to recover and perform systems operations for an extended
period of time. Document the steps and resources necessary to bring the alternative site
on-line while maintaining the security of ePHI.
Alternative Site Location
Facility Name:
Floor/Room:
Address:
Phone Number:
Fax Number:
Contact Person:
Phone Number:
Alternate Contact:
Security Considerations (e.g., How to Enter Facility):
G. Layout (Blueprint) of Backup/Alternative Site
The organization should have determined in advance and obtained a copy of the blueprint
to allow appropriate planning for equipment and telecommunications needs.
H. Disaster Recovery Site Equipment/Inventory Needs
The organization should create a list of disaster recovery supplies and ensure that they are
readily available. The supplies may be kept at the alternative site or maintained in a
manner that would make them readily accessible. Supplies may include:
Recovery Resources Supply Checklist Sample
Workspace
□ Desk, Chairs, Tables, Lights
□ Electrical Support
□ Telecommunications Support
Documentation
□ Hardware Inventory Lists and Serial Numbers
□ Software Inventory Lists and License Numbers
□ Network Schematic Diagrams
□ Equipment Room Floor Grid Diagrams for
Each Facility, Alternate Sites, and Command
Center
□ Contract and Maintenance Agreements
□ Steps to recover systems/applications/networks
□ Steps to recover ePHI
□ Steps to restore lost data
Hardware
□ PC’s/Laptops
□ Printers
□ Scanners
Forms (Each dept. is responsible for determining what
forms to stock in the event any/all systems are
unavailable, the power is out, or there is a nature
disaster. Below are some examples).
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
12
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Recovery Resources Supply Checklist Sample
□
□
□
Server
Wiring
Secondary Power Sources
□
□
□
□
□
□
Software
Back-Up Copies of Data Files
Communications (Identify Location of Each)
□ Telephones
□ Cellular Phones With Chargers
□ Fax and Backup Fax
□ Dedicated Telephone Line(s)
□ Radios (Walkie-Talkie, Weather) As Required
□ Organizational Contact Information/Directories
□ Telephone Directories
□ Telephone Log
Clinical forms to track/monitor patient care
Patient registration forms
Invoices
Human Resources forms (payroll, workers
compensation, etc.)
Maintenance Forms
Message Pads
Other Supplies
□ Office Supplies (pens, paper, folders, paper
clips, scissors, staplers, tape, etc.)
□ Office Equipment (shredder, copiers, etc.)
□ Camera/Video Recorder
□ Film/Blank Recoding Media
□ Duct Tape
□ Backup Media
□ Flashlights and Spare Batteries
□ Area Maps/Site Maps of Each Facility,
Including Alternate Sites and Command
Centers
Other
I. Prioritized List of Components of System
The organization shall prioritize based on business impact/criticality analysis and system
interdependencies to determine what applications, systems, and/or networks are
recovered first. It is recommended that this be determined in advance and approved by
the organization’s senior leadership. A sample matrix is provided below as a template.
The boxes should identify the name of the application, system, network, etc. Other
applications, systems, networks, and interfaces to consider include, but are not limited to,
lab systems (LIS), X-ray systems, specialty testing equipment, master patient index,
interface engines, picture archiving and communication system (PACS), operating
systems, patient insurance eligibility applications, etc.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
13
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Local Application/
System/Network/
Interface
Administration
Admissions
Communications External
Communications Internal
Corporate Integrity
Decision Support/
Reporting Systems
Financial
Critical
Priority 1
RTO: 0-8 Hours
Essential
Priority 2
RTO: 9-24 Hours
Necessary
Priority 3
RTO: 25-72 Hours
Health Information/
Medical Record
Human Resources
Patient Care
Patient
Accounting/Billing
Other
Develop for each application, system, network, and interface written procedures that
identify how to restore lost data, recover existing data, and make ePHI accessible within
the RTO while safeguarding ePHI from inappropriate access and/or disclosure. Include
how to set up equipment, power requirements, reboot, troubleshoot, contain viruses, etc.
J. Current Inventory List
The organization shall have compiled an inventory list of IS equipment, hardware,
software, and key application, system, and network information/specifications. This list
could be a part of a database that stores information about many key IS components,
associated contacts, etc.
K. Contact Lists
The organization shall have compiled contact lists for key workforce members, business
associates, stakeholders, utilities management, disaster recovery specialists, emergency
government contacts, radio and TV stations, etc.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
14
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Examples of other external contacts for assistance may include:
Agency
Electric
Water
Gas
Telecommunications-Phone
Internet Service Provider
Food Services
Emergency
Other
L. System/Vendor Contact Information
In addition to the current inventory list, the organization should maintain emergency
contact information for support and possible replacement of key applications, systems,
and networks. Information for every system, application, server, etc. to be included
should address:
System/Vendor Contact Information
Official System Name
Acronym
System Description
Contact(s)
Phone #
Emergency Phone #
E-Mail
Web Site/Support
Contract Number
Address
Other
As is the case with the Current Inventory List mentioned above, this list could be a part of
a database that includes IS components and associated contact information.
M. Contacts for Replacement Hardware/Equipment
The organization shall ensure the access and availability of this information during an IS
disaster. Consider maintaining this documentation electronically as well as in hard-copy.
N. Law Enforcement/Government Agency Contact Information
Examples of law enforcement and governmental agencies that may need to be contacted
for assistance may include:
Agency
Police Department
Sheriff’s Department
State Patrol
Emergency
Other
911
911
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
15
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Fire Department
Wisconsin Emergency Management1
Federal Emergency Management
Association (FEMA)
Federal Bureau of Investigation
U.S. Secret Service
Other
911
Check Nearest Office
http://emergencymanagement.wi.gov/
Check Nearest Office
IV. Plan Maintenance
A. Testing
The organization shall determine the scope and how often the plan shall be tested. It is
recommended that testing be done on an annual basis as a minimum. Figuring out how to
test can be a challenge. A “table top” drill allows examining alternatives without actually
interfering with any daily operations. All JCAHO accredited organizations are required
to conduct periodic disaster drills. Testing a data contingency plan can be made part of
that. During the normal use of any system, components fail. Documenting how the
system is recovered is also a part of the testing process. A combination of all of these
strategies should provide at least a good start for testing the plan. As demonstrated by the
Katrina disaster, no amount of testing can anticipate all possible problems that may
happen.
B. Maintenance and Revision
The DRP should be reviewed and revised as necessary on an annual basis or as often as
necessary to ensure that the information it contains is up-to-date and reflects current
workforce information (titles, names, and contact information), systems, vendors, and
other external contacts information. Additionally, after each disaster incident, whether a
planned drill or actual disaster, the plan should be reviewed and revised to address
practical application issues.
C. Responsibility
The organization shall designate the individual(s), department(s), or team responsible for
the maintenance and revision of the plan. The organization might consider the following
individuals or structures to be responsible for the plan:
i. Leader/Director of Information Services
ii. Security Officer
iii. Administrative Designee
iv. Consultant
1
Wisconsin Emergency Management specializes in Hazard Mitigation, Warning & Communications, Emergency
Police Services, Disaster Response & Recovery, Hazardous Materials & EPCRA, Radiological Emergency
Preparedness, and Exercise & Training for the State of Wisconsin. Emergency Management efforts are coordinated
with state and federal agencies, as well as volunteer and private sector partners.
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
16
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
D. Staff Education and Training
Members of the organization’s workforce shall be provided education and training in
emergency preparedness and disaster recovery upon hire and as needed to reflect any
significant changes to the organization’s emergency preparedness/disaster recovery
practices including information system disaster events and security incidents. Workforce
members with specific responsibilities for IS disaster recovery shall receive the necessary
education and training required to ensure that they can carry out their assigned duties in
the event of an IS disaster event.
E. Examples of Plans
i. Small Organizations (e.g., Provider Practice) - Refer to Wisconsin Homeland
Security Website, http://homelandsecurity.wi.gov/
ii. Medium Organization (e.g., Independent Hospital) - Refer to NIST Document,
http://csrc.nist.gov/publications/nistpubs/800-34/sp800-34.pdf
iii. Large Organizations (e.g., Integrated Delivery Systems) - Refer to NIST Document,
http://csrc.nist.gov/publications/nistpubs/800-34/sp800-34.pdf
iv. Payor (e.g., Health Plan) – Refer to NIST Document,
http://csrc.nist.gov/publications/nistpubs/800-34/sp800-34.pdf
F. How to Find Appropriate Vendors
The determination of appropriate IS vendors will be based on the organization’s needs.
The organization’s key IS application and system vendors may be able to provide
additional IS disaster recovery support or make recommendations regarding vendor
partners. Additionally, networking with other user groups or professional organizations
will aid in determining appropriate vendor needs and contacts. At a minimum, the
organization should investigate the availability of an electronic restoration vendor and
have that contact information available at all times.
G. References and Resources
i. NIST 800-34, accessed April 20, 2006, http://csrc.nist.gov/publications/nistpubs/80034/sp800-34.pdf
ii. Disaster Recovery Journal, accessed April 20, 2006, http://www.drj.com/
iii. “Successful Contingency Planning – Complying with HIPAA Security Rule,” HIPAA
COW Fall Conference, September 2005,
http://www.hipaacow.org/Events/Fall%202005/SecurityContingencyWebVersion.PP
T
iv. “Is Your Business Continuity Plan HIPAA?” HIPAA COW Fall Conference,
September 2003,
http://www.hipaacow.org/Events/Spring2005Security/ContingencyPlanning.ppt
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
17
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
v. “Business Continuity/Disaster Recovery Presentation,” HIPAA COW Spring 2003
Meeting, http://www.hipaacow.org/Docs/Disaster%20Recovery.ppt
vi. Wisconsin Homeland Security, accessed April 20, 2006,
homelandsecurity@dma.state.wi.us.
vii. Federal Department of Homeland Security, accessed April 20, 2006,
http://www.dhs.gov/dhspublic/
viii. Forbes Calamity Prevention Website, accessed April 20, 2006,
http://www.calamityprevention.com/index.php
ix. HIPAA COW Website for Past IS Disaster Recovery Presentations, accessed April
24, 2006, http://www.hipaacow.org/Home/events.aspx
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
18
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
APPENDIX 1: IS DISASTER RECOVERY TEAM STATUS REPORT –
SAMPLE TEMPLATE
Use this form to log and report significant information system disaster recovery activities.
During an IS disaster, the team leader is required to submit a written information systems
disaster recovery status report daily (or other pre-determined time period). This status report
may be submitted handwritten as long as it is legible.
Date: ____________________________________________ Time:
_________________
Submitted By: _________________________________________________________________
Team/Department/Business Unit: __________________________________________________
COMMENTS:
CONCLUSIONS:
RESOURCES EXPENDED (Brief Description of Major Expenditures Related to Disaster)
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
19
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
APPENDIX 2: SAMPLE INFORMATION SECURITY INCIDENT REPORT FORM
INCIDENT IDENTIFICATION INFORMATION2
Incident Detector’s Information:
Name:
Title:
Phone/Contact Info:
Date/Time Detected:
Location:
System/Application:
INCIDENT SUMMARY
Type of Incident Detected:
 Denial of Service
 Unauthorized Access


Malicious Code
Unplanned
Downtime


Unauthorized Use/Disclosure
Other:
Description of Incident:
Names of Others Involved:
INCIDENT NOTIFICATION





IS Leadership
Security Incident Response Team
Administration
Human Resources
Other:




System/Application Owner
System/Application Vendor
Public Affairs
Legal Counsel
ACTIONS (Include Start & Stop Times)
Identification Measures (Incident Verified, Assessed, Options Evaluated):
Containment Measures:
Evidence Collected (Systems Logs, etc.):
2
This form has been developed as a working tool for assessment and improvement activities; it is intended for
internal use only
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
20
DRAFT
Version 8
April 25, 2006
Based on Final Security Rule
Eradication Measures:
Recovery Measures
EVALUATION
How Well Did the Workforce Members Respond?
Were the Documented Procedures Followed? Were They Adequate?
What Information Was Needed Sooner?
Were Any Steps or Actions Taken That Might Have Inhibited the Recovery?
What Could the Workforce Members Do Differently the Next Time an Incident Occurs?
What Corrective Actions Can Prevent Similar Incidents in the Future?
What Additional Resources Are Needed to Detect, Analyze, and Mitigate Future Incidents?
Other Conclusions/Recommendations:
FOLLOW-UP
Review By (Organization to
 Security Officer
determine):
 Other:
Recommended Actions Carried Out:

IS Department/Team
Initial Report Completed By:
Follow-Up Completed By:
_____________________________________________________________________________
 Copyright 2006 HIPAA COW
21
Download