14.4 PREPARING FOR THE AUDIT

Once you have hired the auditor , work closely to ensure that you have gathered documents including manuals for networks, security policies, and other documentation. Due to the complexity of the computer industry, security experts may need to review manuals for firewalls, routers, applications, servers, etc. in order to complete the audit. Thus, ensure that you have documentation and manuals on site for all devices used in your organization.

14.4.1 Goal of the Audit or Evaluation

First and foremost, the audit or evaluation should be testing to ensure that you are following the required Administration, Physical and Technical Safeguards that you have set up after you have performed your required Risk analysis. The following matrix details those standards that are required or addressable: ^[10]

Administrative Safeguard Standards	Sections	Implementation is Required or Addressable
Security Management Process	164.308(a)(1)	Risk Analysis	Required
		Risk Management	Required
		Sanction Policy	Required
		Information System Activity Review	Required
Assigned Security Responsibility	164.308(a)(2)		Required
Workforce Security	164.308(a)(3)	Authorization and/or Supervision	Addressable
		Workforce Clearance Procedure	Addressable
		Termination Procedure	Addressable
Information Access Management	164.308(a)(4)	Isolating Healthcare Clearinghouse Function	Required
		Access Authorization	Addressable
		Access Establishment and Modification	Addressable
Security Awareness and Training	164.308(a)(5)	Security Reminders	Addressable
		Protection from Malicious Software	Addressable
		Log-in Monitoring	Addressable
		Password Management	Addressable
Security Incidents Procedures	164.308(a)(6)	Response and Reporting	Required
Contingency Plan	164.308(a)(7)	Data Backup Plan	Required
		Disaster Recovery Plan	Required
		Emergency Mode Operation Plan	Required
		Testing and Revision Procedure	Addressable
		Applications and Data Criticality Analysis	Addressable
Evaluation	164.308(a)(8)		Required
Business Associate Contracts and Other Arrangements	164.308(b)(1)	Written Contract or other arrangement	Required

Physical Safeguards Standards	Sections	Implementation is Required or Addressable
Facility Access Controls	164.310(a)(1)	Contingency Operations	Addressable
		Facility Security Plan	Addressable
		Access Control and Validation Procedures	Addressable
		Maintenance Records	Addressable
Workstation Use	164.310(b)		Required
Workstation Security	164.310		Required
Device and media controls	164.310(d)(1)	Disposal	Required
		Media re-use	Required
		Accountability	Addressable
		Data backup and storage	Addressable

Technical Safeguards and Standards (see 164.312)	Sections	Implementation is Required or Addressable
Access Controls	164.312(a)(1)	Unique User Identification	Required
		Emergency Access Procedure	Required
		Automatic logoff	Addressable
		Encryption and Decryption	Addressable
Audit Controls	164.312(b)		Required
Integrity	164.312 (1)	Mechanism to Authenticate Electronic Protected Health Care information	Addressable
Person or Entity Authentication	164.312(d)		Required
Transmission Security	164.312(e)(1)	Integrity Controls	Addressable
Transmission Security	164.312(e)(1)	Encryption	Addressable

14.4.2 Gathering Manuals, Policies, Documentation

First and foremost, before you can have a Security Audit, written, documented security policies must be in place. As in addressed elsewhere in this book, at a minimum, the manner in which Protected Health Information is handled within your organization should be documented to ensure Physical Safeguards and Technical Safeguards. The Audit process should be seen as a proactive means to ensure these policies are still meeting minimum requirements as set forth by federal and/or state legislation and industry best practices within the information technology industry and the healthcare industry. The guidelines are, by design, vendor and technology neutral, thus as the technology changes in the coming months and years , the concept of 'best practices' will change as well.

14.4.3 Determining Need for Audit Committee

In typical 'business' audits , there is typically a requirement for an audit committee, an organizational unit that the auditors report to that is separate from the management of the organization. Depending on the needs of your organization and its structure, you may wish to put together a HIPAA evaluation/audit committee that will serve two functions. First and foremost, to be the unit that formulates the security policies of the organization, and secondly to serve as the conduit for Security Audits or evaluations. The people on this committee should be taken from all departments of your organization and should include both Information Technology Professionals as well as key medical personnel with insights into the handling of patient information. In smaller organizations, this audit committee may not need to be comprised of a large group of people.

14.4.4 Risk Analysis

