PrivaGuide: Risk Assessment€¦ · Web viewIntranet - An intranet is a private network of multiple computer desktop workstations, fileservers, applications servers, and other components,

PrivaGuide: Risk Analysis

PrivaGuide: Security Risk AnalysisBy David Ginsberg and Rebecca Herold, CISSP, CISA, FLMI

Introduction

HIPAA requires that each covered entity conduct a formal risk analysis. Specifically, this means:

Analyze the risks and vulnerabilities to the electronic PHI each covered entity creates, maintains, stores or transmits

Understand the probability of these risks and vulnerabilities Assess measures already in place to reduce these risks Analyze its information and applications to find what is critical and what is not. Conduct a formal risk analysis that balances the cost of security against the

expected value of losses. As a result of the analysis each entity must have a formal risk management

process that reduces risk to an acceptable level.

Considering the potential costs and effort associated with HIPAA compliance, it is a mistake to install HIPAA "solutions" without first understanding organizational HIPAA "problems." There may already be policies, procedures, systems, and technology in place that adequately address at least some of the HIPAA requirements. To determine where HIPAA compliance requirements must be addressed (the HIPAA “gaps”). HIPAA security risk assessments must be performed. Using the results of the assessments, along with any existing business financial plans, an organization will be ready to develop a HIPAA security compliance plan, including a list of compliance priorities.

How to do this:This section documents the information necessary to conduct a HIPAA security risk analysis along with a series of questions that will help you in your internal review. More questions will need to be added based upon each individual situation, and according to the responses to these initial questions. “Implementation” relates to the tasks necessary to perform the initial HIPAA risk assessment. “Maintenance” suggestions relate to on-going risk assessment activities. The implementation and maintenance suggestions are designed to help you complete the appropriate policies and procedures and specifically, the risk analysis required by HIPAA.

Before completing this PrivaGuide we suggest you read the Implementing the Security Rule PrivaGuide for a comprehensive overview of the security rule.

© 2010 by PrivaPlan™ Associates, Inc. All Rights Reserved. 1

Disclaimer:

The information provided in this document does not constitute, and is no substitute for, legal or other professional advice. Users should consult their own legal or other professional advisors for individualized guidance regarding the application of the law to their particular situations, and in connection with other compliance-related concerns.


As you go through this Risk Analysis, please refer to the Glossary at the end if you see a phrase or word that is unfamiliar.



PROCEDURE — SECURITY RULE RISK ANALYSIS

A Note about the Security Requirements:

Certain security measures are required by the HIPAA final security rule, and certain others are “addressable” (i.e. you must either implement them or document the reasons why it would not be reasonable and appropriate to do so and provide an alternative if necessary). This PrivaGuide includes sample language that identifies risks that are common to many organizations. You may find that some of the risks mentioned below to not apply to your organization. Remember that you must implement all of the required security measures and you must document your analysis of all required measures.

Implementation Suggestion: Take the Risk Analysis Tutorial

An easy-to-follow PowerPoint or PDF tutorial for the Risk Analysis is included on the Risk Analysis Tutorial in the Training folder. Read the Risk Analysis Tutorial to get a good overview of completing a risk analysis.

Implementation Suggestion: Inventory electronic PHI and Start the Security Walk Through

The first step is to inventory the electronic PHI that you create, maintain, store or transmit. Remember the definition of PHI (if you have forgotten, go to the Definition of Terms document in the HIPAA Reference Material folder).

1) Review the ePHI inventory created in Stat # 2 (refer to the PHI inventory document you previously completed and the PHI Inventory PrivaGuide; if you have not completed a PHI inventory you will need to do this first). Be specific but use categories. For example you wouldn’t inventory the electronic information kept on each patient by their name-rather you can indicate “patient registration and demographic information”.

2) Determine if the inventory adequately includes all electronic PHI (“ePHI”). To do this, conduct a walk through of your organization and list all forms of electronic information systems where electronic PHI may exist.


PrivaTip #2Keep in mind that electronic protected health information may take many forms and be transferred and processed in many different ways: Claims transmitted to a payer or clearing

house Information kept on a PDA (personal digital

assistant Emails containing patient information Patient data accessed by a billing system

vendor to research a problem Health information maintained on diagnostic

equipment like an EKG/Treadmill Back up tapes

PrivaTip #1If you are a small provider, consider using the PrivaPlan Stat [Step 3] list to help you determine your risk ranking. The Stat list provides a good way for you to determine the high priority actions you need to take. If you have not done any, or very little, work for a Stat item, then you should most likely rank that item as a high risk.


3) Review the document “Start the Security Walk Through”. This provides an easy to follow guide on conducting a Security walkthrough of your organization and identifying ePHI!

4) You may also want to sketch the layout and location of the electronic information systems where the electronic PHI exists. Don’t forget PDA’s and laptops that may be offsite or with one of the physicians, and back up tapes or disks that are kept offsite.

5) Using the ePHI Use and Disclosure Inventory form, record your findings.6) Be sure the ePHI Use and Disclosure Inventory form includes the location of the PHI

—for example “on network server” or “on physician’s laptop.” 7) Update the inventory if necessary to reflect the purpose of the use or disclosure.8) Update the inventory to indicate the staff or workforce member who uses or discloses

this information--you can choose at this point to indicate the job title (i.e. “billing department” or “appointment scheduler”) or the actual name.

9) Update the inventory to indicate if the electronic PHI is disclosed to any business associates--for example a claims clearing house (for more information on business associates refer to Stat # 9 and the corresponding Business Associates and Data Use PrivaGuide).

10) Indicate the application program that creates each electronic PHI. For example, indicate the name of your practice management and billing software (it probably will relate to more electronic PHI than any other application you use), appointment scheduling system, email software, electronic medical records software, spreadsheet software and so forth.

