HIPAA Security Rule Technical Safeguards

References §164.312(a)(2)(i) Unique user identification.

Process: Your CO, in collaboration with your CIO, should ensure that all Information Systems and computing infrastructure require unique identification so that proper authentication of a user can be ensured. Your CO, in collaboration with your CIO, is responsible for establishing a unique identifier methodology for all Workforce members, business associates, and third-party Information Systems that require access to your ePHI and for ensuring that all Information Systems and infrastructure enforce it.

Tracking: Your unique identification methodology will be stored in your Compliance Repository. Information Systems and other computing infrastructure should be enabled so that only a person or application that provides a valid unique identifier will be allowed access to the resource.

Unique Identifer: What is this? Each member in your Workforce is required to have a unique identifier. Normally, this is the member’s email address, but it could be any identifier that the organization chooses. The purpose of this identifier is to track who does what in the applications, infrastructure, and devices that access PHI. In other words, this identifier is used for accountability.

References §164.312(a)(2)(ii) Emergency access procedure.

Process: Your DRP should contain a list of essential personnel required to have access to ePHI during emergency mode operations. Testing of your DRP will ensure that these individuals get prioritized access to ePHI so that ePHI can readily be made available to other stakeholders that may require access. Once emergency mode operations stabilize, then other stakeholders should be granted their usual and customary access to ePHI.

Tracking: Real time emergency mode testing should capture results showing the effectiveness of your emergency mode access processes. Your emergency mode access process should be updated based on test results and post- mortem analysis after live emergencies. Your emergency mode processes, test results, and analysis documentation should be stored in our Compliance Repository.

Emergency Accesss Procesures: What is this? You are required to identify who, from your Workforce, needs immediate access to PHI in the case of an emergency. This implies that you have moved your operations to a remote site and are rebuilding your application infrastructure. Not everyone needs immediate access for your organization to start serving stakeholders. Obviously, and almost certainly, clinicians are going to need immediate access so that they can start treating patients. Access for administrative personnel can wait until the emergency subsides.

References §164.312(a)(2)(ii) Automatic logoff.

Process: Your CO and CIO should ensure that all COTS Information Systems and computing infrastructure purchased have “automatic logoff” functionality built-in and that it is enforced across your ePHI Assets. Your CO and CIO should ensure any custom developed Information Systems behave in a similar manner. Your CO and CIO should ensure that “automatic logoff” events are captured in Information System and computing infrastructure audit logs.

Tracking: Automatic logoff events should be captured in Information System audit logs and reviewed by Workforce members whose responsibility it is to review these logs. Yur CO should conduct periodic audits to ensure that “automatic logoff” functionality is embedded in all your Information Systems and computing infrastructure and behaving in manner consistent with our Security Rule objectives.

Automatic Logoff: What is this? Systems and applications should automatically logoff once they have been idle for a predetermined length of time. Expresso® specifies the idle time required to trigger logoff. Obviously, the intent here is that others do not utilize another Workforce member’s credentials while they may be away from the current application or device they were interacting with. In addition, workforce members often use “black screens” to cover and prevent others from viewing the ePHI on their devices.

References §164.312(a)(2)(ii)) Encryption and decryption.

Process: Your CO and CIO should ensure that your Organization maintains a complete list of media containing ePHI to encrypt ePHI as much as practical and to dispose of the media properly at end-of-life. Your CO and CIO should institute a process for moving all ePHI from mobile devices and personal computers to centralized servers (i.e., either locally hosted or cloud based) wherever practical. The reasons for these are manifold including, but not limited to, the following: (a) centralization makes it easier to manage encryption; and (b) centralization provides more opportunities to implement rigorous safeguards—Administrative, Technical, and Physical. Best practices from COTS vendors (e.g., Microsoft, Oracle, Google, Apple, etc.) should be reviewed to determine how to best encrypt ePHI where their proprietary operating systems and Information Systems provide the vector by which encryption is best enabled.

Tracking: Information Systems and infrastructure with encryption enabled should be designated as such in your Security Objects inventory, which is stored in your Compliance repository. Random audits should be conducted to ensure that mobile devices and personal computers, if they contain ePHI at all, only contain ePHI that has been encrypted as per the Secretary’s Guidance, unless an exception has been approved by your CO. Results from random audits should be stored in your Compliance Repository. Sanctions on Workforce members imposed as a result of your random audits should be stored in your Compliance Repository.

Encryption and decryption: What is this? Encryption of PHI means to make it unreadable, unusable, or indecipherable to unauthorized individuals and allows the organization to take advantage of the Breach Notification Safe Harbor, which means that a Breach of this data is not possible if the recommended NIST protocols are used (i.e., according to law). This does not mean that, for example, you could not have a ransomware attack; but such attack would be encrypting already encrypted data. The “bad guys” may still be able to extract a ransom so that you get your data back, but they can’t view/sell your data due to the encryption. A ransomware attack still qualifies as a Security Incident but does NOT qualify as a Breach if your data as been encrypted and/or disposed according to the NIST protocols.

References §: §164.312(b) Audit controls.

Process: Each Risk Assessment should review your Information System Audit Logs to ensure that they continue to meet your Security Rule objectives. Any anomalous behavior found in an Audit Log should be reported as a Security Incident and investigated by your CO. Individual Workforce members whose behavior, after investigation, is determined to have violated the Privacy Rule should be sanctioned and/or terminated according to your Sanction Policy. Business Associates whose behavior, after investigation, is determined to have violated the Privacy Rule should be given a warning by your General Counsel and/or terminated depending on the egregiousness of the violation.