The evaluation or audit process begins with a risk analysis of the organization. The data systems used in the organization, the threats to these systems, impact and risk to these systems should be documented. Inventory of all hardware, software, users, methods of data storage, transmission should be included in this document. For guidelines, you may wish to review the National Institute of Standards and Technology's Risk Management Guide for Information Technology Systems. ^[11] Given that this process of analysis of Risk factors may be beyond the normal scope of your organization, using a committee process or external risk analysis by an external auditor is highly recommended. Using the Risk Management Guide as a starting point, the recommended way by most organizations to begin a risk management evaluation for your entity is literally to invite people to a brain storming session [have Pizza and soft drinks handy] and facilitate an evaluation of the potential and realistic threats for your organization. This will also assist you in later implementation procedures where items are 'addressable' and thus can be mitigated. Remember that threats can come from many ways, and internal threats normally have larger impact than external threats.

14.4.5 Documents Needed

According to 68 Federal Register at 8361, documentation 'must be detailed enough to communicate the security measures taken and to facilitate periodic evaluations pursuant to sections 164.308(a)(8)'. Thus a review of internal systems and comparison to current industry best practices is recommended.

Begin first by ensuring that written security polices are in place to cover human interactions with electronic information. Samples can be found from many resources including SANS ^[12] , Stanford Electronic Health Information Security Committee ^[13] and others. Documentation may include but not be limited to:

Documentation that a computer system or network meets a security requirement.
Documented security awareness program for all levels of affected personnel. This documentation should include definitions and examples of methods of harm that can be done by viruses, worms and other malware.
Documentation of the procedure for updating and informing personnel of matters of concern that include new procedures to overcome issues.
Documentation of Password management and implementation of change of passwords.
Documentation of monitoring log in and access procedures including audit log retention.
Documentation of disaster plans that cover system emergencies.
Documentation of the regular review of access to critical data and how rights to access of data is set by management.
Documentation of backup and retention of data procedures.
Documentation of disaster plans.
Documentation of procedures used to install and configure systems to ensure a secure configuration.
Documentation of procedures to reduce risks from any source of threat vector, [i.e. virus scanning and firewall protection on all attached systems, standalone products on detached systems]
Documentation of installation of systems to ensure legal copies of software are installed, and only those devices and services that are needed are installed.
Documentation of all hardware and software that are assets of the firm.
Documentation of systems that are installed are properly functioning and are performing as was intended [note this may need additional outside testing to confirm]
Documentation of handling of data by third parties [ please note, this normally requires audits of such Service bureaus.
Documentation of procedures to review, manage, and choose security tools, programs, or processes to increase protection of the data on a regular basis.
Documentation of review of violations of security requirements and follow up remedial action.
Documentation of actions taken if violations of law are observed .
Documentation of rules of conduct by anyone who comes in contact with patient data and the procedures taken to ensure only those people needing access to the data, do so.
Documentation of exit procedures when an employee, temporarily employees , contract workers or volunteers with access to data leave the firm or no longer need access to the data.
Documentation of the procedures performed to review access to the data and ensure that only those required persons needing access have it.
Documentation of handling of security incidents that include steps to notify law enforcement agencies if needed.
Documentation of the manner in which staff members have access to data, what necessary rights to view, edit, change data and who is allowed to increase these rights in an organization.
Documentation of the method that granting of rights to view data is confirmed before access is provided.
Documentation of methods for protection of health care information will not be accidentally seen by unauthorized personnel.
Documentation of the necessary authority and clearances needed to review the health care information.
Documentation of the level of access given to each person.
Documentation of the procedures undertaken to ensure that PHI confidentiality is maintained while around personnel such as maintenance, contractual , volunteers or anyone without the necessary clearances.
Documentation to track physical location of all assets of the organization.
Documentation of the mechanisms that are in place to audit, track, log or trace activity to its original source.
Documentation of limitations to physical access to buildings , data, assets, data backup, etc.
Documentation and detailed procedures for proper handling of disposal of hardware, media and electronic data.
Documentation of maintenance to the facilities that house the PHI.
Documentation of program changes, program testing and evaluation is only done by authorized persons.
Documentation of systems in place to ensure that PHI has not been tampered or destroyed in any way.
Documentation of the use, requirement or other procedures that require encryption in the accessing or transmitting of PHI over electronic communication.
Documentation of procedures in place to alert administrators of unusual system conditions.
Documentation of the handling of incidents that occur that affect PHI.

Please note this is not an all inclusive listing of the documentation needed in an organization, nor is it meant to be such. Your organizations risk analysis will determine what documentation you need to put in force to meet the administrative, technical and physical safeguards needed by your organization.

^[10] CMS' Southern Consortium's ACT[Achieving Compliance Together] Training http://www.eventstreams.com/cms/tm_001/security.pdf

^[11] Risk Management Guide for Information Technology Systems http://csrc.nist.gov/ publications /nistpubs/80030/sp80030.pdf

^[12] http://www.sans.org/resources/policies/

^[13] http://ostinato.stanford.edu/hipaa-feedback/