11) Update the Job Responsibilities with Respect to PHI form to reflect electronic PHI and the staff or workforce members who use it. This will make it easier later on to assign passwords, keys and other security measures.

Implementation suggestion: Threats, vulnerabilities, and criticality

Define the threats and vulnerabilities. 1) Start by creating a master list of threats and vulnerabilities (refer to the table below)2) Based on your current measures in place, identify the probability–use the rankings

“high, medium, and low” to rank.3) Document your reasoning by listing the security measures in place4) Enter your findings on the ePHI Use and Disclosure Inventory form



Threat and Vulnerability Matrix--Sample GuideThreat or Risk

TypeSpecific threat

Probability Measure in place

Hazards--Natural

Earthquake Low None--but this is not an earthquake prone area

Tornado Medium Computer is located in an inner office that is most protected

Snowstorms or freezing weather

Medium This area is prone to such weather during the winter

Hurricane and flooding

Medium Office building is somewhat elevated from street

Lightning High No surge protectors in placeHazards--Man made

Power outage Medium No uninterruptible power supply

Terrorist act Low Semi rural area Fire Medium Fire extinguishers in office (but not

the type for electronic equipment); no sprinkler system

Loss of Heat LowLoss of AC Medium Computer server is in a closet with

minimal coolingBiological Hazard

Low

Chemical Hazard

Medium Organization is near a train crossing and trains carrying chemicals frequently pass through

Nuclear hazard LowLoss of gas or water

Low Could disrupt use of facility

Loss of telecommunications

Medium Several times in past few years phone and internet service has been disrupted

Malicious Virus and worm infection

High High no antivirus software or firewall in place and just installed high speed connection

Spyware High No Spyware scans are doneEx-employee hacks into system

Medium No firewall in place and office manager doesn’t delete passwords as timely as necessary

Theft of equipment

Medium Office is locked and alarmed-but alarm codes are not routinely changed; laptops are not secured to desks; server is not secure

Vandalism Medium Office is somewhat remote Accidental Back up tape

left in car and melts

Low Tapes are taken by a storage company

System crashes

Medium System has been stable; backups not done regularly

Add your own…



Implementation suggestion: Criticality analysis

Rank the criticality of each application program or electronic PHI. That is, in the event of a problem, how critical is it to have this information available and to continue to operate the application? For example, if you use an electronic medical record this is very critical. Again, rank based on “high, medium or low.” Remember the HIPAA privacy rule mandates that patients have access to their PHI--as a covered entity you have an obligation to maintain this access even during an emergency. Other applications may be essential so you can continue in business--for example appointment scheduling and billing.

You can do this using the ePHI Use and Disclosure Inventory, or by creating a separate chart. For example:

Electronic PHI Application CriticalityPatient registration data XYZ Billing system HighPatient billing data XYZ Billing system HighPatient appointments XYZ scheduling module HighClearing house claims transmissions

Infinedi clearing house file Medium

Collection notices–documents Word processor LowEmail correspondence with patients

Outlook Low

PDA patient names Palm data base Low

Implementation suggestion: Matching threats and risks to vulnerabilities and criticality

Use this step to determine the risks to each kind of electronic PHI; based on the criticality of the electronic PHI you will want to add security measures. You can use the chart format above--for example:

Electronic PHI Application Criticality Threat and RankPatient registration data

XYZ Billing system High Lightning surge destroys data file. High–practice does not have a surge protector or power supply at each workstation

Patient billing data XYZ Billing system High Lightning; also hacker breaks in and steals information. High-practice is now on line with high speed connection but has no firewall or virus software in place

Hospital round patient names

PDA patient data module

Low Theft. Low since physician uses passwords to lock the PDA

Clearing house claims transmitted

Infinedi clearing house software

Medium Low--clearing house provides a secure transmission protocol



Electronic PHI Application Criticality Threat and RankCollection notices –documents

Word processor Low Medium--no passwords on these files and they are not encrypted on the system

Email correspondence with patients

Outlook Low Medium-no passwords on the email files

Add your own…

Note: You should start with the threats or risks that you determined were high, and then proceed to medium and low. Match this first with the most critical electronic PHI (again use the rankings). The list may be quite long since almost all electronic PHI is vulnerable. Again, you can document this with a separate chart or using the ePHI Use and Disclosure Inventory form.

Implementation suggestion: Complete the Risk Analysis Tracking Form

At this point you have:

Inventoried all known electronic PHI, its location and who uses it

Identified risks and threats (the charts above helped you understand some of these threats).

Identified how probably or likely those are based on the type of risk as well as the measures you have in place

Identified how critical it is to maintain access to the electronic PHI

To complete the risk analysis, you must now identify the security measures needed to sufficiently reduce these risks. At this point you can take into account the cost of the measures as well as other factors. HIPAA refers to this as flexibility of approach. Specifically:

a) You must take into account the size, complexity and capabilities of your organization as you consider security measures

b) You must take into account the technical infrastructure (do you have someone on staff is familiar with computers and technical matters?), and your hardware and software capabilities

c) Costs of security measuresd) Probability and criticality of potential risks to electronic PHI.

To complete the risk analysis:

1) Review the Implementing the Security Rule PrivaGuide once again, paying close attention to the security measures that are described as “required” or “addressable.” The required measures must be in place. Addressable measures should be implemented if reasonable and appropriate, if not, an equivalent alternative can be implemented.


PrivaTip #3

Need help evaluating each of your Windows based computers? You can configure Windows to disable certain features and make your PC more secure. The Stat list provides a good way for you to determine the high priority actions you need to take. If you have not done any, or very little, work for a Stat item, then you should most likely rank that item as a high risk.


2) Review the electronic PHI inventory, risk and probability charts and criticality chart you just completed.

