Printer Friendly, PDF & Email

OCR's Cyber Security Newsletters: "Cheat sheets" for good security compliance in our cyber age

Iliana L. Peters ( is a Shareholder in the Washington, DC offices of Polsinelli, PC.

Most businesses, whatever the economic sector, acknowledge that they must devote resources to understanding and implementing data security, particularly given that security incidents and their fallout make the news on a daily, if not hourly, basis. Conversations about risks for data security breaches happen at breakfast tables and boardroom tables around the country, and topics range from social media to national elections to international espionage. For compliance personnel, these conversations boil down to concrete reasons for investing the resources in implementing data security practices and the best ways to do so. Importantly, good data security in our current cyber age is essential for entities of all sizes, types, and focus areas, for a few very persuasive reasons, including:

  • An entity’s data is its most valuable asset, replacing assets that used to be considered more high-value, from physical assets to copyrighted material to well-trained employees, in a corporate valuation analysis.[1]

  • An entity’s reputation is on the line anytime its data is compromised in a data breach or cyberattack; recent examples of high-profile data breaches have angered both consumers and state, federal, and international legislators and regulators.

  • Good data security is required under state, federal, and international law, and violations of these laws can have serious penalties.

  • With respect to certain critical economic sectors, such as the healthcare sector, the lack of good data security is a safety issue for individuals. For example, if a healthcare entity does not implement good data security and falls victim to a security incident or attack that results in either data accessibility or data integrity compromises (i.e., patient data is made either inaccessible or incorrect), the healthcare entity cannot treat patients, or may treat patients incorrectly, which could seriously affect the health or lives of the patients.

So, what does good data security hygiene look like from a cybersecurity perspective, particularly in the healthcare sector? How are healthcare entities supposed to keep up with a constantly changing risk landscape? What are the risks that the regulators are most concerned with and that healthcare entities should prioritize? These are all good questions; the answers are regularly discussed in Cyber Security Newsletters, a monthly publication by the Department of Health and Human Services (HHS), Office for Civil Rights (OCR), which is the primary regulator responsible for implementation and enforcement of the Health Insurance Portability and Accountability Act Privacy, Security, and Breach Notification Rules (HIPAA Rules).[2]

Although regulated entities are generally familiar with settlement agreements and civil money penalties (CMP) published by OCR,[3] and the insight they provide into the data security issues on which OCR is focusing its enforcement efforts, many regulated entities are not leveraging the information contained in the Cybersecurity Newsletters[4] to augment their HIPAA Security Rule compliance efforts, particularly with regard to high-risk issues. Reviewing some of the most recent Cyber Security Newsletters is particularly instructive to understand recurring HIPAA Security Rule compliance issues that create cybersecurity risks for HIPAA covered entities and business associates.

HIPAA Risk Analysis: Identify ePHI and risks to it

The HIPAA Security Rule requires, as a foundational administrative safeguard for electronic protected health information (ePHI), that HIPAA covered entities and their business associates (as defined by the HIPAA Rules) undertake a comprehensive and enterprise-wide analysis (or assessment, as it is referred to in other economic sectors) of the risks, including threats and vulnerabilities to all of the ePHI they hold.[5] The requirement is essential for purposes of identifying all of an entity’s data and the risks to it, including those associated with any cybersecurity threats or vulnerabilities that could be exploited by cybersecurity threat vectors or attackers.

This requirement is fairly straightforward; that is, HIPAA covered entities and their business associates must identify:

  • the ePHI they hold, including through data inventories, mappings, and flows;

  • the threats to and vulnerabilities of the ePHI, given the people, entities, and assets that create, access, maintain, and transmit such ePHI, including systems, applications, devices, workforce members, and partners; and

  • the likelihood that these threats or vulnerabilities could be exploited, which is the risk to ePHI.

Essentially, this means that HIPAA covered entities and their business associates should understand where their ePHI is throughout its lifecycle (from creation to maintenance to destruction), and what the risks (including cybersecurity threats or vulnerabilities that could be exploited by cyberthreat vectors or attackers) to it are, given where it is created, accessed, maintained, and transmitted until it is destroyed.

The point is—if a HIPAA covered entity or business associate does not identify all the places where ePHI “lives,” and the risks to ePHI in those places, then it cannot sufficiently protect the ePHI against threats or exploitation of vulnerabilities, which will very likely result in a breach.

However, HIPAA covered entities and their business associates often have misunderstood this requirement to be an audit or gap analysis, and instead of analyzing the risk to the ePHI, they assess the gaps in their enterprise practices against the requirements of the HIPAA Security Rule or another cybersecurity framework, such as the NIST Cyber Security Framework.[6] A gap analysis or audit is also a helpful exercise, and is required by the evaluation requirement of the HIPAA Security Rule at 45 CFR § 164.308(a)(8), but it is not a risk analysis.

HIPAA risk analysis vs. gap analysis

OCR’s April 2018 Cyber Security Newsletter[7] focused specifically on this issue, and highlighted the differences between what OCR considers a comprehensive, enterprise-wide risk analysis, versus a gap analysis for purposes of compliance with the HIPAA Security Rule. OCR notes that a “risk analysis is a comprehensive evaluation of a covered entity or business associate’s enterprise to identify the ePHI and the risks and vulnerabilities to the ePHI.” Alternatively, a “gap analysis is typically a narrowed examination…to assess whether certain controls or safeguards required by the Security Rule are implemented.”

The April 2018 Cybersecurity Newsletter then goes on to outline the elements of a risk analysis, particularly as explained further in NIST Special Publication 800-30:

  • A comprehensive scope

  • Identification of all locations and systems where ePHI is “created, received, maintained, or transmitted”

  • Identification of threats and vulnerabilities (both technical and nontechnical)

  • Assessment of current security measures

  • Determination of likelihood and impact

  • Determination of the resulting level of risk

  • Documentation of all elements

  • Revisions and updates

The April 2018 Cyber Security Newsletter also provides an example of a typical gap analysis, which would not comply with the requirements of the HIPAA Security Rule with regard to a risk analysis. The example table in the newsletter starts with a column on the left that includes specific requirements of and citations to the HIPAA Security Rule, then moves across the page to the right to include a description of specific requirement and assessments of whether a particular entity has fully implemented the requirement cited. Again, although this type of exercise is helpful for an entity to determine whether it has, in fact, implemented the requirements of the HIPAA Security Rule or another law or framework, a similar audit or analysis does not accurately reflect the risks to the ePHI in the entity’s enterprise, particularly given that there is no assessment of these risks anywhere in the audit or analysis.

The bottom line is that if a HIPAA covered entity or business associate has undertaken a gap analysis, rather than a HIPAA-compliant risk analysis, it may have correctly implemented some of the requirements of the HIPAA Security Rule or correctly addressed the recommendations of another tool or framework, but it still may have missed some of the ePHI in its enterprise and, correspondingly, the risks to that ePHI, which is left unprotected and exploitable by cyberthreats and attackers.

Prioritize patching

Probably the scariest cyberthreat to HIPAA covered entities and business associates is one that may be the easiest for cyberattackers to exploit—unpatched applications, software, or systems. Entities in all sectors frequently underestimate the ease of finding “a recipe” on the internet to exploit a known vulnerability in a particular type of application. However, well-resourced nation-state attackers can exploit these unpatched systems or applications, and extremely unsophisticated attackers can also take advantage of “holes” in systems or applications that result from a lack in updated coding or patching, or they may direct others to do so.

OCR’s June 2018 Cybersecurity Newsletter[8] is particularly helpful in walking HIPAA covered entities and business associates through the logic behind, and the process for, patching on an enterprise level. OCR notes that, “vulnerabilities may be present in many types of software including databases, electronic health records (EHRs), operating systems, email, applets such as Java and Adobe Flash, and device firmware.” Further, OCR explains that, as provided for by NIST, patch management is the process of “identifying, acquiring, installing and verifying patches for products and systems,”[9] and OCR suggests some specific steps for patch management, including:

  • Evaluation: Evaluate patches to determine if they apply to your software/systems.

  • Patch testing: When possible, test patches on an isolated system to determine if there are any unforeseen or unwanted side effects, such as applications not functioning properly or system instability.

  • Approval: Once patches have been evaluated and tested, approve them for deployment.

  • Deployment: Following approval, patches can be scheduled to be installed on live or production systems.

  • Verification and testing: After deploying the patches, continue to test and audit systems to ensure that the patches were applied correctly and that there are no unforeseen side effects.

As part of any patch management program, and as OCR discusses briefly in the June 2018 Cybersecurity Newsletter, the process for implementing patches should be closely monitored. Although most patches are routine and do not result in significant changes to applications or systems, some patches update systems or applications in unexpected ways, such as by setting all security features back to default settings or inadvertently misconfiguring a setting that results in leaking data to the internet, for example. As such, HIPAA covered entities and business associates should appropriately evaluate the changes to their applications or systems in association with any patches, as required by the HIPAA Security Rule at 45 CFR § 164.308(a)(8) and as discussed in the bullets above.

Mobile devices—A vector for attack

Mobile devices create particular challenges for entities of all types and in all sectors, including HIPAA covered entities and business associates. Mobile devices are extremely vulnerable to theft or loss and, as such, if not properly protected, can not only provide a thief with access to all of the valuable information held on the device itself, but also create a vector or gateway into an entity’s enterprise for an attacker to exploit. OCR’s August 2018 Cyber Security Newsletter[10] describes techniques, tools, and HIPAA Security Rule requirements that can be used to protect the ePHI on mobile devices and to protect HIPAA covered entities and business associates more generally from attacks that exploit the vulnerabilities of mobile devices.

The August 2018 Cyber Security Newsletter describes mobile electronic devices as including “a broad range of hardware such as laptops, smartphones, servers, desktops, and tablets. Electronic media includes electronic storage devices, such as hard drives, USB drives, CDs/DVDs, tapes and memory cards.” Mobile devices of all types are essential to the business of healthcare today, but they are particularly vulnerable to all types of threats—just by the nature of their being “mobile.” These include risks such as theft, loss, and other types of cyber-threat exploitation.

For example, many people do not realize that a large majority of mobile devices are networked (i.e., they have the capability to connect to the internet, as part of the “Internet of Things”), and may do so without the user’s knowledge on a regular basis. As such, they can be used by cyber-attackers as a jumping-off point into a HIPAA covered entity’s or business associate’s enterprise,[11] or as part of a “botnet” or other large-scale computing attack.[12] Finally, to the extent that transmissions of ePHI to and from mobile devices (e.g., pagers or smartphones) are not protected, the ePHI can be intercepted in transit by cyber-attackers seeking to exploit the information collected from those devices during transit.

The first, and perhaps the most important, effort to protect mobile devices is (similar to the HIPAA risk analysis effort) the identification and tracking of all of the entity’s mobile devices during their useful life and as they move in and out of any particular HIPAA covered entity or business associate. As with ePHI and a risk analysis, if you don’t know where all of your mobile devices are at any particular moment, you cannot appropriately protect them.

So, as OCR asks in the August 2018 Cyber Security Newsletter:

  • Is there a record that tracks the location, movement, modifications or repairs, and disposition of devices and media throughout their lifecycles?

  • Does the organization’s record of device and media movement include the person(s) responsible for such devices and media?

  • Are workforce members (including management) trained on the proper use and handling of devices and media to safeguard ePHI?[13]

Any corresponding efforts to protect mobile devices should answer the additional question that OCR asks in the August 2018 Cybersecurity Newsletter regarding mobile device security: “Are appropriate technical controls, for example, access controls, audit controls, and encryption, in use?”[14]

Let’s take a moment to walk through these specific tools and requirements with regard to how they can be used to protect mobile devices from cybersecurity threats.

Access controls include all of the policies and techniques that HIPAA covered entities and business associates use to allow access to their ePHI to only those persons and entities that should be able to access that data.[15] This includes not only determining who or what should have access, but also what type of access and how it should be provided. In other words, not every person or entity needs access to all of the data in an enterprise through a particular mobile device, for example; and all people or entities accessing these mobile devices must do so in a secure way, using techniques that should include multifactor authentication or strong usernames and passwords or passphrases. For example, can workforce members access an entity’s enterprise systems using any device, or only particular devices, such as those owned and/or controlled by the entity (as is generally recommended)? Are all default usernames and passwords on devices of all types (including copiers, printers, medical devices, etc.) changed regularly, as is generally required? Have vulnerability scans been run on mobile devices and any critical or important issues identified remediated, as is generally required?

Audit controls include all of the policies and tools that HIPAA covered entities and business associates use to track who and what are accessing their ePHI, and how.[16] In other words, entities should have logs and reports that identify:

  • Which persons or entities are accessing, creating, modifying, or transmitting their ePHI?

  • What specific ePHI was accessed and how?

  • What specifically is being done with the ePHI and how. Was it changed?

  • How was it accessed or transmitted and by whom and where?

Audit controls also include ensuring that all of the important information in these logs and reports is reviewed regularly and that any irregularities are addressed. So, the questions with regard to mobile devices become: Are audit capabilities enabled on all mobile devices throughout a HIPAA covered entity’s or business associate’s enterprise? Are the audit logs and access reports from the entity’s mobile devices reviewed regularly, and is suspicious activity investigated?

Encryption is generally required for HIPAA covered entities and business associates, unless the entity can specifically document the reason encryption in a particular circumstance and to particular ePHI is not reasonable and appropriate, as well as the compensating controls the entity put in place in lieu of encryption. Encryption is particularly important to address the risks to ePHI on or transmitted from mobile devices.[17] Theft and loss are still the major breach incidents that HIPAA covered entities and business associates experience and, as a result, it just makes good sense to encrypt the ePHI at rest on mobile devices. That said, ePHI being transmitted from mobile devices may also be vulnerable to attack and/or interception. As such, encryption is important to implement for ePHI in transit from mobile devices of all types, including smartphones, pagers, and medical devices as well.

Mobile devices, large and small, must be considered particularly vulnerable to threats of all kinds, including not only those that immediately come to mind, such as theft and loss, but also those that are more sophisticated and menacing, such as cyberattacks. Remember that almost every device in your enterprise (or your home, for that matter) can be a vector for an attack, and take steps to protect yourself and your enterprise.

Good data security just makes good sense

Ultimately, the Golden Rule applies to data, just as it does elsewhere in life, with a bit of finesse: “Do unto others’ data as you would have them do unto yours.” In other words, although there are several very persuasive business reasons to implement good data security, ultimately, we all have the responsibility to be good stewards of consumer data wherever we encounter it, because we expect the same of the businesses and their employees that hold our data. And, given the tools available to protect data from cybersecurity threats, good data security just makes good sense.


  • An entity’s data is its most valuable asset, and an entity’s reputation is on the line anytime its data is compromised.

  • Good data security is required under state, federal, and international law, and violations of these laws can have serious penalties.

  • Lack of good data security is a patient safety issue.

  • Cyber Security Newsletters from HHS OCR are a fantastic source of advice on important cybersecurity issues.

  • Given the tools available to protect data from cybersecurity threats, good data security just makes good sense.

1 Lisa Morgan, “How Valuable Is Your Company's Data?” InformationWeek; March 14, 2018.
2, Health Information Privacy.
3, HIPAA Enforcement.
4, Cyber Security Guidance Material.
5 45 C.F.R. § 164.308(a)(1)(ii)(A) Administrative safeguards.
6 National Institute of Standards and Technology (NIST), Cyber Security Framework.
7 HHS OCR,Risk Analysis vs. Gap Analyses – What is the difference?” Cyber Security Newsletter, April 2018.
8 HHS OCR, “Guidance on Software Vulnerabilities and Patching” Cybersecurity Newsletter, June 2018.
9 NIST Patch Management.
10 HHS OCR, “Considerations for Securing Electronic Media and Devices” Cyber Security Newsletter, August 2018.
11 Stephen Northcutt: “The Risk of Default Passwords” SANS Technology Institute, Security Laboratory: Methods of Attack Series; May 11, 2007.
12 Paul Sabanal, “Thingbots: The Future of Botnets in the Internet of Things” SecurityIntelligence; February 20, 2016.
13 Ibid, Ref #5 at (a)(5)
14 45 CFR § 164.312 Technical safeguards.
15 Idem at (a).
16 Idem at (b).
17 Idem at (a) and (d).