No, unless the disclosure is otherwise permitted under the HIPAA Privacy Rule, particularly given that cyber threat indicators do not generally include PHI.

The Cybersecurity Information Sharing Act of 2015 (CISA) describes cyber threat indicators as information that is necessary to describe or identify: malicious reconnaissance; methods of defeating a security control or exploitation of a security vulnerability; a security vulnerability; methods of causing a user with legitimate access to defeat of a security control or exploitation of a security vulnerability; malicious cyber command and control; a description of actual or potential harm caused by an incident; any other attribute of a cybersecurity threat, if disclosure of such attribute is not otherwise prohibited by law; or any combination thereof.

The disclosure of cyber threat indicators for cyber information sharing is meant to alert other entities and the federal government to possible or actual threats or vulnerabilities to information systems, and to generally describe possible harms from such threats or vulnerabilities. Such information may include, as described above, technical, physical, or administrative specifications regarding threats to such systems, or vulnerabilities in such systems, and a general description of the harm caused by exploitation of these specifications.

The disclosure of PHI generally is not needed to describe such threats or vulnerabilities. Further, HIPAA would not permit such disclosures unless specific conditions provided in the HIPAA Privacy Rule were met, specifically, an authorization from the individual or the requirements of an applicable permission for disclosure under the Rule.

For example, the HIPAA Privacy Rule in 45 CFR § 164.512 permits covered entities and business associates to disclose PHI to law enforcement officials, without the individual’s written authorization, if specific conditions and limitations are met, including:

• To comply with a court order or court-ordered warrant, a subpoena or summons issued by a judicial officer, or a grand jury subpoena (45 CFR 164.512(f)(1)(ii)(A)-(B)).
• To respond to an administrative request, such as an administrative subpoena or investigative demand or other written request from a law enforcement official, that includes or is accompanied by a written statement that the information requested is relevant and material, specific and limited in scope, and de-identified information cannot be used (45 CFR 164.512(f)(1)(ii)(C)).
• To respond to a request for limited PHI for purposes of identifying or locating a suspect, fugitive, material witness or missing person (45 CFR 164.512(f)(2)).
• To respond to a request for PHI about a victim of a crime, and the victim agrees (45 CFR 164.512(f)(3)).
• To report PHI to law enforcement when required by law to do so (45 CFR 164.512(f)(1)(i)).
• To alert law enforcement to the death of the individual, when there is a suspicion that death resulted from criminal conduct (45 CFR 164.512(f)(4)).
• To report PHI that the covered entity in good faith believes to be evidence of a crime that occurred on the covered entity’s premises (45 CFR 164.512(f)(5)).
• When responding to an off-site medical emergency, as necessary to alert law enforcement about criminal activity, specifically, the commission and nature of the crime, the location of the crime or any victims, and the identity, description, and location of the perpetrator of the crime (45 CFR 164.512(f)(6)).
• To federal officials authorized to conduct intelligence, counter-intelligence, and other national security activities under the National Security Act (45 CFR 164.512(k)(2)) or to provide protective services to the President and others and conduct related investigations (45 CFR 164.512(k)(3)).

Absent a provision in the Rule expressly permitting disclosure of PHI, such as outlined above, an individual’s authorization would be required for the disclosure of the individual’s PHI.

The HIPAA Privacy and Security Rules are enforced by the Office for Civil Rights (OCR). View more information about complaints related to concerns about protected health information.

The Office of E-Health Standards and Services within the Centers for Medicare & Medicaid Services (CMS) enforces the Transactions and Code Sets and National Identifiers (Employer and Provider identifiers) regulations of the Health Insurance Portability and Accountability Act (HIPAA). Complaints regarding the Transactions and Code Sets and National Identifiers regulations may be submitted electronically or via paper form – PDF. CMS also enforces the insurance portability requirements under Title I of HIPAA. View more information about portability and how to obtain information or assistance.

With regard to networking computers, there is nothing in the Security Rule that prohibits the networking of computers, whether inside the same company, or between two unrelated companies who conduct business together. However, the covered entity must demonstrate that it has evaluated the risks associated with a network connection, and document that it has established all of the safeguards (technical, physical and administrative) that would serve to reasonably protect the information that is exchanged along the network. That will include an assessment of everything from the firewall to the designation and training of the individuals who have access to the data.