3) Determine the measures you can take for risks and criticality (start with the highest first)—that is, look at your most critical applications and where you have the greatest risks. Consider the measures you can take to reduce these risks. You might want to talk to your software or hardware vendor or consultant for their advice.

4) Consider the cost of each measure and your current capabilities5) Determine the most appropriate measure6) Get help if needed! Your software vendor and hardware vendor are often a reliable

source of assistance. Questions can always be posted on the PrivaPlan online discussion group. There are also numerous consultants and security experts who can provide additional assistance. Please visit www.privaplan.com and look at our partner and affiliate pages for some names.

7) List the measure and associated details on the Risk Analysis Tracking Form.8) Be sure to update your policies and procedures to reflect these measures when they

are implemented (See the “\PrivaPlan\Policies and Procedures\” folder).

You will end up with a chart that looks like this (a version with sample text can be found in the Risk Analysis Tracking Form.


http://www.privaplan.com/


Risks Identified Date Found

Target Completion

Date

Person or Team

Assigned

Immediate Actions

NecessaryComments

HIGH Priority

MEDIUM Priority

LOW Priority

Maintenance Suggestions:1. Repeat the risk analysis following your “remediation” steps once you have

implemented the measures you identified on the Risk Analysis Tracking Form. This will not only verify that the “gaps” in your security compliance have been filled, but it will also show the progress you have made. Additionally, the subsequent risk analyses will reveal new risks and vulnerabilities that are created as a result of implementing new technology, procedures, and software. For example, if you implement a new alarm system but have not set up a regular way to change codes.

2. Periodically repeat the risk analysis. You should repeat the risk analysis on a regular (at least yearly) basis. Additionally, whenever you introduce new software, hardware or other electronic information systems be sure to implement the appropriate procedures. You can periodically repeat the walk through (remember you can use the Start the Walk Through document).

3. Use the HIPAA Ready Reference as a guide. The HIPAA Ready Reference can help you understand when security measures should be implemented. It is a good reference to also understanding when you should update the risk analysis.

4. Update the Job Responsibilities with Respect to PHI form. Keep this form up to date as staff or workforce members change job roles, are hired or terminated. Be sure to keep the associated security measures up to date, such as removal of passwords or assignment of new user ID’s and system privileges.

Additional help: The following questions and their responses can be used to help you complete the risk analysis including their priority for completion. Note: Many of these questions are designed for larger provider practices, institutional providers (like hospitals) or health plans; however they may be of interest for small practices.

1. Has the organization appointed a person or individual to act as the security official? (Please refer to the Implementing the Security Rule PrivaGuide for instruction on this step. The reason for this question relates to risk; if you don’t have a security official your organization is at greater risk for a security violation!)



Yes No

A few suggested types of documentation to collect and interview questions:

Has the responsibility been communicated to everyone within the organization? Does the documentation include such tasks as the management and supervision of the

use of security measures to protect information, as well as the conduct of personnel in relation to the protection of information?

To whom does this position report? Has this been communicated to everyone in the organization?

The organization’s priority ranking: High Medium Low

2. Have the computer systems and networks owned and/or operated by the organization been reviewed and are known to be adequately secure? Gather information from your IT staff, if any, and your vendors. Also, consider any other areas in your organization where there are web site administrators, help desks, or other types of technical responsibilities.

Yes No

A few suggested types of documentation to collect and interview questions: Have you performed a vulnerability assessment on every computing system,

including desktops, laptops and handheld computing devices? When was the most recent assessment made? Who performed the assessment? What will be the costs to reduce the identified risks? What are the expected costs of losses if the risks are not removed? What identified risks can be reduced to an acceptable level balanced with the

organization’s environment and operations? Obtain copies of any assessments that have been performed.


2. Have business associate agreements been signed by all the organization’s applicable third parties? (See the PrivaGuide “Business Associate and Data Use Agreements.”)

Yes No

A few suggested types of documentation to collect and interview questions: Do you outsource any of your IT activities? For example your billing? Or does the

practice management vendor provide maintenance and support? Does a third party manage your web sites? Do you use a clearinghouse? Are the business associate agreements adequate to cover the HIPAA security rule?




3. Does the organization have a current and comprehensive contingency plan (a plan in the event of an emergency)? This step is outlined in the Implementing the Security Rule PrivaGuide. A contingency plan is an important security measure that addresses certain risks and vulnerabilities. If you don’t have a contingency plan in place your organization is at greater risk for a security violation. Be sure to check with all departments and groups within the organization. It is common for many departments or teams to create some type of at least limited contingency (or emergency), backup or disaster recovery plan to help them know what to do in the event of a computer outage or environmental disaster that keeps them from accessing their information, and so on. This plan should be scaled depending on the necessity of the organization. Be sure to ask your vendor if they have a contingency plan. For example, if your electronic medical records software is stored at the vendor’s site (ASP mode of operations), then you should determine what their plan is in the case of emergency.

Yes No

A few suggested types of documentation to collect and interview questions: Gather all documentation, both

physical and electronic, that could be considered as part of the plan.

Does one consolidated plan exist for the entire organization?

When was the plan created? Who has copies of the plan? Who is responsible for the plan? Does the plan address all types of

information emergencies, including physical and electronic? Are roles and responsibilities outlined within the plan?


4. Are the contingency plans regularly tested and updated as necessary? See the Implementing the Security Rule PrivaGuide for more instruction; again if you don’t regularly test and update your contingency plans you are at greater risk for a security violation. Plans should have run-throughs to make sure they will actually work in the event of a true emergency. Again, ask all areas of the organization, if appropriate, not just the Information Technology area or network administrator. Many times other business departments or employees have established their own contingency plan testing and updating practices, even if they are limited in their scope. Remember to check with your vendors—for example, they should also have plans in place to update and test their contingency plan.

Yes No

A few suggested types of documentation to collect and interview questions: When was the last time the plan was updated? Who updated the plan?


PrivaTip #5A few possibilities for classifying your information: Think about what information that you

electronically store you could not live without in the event of a disaster. For example, your billing software may be very important to ensure your financial viability!

Consider the methodology found within the National Security Agency’s INFOSEC Assessment Methodology (AIM)

PrivaTip #4Examples of when emergency mode operations may be needed. An emergency mode can result from different events:

Hazards--natural (like earthquakes) and man made (arson or power failures) events that either destroy your facility, or the electronic PHI, or restrict your access to your operations.

Deliberate and malicious acts--For example a virus infects your system and you must erase all data files and restore. Or a theft removes computers or vandalizes them.

Unintentional actions—For example a critical process is interrupted by a staff member and the data base is corrupted and must be rebuilt.


Are persons identified to be involved with executing the contingency plans (i.e. your HIPAA implementation staff)? Have roles and responsibilities been assigned?

How often is the plan tested? Does the plan include third party and business associate considerations? Are regular back ups of critical electronic PHI done? Are they transported in a secure

manner? Where are the backups stored of your electronic PHI and other important information

such as contact information on the individuals who have the back ups? What is the procedure for making backups? Who has access to the backups? How quickly can your facilities be recreated if your primary processing location is

destroyed? Do you have, or do you need, an identified hot site?


5. Does the organization have policies and procedures governing the use, processing and protection of electronic protected health information? Remember to also look for any type of documentation that provides guidance for the routine and non-routine receipt, manipulation, storage, dissemination, transmission, and/or disposal of health information. See the PrivaPlan Security Policy Draft and Procedure Manual documents—if you completed customization of these documents, then you should be up-to-date.

Yes No

A few suggested types of documentation to collect and interview questions: How are old back ups and hardware with electronic PHI destroyed or discarded? Where are they destroyed? By personnel, or by contracted companies? Who created the policies and procedures? Who maintains them? When were your policies and procedures last updated? Do you maintain copies of all previous policies and procedures?


6. Has an information and applications data criticality analysis been performed? This is a structured assessment of the sensitivity, security, and vulnerability risks for each type of information and organizational processes to classify it accordingly. In other words, what information, both electronic PHI and other types, is critical for you to be able to maintain in an emergency. For each of these kinds of information, you should think about how you will secure it and how vulnerable it is. If you have done a PHI inventory, then you are already on your way to determining this step. The results will indicate which pieces of information are most critical, which need to be made most readily available following a disaster, and so on. See the PrivaGuide: PHI Inventory for more information.

Yes No

A few suggested types of documentation to collect and interview questions: What are your data classification labels

and/or categories? For example, is information labeled as confidential, proprietary, public, and so on? You probably already stated this if you conducted a PHI inventory.

How is electronic PHI classified?


PrivaTip #6See PrivaPlan Stat Step 2. Ensure all electronic information is inventoried. Update the inventory as you add new files and programs, or as you remove them.


Who is responsible for maintaining all your organization’s data classification information? Your HIPAA Privacy and Security Official?

Have you identified information owners for all your information? Who determines the criticality of your information? Is information classification part considered within your overall application

development process?


7. Has the organization established policies and procedures that detail the types and levels of access allowed to protected health information? Look for documentation and directives that detail specific people, departments, teams or positions that are allowed access to specific types of health information. See the PrivaPlan Security Policy Draft and Procedure Manual for examples. Again, you should have completed this when you did your PHI inventory in Stat step #2.

Yes No

A few suggested types of documentation to collect and interview questions: Look for documentation addressing or governing provider file integrity, sharing

passwords among personnel and business associates, and email sharing among administrative assistants.

Have you documented the kinds of information that each staff member should have access to (Stat #2)?

Who established the access allowed (i.e. the Privacy and Security Official)? Who approves access to information? Under what circumstances do you remove access to information for any particular

employee? What staff have the most access to protected health information? What are the

management procedures for these staff members to reduce the possible risks they present to the information?


8. Has a process to perform ongoing internal audits for HIPAA compliance been implemented? These are important to enable an organization to identify potential security violations. We now have a PrivaGuide: Using PrivaPlan as an Auditing Tool that you can use to guide you through a formal HIPAA compliance audit.

Yes No

A few suggested types of documentation to collect and interview questions: Have any systems security audits been performed in the past year? Obtain copies. Who performs the audits; an internal audit team, or an outside third party resource? Does your internal audit team have any background or experience with HIPAA? If you use a third party audit resource, are they experienced in HIPAA reviews? When is the next security audit planned? And, what will be the scope?


9. Has a process been implemented to grant access to health information only after personnel have been appropriately authorized? This is important to prevent unnecessary or inadvertent access to protected health information, in addition to ensuring health information file integrity. Absence of this process presents a high risk to your organization. See the PrivaGuide: Personnel Clearance procedures for some suggestions. Remember that how you “clear” your personnel will depend greatly on the



size and scope of your organization—for example, it can be as simple as checking references or as complex as performing a background check.

Yes No

A few suggested types of documentation to collect and interview questions: Who is responsible for authorizing access to health information (i.e. Security Officer)? Who is responsible for establishing the access authorizations within the networks and

computer systems? Does a process exist for removing authorization from individuals? Under what circumstances is authorization changed or removed?


10. Have procedures and methodologies been implemented to help ensure information and system integrity and security? The integration of security procedures and methodologies into your HIPAA compliance program is important to ensure that routine changes to systems hardware and/or software do not contribute to or create security weaknesses. For example, you want to be sure that the new practice management software that you purchase or any updates will be implemented since the updates or new software might have new security features. Make sure you know who your vendors are and that they will protect your information. Lack of simple but effective procedures and methodologies presents a high risk to protected health information.

Yes No

A few suggested types of documentation to collect and interview questions: Do your Internet, network settings, and software include security requirements such

as firewalls or password protection? Does your Security Official participate in all new systems and application

implementation projects? Are your requirements for systems security and integrity documented in your Security

Policies and Procedures? Have you communicated the requirements to all personnel who participate in

systems and applications implementation and maintenance?


11. Have security incident (such as a breach in your firewall) procedures been implemented and tested? More guidance can be found in the Implementing the Security Rule PrivaGuide. Documented plans should exist to outline how to handle security incidents, or situations in which the technical security of your computer and other electronic data is breached. These plans should be periodically tested to make sure they would actually work. These procedures are important for helping you to respond appropriately to a wide range of threats and information security incidents that could happen within your organization. Again, this step is scalable to the size and necessities of your organization.

Yes No

A few suggested types of documentation to collect and interview questions: Check not only with the Information Technology (IT) staff for documentation, but also

check with each of the departments, groups, and other areas within your organization. You may also need to check with your vendors.



Keep in mind some of the procedures may be based upon common knowledge verbally communicated within the areas, for example, keeping an up-to-date firewall in place. Be sure you formally document such unwritten procedures.

Include procedures and technologies for such security incidents as computer viruses, hackers, denial of service attacks, social engineering, and so on.

Be sure your detection systems are set so that they retrieve only a manageable amount of information

Have you defined what constitutes a security incident and trained your workforce on this?


12. Do you have a formal documented Security Policy and Procedure? A specific team or department should be identified and communicated to the rest of the organization as being responsible for information security management, in addition to having organizational-wide information security policies and procedures. The most likely person for this will probably be your HIPAA Privacy Official. Each covered entity must have a formal security and risk management process and responsibility area in place to reduce risks to protected health information to an acceptable level. For example, you could complete this risk assessment once a year to ensure compliance. Ensure that this is clearly stated in your Security Policy and Procedure Manual.

Yes No

A few suggested types of documentation to collect and interview questions: Who is responsible for creating, administering, and overseeing policies and

procedures to ensure the prevention, detection, containment, and correction of security breaches as well as to ensure the confidentiality, integrity and availability of mission critical information, such as protected health information?

Does a formal security management process exist to address the full range of security issues—do you have a Security Policy and Procedure customized to your practice?


13. Have employee termination procedures been implemented? See the PrivaPlan Procedure Manual document for an example of the procedural format. It is important to consider security as well as privacy when you terminate an employee.

Yes No

A few suggested types of documentation to collect and interview questions: Look for formal, documented instructions, including appropriate security measures,

for actions personnel must take when an employee’s employment is ended (either by your organization, or by the employee’s own initiative). See your Procedure Manual.

Gather documentation detailing how to remove all terminated personnel access to information, including from remote locations, as well as on systems that are not located within your facilities (such as on handheld computing devices) must exist.

Does access termination include disabling physical site access, ID or swipe cards or retrieving keys?

Is there a person or department responsible for coordinating and or removing all access following a termination?

Do you have a timeframe within which access must be removed following the termination of personnel?




14. Have all personnel received general information security training with an emphasis on the vulnerabilities and risks of processing protected health information? See Stat #10 and your Training PrivaGuide for more detailed help on how to train your staff.

Yes No

A few suggested types of documentation to collect and interview questions: Is a person or department responsible for security training for everyone within your

organization (i.e. the Security Official)? Is documentation maintained regarding who has participated in training, and when? Do you perform some type of assessment to ensure the training participants

understand and follow the information obtained within the training? How often is security training provided? Is security training mandatory? Have all management been included (this means the physicians and other providers!) Does someone internal provide security training, or do you hire someone from

outside your organization?


15. Has the organization implemented policies and procedures for protecting hardware, software, and data media used for processing protected electronic protected health information? See the PrivaPlan Security Policy Draft and Procedures Manual documents for examples—if you have customized these documents, then you should be up-to-date. Lack of such policies and procedures places all electronic information at risk.

Yes No

A few suggested types of documentation to collect and interview questions: Do directives exist to protect electronic PHI in while in storage or while the storage

media is being transferred outside of your facility? What requirements exist for personnel to remove health information, in any form,

from your facilities? Are personnel allowed to work with health information from remote locations, such as

their homes? Are personnel allowed to use handheld computing devices, such as personal digital

assistants (PDAs)?


16. Has the organization established and implemented physical access controls and policies? See the PrivaPlan Security Policy Draft and Procedure Manual documents and the Physical Security PrivaGuide.

Yes No

A few suggested types of documentation to collect and interview questions: Do you have formal, documented policies and procedures for limiting physical access

within your facilities and on your network while ensuring that only properly authorized access is allowed?

What types of physical security mechanisms do your have for your buildings? How are computers physically secured?



Do all personnel follow physical access control requirements? Who is responsible for physical access controls? Are physical access controls in place for all areas where health information is

located? (Are areas with ePHI separated from visitors?) Are laptops locked or cabled to a desk when not in transit?


17. Has the organization created and implemented policies and procedures to assure appropriate computer use and computer security? See the PrivaPlan Policy Draft and Procedure Manual documents.

Yes No

A few suggested types of documentation to collect and interview questions: Check all areas and groups within your organization; have they developed and/or

documented their own computer use policies? Do any computer security directives exist on intranet sites? (large organizations often

have a company wide “intranet” for employee to employee communication. Often the intranet has organization wide directives and policies).

Have memos have been issued with computer security requirements? What mechanisms exist for ensuring computer security and appropriate computer

use? How are computers secured in public areas (such as waiting rooms, lobbies, and so

on)?


18. Has the organization implemented policies and procedures to help prevent unauthorized information access using computers and in public areas? (Once you complete the steps in the steps in “Implementing the Security Rule” PrivaGuide, as well as this Risk Analysis PrivaGuide, you should have the necessary information to customize the Security Policy and Procedures drafts included in PrivaPlan).

Yes No

A few suggested types of documentation to collect and interview questions: What documented and unwritten practices are currently used throughout every area

of your organization to prevent unauthorized access to information? Do you provide access to health information in public areas? Is someone centrally responsible for controlling information access via computers?


19. Has the organization created and implemented security awareness training for specific positions that regularly process and handle health information? See the Workforce Training PrivaGuide and Stat step #10.

Yes No

A few suggested types of documentation to collect and interview questions: Do you require specific job positions to have security and privacy training prior to

giving them access to health information? Have you determined the personnel who must receive specialized ongoing employee

training?



What kind of security clearance measures have you implemented for job positions with access to protected health information? Remember, this is a scalable step.


20. Has the organization established and implemented information access controls to allow protected health information access to only authorized persons? See the PrivaPlan Stat steps 4 and 5. Don’t forget that how much detail you will need will depend on the size of your organization—for example, if you only have one staff member, then this person is likely to need access to everything.

Yes No

A few suggested types of documentation to collect and interview questions: Check documentation within your Information Technology (IT) department, your

HIPAA Security Policies and Procedures, or your vendors. Also determine access authorization practices within all the departments by

interviewing managers and reviewing their documentation, memos, intranet web sites, and other possible sources.

Who is responsible for authorizing access? Who is responsible for establishing the systems access following authorization?


22. Are audit trails of systems and record activity maintained and regularly reviewed? Audit trails vary greatly from system to system in the way they look, the specific pieces of information they contain, and how intuitively easy they are to read and understand.

You may also want to consider whether or not your vendors or IT staff keep audit trails. Most programs with access controls have a built in way for a program expert to audit access attempts at the very least.

An example of an audit trail is that in many programs any failed login attempts are typically recorded with the date and time the attempt occurred. If an unauthorized individual does somehow gain access to the system, the audit trail should provide a record of the activities taken by the intruder, including the date and time of each action. This will not restore files that are destroyed, but it helps determine the extent of the damage caused by the intruder. Additionally, authorized users may be deterred from attempting to perform certain unauthorized activities because they know that a record of their actions is being created. In this sense the audit trail feature serves to deter unauthorized activities.

The security rule requires covered entities to perform ongoing internal audits. These should include having assigned personnel to review the audit logs to identify any inappropriate or suspicious login activity, file accesses, and security incidents. These structured reviews will help organizations to identify possible security violations and inappropriate access to protected health information. The audit process should examine the audit logs to: Investigate security breaches Identify questionable information access activities Identify and respond to potential weaknesses Assess the effectiveness of the security program

If an organization uses network controls to protect confidential information, such as protected health information, that is transmitted electronically over open networks so that



it cannot be easily intercepted and interpreted by parties other than the intended recipient, the technical security mechanisms must include an audit trail.

Audit controls may apply to manual procedures, a system, a network, an application or any other technical processes. Covered entities must establish a process to record persons who have accessed or attempted to access electronic protected health information. Entities must determine what activities need to be monitored within their organizations based upon their own unique environment, operations and exposures, and define at what level information audits should be maintained. Of course, the nature and scale of these activities will depend upon what your office uses—internet, a network, vendors, etc. Your vendor may also provide audit logs for you.

Each covered entity needs to audit and track the information used and disclosed within the organization, as well as information that is released outside the organization. Standards should exist specifying how long the organization will retain the audit trail information. The required retention period for the audit log data should provide enough time to investigate instances of inappropriate access, in addition to adhering to HIPAA retention requirements (6 years minimum). The organization should define the people authorized to access the audit trail information and provide for secure storage and protection of the audit trail information, especially for audit information about protected health information. Audit trails may become evidence in legal proceedings, so the integrity of the information must be preserved to ensure their usefulness for such purposes.

Another purpose of the internal audit process is to ensure that users are in compliance with policies and procedures. Audit trails and associated activity logs must be periodically reviewed. Organizations must determine how often the audits will occur and if they will be random or scheduled ahead of time. Audit policies and procedures should define the positions authorized and responsible for reviewing audit trail information and who will prepare and disseminate the audit reports.

So, a restatement of the risk question: Are audit trails of systems and record activity maintained and regularly reviewed?

Yes No

A few suggested types of documentation to collect and interview questions: Identify all automated electronic audit trails. Identify all handwritten audit logs, such as those commonly maintained in computer

operations centers or by vendors. How long are the audit logs maintained? Are the audit logs backed up? Who has access to the audit logs? What information is audited? Who reviews the audit logs? How often are the audit logs reviewed?


23. Are there methodologies and technology in place to provide verification of the integrity of the health information in the organization’s possession? For example, anti-virus software, firewalls, access controls like logins. See your Security Policies and Procedure Manual.

Yes No



A few suggested types of documentation to collect and interview questions: Gather all information that describes the requirements on checking any information

errors. Gather all information about requirements for ensuring file integrity through the use of

access controls, the prevention of computer viruses, and other similar types of activities.

Is there a person responsible for ensuring information integrity? What requirements exist for business associates to ensure information integrity?


24. Has the organization established an authentication process to verify a person or entity (for example an employee, business associate, patient, and so on) identity? Check your PrivaPlan Policies and Procedures Manual. For example, do you check the identity of callers who request PHI?

Yes No

A few suggested types of documentation to collect and interview questions: Obtain information about procedures used by help desk and call center staff Look for ways identity is verified when information is faxed between providers and

other business associates How does your organization ensure the faxes are distributed to the correct recipients

—do you verify faxes? Do you verify emails? How do you confirm the identity of callers making requests related to protected health

information?


25. Has the organization identified all health information that is sent over open networks, if any, and implemented technology and processes to protect the information from unauthorized access? Software programs called “sniffers” are freely available on the Internet. Sniffers can copy or intercept clear text information passing through networks. Sending clear text through open networks is a high risk activity. Again, this step will be scalable depending on the relevance to your organization.

Yes No

A few suggested types of documentation to collect and interview questions: Collect information in documentation and through interviews that describe when and

how encryption is used—remember, encryption of email is not required but should be based on your reasonable assessment.

Determine the type of information sent in email messages; do personnel send protected health information within email messages?

Collect information describing how information passing over public networks is secured. For example transmitting claims to a payer or a clearing house.

What technology solutions are used to protected information passing over public network, for example, a firewall?





PrivaTip #7Use the summary security risk assessment report information to:1. Create project plans for addressing identified current security risks and

vulnerabilities2. Create timelines for closing HIPAA security rule gaps and

addressing security risks3. Determine HIPAA security rule compliance action priorities4. Develop HIPAA security rule compliance budgets


About the Authors:

Rebecca Herold, CISSP, CISA, FLMI

Ms. Herold is a noted author and information security consultant.

Ms. Herold has over 15 years of experience in privacy and security services; over 12 years of which was in the healthcare industry as the security director of a large multinational health and life insurance company. Ms. Herold’s book “The Privacy Papers” was published in December 2001 and “The Practical Guide to HIPAA Privacy and Security Compliance” was published in 2003. Ms. Herold has also written several chapters covering privacy and security for a variety of security and privacy management books. Ms. Herold authors a monthly privacy column in the Computer Security Institute Alert newsletter. Ms. Herold has written numerous magazine and newsletter articles on information security and privacy topics and has given numerous presentations at conferences and seminars. Ms. Herold has a B.S. in Math and Computer Science and an M.A. in Computer Science and Education. Ms.Herold is a Certified Information Systems Security Professional (CISSP), a Certified Information Systems Auditor (CISA) and a Fellow of the Life Management Institute (FLMI). Ms. Herold has been a member of the Information Systems Audit and Control Association (ISACA) since 1990 and has held all board positions throughout her membership in the Iowa chapter. Ms. Herold is a charter member of the Iowa Infragard chapter that was formed in 2000, and an active member of the International Association of Privacy Officers (IAPO). In addition, Ms. Herold has assisted large government and corporations to perform HIPAA risk assessments. This gives her an extensive and current knowledge of HIPAA remediation solutions. Rebecca Herold, CISSP, CISM, CISA, FLMIInformation Privacy, Security and Compliance Consultant, Author and InstructorRebecca Herold & Associates LLC1408 Quail Ridge AvenueVan Meter, Iowa 50261 business: 515.491.1564fax: [email protected]://www.rebeccaherold.com

.

David Ginsberg

Mr. Ginsberg is President of PrivaPlan Associates, Inc. and is one of the founders. David Ginsberg is a healthcare consultant with over twenty-five years experience. Most currently he organized and is Executive Director of the Colorado Physician Network, a statewide network of 2500 physicians. Mr. Ginsberg was also Vice President of Intellectron/Medcobill a large regional physician practice management and billing company providing services to over 1000 physicians in California; during this time he implemented the second Medicare electronic claims transmission program of its kind and pioneered an EDI solution for Medicaid.

Mr. Ginsberg has expertise in managed care operations, IPA development, and physician-hospital strategic planning, practice management consulting, and compliance issues. In addition he has helped numerous health care organizations in the search and selection process for information technology solutions.


http://www.rebeccaherold.com/

mailto:[email protected]


Mr. Ginsberg can be contacted at David A. Ginsberg Consulting, 3 Monte Alto Way, Santa Fe, NM 87508. Telephone: 877-218-7707. Email: [email protected].


mailto:[email protected]


GLOSSARY

1. Administrative Security - The typically manual activities and management constraints, operational procedures, accountability procedures, and other supplemental controls established to provide protect sensitive information. With particular regard to HIPAA, protected health information.

2. Archive – A copy of a file made to create more space on the primary computer storage devices. The copy is typically saved on a diskette, CD, tape or other type of information storage media.

3. Audit log - A set of records that collectively provides documentary evidence of system resources accessed by specific users, groups, processes or other components of a network. The audit logs helps people to trace original transactions forward and backward to see who was involved with accessing a particular information file, or was involved with a specific computer transaction. Audit logs can also be created manually; for example, a log of everyone who has signed into a clinic, or a log of everyone who has looked at a particular patient file folder. These audit logs will help to enable the reconstruction, review and examination of each activity and event involved with a specific transaction or piece of information.

4. Audit Trail – The same as an audit log; see the definition of ‘audit log’.5. Authentication - The act of identifying or verifying the identity or eligibility of a person,

workstation, or other type of entity to access specific types of information, such as protected health information.

6. Computer Viruses – Computer code that can reproduce itself and spread, attaching to various types of other computer files, without the consent, and often knowledge, of the people sending or receiving the files. Viruses are often hostile code that can possible modify or destroy other computer files, or even result in making the computer unusable. Vendors of anti-virus (AV) software have identified approximately 50,000 known viruses.

7. Contingency plan – Planning ahead with great detail for how to respond to the sudden loss, unavailability or other types of computer systems or information malfunctions, to quickly return the system or information back to a secure, functioning and operational state. These are plans for emergency response, backup operations, and post-disaster recovery maintained by organizations with computer information processing capabilities as a part of their security programs.

8. Data criticality analysis – Reviewing and analyzing your information to determine the confidentiality and priority of each piece of information. Data criticality analyses often determine criticality and/or classification by prioritizing the information based upon five security requirements: confidentiality of the information, the integrity importance of the information, the necessary availability of the information, the need for some type of non-repudiation (the ability to prevent the denial that a transaction occurred), and the importance of time with regard to information and associated transactions.

9. De-identified - Health information that has had key pieces of information removed so that it does not identify a specific individual, and for which there is no reasonable basis to believe that the information can be used to identify an individual. In effect, de-identifying information makes it anonymous information.

10. Denial of Service Attacks – Attacks to a computer network that result in making the network unusable for brief, or extended, period of time. For instance, sending large numbers of email at the same time to one email account, or one email server, may flood the computer network with so much email traffic that it results in bringing down the network. There are many ways in which denial of service attacks may be launched.

11. Encrypt – Scrambling information, through the computerized use of mathematical algorithms, to make it unreadable by anyone who does not know how to decrypt the information.

12. File Integrity – When information can be assured that it has not been changed or destroyed in any type of unauthorized manner.



13. Hackers – Persons who break into computer systems for which they are not authorized to use. Some hackers break into systems for a challenge, and other break in to get access to confidential information that they can then use for their own, often monetary, purposes. Such types of information targeted often include credit card numbers, social security numbers, and if specific people are targeted, there have been instances when medical records have been obtained.

14. Hot Site – These are locations with computer equipment that are located geographically away from the business computer facilities. Hot sites are fully equipped, ready-to-run computer centers that are used when an authorized person declares that a computer disaster has occurred.

15. Information Access Controls - The process of allowing only authorized users, programs, or other computer systems (for example, networks, specific computer workstations, and so on) to access the information resources of a computer system.

16. Intranet - An intranet is a private network of multiple computer desktop workstations, fileservers, applications servers, and other components, that is connected to the Internet at a single point, or just a very few points. The whole intranet looks to anyone on the Internet as a single Internet participant. It requires only a single, or a few, IP addresses at the Internet side, while internally it can provide all Internet services to all the people and other resources that use the network.

17. Network – A collection of a few to many computer systems and peripherals that are integrated and communicate with each other.

18. Open Network – A computer environment in which systems and network access is not controlled by the people who own the electronic files, or who put the electronic files on the network. An example of an open network would be one on which multiple businesses and/or corporations are connected and use to share information between organizations.

19. Personal Digital Assistants (PDAs) - Handheld computing devices that typically fit in the palm of a person’s hand and are noticeably smaller than laptop computers. PDA users can also often use PDAs to talk to others (as a cell phone), or send email or photos to others through the Internet or connect to a wireless network. PDAs are becoming very popular and pose very significant security threats to protected health information because of the ease with which wireless transmissions can be intercepted, and because the high incidence of PDA losses.

20. Physical Security - Protection of physical computer systems and hard copy information (such as paper files) and related buildings, facilities and equipment from fire and other natural and environmental hazards, as well as from intrusion. Physical security also covers the use of locks, keys, and administrative measures used to control access to computer systems and facilities.

21. Public Networks – Networks that are used by multiple entities and organizations. The Internet is the most widely known public network. However, other public networks include the public telephone network, frame relay connections, dial-up subscription services, the cable system, and many unsecured wireless networks. Sending information through public networks is a very risky activity. There are numerous opportunities for private information to be obtained on these networks by unauthorized persons. Measures must be taken (such as encrypting information) to help protect the information sent through public networks.

22. Sanctions - Organizations must have policies and procedures regarding disciplinary actions (sanctions), which are communicated to all employees, agents and contractors. For example, verbal warning, notice of disciplinary action placed in personnel files, removal of system privileges, and termination of employment and contract penalties. In addition to enterprise sanctions, employees, agents, and contractors must be told the civil and/or criminal penalties for misuse or misappropriation of health information. Employees, agents and contractors, must be made aware that violations may result in notification to law enforcement officials and regulatory, accreditation and licensure organizations.



23. Security Incident – Any type of compromise of any critical or sensitive data, including protected health information. Security incidents may be isolated, but many times they are not; they can include attacks on laptops or PDAs that appear to be global against an organization, rather than attacks against just one workstation. Often security incidents are considered incidents of opportunity; the intruder or perpetrator finds a weakness in the computer system, or with information handling practices, and exploits these weaknesses to gain access to confidential information, systems resources, or to render the network unusable. Security incidents include, but are not limited to, the following examples:

Any attack on your monitoring, logging, or auditing systems or data Successful, or potentially successful, attack on your Internet firewall Successful, or potentially successful, attack on core financial, marketing,

production, or development systems Successful, or potentially successful, attack on your protection or security

systems at any level (information, logical, or physical, such as security or protective systems)

24. Separation of duties – Separating responsibilities and authorization capabilities to ensure that no single person or department has total control over the information and validation process. Lack of separation of duties would enable someone to enter or conceal an error that is intended to defraud the organization or commit other harmful acts. An example would be not allowing the same individual to establish vendors to an authorized vendor file, and then also be capable of authorizing payments to a vendor.

25. Social Engineering – Attempts, sometimes successful and sometimes unsuccessful, to influence a person(s) into either revealing information or acting in a manner that would allow an intruder unauthorized access, unauthorized use, or unauthorized disclosure, to information, an information system, network or systems resources.

26. System integrity – The current state of a computer network or systems component that reduces the risk to the network resources, and helps to ensure the continued confidentiality, integrity and availability of systems resources. Integrity depends greatly upon the reduction of risks to a level that is acceptable to allow successful business functioning.

27. Technical Security - The technical and automated processes that are put in place to guard against unauthorized access to information and systems components on a computer network. The processes implemented protect information and also control and monitor individual access to information. For example, automatically produced audit logs, login authentication processes, and encryption solutions are all examples of technical security methods.

28. Vulnerability Assessment – The formal steps and methodology used to identify weaknesses in network and computer systems that could potentially be exploited to allow unauthorized access and information modification within a systems. A vulnerability assessment should identify risks that to systems and information safety, security, reliability, availability, integrity, non-repudiation, legal compliance, and so on.


PrivaGuide: Risk Assessment€¦ · Web viewIntranet - An intranet is a private network of multiple computer desktop workstations, fileservers, applications servers, and other components,

Documents