|
|
HIPAA/SECURE:
Security Q/A
July 2003
"Testing Your Contingency Plan"
by Amanda Dorsey, Director
Phoenix Health Systems
QUESTION: Testing of a covered entity's IT contingency plan
is an "addressable" requirement of the HIPAA Security
Rule. Should we conduct such testing – and if so, what should
the testing consist of?
ANSWER: If you are like most organizations, you have an
IT contingency plan that outlines how your organization will respond
to a specific systems failure. This IT Contingency plan typically
sits in a binder on a shelf in the CIO's office. And when your triennial
JCAHO survey rolls around, you dust off the contingency plan, change
a few internal items in the binder along with the date on the cover
page and offer it up as evidence as a bona fide contingency plan.
Enter the HIPAA Final Security Rule, section 164.308 (7)(i), which
asks covered entities to implement procedures for periodic testing
and revision of contingency plans. While this implementation feature
is addressable, testing (and subsequent revision, as needed) can
ensure that your disaster recovery team and employees will know
how to react in a disaster situation and understand what is expected
of them. Until your plan is put into action, whether through testing
or in the event of a real disaster, the plan that merely sits on
the shelf and is never tested will remain purely theoretical.
Testing an entire contingency plan might seem like a daunting task,
especially to those covered entities that are short on staff and
have not budgeted time or materials to conduct testing. The following
offers a range of testing scenarios – from the relatively quick
and inexpensive to full-blown, organization-wide testing. After
completing your Business Impact Analysis (BIA) and identifying and
prioritizing your key applications and equipment, consider conducting
a test of your own organizations' contingency plan using at least
one of these techniques.
- Checklist Testing uses the terms defined in the disaster
recovery component of your contingency plan (or persons according
to their responsibility) to test the "checklists" to
be used in the event of a disaster. For example, a network recovery
team may perform a checklist test to ensure accuracy of the emergency
call tree, critical technology vendors or forms inventory. If
any information on the lists is found to be outdated or inadequate,
update it immediately and let others, especially the Disaster
Recovery process-owner, know of the pertinent changes. This team-based
approach can help establish a common ownership of the plan itself
and the ongoing maintenance effort.
- Walkthrough or "Paper" Testing requires appropriate
disaster recovery team members to verbally walk through steps
as documented in the contingency plan. This is another important
yet relatively easy step to take toward identifying gaps or weaknesses
in your current procedures. As with any test, document the outcomes
accordingly in your recovery procedures.
- Limited Scope or Integrated Testing involves operational
testing of one or more components of the organization's IT disaster
recovery procedures. For example, a limited scope test might consist
of using backup tapes to restore selected information systems
at a remote recovery facility or on test machines within your
organization.
- Simulated Full-Scale Disaster Testing involves a complete
(operational) test of the disaster recovery plan. This test may
interrupt normal operations and should only be attempted after
determination that such a test would not impact patient care.
Keep in mind that this type of testing will require extensive,
upfront planning and permission from executive management. Simulation
or full-scale testing is sometimes seen as cost-prohibitive but
can prove invaluable when determining how your organization will
operate at its hot or warm site.
Gaining support of the key staff before conducting interdisciplinary
tests (i.e., those that involve departments outside of IT) is a
good way to prevent the "ownership" of recovering from
a disaster from being the sole responsibility of the IT department.
If you conduct unannounced testing within areas of your organization,
don't be surprised to get some undesirable responses. Partner with
other departments when planning and conducting tests and make sure
that they understand that planning for contingencies in the event
of a disaster is a collaborative effort.
Remember that conducting any of these tests requires a positive
attitude and should be done in the name of improvement – not
from a pass/fail perspective. Time is of the essence after a disaster
strikes. Finding flaws in your recovery procedures just after a
disaster has happened (and when tensions are already high) does
little to improve the morale of the Disaster Recovery Team (and
the confidence of senior management). Have the foresight to test
your disaster recovery plan before it tests you.
Read past HIPAA / SECURE Q/A articles.
Amanda Dorsey, Director, Phoenix Health Systems, delivers HIPAA
consulting solutions to physician practices and hospital clients,
which have included a major multi-hospital IDN, an academic medical
center, and two mid-size rural hospital groups.
|
 |
 |
