Controls-based “checklists” and dubious certifications will not adequately protect a healthcare organization’s sensitive digital assets. What will work is a formal Information Risk Management (IRM) program designed to grow more effective and mature over time.
Two documents from the Office for Civil Rights (OCR) reveal what the HIPAA regulatory arm of the federal government believes are appropriate for determining an organization’s level of compliance and information security as required by HIPAA: the Phase 2 Audit Protocol that covers all three HIPAA regulations and OCR’s Final Guidance on Risk Analysis, which is specific to the HIPAA Security Rule and information risk management.
You should consider this OCR guidance when looking for tools to determine your current level of compliance and information security. These directives can also serve as a prioritization plan for remediating weaknesses and a project management tool for tracking remediation progress. The ability to document improvement in IRM compliance over time provides the evidence regularly requested by OCR – and the lack thereof can result in increased fines and penalties.
Here’s what the two OCR documents require:
Compliance assessments
Specifically required by the Security Rule (and a best business practice for the Privacy and Breach Notification Rule), non-technical evaluations must be performed periodically by qualified individuals (internal or external) who walk through every applicable regulation in the Privacy, Security and Breach Notification Rules to include review of documented policies, procedures and other evidence of compliance – plus an assessment of the “reasonability and appropriateness” of each.
The test of “reasonable and appropriate” requires taking into account the following factors:
- The size, complexity, and capabilities of the covered entity or business associate;
- The covered entity’s or business associate’s technical infrastructure, hardware, and software security capabilities;
- The costs of security measures; and
- The probability and criticality of potential risks to electronic Protected Health Information (ePHI).
Risk analyses performed periodically by qualified individuals
The scope of risk analysis that the HIPAA Security Rule encompasses includes the consideration of potential threats and vulnerabilities to the confidentiality, availability and integrity of all ePHI that an organization creates, receives, maintains, or transmits. A risk analysis process includes, but is not limited to, the following activities:
- Evaluating the likelihood and impact of potential risks to ePHI;
- Determining appropriate risk treatment to address the risks identified in the risk analysis;
- Implementing and documenting chosen security measures and, where required, the rationale for adopting those measures; and
- Maintaining continuous, reasonable, and appropriate security protections.
The conduct of risk analyses should be an ongoing process, in which a covered entity regularly reviews its records to track access to ePHI and detect security incidents, periodically evaluates the effectiveness of security measures put in place, and regularly reevaluates potential risks from evolving threats to ePHI and the vulnerabilities that may be exploited.
Technical testing
Specifically addressed in the Security Rule, covered entities are required to perform technical testing both initially and in response to environmental or operational changes affecting the security of ePHI. Technical testing evaluates the effectiveness of your security controls against specific threat agents and can include vulnerability assessments, penetration testing, web application assessment, sensitive data discovery scans, firewall and router confirmation reviews and (of ever-increasing importance) social engineering. While technical testing has not shown up (yet) in corrective action plans, the recent increase in more sophisticated hacking techniques including ransomware would certainly qualify as an environmental change.
Implementation of a risk management program
About 60 percent of the organizations that have entered into settlement agreements with OCR following a breach had failed to establish a risk management plan and process beforehand. (Implementing such a plan is Priority #1 in each settlement agreement.)
On its website, OCR has published the National Institute of Standards and Technology (NIST) Risk Management Guide for Information Technology Systems (Special Publication 800-30) that outlines what a successful IRM program should look like.
Keys to success include:
- Senior management’s commitment;
- Full support and participation of the IT team;
- Competence of the risk assessment team in applying the risk assessment methodology;
- Awareness and adherence of the user community to compliance, policies and procedures; and
- Ongoing evaluation and assessment of risks to information security.
Then there’s the follow-up:
- Ongoing requirement to “evaluate and determine whether the implemented security measures appropriately respond to the threats and vulnerabilities identified in the risk analysis according to the risk rating – and that such security measures are sufficient to mitigate or remediate identified risks to an acceptable level” as specifically stated in the Phase 2 Audit protocol.
How do these OCR requirements translate into action? For best success, the adoption of a formal Information Risk Management (IRM) program designed to grow more effective and mature over time beats a “whack a mole” approach. It’s highly advisable to adopt the OCR-recommended NIST Cybersecurity Framework and the NIST IRM process, with a proven maturity model to help provide structure for improving decisions and monitoring progress in this critical initiative. A well-designed program like this can assist executive teams and boards in making wiser decisions about their investments in information security and compliance.