Physical safeguards are physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment from natural and environmental hazards, and unauthorized intrusion. The standards under physical safeguards include facility access controls, workstation use, workstation security, and device and media controls. The Security Rule requires covered entities to implement physical safeguard standards for their electronic information systems whether such systems are housed on the covered entity’s premises or at another location.

No, the Security Rule is not suspended during a national or public health emergency. The Secretary of HHS may waive sanctions and penalties arising from certain provisions of the Privacy Rule under the Project BioShield Act of 2004 (PL 108-276) and section 1135(b)(7) of the Social Security Act if the President declares an emergency or disaster and the Secretary declares a public health emergency. However, these provisions have no application to the Security Rule. The Security Rule includes requirements for covered entities to ensure the confidentiality, integrity and availability of all electronic protected health information they create, receive, maintain or transmit. The rule further requires that covered entities protect against any reasonably anticipated threats or hazards to the security or integrity of such information. Other provisions of the Security Rule require covered entities to implement security measures that specifically contemplate emergency conditions. For example, covered entities must have contingency plans that establish policies and procedures for responding to an emergency or other occurrence (fire, system failure and natural disaster) that damages systems that contain e-PHI (45 CFR §164.308(a)(7)(i)). As with all HIPAA-related complaints, the Office for Civil Rights will evaluate complaints that arise during the course of a national or public health emergency on a case-by-case basis and exercise its discretion in taking enforcement action. For more information on suspension of the Privacy Rule during a national or public health emergency, please see FAQ #1068.

The purpose of the Security Rule is to adopt national standards for safeguards to protect the confidentiality, integrity, and availability of electronic protected health information (e-PHI) that is collected, maintained, used or transmitted by a covered entity. Compliance is different for each organization and no single strategy will serve all covered entities. Covered entities should look to § 164.306 of the Security Rule for guidance to support decisions on how to comply with the standards and implementation specifications contained in § 164.308, 164.310, 164.312, 164.314, and 164.316. In general, this includes performing a risk analysis; implementing reasonable and appropriate security measures; and documenting and maintaining policies, procedures and other required documentation. Compliance is not a one-time goal, but an ongoing process. Meeting the requirements set out in the evaluation standard at § 164.308(a)(8) will assist covered entities in maintaining substantial compliance. By performing periodic technical and non-technical evaluations of the information security environment, a covered entity will be able to better ensure the security of e-PHI.

No, there is no standard or implementation specification that requires a covered entity to “certify” compliance. The evaluation standard § 164.308(a)(8) requires covered entities to perform a periodic technical and non-technical evaluation that establishes the extent to which an entity’s security policies and procedures meet the security requirements. The evaluation can be performed internally by the covered entity or by an external organization that provides evaluations or “certification” services. A covered entity may make the business decision to have an external organization perform these types of services. It is important to note that HHS does not endorse or otherwise recognize private organizations’ “certifications” regarding the Security Rule, and such certifications do not absolve covered entities of their legal obligations under the Security Rule. Moreover, performance of a “certification” by an external organization does not preclude HHS from subsequently finding a security violation.

Although a plan sponsor may not be a HIPAA covered entity subject to the Security Rule, it would nevertheless be obligated, through its plan documents, to report such security incidents to the group health plan. Specifically, the required implementation specification at § 164.314(b)(2)(iv) requires the plan documents of the group health plan to require the plan sponsor to “report to the group health plan any security incident of which it becomes aware.” (Note that in certain circumstances a group health plan may not be required to amend its plan documents. See § 164.314(b)(1).) The plan documents could serve as the vehicle to establish a plan sponsor’s specific reporting requirements and should be developed to meet the group health plan’s specific needs. The group health plan and its plan sponsor must document the specifics of the reporting, including the frequency, level of detail, format and other relevant considerations (e.g., in aggregate or per incident, weekly or monthly). In addressing this required implementation specification, a group health plan may consider some of the following questions: what specific actions would be considered security incidents; how will incidents be documented and reported; what information should be contained in the documentation; how often and to whom within the covered entity should incidents be reported; what are the appropriate responses to certain incidents; and whether identifying patterns of attempted security incidents is reasonable and appropriate.

For example, in order to determine the detailed content of its plan documents, in taking into consideration the requirements of § 164.306(a) and (b) and its risk analysis, the group health plan may decide that certain types of attempted or successful security incidents or patterns of attempted or successful incidents, such as a “ping” (a request-response utility used to determine whether a specific Internet Protocol (IP) address, or host, exists or is accessible) on the plan sponsor’s communications network initiated from an external source, could be reported to the group health plan in a monthly report that only includes an aggregate number of pings that month. Based on its analysis, the group health plan may also determine that other types of incidents, such as suspicious patterns of “pings” on the plan sponsor’s communications network initiated from an external source, or a specific malicious security incident, would require a detailed report to the group health plan as soon as the plan sponsor becomes aware of them.

45 CFR § 164.304 defines security incident as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. The Security Incident Procedures standard at § 164.308(a)(6)(i) requires a covered entity to implement policies and procedures to address security incidents. The associated implementation specification for response and reporting at § 164.308(a)(6)(ii) requires a covered entity to 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, and document security incidents and their outcomes. In order to maintain a flexible, scalable and technology neutral approach to the Security Rule, no single method is identified for addressing security incidents that will apply to all covered entities. As stated in the preamble to the Security Rule, 68 Fed. Reg. 8350 (February 20, 2003), 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 Rule standards, to determine what constitutes a security incident in the context of its business operations. In addressing the Security Incident Procedures standard, a covered entity may consider some of the following questions: what specific actions would be considered security incidents; how will incidents be documented and reported; what information should be contained in the documentation; how often and to whom should incidents be reported; what are the appropriate responses to certain incidents; and whether identifying patterns of attempted security incidents is reasonable and appropriate. When taking into consideration the requirements of § 164.306(a) and (b), and its risk analysis, the covered entity may decide that certain types of attempted or successful security incidents or patterns of attempted or successful incidents warrant different actions.

For example, a covered entity may decide that a “ping” (a request-response utility used to determine whether a specific Internet Protocol (IP) address, or host, exists or is accessible) on the communications network initiated from an external source would require the following actions to comply with the standard; (1) minimal, if any, response; (2) no mitigation actions since no harmful effects were caused by the incident; and (3) brief documentation of the security incident and outcome, such as, a recording of aggregate statistical information. Based on its analysis, the entity may also determine that other types of incidents, such as suspicious patterns of “pings” on the communications network initiated from an external source or a specific malicious security incident would require a more detailed response, mitigation steps, and more detailed documentation of the incident and outcome. While internal reporting of security incidents is an inherent part of security incident policies and procedures, the Security Rule generally does not require a covered entity to report incidents to outside entities. However, § 164.314(a)(2)(i)(C) and (b)(2)(iv) require contracts between a covered entity and a business associate, and plan documents of a group health plan, respectively, to include provisions that require business associates and plan sponsors to report to the covered entity any security incidents of which they become aware. (Note that in certain circumstances a group health plan may not be required to amend its plan documents. See § 164.314(b)(1).)

No. Under the Security Rule, covered entities, regardless of their size, are required, under § 164.312(a)(2)(i) to “assign a unique name and/or number for identifying and tracking user identity.” A “user” is defined in § 164.304 as a “person or entity with authorized access.” Accordingly, the Security Rule requires covered entities to assign a unique name and/or number to each employee or workforce member who uses a system that maintains electronic protected health information (e-PHI), so that system access and activity can be identified and tracked by user. This pertains to workforce members within small or large healthcare provider offices, health plans, group health plans, and healthcare clearinghouses.

No. Covered entities may use any of the NIST documents to the extent that they provide relevant guidance to that organization’s implementation activities. While NIST documents were referenced in the preamble to the Security Rule, their use is not required by the Security Rule.

No. The Security Rule was written to allow flexibility for covered entities to implement security measures that best fit their organizational needs. The Security Rule does not specify minimum requirements for personal computer operating systems, but it does mandate requirements for information systems that contain electronic protected health information (e-PHI). Therefore, as part of the information system, the security capabilities of the operating system may be used to comply with technical safeguards standards and implementation specifications such as audit controls, unique user identification, integrity, person or entity authentication, or transmission security. Additionally, any known security vulnerabilities of an operating system should be considered in the covered entity’s risk analysis (e.g., does an operating system include known vulnerabilities for which a security patch is unavailable, e.g., because the operating system is no longer supported by its manufacturer).

No, the Security Rule does not require the use of electronic or digital signatures. However, electronic or digital signatures could be used as a security measure if the covered entity determines their use is reasonable and appropriate.