Tracking: Security Incidents should be tracked in your Security Incident Log and stored in your Compliance Repository. Workforce and Business Associate sanctions should be stored in their respective folders in your Compliance Repository. Audit Logs should be stored with their respective Information Systems and kept for a period of time consistent with your Documentation Policy.

Audit controls: What is this? This means that your organization needs the ability to log the activity of Workforce members when they interact with applications and devices that contain PHI. Generally, vendors provide this type of capability but not always. Further, it does little good to collect logs if no Workforce member is reviewing them. Of course, it is virtually impossible to review all logs all the time. Your applications need to be selective in sending the alerts that these logs generate otherwise nothing will be achieved because IT will simply ignore the mountain of information produced daily. Often these logs are most useful during a forensic review after a Breach or other serious PHI incident has occurred.

References: §164.312(b) Mechanism to authenticate ePHI.

Process: Your CO and CIO should review your Information Systems and other computing infrastructure to look for opportunities to enable ePHI authentication in your most mission critical computing assets. Any custom-built Information Systems, either developed by your Organization or built on behalf of the Organization, should include implementing ePHI data authentication mechanisms wherever practical. Each time you conduct a Risk Assessment your CO and CIO should review your Information Systems for an opportunity to implement ePHI data authentication mechanisms.

Tracking: Your CO and CIO are responsible for staying abreast of best practices for ePHI data authentication either as provided by your COTS vendors or via a third-party solution. Data authentication opportunities should be incorporated as part of your CO’s “State of Organizational Security” report provided to the executive team at least once a year. Collateral for ePHI data authentication best practices should be stored in your Compliance Repository.

Mechanism to authenticate ePHI: What is this? This requirement mandates that organization determine that PHI has been altered in a nefarious manner. In practice, very little progress has been made on this front because applications generally cannot perform real-time checks to see if some process has changed the data unbeknownst to the application. Although some progress is being made on this front by cloud vendors (e.g., detecting changes from unauthorized IP addresses) it remains an intractable problem to guarantee the integrity of the PHI being used by your organization.

References: §164.312(d) Person or entity authentication.

Process: During a Risk Assessment, and as warranted by events, your CO and CIO should ensure that all your Information Systems and computing infrastructure require, at a minimum, single factor authentication. Your CO and CIO are tasked with reviewing the feasibility of two-factor authentication mechanisms for your most mission critical Information Systems, especially with respect to Information Systems that contain ePHI. Information Systems that experience a breach must undergo a review to determine whether or not your existing authentication mechanism contributed directly or indirectly to ePHI being compromised.

Tracking: Information System authentication mechanisms should be tracked in your Compliance Repository as part of your ePHI asset inventory. Authentication best practices collateral should be tracked in your Compliance Repository after review by your CO and CIO. Authentication audit reports should be stored in your Compliance Repository after a breach post-mortem.

Person or entity authentication: What is this? This requirement mandates that your organization authenticate (i.e., verify that the person is who they say they are) before granting them access to PHI. Generally, this is done using login credentials (i.e., userid and password), but more and more organizations have migrated to two-factor (or multiple factor) authentication. This usually takes the form of possessing two things: (1) something you know (e.g., credentials); and (2) something you have (e.g., your mobile phone). Security message(s) are subsequently sent to your phone to ensure that you do indeed have it on your person. If the phone verification fails, the login attempt is not allowed to proceed.

References: §164.312(e)(2)(i) Integrity controls.

Process: Your CO and CIO should ensure that the appropriate transmission protocol is used when ePHI is sent both internally and externally. Whenever a Risk Assessment is conducted, or when needed as new Information Systems come online, your CO and CIO should review your communications protocols to ensure they remain consistent with best practices.

Tracking: Specified members of your Workforce should periodically review transmission logs to ensure that the protocols used are behaving consistent with the objectives of our Security Program. Best practices collateral regarding transmission protocols should be stored in your Compliance Repository after review by our CO and CIO.

Integrity controls: What is this? This requirement mandates that the protocols that are used to send electronic communications ensure that what was sent is the same as what was received. This is not the same thing as encryption. Encryption prevents the electronic message sent from being viewed by unauthorized individuals. This requirement wants to ensure that nothing was lost in transmission. That is what is meant by ensuring the integrity of the data.

References: §164.312(e)(2)(ii) Encryption.

Process: Your CO and CIO are responsible for identifying ePHI transmission points during Risk Assessments, or as events warrant, and ensuring that ePHI transmissions are protected using Transport Layer Security and/or whatever other enhanced protocol the Secretary may recommend in the future. Your CO is responsible for reviewing the protocol(s) that business associates use when transmitting ePHI across open networks to third parties.

Tracking: Specified members of your Workforce should periodically review transmission logs to ensure that the encryption protocols used are behaving consistent with the objectives of our Security Program. Best practices collateral regarding encryption transmission protocols should be stored in your Compliance Repository after review by your CO and CIO.

Encryption: What is this? Encryption is not a mandated requirement under the Security Rule. It is labeled as “Addressable” instead of “Required.” You can be in compliance with the Security Rule even if your organization does not encrypt PHI whatsoever. However, as discussed above, unless you encrypt according to the NIST protocols you cannot take advantage of the Breach Notification Safe Harbor, including the Safe Harbor expanded under the Cares Act in 2021. Further, you may find that a judge, auditor, or opposing counsel argues and/or rules that you did not do what was “reasonable and appropriate” under the Security Rule. The bottom line is that your organization should encrypt ALL PHI that is practical to encrypt. Cloud vendors will now do this for your (e.g.,for data at rest) by merely selecting the option.