III. Analysis of, and Responses to, Public Comments on the Proposed Rule
D. General Rules (§ 164.306)
In the proposed rule, we proposed to cover all health information maintained or transmitted in electronic form by a covered entity. We proposed to adopt, in § 142.308, a nation-wide security standard that would require covered entities to implement security measures that would be technology-neutral and scalable, and yet integrate all the components of security (administrative procedures, physical safeguards, technical security services, and technical security mechanisms) that must be in place to preserve health information confidentiality, integrity, and availability (three basic elements of security). Since no comprehensive, scalable, and technology-neutral set of standards currently exists, we proposed to designate a new standard, which would define the security requirements to be fulfilled.
The proposed rule proposed to define the security standard as a set of scalable, technology-neutral requirements with implementation features that providers, plans, and clearinghouses would have to include in their operations to ensure that health information pertaining to an individual that is electronically maintained or electronically transmitted remains safeguarded. The proposed rule would have required that each affected entity assess its own security needs and risks and devise, implement, and maintain appropriate security to address its own unique security needs. How individual security requirements would be satisfied and which technology to use would be business decisions that each entity would have to make.
In the final rule we adopt this basic framework. In § 164.306, we set forth general rules pertaining to the security standards. In paragraph (a), we describe the general requirements. Paragraph (a) generally reflects section 1173(d)(2) of the Act, but makes explicit the connection between the security standards and the privacy standards (see § 164.306(a)(3)). In § 164.306(a)(1), we provide that the security standards apply to all electronic protected health information the covered entity creates, receives, maintains, or transmits. In paragraph (b)(1), we provide explicitly for the scalability of this rule by discussing the flexibility of the standards, and paragraph (b)(2) of § 164.306 discusses various factors covered entities must consider in complying with the standards.
The provisions of § 164.306(c) provide the framework for the security standards, and establish the requirement that covered entities must comply with the standards. The administrative, physical, and technical safeguards a covered entity employs must be reasonable and appropriate to accomplish the tasks outlined in paragraphs (1) through (4) of § 164.306(a). Thus, an entity's risk analysis and risk management measures required by § 164.308(a)(1) must be designed to lead to the implementation of security measures that will comply with § 164.306(a).
It should be noted that the implementation of reasonable and appropriate security measures also supports compliance with the privacy standards, just as the lack of adequate security can increase the risk of violation of the privacy standards. If, for example, a particular safeguard is inadequate because it routinely permits reasonably anticipated uses or disclosures of electronic protected health information that are not permitted by the Privacy Rule, and that could have been prevented by implementation of one or more security measures appropriate to the scale of the covered entity, the covered entity would not only be violating the Privacy Rule, but would also not be in compliance with § 164.306(a)(3) of this rule.
Paragraph (d) of § 164.306 establishes two types of implementation specifications, required and addressable. It provides that required implementation specifications must be met. However, with respect to implementation specifications that are addressable, § 164.306(d)(3) specifies that covered entities must assess whether an implementation specification is a reasonable and appropriate safeguard in its environment, which may include consideration of factors such as the size and capability of the organization as well as the risk. If the organization determines it is a reasonable and appropriate safeguard, it must implement the specification. If an addressable implementation specification is determined not to be a reasonable and appropriate answer to a covered entity's security needs, the covered entity must do one of two things: implement another equivalent measure if reasonable and appropriate; or if the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure at all. The covered entity must document the rationale behind not implementing the implementation specification. See the detailed discussion in section II.A.3.
Paragraph (e) of § 164.306 addresses the requirement for covered entities to maintain the security measures implemented by reviewing and modifying the measures as needed to continue the provision of reasonable and appropriate protections, for example, as technology moves forward, and as new threats or vulnerabilities are discovered.
1. Scope of Health Information Covered by the Rule (§ 164.306(a))
We proposed to cover health information maintained or transmitted by a covered entity in electronic form. We have modified, by narrowing, the scope of health information to be safeguarded under this rule from that which was proposed. The statute requires the privacy standards to cover individually identifiable health information. The Privacy Rule covers all individually identifiable information except for: (1) education records covered by the Family and Educational Rights and Privacy Act (FERPA); (2) records described in 20 U.S.C. 1232g(a)(4)(B)(iv); and (3) employment records. (see the Privacy Rule at 65 FR 82496. See also 67 FR 53191 through 53193). The scope of information covered in the Privacy Rule is referred to as "protected health information." Based upon the comments we received, we align the requirements of the Security and Privacy Rules with regard to the scope of information covered, in order to eliminate confusion and ease implementation. Thus, this final rule requires protection of the same scope of information as that covered by the Privacy Rule, except that it only covers that information if it is in electronic form.
We note that standards for the security of all health information or protected health information in nonelectronic form may be proposed at a later date.
a. Comment: One commenter stated that the rule should apply to aggregate information that is not identifiable to an individual. In contrast, another commenter asked that health information used for statistical analysis be exempted if the covered entity may reasonably expect that the removed information cannot be used to re-identify an individual.
Response: As a general proposition, any electronic protected health information received, created, maintained, or transmitted by a covered entity is covered by this final rule. We agree with the second commenter that certain 51 information, from which identifiers have been stripped, does not come within the purview of this final rule. Information that is de-identified, as defined in the Privacy Rule at § 164.502(d) and § 164.514(a), is not "individually identifiable" within the meaning of these rules and, thus, does not come within the definition of "protected health information." It accordingly is not covered by this final rule. For a full discussion of the issues of de-identification and re-identification of individually identifiable health information see 65 FR 82499 and 82708 through 82712 and 67 FR 53232 through 53234.
b. Comment: Several commenters asked whether systems that determine eligibility of clients for insurance coverage under broad categories such as medical coverage groups are considered health information. One commenter asked that we specifically exclude eligibility information from the standards.
Response: We cannot accept the latter suggestion. Eligibility information will typically be individually identifiable, and much eligibility information will also contain health information. If the information is "individually identifiable" and is "health information," (with three very specific exceptions noted in the general discussion above) and it is in electronic form, it is covered by the security standards if maintained or transmitted by a covered entity.
c. Comment: Several commenters requested clarification as to whether the standards apply to identifiable health information in paper form. Some commenters believed the rule should be applicable to paper; others argued that it should apply to all confidential, identifiable health information.
Response: While we agree that protected health information in paper or other form also should have appropriate security protections, the proposed rule proposing the security standards proposed to apply those standards to health information in electronic form only. We are, accordingly, not extending the scope in this final rule. We may establish standards to secure protected health information in other media in a future rule, in accordance with our statutory authority to do so. See discussion, supra, responding to a comment on the definition of "health information" and "individually identifiable health information."
d. Comment: The proposed rule would have excluded "telephone voice response" and "faxback" systems from the security standards, and we specifically solicited comments on that issue. A number of commenters agreed that telephone voice response and faxback should be excluded from the regulation, suggesting that the privacy standards rather than the security standards should apply. Others wanted those systems included, on the grounds that inclusion is necessary for consistency and in keeping with the intent of the Act. Still others specifically wanted personal computer-fax transmissions included. One commenter asked for clarification of when we would cover faxes, and another commenter asked why we were excluding them. Several commenters suggested that the other security requirements provide for adequate security of these systems.
Response: In light of these comments, we have decided that telephone voice response and "faxback" (that is, a request for information from a computer made via voice or telephone keypad input with the requested information returned as a fax) systems fall under this rule because they are used as input and output devices for computers, not because they have computers in them. Excluding these features would provide a huge loophole in any system concerned with security of the information contained and/or processed therein. It should be noted that employment of telephone voice response and/or faxback systems will generally require security protection by only one of the parties involved, and not the other. Information being transmitted via a telephone (either by voice or a DTMP tone pad) is not in electronic form (as defined in the first paragraph of the definition of "electronic media") before transmission and therefore is not subject to the Security Rule. Information being returned via a telephone voice response system in response to a telephone request is data that is already in electronic form and stored in a computer. This latter transmission does require protection under the Security Rule.
Although most recently made electronic devices contain microprocessors (a form of computer) controlled by firmware (an unchangeable form of computer program), we intend the term "computer" to include only software programmable computers, for example, personal computers, minicomputers, and mainframes. Copy machines, fax machines, and telephones, even those that contain memory and can produce multiple copies for multiple people are not intended to be included in the term "computer." Therefore, because "paper-to-paper" faxes, person-to-person telephone calls, video teleconferencing, or messages left on voice-mail were not in electronic form before the transmission, those activities are not covered by this rule. See also the definition of "electronic media" at § 160.103.
We note that this guidance differs from the guidance regarding the applicability of the Transactions Rule to faxback and voice response systems. HHS has stated that faxback and voice response systems are not required to follow the standards mandated in the Transactions Rule. This new guidance refers only to this rule.
e. Comment: One commenter asked whether there is a need to implement special security practices to address the shipping and receiving of health information and asked that we more fully explain our expectations and solutions in the final rules.
Response: If the handling of electronic protected health information involves shipping and receiving, appropriate measures must be taken to protect the information. However, specific solutions are not provided within this rule, as discussed in section III.A.3 of this final rule. The device and media controls standard under § 164.310(d)(1) addresses this situation.
f. Comment: One commenter wanted the "HTML" statement reworded to eliminate a specific exemption for HTML from the regulation.
Response: The Transactions Rule did not adopt the proposed exemption for HTML. The use of HTML or any other electronic protocol is not exempt from the security standards. Generally, if protected health information is contained in any form of electronic transmission, it must be appropriately safeguarded.
g. Comment: One commenter asked to what degree "family history" is considered health information under this rule and what protections apply to family members included in a patient's family history.
Response: Any health-related "family history" contained in a patient's record that identifies a patient, including a person other than the patient, is individually identifiable health information and, to the extent it is also electronic protected health information, must be afforded the security protections.
h. Comment: Two commenters asked that the rule prohibit re-identification of de-identified data. In contrast, several commenters asked that we identify a minimum list or threshold of specific re-identification data elements (for example, name, city, and ZIP) that would fall under this final rule so that, for example, the rule would not affect numerous systems, for example, network adequacy and population-based clinical analysis databases. One commenter asked that we establish a means to use re-identified information if the entity already has access to the information or is authorized to have access.
Response: The issue of re-identification is addressed in the Privacy Rule at § 164.502(d) and § 164.514(c). The reader is referred to those sections and the related discussion in the preamble to the Privacy Rule (65 FR 82712) and the preamble to the Privacy Modifications (67 FR 53232 through 53234) for a full discussion of the issues of re-identification. We note that once information in the possession (or constructive possession) of a covered entity is re-identified and meets the definition of electronic protected health information, the security standards apply.
2. Technology-Neutral Standards
Comment: Many commenters expressed support for our efforts to develop standards for the security of health information. A number of comments were made in support of the technology-neutral approach of the proposed rule. For example, one commenter stated, "By avoiding prescription of the specific technologies health care entities should use to meet the law's requirements, you are opening the door for industry to apply innovation. Technologies that don't currently exist or are impractical today could, in the near future, enhance health information security while minimizing the overall cost." Several other commenters stated that the requirements should be general enough to withstand changes to technology without becoming obsolete. One commenter anticipates no problems with meeting the standards.
In contrast, one commenter suggested that whenever possible, specific technology recommendations should provide sufficient detail to promote systems interoperability and decrease the tendency toward adoption of multiple divergent standards. Several commenters stated that by letting each organization determine its own rules, the rules impose procedural burdens without any substantive benefit to security.
Response: The overwhelming majority of comments supported our position. We do not believe it is appropriate to make the standards technology-specific because technology is simply moving too fast, for example, the increased use and sophistication of internet-enabled hand held devices. We believe that the implementation of these rules will promote the security of electronic protected health information by (1) providing integrity and confidentiality; (2) allowing only authorized individuals access to that information; and (3) ensuring its availability to those authorized to access the information. The standards do not allow organizations to make their own rules, only their own technology choices.
3. Miscellaneous Comments
a. Comment: Some commenters stated that the requirements and implementation features set out in the proposed rule were not specific enough to be considered standards, and that the actual standards are delegated to the discretion of the covered entities, at the expense of medical record privacy. Several commenters stated that it was inappropriate to balance the interests of those seeking to use identifiable medical information without patient consent against the interest of patients. Several other commenters believe that allowing covered entities to make their own decisions about the adequacy and balance of security measures undermined patient confidentiality interests, and stated that the proposed rule did not appear to adequately consider patient concerns and viewpoints.
Response: Again, the overwhelming majority of commenters supported our approach. This final rule sets forth requirements with which covered entities must comply and labels those requirements as standards and implementation specifications. Adequate implementation of this final rule by covered entities will ensure that the electronic protected health information in a covered entity's care will be as protected as is feasible for that entity. We disagree that covered entities are given complete discretion to determine their security polices under this rule, resulting in effect, in no standards. While cost is one factor a covered identity may consider in determining whether to implement a particular implementation specifications, there is nonetheless a clear requirement that adequate security measures be implemented, see 45 CFR 164.306(b). Cost is not meant to free covered entities from this responsibility.
b. Comment: Several commenters requested we withdraw the regulations, citing resource shortages due to Y2K preparation, upcoming privacy legislation, and/or the "excessive micro-management" contained in the rules. One commenter stated that, to insurers, these rules were onerous, not necessary, and not justified as cost-effective, as they already have effective practices for computer security and are subject to rigorous State laws for the safeguarding of health information. Another commenter stated that these rules would adversely affect a provider's practice environment.
Response: The HIPAA statute requires us to promulgate a rule adopting security standards for health information. Resource concerns due to Y2K should no longer be an issue. Covered entities will have 2 years (or, in the case of small health plans, 3 years) from the adoption of this final rule in which to comply. Concerns relative to effective and compliance dates and the Privacy Rule are discussed under § 164.318, Compliance dates for initial implementation, below and at 65 FR 82751 through 82752.
We disagree that these standards will adversely affect a provider's practice environment. The scalability of the standards allows each covered entity to implement security protections that are appropriate to its specific needs, risks, and environments. These protections are necessary to maintain the confidentiality, integrity, and availability of patient data. A covered entity that lacks adequate protections risks inadvertent disclosure of patient data, with resulting loss of public trust, and potential legal action. For example, a covered entity with poor facility access controls and procedures would be susceptible to hacking of its databases. A provider with appropriate security protections already in place would only need to ensure that the protections are documented and are reassessed periodically to ensure that they continue to be appropriate and are actually being implemented. Our decision to classify many implementation specifications as addressable, rather than mandatory, provides even more flexibility to covered entities to develop cost-effective solutions. We believe that insurers who already have effective security programs in place will have met many of the requirements of this regulation.
c. Comment: One commenter believes the rule is arbitrary and capricious in its requirements without any justification that they will significantly improve the security of medical records and with the likelihood that their implementation may actually increase the vulnerability of the data. The commenter noted that the data backup requirements increase access to data and that security awareness training provides more information to employees.
Response: The standards are based on generally accepted security procedures, existing industry standards and guidelines, and recommendations contained in the National Research Council's 1997 report "For The Record: Protecting Electronic Health Information," Chapter 6. We also consulted extensively with experts in the field of security throughout the health care industry. The standards are consistent with generally accepted security principles and practices that are already in widespread use.
Data backup need not result in increased access to that data. Backups should be stored in a secure location with controlled access. The appropriate secure location and access control will vary, based upon the security needs of the covered entity. For example, a procedure as simple as locking backup diskettes in a safe place and restricting who has access to the key may be suitable for one entity, whereas another may need to store backed-up information off-site in a secure computer facility. The information provided in security awareness training heightens awareness of security anomalies and helps to prevent security incidents.
d. Comment: Several commenters suggested that the proposed rule appears to reflect the Medicare program's perspective on security risks and solutions, and that it should be noted that not all industry segments share all the same risks as Medicare. One commenter stated that as future proposed rules are drafted, we should solicit input from those most significantly affected, for example, providers, plans, and clearinghouses. Others stated that Medicaid agencies were not sufficiently involved in the discussions and debate. Still another stated that States would be unable to perform some basic business functions if all the standards are not designed to meet their needs.
Response: We believe that the standards are consistent with common industry practices and equitable, and that there has been adequate consultation with interested parties in the development of the standards. These standards are the result of an intensive process of public consultation. We consulted with the National Uniform Billing Committee, the National Uniform Claim Committee, the American Dental Association, and the Workgroup for Electronic Data Interchange, in the course of developing the proposed rule. Those organizations were specifically named in the Act to advise the Secretary, and their membership is drawn from the full spectrum of industry segments. In addition, the National Committee on Vital and Health Statistics (NCVHS), an independent advisory group to the Secretary, held numerous public hearings to obtain the views of interested parties. Again, many segments of the health care industry, including provider groups, health plans, clearinghouses, vendors, and government programs participated actively. The NCVHS developed recommendations to the Secretary, which were relied upon as we developed the proposed rule. Finally, we note that the opportunity to comment was available to all during the public comment period.
e. Comment: One commenter stated that there is a need to ensure the confidentiality of risk analysis information that may contain sensitive information.
Response: The information included in a risk analysis would not be subject to the security standards if it does not include electronic protected health information. We agree that risk analysis data could contain sensitive information, just as other business information can be sensitive. Covered entities may wish to develop their own business rules regarding access to and protections for risk analysis data.
f. Comment: One commenter expressed concern over the statement in the preamble of the proposed rule
(63 FR 43250) that read: "No one item is considered to be more important than another." The commenter suggested that security management should be viewed as most critical and perhaps what forms the foundation for all other security actions.
Response: The majority of comments received on this subject requested that we prioritize the standards. In response, we have regrouped the standards and implementation specifications in what we believe is a logical order within each of three categories: "Administrative safeguards," "Physical safeguards," and "Technical safeguards." In this final rule, we order the standards in such a way that the "Security management process" is listed first under the "Administrative safeguards" section, as we believe this forms the foundation on which all of the other standards depend. The determination of the specific security measures to be implemented to comply with the standards will, in large part, be dependent upon completion of the implementation specifications within the security management process standard (see § 164.308(a)(1)). We emphasize, however, that an entity implementing these standards may choose to implement them in any order, as long as the standards are met.
g. Comment: One commenter stated that there is a need for requirements concerning organizational practices (for example, education, training, and security and confidentiality policies), as well as technical practices and procedures.
Response: We agree. Section 164.308 of this final rule describes administrative safeguards that address these topics. Section 164.308 requires covered entities to implement standards and required implementation specifications, as well as consider and implement, when appropriate and reasonable, addressable implementation specifications. For example, the security management process standard requires implementation of a risk analysis, risk management, a sanction policy, and an information system activity review. The information access management standard requires consideration, and implementation where appropriate and reasonable, of access authorization and access establishment and modification policies and procedures. Other areas addressed are
68 assigned security responsibility, workforce security, security awareness and training, security incident procedures, contingency planning, business associate contracts, and evaluation.
h. Comment: One commenter stated that internal and external security requirements should be separated and dealt with independently.
Response: The presentation of the standards within this final rule could have been structured in numerous ways, including by addressing separate internal and external security standards. We chose the current structure as we considered it a logical breakout for purposes of display within this final rule. Under our structure a covered entity may apply a given standard to internal activities and to external activities. Had we displayed separately the standards for internal security and the standards for external security, we would have needed to describe a number of the standards twice, as many apply to both internal and external security. However, a given entity may address the standards in whatever order it chooses, as long as the standards are met.
i. Comment: Two commenters stated that the standards identified in Addendum 3 of the proposed rule may not all have matured to implementation readiness.
Response: Addendum 3 of the proposed rule cross-referred individual requirements on the matrix to existing industry standards of varying levels of maturity. Addendum 3 was intended to show what we evaluated in searching for existing industry standards that could be adopted on a national level. No one standard was found to be comprehensive enough to be adopted, and none were proposed as the standards to be met under the Security Rule.
j. Comment: One commenter suggested we include a revised preamble in the final publication. Another questioned how clarification of points in the preamble will be handled if the preamble is not part of the final regulation.
Response: Preambles to proposed rules are not republished in the final rule. The preamble in this final rule contains summaries of the information presented in the preamble of the proposed rule, summaries of the comments received during the public comment period, and responses to questions and concerns raised in those comments and a summary of changes made. Additional clarification will be provided by HHS on an ongoing basis through written documents and postings on HHS's websites.
k. Comment: One commenter asked that we clarify that no third party can require implementation of more security features than are required in the final rule, for example, a third party could not require encryption but may choose to accept it if the other party so desires.
Response: The security standards establish a minimum level of security to be met by covered entities. It is not our intent to limit the level of security that may be agreed to between trading partners or others above this floor.
l. Comment: One commenter asked how privacy legislation would affect these rules. The commenter inquired whether covered entities will have to reassess and revise actions already taken in the spirit of compliance with the security regulations.
Response: We cannot predict if or how future legislation may affect the rules below. At present, the privacy standards at subpart E of 42 CFR part 164 have been adopted, and this final rule is compatible with them.
m. Comment: One commenter stated that a data classification policy, that is a method of assigning sensitivity ratings to specific pieces of data, should be part of the final regulations.
Response: We did not adopt such a policy because this final rule requires a floor of protection of all electronic protected health information. A covered entity has the option to exceed this floor. The sensitivity of information, the risks to and vulnerabilities of electronic protected health information and the means that should be employed to protect it are business determinations and decisions to be made by each covered entity.
n. Comment: One commenter stated that this proposed rule conflicts with previously stated rules that acceptable "standards" must have been developed by ANSI-recognized Standards Development Organizations (SDOs).
Response: In general, HHS is required to adopt standards developed by ANSI-accredited SDOs when such standards exist. The currently existing security standards developed by ANSI-recognized SDOs are targeted to specific technologies and/or activities. No existing security standard, or group of standards, is technology-neutral, scaleable to the extent required by HIPAA, and broad enough to be adopted in this final rule. Therefore, this final rule adopts standards under section 1172(c)(2)(B) of the Act, which permits us to develop standards when no industry standards exist.
o. Comment: One commenter stated that this regulation goes beyond the scope of the law, unjustifiably extending into business practices, employee policies, and facility security.
Response: We do not believe that this regulation goes beyond the scope of the law. The law requires HHS to adopt standards for reasonable and appropriate security safeguards concerning such matters as compliance by the officers and employees of covered entities, protection against reasonably anticipated unauthorized uses and disclosures of health information, and so on. Such standards will inevitably address the areas the commenter pointed to.
The intent of this regulation is to provide standards for the protection of electronic protected health information in accordance with the Act. In order to do this, covered entities are required to implement administrative, physical, and technical safeguards. Those entities must ensure that data are protected, to the extent feasible, from inappropriate access, modification, dissemination, and destruction. As noted above, however, this final rule has been modified to increase flexibility as to how this protection is accomplished.
p. Comment: One commenter stated that all sections regarding confidentiality and privacy should be removed, since they do not belong in this regulation.
Response: As the discussion in section III.A above of this final rule makes clear, the privacy and security standards are very closely related. Section 1173(d)(2) of the Act specifically mentions "confidentiality" and authorizes uses and disclosures of information as part of what security safeguards must address. Thus, we cannot omit all references to confidentiality and privacy in discussions of the security standards. However, we have relocated material that relates to both security and privacy (including definitions) to the general section of part 164.
q. Comment: One commenter asked that data retention be addressed more specifically, since this will become a significant issue over time. It is recommended that a national work group be convened to address this issue.
Response: The commenter's concern is noted. While the documentation relating to Security Rule implementation must be retained for a period of 6 years (see § 164.316(b)(2)), it is not within the scope of this final rule to address data retention time frames for administrative or clinical records.
r. Comment: One commenter stated that requiring provider practices to develop policies, procedures, and training programs and to implement record keeping and documentation systems would be tremendously resource-intensive and increase the costs of health care.
Response: We expect that many of the standards of this final rule are already being met in one form or another by covered entities. For example, as part of normal business operations, health care providers already take measures to protect the health information in their keeping. Health care providers already keep records, train their employees, and require employees to follow office policies and procedures. Similarly, health plans are already frequently required by State law to keep information confidential. While revisions to a practice's or plan's current activities may be necessary, the development of entirely new systems or procedures may not be necessary.
s. Comment: One commenter stated that there is no system for which risk has been eliminated and expressed concern over phrases such as covered entities must "assure that electronic health information pertaining to an individual remains secure."
Response: We agree with the commenter that there is no such thing as a totally secure system that carries no risks to security. Furthermore, we believe the Congress' intent in the use of the word "ensure" in section 1173(d) of the Act was to set an exceptionally high goal for the security of electronic protected health information. However, we note that the Congress also recognized that some trade-offs would be necessary, and that “ensuring” protection did not mean providing protection, no matter how expensive. See section 1173(d)(1)(A)(ii) of the Act. Therefore, when we state that a covered entity must ensure the safety of the information in its keeping, we intend that a covered entity take steps, to the best of its ability, to protect that information. This will involve establishing a balance between the information's identifiable risks and vulnerabilities, and the cost of various protective measures, and will also be dependent upon the size, complexity, and capabilities of the covered entity, as provided in § 164.306(b).