The Security Rule does not expressly prohibit the use of email for sending e-PHI. However, the standards for access control (45 CFR § 164.312(a)), integrity (45 CFR § 164.312(c)(1)), and transmission security (45 CFR § 164.312(e)(1)) require covered entities to implement policies and procedures to restrict access to, protect the integrity of, and guard against unauthorized access to e-PHI. The standard for transmission security (§ 164.312(e)) also includes addressable specifications for integrity controls and encryption. This means that the covered entity must assess its use of open networks, identify the available and appropriate means to protect e-PHI as it is transmitted, select a solution, and document the decision. The Security Rule allows for e-PHI to be sent over an electronic open network as long as it is adequately protected.

Yes. Covered entities that allow employees to telecommute or work out of home-based offices, and have access to e-PHI, must implement appropriate safeguards to protect the organization’s data. The automatic logoff implementation specification is addressable, and must therefore be implemented if, after an assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its environment. If the entity decides that the logoff implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision. The information access management and access control standards, however, require the covered entity to implement policies and procedures for authorizing access to e-PHI and technical policies and procedures to allow access only to those persons or software programs that have been appropriately granted access rights.

Encryption is a method of converting an original message of regular text into encoded text. The text is encrypted by means of an algorithm (type of formula). If information is encrypted, there would be a low probability that anyone other than the receiving party who has the key to the code or access to another confidential process would be able to decrypt (translate) the text and convert it into plain, comprehensible text. For more information about encryption , please see NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices. – PDF

No. The final Security Rule made the use of encryption an addressable implementation specification. See 45 CFR § 164.312(a)(2)(iv) and (e)(2)(ii). The encryption implementation specification is addressable, and must therefore be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity and availability of e-PHI. If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision.

If an implementation specification is described as “required,” the specification must be implemented. The concept of “addressable implementation specifications” was developed to provide covered entities additional flexibility with respect to compliance with the security standards. In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification: (a) implement the addressable implementation specifications; (b) implement one or more alternative security measures to accomplish the same purpose; (c) not implement either an addressable implementation specification or an alternative. The covered entity’s choice must be documented. The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative. This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.

No. The Security standards were designed to be “technology neutral” in order to facilitate use of the latest and most promising technologies that meet the needs of different healthcare organizations. Any regulatory requirement for implementation of specific technologies would bind the health care community to specific systems and/or software that may be superseded by rapidly developing technologies and improvements.

No. The standards and specifications of the Security Rule are specific to electronic protected health information (e-PHI). It should be noted however that e-PHI also includes telephone voice response and fax back systems because they can be used as input and output devices for electronic information systems. E-PHI does not include paper-to-paper faxes or video teleconferencing or messages left on voice mail, because the information being exchanged did not exist in electronic form before the transmission. In contrast, the requirements of the Privacy Rule apply to all forms of PHI, including written and oral.

In enacting HIPAA, Congress mandated the establishment of Federal standards for the security of electronic protected health information (e-PHI). The purpose of the Security Rule is to ensure that every covered entity has implemented safeguards to protect the confidentiality, integrity, and availability of electronic protected health information. Standards for security are needed because there is a growth in the exchange of protected health information between covered entities as well as non-covered entities. The standards mandated in the Security Rule protect an individual’s health information, while permitting the appropriate access and use of that information by health care providers, clearinghouses, and health plans. The Security Rule establishes a Federal floor of standards to ensure the availability, confidentiality and integrity of e-PHI. State laws which provide more stringent standards will continue to apply over and above the new Federal security standards.

Health care providers, health plans and their business associates have a strong tradition of safeguarding private health information. However, in today’s world, the old system of paper records in locked filing cabinets is not enough. With information broadly held and transmitted electronically, the Rule provides clear standards for the protection of e-PHI.

The Security Rule standards allow any covered entity (including small providers) to use any security measures that help the covered entity to reasonably and appropriately implement the standards to protect electronic health information. In deciding what security measures to use, a covered entity can take into account its size, capabilities, and costs of security measures. A small provider who is a covered entity would first assess their security risks and vulnerabilities and the mechanisms currently in place to mitigate those risks and vulnerabilities. Following this assessment, they should determine what additional measures, if any, need to be taken to meet the standards; taking into account their capabilities and the cost of those measures. For more information on the implementation of the Security Rule by small providers, please see the Security Paper Educational Series. – PDF.