New OCR-ready risk analysis: Why the confusion?

Rich Curtiss, Director, Healthcare Cyber Risk Services, Coalfire

Are you ready for an Office for Civil Rights (OCR) investigation? Will your risk analysis and risk management methodologies and documents be sufficient to meet the HIPAA Security Rule?

The HIPAA Security Rule specifically requires that Covered Entities (CEs) and their Business Associates (BAs) conduct a risk analysis and risk management assessment. However, when shopping for vendors to conduct these assessments, many regulated entities simply look for the lowest bidder to check a HIPAA compliance “box” with little concern for whether the deliverables will stand up to an OCR audit or investigation. HIPAA is the responsibility of the CE or BA and shoddy work by a vendor will still fall on your shoulders.

Time after time, OCR has deemed risk analysis and risk management submittals to data requests as “insufficient.” This insufficiency comes from a number of factors. While not all inclusive, some of these factors are:

  • It appears as a compliance “gap assessment” presented as a risk analysis
    • This could take the form of a “checklist” against the HIPAA Security Rule or the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF)
  • It is not comprehensive enough, and doesn’t sufficiently scope the enterprise-wide electronic Protected Health Information (ePHI) environment
    • It is not “enterprise-wide”
  • The methodology is incorrect
    • Threats, vulnerabilities, security controls, likelihood, impact, and risk determination are not evident
  • OCR guidance and recommendations are ignored
  • Identified risks requiring some form of treatment or mitigation have been ignored and/or not documented sufficiently
  • Governance of information security risks are ineffective or not present
  • Willful neglect

The 2017 OCR Audits for Covered Entities and Business Associates indicated that, in many cases, risk analyses and risk management were not being done or were not being done correctly. It was evident in the analysis of the audit results that there were clear deficiencies across many of the audited entities in that they were not being done, or they were deemed insufficient in their approach. The situation hasn’t improved much since 2017, and risk analysis and risk management are top enforcement priorities for the OCR and continue to be problematic for organizations.

This leads to the question – “Am I receiving a risk analysis and conducting risk management that will be defensible with OCR?” This requires a basic understanding of OCR guidance that amplifies the HIPAA Security Rule implementation specifications, and ensures you are making equal comparisons and price- to-value is supported.

The OCR is explicit in its guidance on conducting what the HIPAA Security Rule calls “Risk Analysis” and “Risk Management.” These terms are synonymous with “Risk Assessment” and “Risk Response” as defined by NIST in their Special Publications 800-30 “Guide to Conducting Risk Assessments” and 800-39 “Managing Information Security Risk.” The OCR recommends in their “Guidance on Risk Analysis Requirements Under the HIPAA Security Rule” to use these NIST guidelines for conducting a conforming risk analysis.

According to the OCR guidance, an OCR-ready risk analysis must include nine elements:1

  1. Scope of the Analysis – Emphasis on the ePHI environment.
  2. Data Collection – Identification of where ePHI is being stored, received, maintained, or transmitted.
  3. Identify and Document Threats and Vulnerabilities – Identify reasonably anticipated threats to and vulnerabilities within a covered organization that could compromise the confidentiality, integrity, and/or availability of ePHI.
  4. Assess Current Security Measures – Evaluate and analyze security controls implemented to reduce risk exposure and safeguard ePHI.
  5. Determine the Likelihood of Threat Occurrence – Assess the likelihood of a threat exploiting a vulnerability given the implementation of existing security controls.
  6. Determine the Potential Impact of Threat Occurrence – Consider the “criticality” or impact of the system and/or data if it were to be exploited by a threat.
  7. Determine Level of Risk – A calculated value of the likelihood element multiplied by the impact element yields a risk level. NIST recommends using a 5 x 5 matrix of Very High, High, Moderate, Low and Very Low.2 If a vulnerability is determined to be exploitable by a threat due to ineffective security measures/controls, the likelihood could be assessed as “Very High,” or 5. If the information asset subject to exploitation has many thousands of ePHI records or is critical to operations, it could be assessed as a “Very High,” or 5. When multiplied, a risk level or risk rating of 25 is determined.
  8. Finalize Documentation – As the OCR often says, “show your work.” Document the risks and identify strengths, weaknesses, deficiencies, etc., in the security controls associated with the threats and vulnerabilities. This documentation is a direct input to the risk management process.
  9. Periodic Reviews and Updates to the Risk Assessment – The risk analysis should be an ongoing process. To quote: “A truly integrated risk analysis and management process is performed as new technologies and business operations are planned, thus reducing the effort required to address risks identified after implementation.”

Due diligence requires that an organization ensures their vendor or partner of choice is experienced with OCR and can provide evidence of their methodology and approach including sample deliverables which clearly “show your work.”

HIPAA is your responsibility, and shoddy work by a vendor will still fall on your shoulders. Make sure you get an OCR-ready, enterprise-wide, risk analysis and risk management plan.



Rich Curtiss


Rich Curtiss — Director, Healthcare Cyber Risk Services, Coalfire

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS