HIPAA Security Regulations: Administrative Safeguards - § 164.308
As Contained in the HHS HIPAA Security Rules
|
HHS Regulations as Amended January 2013 |
(a) A covered entity or business associate must, in accordance with §164.306:
(1)(i) Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.
(ii) Implementation specifications:
(A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.
(B) Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).
(C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity or business associate.
(D) Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
(2) Standard: Assigned security responsibility. Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the covered entity or business associate.
(3)(i) Standard: Workforce security. Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information.
(ii) Implementation specifications:
(A) Authorization and/or supervision (Addressable). Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
(B) Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
(C) Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of, or other arrangement with, a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section.
(4)(i) Standard: Information access management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.
(ii) Implementation specifications:
(A) Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.
(B) Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
(C) Access establishment and modification (Addressable). Implement policies and procedures that, based upon the covered entity's or the business associate's access authorization policies, establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process.
(5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).
(ii) Implementation specifications. Implement:
(A) Security reminders (Addressable). Periodic security updates.
(B) Protection from malicious software (Addressable). Procedures for guarding against, detecting, and reporting malicious software.
(C) Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting discrepancies.
(D) Password management (Addressable). Procedures for creating, changing, and safeguarding passwords.
(6)(i) Standard: Security incident procedures. Implement policies and procedures to address security incidents.
(ii) Implementation specification: Response and reporting (Required). Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.
(7)(i) Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.
(ii) Implementation specifications:
(A) Data backup plan (Required). Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.
(B) Disaster recovery plan (Required). Establish (and implement as needed) procedures to restore any loss of data.
(C) Emergency mode operation plan (Required). Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.
(D) Testing and revision procedures (Addressable). Implement procedures for periodic testing and revision of contingency plans.
(E) Applications and data criticality analysis (Addressable). Assess the relative criticality of specific applications and data in support of other contingency plan components.
(8) Standard: Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart.
(b)(1) Business associate contracts and other arrangements. A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with §164.314(a), that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.
(2) A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances, in accordance with §164.314(a), that the subcontractor will appropriately safeguard the information.
(3) Implementation specifications: Written contract or other arrangement (Required). Document the satisfactory assurances required by paragraph (b)(1) or (b)(2) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of §164.314(a).
|
HHS Description and Commentary From the January 2013 Amendments |
Proposed Rule
We proposed a technical change to § 164.308(a)(3)(ii)(C) regarding security termination procedures for workforce members, to add the words “or other arrangement with” after “employment of” in recognition of the fact that not all workforce members are employees (e.g., some may be volunteers) of a covered entity or business associate.
We also proposed a number of modifications to § 164.308(b) to conform to modifications proposed in the definition of “business associate.” Section 164.308(b) provides that a covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information only if the covered entity has a contract or other arrangement in place to ensure the business associate will appropriately safeguard the protected health information. Section164.308(b)(2) contains several exceptions to this general rule for certain situations that do not give rise to a business associate relationship, such as where a covered entity discloses electronic protected health information to a health care provider concerning the treatment of an individual.
We proposed to remove these exceptions from this provision, since as discussed above, they would now be established as exceptions to the definition of “business associate.”
In addition, we proposed to modify § 164.308(b)(1) and (2) to clarify that covered entities are not required to obtain satisfactory assurances in the form of a contract or other arrangement with a business associate that is a subcontractor; rather, it is the business associate that must obtain the required satisfactory assurances from the subcontractor to protect the security of electronic protected health information.
Finally, we proposed to remove the provision at § 164.308(b)(3), which provides that a covered entity that violates the satisfactory assurances it provided as a business associate of another covered entity will be in noncompliance with the Security Rule’s business associate provisions, as a covered entity’s actions as a business associate of another covered entity would now be directly regulated by the Security Rule’s provisions that apply to business associates.
Overview of Public Comments
One commenter asked for confirmation that the changes to § 164.308 would require a covered entity to enter into a business associate agreement with its own business associate and not any subcontractors of those business associates.
Final Rule
The final rule adopts the proposed modifications to § 164.308. Section 164.308(b) expressly provides that a covered entity is not required to enter into a business associate agreement with a business associate that is a subcontractor; rather, this is the obligation of the business associate that has engaged the subcontractor to perform a function or service that involves the use or disclosure of protected health information.
| HHS Description From Original Security Rulemaking Security Standards for the Protection of Electronic PHI: Administrative Safeguards |
We proposed that measures taken to comply with the rule be appropriate to protect the health information in a covered entity's care. Most importantly, we proposed to require that both the measures taken and documentation of those measures be kept current, that is, reviewed and updated periodically to continue appropriately to protect the health information in the care of covered entities. We would have required the documentation to be made available to those individuals responsible for implementing the procedure. We proposed a number of administrative requirements and supporting implementation features, and required documentation for those administrative requirements and implementation features. In this final rule, we have placed these administrative standards in § 164.308. We have reordered them, deleted much of the detail of the proposed requirements, as discussed below, and omitted two of the proposed sets of requirements (system configuration requirements and a requirement for a formal mechanism for processing records) as discussed in paragraph 10 of the discussion of § 164.308 of section III.E. of this preamble. Otherwise, the basic elements of the administrative safeguards are adopted in this final rule as proposed.
Security management process (§ 164.308(a)(1)).
We proposed the establishment of a formal security management process to involve the creation, administration, and oversight of policies to address the full range of security issues and to ensure the prevention, detection, containment, and correction of security violations. This process would include implementation features consisting of a risk analysis, risk management, and sanction and security policies.
We also proposed, in a separate requirement under administrative procedures, an internal audit, which would be an in-house review of the records of system activity (for example, logins, file accesses, and security incidents) maintained by an entity.
In this final rule, risk analysis, risk management, and sanction policy are adopted as required implementation specifications although some of the details are changed, and the proposed internal audit requirement has been renamed as "information system activity review" and incorporated here as an additional implementation specification.
Assigned Security Responsibility (§ 164.308(a)(2))
We proposed that the responsibility for security be assigned to a specific individual or organization to provide an organizational focus and importance to security, and that the assignment be documented. Responsibilities would include the management and supervision of (1) the use of security measures to protect data, and (2) the conduct of personnel in relation to the protection of data.
In this final rule, we clarify that the final responsibility for a covered entity's security must be assigned to one official. The requirement for documentation is retained, but is made part of § 164.316 below. This policy is consistent with the analogous policy in the Privacy Rule, at 45 CFR 164.530(a), and the same considerations apply. See 65 FR 82744 through 87445. The same person could fill the role for both security and privacy.
Workforce Security (§ 164.308(a)(3))
We proposed implementation of a number of features for personnel security, including ensuring that maintenance personnel are supervised by a knowledgeable person, maintaining a record of access authorizations, ensuring that operating and maintenance personnel have proper access authorization, establishing personnel clearance procedures, establishing and maintaining personnel security policies and procedures, and ensuring that system users have proper training.
In this final rule, to provide clarification and reduce duplication, we have combined the "Assure supervision of maintenance personnel by authorized, knowledgeable person" implementation feature and the "Operating, and in some cases, maintenance personnel have proper access authorization" feature into one addressable implementation specification titled "Authorization and/or supervision."
In a related, but separate, requirement entitled "Termination procedures," we proposed implementation features for the ending of an employee's employment or an internal or external user's access. These features would include things such as changing combination locks, removal from access lists, removal of user account(s), and the turning in of keys, tokens, or cards that allow access.
In this final rule, "Termination procedures" has been made an addressable implementation specification under "Workforce security." This is addressable because in certain circumstances, for example, a solo physician practice whose staff consists only of the physician's spouse, formal procedures may not be necessary.
The proposed "Personnel security policy/procedure" and "record of access authorizations" implementation features have been removed from this final rule, as they have been determined to be redundant. Implementation of the balance of the "Workforce security" implementation specifications and the other standards contained within this final rule will result in assurance that all personnel with access to electronic protected health information have the required access authority as well as appropriate clearances.
Information Access Management (§ 164.308(a)(4))
We proposed an "information access control" requirement for establishment and maintenance of formal, documented policies and procedures defining levels of access for all personnel authorized to access health information, and how access is granted and modified.
In § 164.308(a)(4)(ii)(B) and (C) below, the proposed implementation features are made addressable specifications. We have added in § 164.308(a)(4)(ii)(A), a required implementation specification to isolate health care clearinghouse functions to address the provisions of section 1173(d)(1)(B) of the Act which related to this area.
Security Awareness and Training (§ 164.308(a)(5))
We proposed, under the requirement "Training," that security training be required for all staff, including management. Training would include awareness training for all personnel, periodic security reminders, user education concerning virus protection, user education in the importance of monitoring login success/failure, and how to report discrepancies, and user education in password management.
In this final rule, we adopt this proposed requirement in modified form. For the standard "Security awareness and training," in § 164.308(a)(5), we require training of the workforce as reasonable and appropriate to carry out their functions in the facility. All proposed training features have been combined as implementation specifications under this standard. Specific implementation specifications relative to content are addressable. The "Virus protection" implementation feature has been renamed "protection from malicious software," because we did not intend by the nomenclature to exclude coverage of malicious acts that might not come within the prior term, such as worms.
Security Incident Procedures (§ 164.308(a)(6))
We proposed a requirement for implementation of accurate and current security incident procedures: formal, documented report and response procedures so that security violations would be reported and handled promptly. We adopt this standard in the final rule, along with an implementation specification for response and reporting, since documenting and reporting incidents, as well as responding to incidents are an integral part of a security program.
Contingency Plan (§ 164.308(a)(7)
We proposed that a contingency plan must be in effect for responding to system emergencies. The plan would include an applications and data criticality analysis, a data backup plan, a disaster recovery plan, an emergency mode operation plan, and testing and revision procedures.
In this final rule, we make the implementation specifications for testing and revision procedures and an applications and data criticality analysis addressable, but otherwise require that the contingency features proposed be met.
Evaluation (§ 164.308(a)(8))
We proposed that certification would be required and could be performed internally or by an external accrediting agency. We solicited input on appropriate mechanisms to permit an independent assessment of compliance. We were particularly interested in input from those engaging in health care electronic data interchange (EDI), as well as independent certification and auditing organizations addressing issues of documentary evidence of steps taken for compliance; need for, or desirability of, independent verification, validation, and testing of system changes; and certifications required for off-the-shelf products used to meet the requirements of this regulation. We also solicited comments on the extent to which obtaining external certification would create an undue burden on small or rural providers.
In this final rule, we require covered entities to periodically conduct an evaluation of their security safeguards to demonstrate and document their compliance with the entity's security policy and the requirements of this subpart. Covered entities must assess the need for a new evaluation based on changes to their security environment since their last evaluation, for example, new technology adopted or responses to newly recognized risks to the security of their information.
Business Associate Contracts or Other Arrangements (§ 164.308(b)(1))
In the proposed rule § 142.308(a)(2) "Chain of trust" requirement, we proposed that covered entities be required to enter into a chain of trust partner agreement with their business partners, in which the partners would agree to electronically exchange data and protect the integrity, confidentiality, and availability of the data exchanged. This standard has been modified from the proposed requirement to reflect, in § 164.308(b)(1) "Business associate contracts and other arrangements," the business associate structure put in place by the Privacy Rule.
In this final rule, covered entities must enter into a contract or other arrangement with persons that meet the definition of business associate in § 160.103. The covered entity must obtain satisfactory assurances from the business associate that it will appropriately safeguard the information in accordance with these standards (see § 164.314(a)(1)).
| HHS Response to Comments Received From the Original Security Rulemaking Security Standards for the Protection of Electronic PHI: Administrative Safeguards |
Security management process (§ 164.308(a)(1)).
Comment: Three commenters asked that this requirement be deleted. Two commenters cited this requirement as a possible burden. Several commenters asked that the implementation features be made optional.
Response: This standard and its component implementation specifications form the foundation upon which an entity's necessary security activities are built. See NIST SP 800-30, "Risk Management Guide for Information Technology Systems," chapters 3 and 4, January 2002. An entity must identify the risks to and vulnerabilities of the information in its care before it can take effective steps to eliminate or minimize those risks and vulnerabilities. Some form of sanction or punishment activity must be instituted for noncompliance. Indeed, we question how the statutory requirement for safeguards "to ensure compliance . . . by a [covered entity's] officers and employees" could be met without a requirement for a sanction policy. See section 1176(d)(2)(C) of the Act. Accordingly, implementation of these specifications remains mandatory. However, it is important to note that covered entities have the flexibility to implement the standard in a manner consistent with numerous factors, including such things as, but not limited to, their size, degree of risk, and environment. We have deleted the implementation specification calling for an organizational security policy, as it duplicated requirements of the security management and training standard.
We note that the implementation specification for a risk analysis at § 164.308(a)(1)(ii)(A) does not specifically require that a covered entity perform a risk analysis often enough to ensure that its security measures are adequate to provide the level of security required by § 164.306(a). In the proposed rule, an assurance of adequate security was framed as a requirement to keep security measures "current."
We continue to believe that security measures must remain current, and have added regulatory language in § 164.306(e) as a more precise way of communicating that security measures in general that must be periodically reassessed and updated as needed.
The risk analysis implementation specification contains other terms that merit explanation. Under § 164.308(a)(1)(ii)(A), the risk analysis must look at risks to the covered entity's electronic protected health information. A thorough and accurate risk analysis would consider "all relevant losses" that would be expected if the security measures were not in place. "Relevant losses" would include losses caused by unauthorized uses and disclosures and loss of data integrity that would be expected to occur absent the security measures.
Comment: Relative to the development of an entity's sanction policy, one commenter asked that we describe the sanction penalties for breach of security. Another suggested establishment of a standard to which one's conduct could be held and adoption of mitigating circumstances so that the fact that a person acted in good faith would be a factor that could be used to reduce or otherwise minimize any sanction imposed. Another commenter suggested sanction activities not be implemented before the full implementation and testing of all electronic transaction standards.
Response: The sanction policy is a required implementation specification because--(1) the statute requires covered entities to have safeguards to ensure compliance by officers and employees; (2) a negative consequence to noncompliance enhances the likelihood of compliance; and (3) sanction policies are recognized as a usual and necessary component of an adequate security program. The type and severity of sanctions imposed, and for what causes, must be determined by each covered entity based upon its security policy and the relative severity of the violation.
Comment: Commenters requested the definitions of "risk analysis" and "breach."
Response: "Risk analysis" is defined and described in the specification of the security management process standard, and is discussed in the preamble discussion of § 164.308(a)(1)(ii)(A) of this final rule. The term breach is no longer used and is, therefore, not defined.
Comment: One commenter asked whether all health information is considered equally "sensitive," the thought being that, in determining risk, an entity may consider the loss of a smaller amount of extraordinarily sensitive data to be more significant than the loss of a larger amount of routinely collected data. The commenter stated that common reasoning would suggest that the smaller amount of data would be considered more sensitive.
Response: All electronic protected health information must be protected at least to the degree provided by these standards. If an entity desires to protect the information to a greater degree than the risk analysis would indicate, it is free to do so.
Comment: One commenter asked that we add "threat assessment" to this requirement.
Response: We have not done this because we view threat assessment as an inherent part of a risk analysis; adding it would be redundant.
Comment: We proposed a requirement for internal audit, the in-house review of the records of system activity (for example, logins, file accesses, and security incidents) maintained by an entity. Several commenters wanted this requirement deleted. One suggested the audit trail requirement should not be mandatory, while another stated that internal audits would be unnecessary if physical security requirements are implemented.
A number of commenters asked that we clarify the nature and scope of what an internal audit covers and what the audit time frame should be. Several commenters offered further detail concerning what should and should not be required in an internal audit for security purposes. One commenter stated that ongoing intrusion detection should be included in this requirement. Another wanted us to specify the retention times for archived audit logs.
Several commenters had difficulty with the term "audit" and suggested we change the title of the requirement to "logging and violation monitoring."
A number of commenters stated this requirement could result in an undue burden and would be economically unfeasible.
Response: Our intent for this requirement was to promote the periodic review of an entity's internal security controls, for example, logs, access reports, and incident tracking. The extent, frequency, and nature of the reviews would be determined by the covered entity's security environment. The term "internal audit" apparently, based on the comments received, has certain rigid formal connotations we did not intend. We agree that the implementation of formal internal audits could prove burdensome or even unfeasible, to some covered entities due to the cost and effort involved. However, we do not want to overlook the value of internal reviews. Based on our review of the comments and the text to which they refer, it is clear that this requirement should be renamed for clarity and that it should actually be an implementation specification of the security management process rather than an independent standard. We accordingly remove "internal audit" as a separate requirement and add "information system activity review" under the security management process standard as a mandatory implementation specification.
Assigned Security Responsibility (§ 164.308(a)(2))
Comment: Commenters were concerned that delegation of assigned security responsibility, especially in large organizations, needs to be to more than a single individual. Commenters believe that a large health organization's security concerns would likely cross many departmental boundaries requiring group responsibility.
Response: The assigned security responsibility standard adopted in this final rule specifies that final security responsibility must rest with one individual to ensure accountability within each covered entity. More than one individual may be given specific security responsibilities, especially within a large organization, but a single individual must be designated as having the overall final responsibility for the security of the entity's electronic protected health information. This decision also aligns this rule with the final Privacy Rule provisions concerning the Privacy Official.
Comment: One commenter disagreed with placing assigned security responsibility as part of physical safeguards. The commenter suggested that assigned security responsibility should be included under the Administrative Procedures.
Response: Upon review of the matrix and regulations text, we agree with the commenter, because this requirement involves an administrative decision at the highest levels of who should be responsible for ensuring security measures are implemented and maintained. Assigned security responsibility has been removed from "Physical safeguards" and is now located under "Administrative safeguards" at § 164.308.
Workforce Security (§ 164.308(a)(3))
Comment: The majority of comments concerned the supervision of maintenance personnel by an authorized knowledgeable person. Commenters stated this would not be feasible in smaller settings. For example, the availability of technically knowledgeable persons to ensure this supervision would be an issue. We were asked to either reword this implementation feature or delete it.
Response: We agree that a "knowledgeable" person may not be available to supervise maintenance personnel. We have accordingly modified this implementation specification so that, in this final rule, we are adopting an addressable implementation specification titled, "Authorization and/or supervision," requiring that workforce members, for example, operations and maintenance personnel, must either be supervised or have authorization when working with electronic protected health information or in locations where it resides (see § 164.308(a)(3)(ii)(A)). Entities can decide on the feasibility of meeting this specification based on their risk analysis.
Comment: The second largest group of comments requested assurance that, with regard to the proposed "Personnel clearance procedure" implementation feature, having appropriate clearances does not mean performing background checks on everyone. We were asked to delete references to "clearance" and use the term "authorization" in its place.
Response: We agree with the commenters concerning background checks. This feature was not intended to be interpreted as an absolute requirement for background checks. We retain the use of the term "clearance," however, because we believe that it more accurately conveys the screening process intended than does the term "authorization." We have attempted to clarify our intent in the language of § 164.308(a)(3)(ii)(B), which now reads, "Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate." The need for and extent of a screening process is normally based on an assessment of risk, cost, benefit, and feasibility as well as other protective measures in place. Effective personnel screening processes may be applied in a way to allow a range of implementation, from minimal procedures to more stringent procedures based on the risk analysis performed by the covered entity. So long as the standard is met and the underlying standard of § 164.306(a) is met, covered entities have choices in how they meet these standards. To clarify the intent of this provision, we retitle the implementation specification "Workforce clearance procedure."
Comment: One commenter asked that we expand the implementation features to include the identification of the restrictions that should be placed on members of the workforce and others.
Response: We have not adopted this comment in the interest of maintaining flexibility as discussed in § 164.306. Restrictions would be dependent upon job responsibilities, the amount and type of supervision required and other factors. We note that a covered entity should consider in this regard the applicable requirements of the Privacy Rule (see, for example, § 164.514(d)(2) (relating to minimum necessary requirements), and § 164.530(c) (relating to safeguards).
Comment: One commenter believes that the proposed "Personnel security" requirement was reasonable, since an administrative determination of trustworthiness is needed before allowing access to sensitive information. Two commenters asked that we delete the requirement entirely. A number of commenters requested that we delete the implementation features. Another commenter stated that all the implementation features may not be applicable or even appropriate to a given entity and should be so qualified.
Response: While we do not believe this requirement should be eliminated, we agree that all the implementation specifications may not be applicable or even appropriate to a given entity. For example, a personal clearance may not be reasonable or appropriate for a small provider whose only assistant is his or her spouse. The implementation specifications are not mandatory, but must be addressed. This final rule has been changed to reflect this approach (see § 164.308(a)(3)(ii)(B)).
Comment: The majority of commenters on the "Termination procedures" requirement asked that it be made optional, stating that it may not be applicable or even appropriate in all circumstances and should be so qualified or posed as guidelines. A number of commenters stated that the requirement should be deleted. One commenter stated that much of the material covered under the "Termination procedures" requirement is already covered in "Information access control." A number of commenters stated that this requirement was too detailed and some of the requirements excessive.
Response: Based upon the comments received, we agree that termination procedures should not be a separate standard; however, consideration of termination procedures remains relevant for any covered entity with employees, because of the risks associated with the potential for unauthorized acts by former employees, such as acts of retribution or use of proprietary information for personal gain. We further agree with the reasoning of the commenters who asked that these procedures be made optional; therefore, "Termination procedures" is now reflected in this final rule as an addressable implementation specification. We also removed reference to all specific termination activities, for example, changing locks, because, although the activities may be considered appropriate for some covered entities, they may not be reasonable for others.
Comment: One commenter asked whether human resource employee termination policies and procedures must be documented to show the types of security breaches that would result in termination.
Response: Policies and procedures implemented to adhere to this standard must be documented (see § 164.316 below). The purpose of termination procedure documentation under this implementation specification is not to detail when or under which circumstances an employee should be terminated. This information would more appropriately be part of the entity's sanction policy. The purpose of termination procedure documentation is to ensure that termination procedures include security-unique actions to be followed, for example, revoking passwords and retrieving keys when a termination occurs.
Information Access Management (§ 164.308(a)(4))
Comment: One commenter asked that the requirement be deleted, expressing the opinion that this requirement goes beyond "reasonable boundaries" into regulating common business practices. In contrast, another asked that we expand this requirement to identify participating parties and access privileges relative to specific data elements.
Response: We disagree that this requirement improperly imposes upon business functions. Restricting access to those persons and entities with a need for access is a basic tenet of security. By this mechanism, the risk of inappropriate disclosure, alteration, or destruction of information is minimized. We cannot, however, specifically identify participating parties and access privileges relative to data elements within this regulation. These will vary depending upon the entity, the needs within the user community, the system in which the data resides, and the specific data being accessed. This standard is consistent with § 164.514(d) in the Privacy Rule (minimum necessary requirements for use and disclosure of protected health information), and is, therefore, being retained.
Comment: Several commenters asked that we not mandate the implementation features, but leave them as optional, a suggested means of compliance. The commenters noted that this might make the rules more scalable and flexible, since this approach would allow providers to implement safeguards that best addressed their needs. Along this line, one commenter expressed the belief that each organization should implement features deemed necessary based on its own risk assessment.
Response: While the information access management standard in this final rule must be met, we agree that the implementation specifications at § 164.308(a)(4)(ii)(B) and (C) should not be mandated but posed as a suggested means of compliance, which must be addressed. These specifications may not be applicable to all entities based on their size and degree of automation. A fully automated covered entity spanning multiple locations and involving hundreds of employees may determine it has a need to adopt a formal policy for access authorization, while a small provider may decide that a desktop standard operating procedure will meet the specifications. The final rule has been revised accordingly.
Comment: Clarification was requested concerning the meaning of "formal."
Response: The word "formal" has caused considerable concern among commenters, as it was thought "formal" carried the connotation of a rigidly defined structure similar to what might be found in the Department of Defense instructions. As used in the proposed rule, this word was not intended to convey such a strict structure. Rather, it was meant to convey that documentation should be an official organizational statement as opposed to word-of-mouth or cryptic notes scratched on a notepad. While documentation is still required (see § 164.316), to alleviate confusion, the word "formal" has been deleted.
Comment: One commenter asked that we clarify that this requirement relates to both the establishment of policies for the access control function and to access control (the implementation of those policies).
Response: "Information access management" does address both the establishment of access control policies and their implementation. We use the term "implement" to clarify that the procedures must be in use, and we believe that the requirement to implement policies and procedures requires, as an antecedent condition, the establishment or adaptation of those policies and procedures.
Security Awareness and Training (§ 164.308(a)(5))
Comment: One commenter believes that security awareness training for all system users would be too difficult to do in a large organization.
Response: We disagree with the commenter. Security awareness training is a critical activity, regardless of an organization's size. This feature would typically become part of an entity's overall training program (which would include privacy and other information technology items as well). For example, the Government Information Systems Reform ACT (GISRA) of 2000 requires security awareness training as part of Federal agencies' information security programs, including Federal covered entities, such as the Medicare program. In addition, National Institute of Standards and Technology (NIST) SP 800-16, Information Technology Security Training Requirements, A role and performance base model, April 1998, provides an excellent source of information and guidance on this subject and is targeted at industry as well as government activities. We also note that covered entities must have discretion in how they implement the requirement, so they can incorporate this training in other existing activities. One approach would be to require this training as part of employee orientation. Standards and Technology (NIST) SP 800-16, Information Technology Security Training Requirements, A role and performance base model, April 1998.
Comment: A number of commenters asked that this requirement be made optional or used as a guideline only. Several commenters stated that this requirement is too specific and is burdensome. Several asked that the implementation features be removed. Several others stated that this requirement is not appropriate for agents or contractors. One commenter asked how to apply this requirement to outsiders having access to data. Another asked if this requirement included all subcontractor staff. Others stated that contracts, signed by entities such as consultants, that address training should be sufficient.
Response: Security training remains a requirement because of its criticality; however, we have revised the implementation specifications to indicate that the amount and type of training needed will be dependent upon an entity's configuration and security risks. Business associates must be made aware of security policies and procedures, whether through contract language or other means. Covered entities are not required to provide training to business associates or anyone else that is not a member of their workforce.
Comment: Several commenters questioned why security awareness training appeared in two places, under "Physical safeguards" as well as "Administrative safeguards." Others questioned the appropriateness of security awareness training under "Physical safeguards."
Response: We reviewed the definitions of the proposed "Awareness training for all personnel" ("Administrative safeguards") implementation feature and the proposed "Security awareness training" ("Physical safeguards") requirement. We agree that, to avoid confusion and eliminate redundancy, security awareness and training should appear in only one place. We believe the appropriate location for it is under "Administrative safeguards," as such training is essentially an administrative function.
Comment: Several commenters objected to the blanket requirement for security awareness training of individuals who may be on site for a limited time period (for example, a single day).
Response: Each individual who has access to electronic protected health information must be aware of the appropriate security measures to reduce the risk of improper access, uses, and disclosures. This requirement does not mean lengthy training is appropriate in every instance; there are alternative methods to inform individuals of security responsibilities (for example, provisions of pamphlets or copies of security policies, and procedures).
Comment: One commenter asked that "training" be changed to "orientation."
Response: We believe the term "training," as presented within this rule is the more appropriate term. The rule does not contemplate a one-time type of activity as connoted by "orientation," but rather an on-going, evolving process as an entity's security needs and procedures change.
Comment: Several commenters asked how often training should be conducted and asked for a definition of "periodic," as it appears in the proposed implementation feature "Periodic security reminders." One asked if the training should be tailored to job need.
Response: Amount and timing of training should be determined by each covered entity; training should be an on-going, evolving process in response to environmental and operational changes affecting the security of electronic protected health information. While initial training must be carried out by the compliance date, we provide flexibility for covered entities to construct training programs. Training can be tailored to job need if the covered entity so desires.
Security Incident Procedures (§ 164.308(a)(6))
Comment: Several commenters asked that we further define the scope of a breach of security. Along this same line, another commenter stated that the proposed security incident procedures were too vague as stated. We were asked to specify what a security incident would be, what the internal chain for reporting procedures would be, and what should be included in the documentation (for example, hardware/software, personnel responses).
Response: We define a security incident in § 164.304. Whether a specific action would be considered a security incident, the specific process of documenting incidents, what information should be contained in the documentation, and what the appropriate response should be will be dependent upon an entity's environment and the information involved. An entity should be able to rely upon the information gathered in complying with the other security standards, for example, its risk assessment and risk management procedures and the privacy standards, to determine what constitutes a security incident in the context of its business operations.
Comment: One commenter asked what types of incidents must be reported to outside entities. Another commented that we clarify that incident reporting is internal.
Response: Internal reporting is an inherent part of security incident procedures. This regulation does not specifically require any incident reporting to outside entities. External incident reporting is dependent upon business and legal considerations.
Comment: One commenter stated that network activity should be included here.
Response: We see no reason to exclude network activity under this requirement. Improper network activity should be treated as a security incident, because, by definition, it represents an improper instance of access to or use of information.
Comment: One commenter stated that this requirement should address suspected misuse also.
Response: We agree that security incidents include misuse of data; therefore, this requirement is addressed.
Comment: Several commenters asked that this requirement be deleted. One commenter asked that we delete the implementation features.
Response: As indicated above, we have adopted the proposed standard and combined the implementation specifications.
Contingency Plan (§ 164.308(a)(7)
Comment: Several commenters suggested the contingency plan requirement be deleted. Several thought that this aspect of the proposed regulation went beyond its intended scope. Another believed that more discussion and development is needed before developing regulatory guidance on contingency plans. Others wanted this to be an optional requirement. In contrast, one commenter requested more guidance concerning contingency planning. Still others wanted to require that a contingency plan be in place but stated that we should not regulate its contents. One comment stated that data backup, disaster recovery, and emergency mode operation should not be part of this requirement.
Response: A contingency plan is the only way to protect the availability, integrity, and security of data during unexpected negative events. Data are often most exposed in these events, since the usual security measures may be disabled, ignored, or not observed.
Each entity needs to determine its own risk in the event of an emergency that would result in a loss of operations. A contingency plan may involve highly complex processes in one processing site, or simple manual processes in another. The contents of any given contingency plan will depend upon the nature and configuration of the entity devising it.
While the contingency plan standard must be met, we agree that the proposed testing and revision implementation feature should be an addressable implementation specification in this final rule. Dependent upon the size, configuration, and environment of a given covered entity, the entity should decide if testing and revision of all parts of a contingency plan should be done or if there are more reasonable alternatives. The same is true for the proposed applications and data criticality analysis implementation feature. We have revised the final rule to reflect this approach.
Comment: One commenter believed that adhering to this requirement could prove burdensome. Another stated that testing of certain parts of a contingency plan would be burdensome, and even infeasible, for smaller entities.
Response: Without contingency planning, a covered entity has no assurance that its critical data could survive an emergency situation. Recent events, such as September 11, 2001, illustrate the importance of such planning. Contingency planning will be scalable based upon, among other factors, office configuration, and risk assessment. However, in response to the scalability issue raised by the commenter, we have made the testing and revision implementation specification addressable (see § 164.308(a)(7)(ii)).
Comment: Two commenters considered a 2-year implementation time frame for this requirement inadequate for large health plans. Another commenter stated that implementation of measures against natural disaster would be too big an issue for this regulation.
Response: The statute sets forth the compliance dates for the initial standards. The statute requires that compliance with initial standards is not later than 2 years after adoption of the standards for all covered entities except small health plans for which the compliance date is not later than 3 years after adoption. The final rule calls for covered entities to consider how natural disasters could damage systems that contain electronic protected health information and develop policies and procedures for responding to such situations. We consider this to be a reasonable precautionary step to take since in many cases the risk would be deemed to be low.
Comment: A commenter requested clarification of the term "Emergency mode" with regard to the proposed "Emergency mode operation plan" implementation feature.
Response: We have clarified the "Emergency mode operations plan" to show that it only involves those critical business processes that must occur to protect the security of electronic protected health information during and immediately after a crisis situation.
Evaluation (§ 164.308(a)(8))
Comment: We received several comments that certification should be performed externally. A larger group of commenters preferred self-certification. The majority of the comments, however, were to the effect that external certification should be encouraged but not mandated. A number of commenters thought that mandating external certification would create an undue financial burden, regardless of the size of the entity being certified. One commenter stated that external certification would not place an undue burden on a small or rural provider.
Response: Evaluation by an external entity is a business decision to be left to each covered entity. Evaluation is required under § 164.308(a)(8), but a covered entity may comply with this standard either by using its own workforce or an external accreditation agency, which would be acting as a business associate. External evaluation may be too costly an option for small entities.
Comment: Several commenters stated that the certification should cover all components of the proposed rule, not just the information systems.
Response: We agree. We have revised this section to reflect that evaluation would be both technical and nontechnical components of security.
Comment: A number of commenters expressed a desire for the creation of certification guides or models to complement the rule.
Response: We agree that creation of compliance guidelines or models for different business environments would help in the implementation and evaluation of HIPAA security requirements and we encourage professional associations and others to do so. We may develop technical assistance materials, but do not intend to create certification criteria because we do not have the resources to address the large number of different business environments.
Comment: Some commenters asked how certification is possible without specifying the level of risk that is permissible.
Response: The level of risk that is permissible is specified by § 164.306(a). How such risk is managed will be determined by a covered entity through its security risk analysis and the risk mitigation activities it implements in order to ensure that the level of security required by § 164.306 is provided.
Comment: Several commenters requested creation of a list of Federally "certified" security software and off-the-shelf products. Several others stated that this request was not feasible. Regarding certification of off-the-shelf products, one commenter thought this should be encouraged, but not mandated; several thought this would be an impractical endeavor.
Response: While we will not assume the task of certifying software and off-the-shelf products for the reason described above, we have noted with interest that other Government agencies such as the National Institute of Standards and Technology (NIST) are working towards that end. The health care industry is encouraged to monitor the activity of NIST and provide comments and suggestions when requested (see http://www.niap.nist.gov.).
Comment: One commenter stated, "With HCFA's publishing of these HIPAA standards, and their desire to retain the final responsibility for determining violations and imposing penalties of the statute, it also seems appropriate for HCFA to also provide certifying services to ensure security compliance."
Response: In view of the enormous number and variety of covered entities, we believe that evaluation can best be handled through the marketplace, which can develop more usable and targeted evaluation instruments and processes.
Business Associate Contracts or Other Arrangements (§ 164.308(b)(1))
The comments received on the proposed chain of trust partner agreements are discussed in section 2 "Business associate contracts and other arrangements" of the discussion of § 164.314.
| Proposed Requirements Not Adopted in the Final Rule Administrative Safeguards |
Security Configuration Management We proposed that an organization would be required to implement measures, practices, and procedures regarding security configuration management. They would be coordinated and integrated with other system configuration management practices for the security of information systems. These would include documentation, hardware and/or software installation and maintenance review and testing for security features, inventory procedures, security testing, and virus checking.
Comment: Several commenters asked that the entire requirement be deleted. Several others asked that the inventory and virus checking implementation features be removed as they believe those features are not germane to security configuration management. A number of commenters requested that security testing be deleted because this implementation feature is too detailed, unreasonable, impractical, and beyond the scope of the legislation.
Others stated that the testing would be very complex and expensive. Others wanted more clarification of what we intend by security testing, and how much would be enough. A number of commenters asked that all of the implementation features be deleted. Others asked that the implementation features be made optional. Several commenters wanted to know the scope of organizational integration required. Several others asked if what we meant by Security Configuration Management was change or version control.
Response: Upon review, this requirement appears unnecessary because it is redundant of other requirements we are adopting in this rule. A covered entity will have addressed the activities described by the features under this proposed requirement by virtue of having implemented the risk analysis, risk management measures, sanction policies, and information systems criticality review called for under the security management process. The proposed documentation implementation feature has been made a separate standard (see § 164.316). As a result, the Security Configuration Management requirement is not adopted in this final rule.
Formal Mechanism for Processing Records The proposed rule proposed requiring a formal mechanism for processing records, and documented policies and procedures for the routine and nonroutine receipt, manipulation, storage, dissemination, transmission, and/or disposal of health information. This requirement has not been adopted in the final rule.
Comment: Several commenters thought this requirement concerned the regulation of formal procedures for how an entity does business and stated that such procedures should not be regulated. Others asked for additional clarification of what is meant by this requirement. One commenter thought the requirement too ambiguous and asked for clarification as to whether we meant such things as "the proper handling of storage media, databases, transmissions," or "the clinical realm of processes."
Two commenters asked how extensive this requirement would be and whether systems' user manuals and policies and procedures for handling health information would suffice and what level of detail would be expected.
Several thought this requirement could result in a significant resource and monetary burden to develop and maintain formal procedures. Two asked for an explanation of the benefit to be derived from this requirement.
One asked that covered entities be required to document processes that create a security risk only and suggested that a risk assessment would determine the need for this documentation.
Response: We agree with the commenters that the standard is ambiguous, and upon review, is unnecessary because the remaining standards, for example, device and media controls, provide adequate safeguards. Accordingly, this requirement is not adopted in this final rule.