Everything You Need to Know About the HIPAA Security Rule

By: Julie Mungai and Zikiya Chabwera

The Health Insurance Portability and Accountability Act (HIPAA) was first signed into law in the U.S. in 1996 to establish policies and procedures for maintaining the security and privacy of individually identifiable health information, also known as Protected Health Information (PHI). The law not only defines standards, but also outlines offenses and creates civil and criminal penalties for violations.

HIPAA has gone through many iterations over the years. In 2005, with the digital era in full swing, the U.S. Department of Health and Human Services (HHS) created the HIPAA Security Rule to ensure the national standard included regulations for protecting patients’ electronic PHI (ePHI) and preventing it from being disclosed without the patient’s consent.

Another update was issued in 2009, when the HITECH Act introduced breach notification requirements and increased civil penalties for HIPAA violations based on the nature and extent of the breach as well as harm caused by the incident.

What is the HIPAA Security Rule?

According to HHS, the goal of the HIPAA Security Rule is to protect electronic protected health information (ePHI) through administrative, physical, and technical safeguards:

• Administrative: This includes controls related to risk analysis and risk management, termination procedures, access authorization, password management, data backup plans, and disaster recovery plans.
• Physical: This includes controls related to facility access, workstation use and security, and device and media controls such as data backup and storage.
• Technical: This includes controls related to unique user identification, emergency access procedures, encryption, and decryption.

While not all of these controls are required for every organization, they each are designed to ensure the confidentiality, integrity, and availability of all ePHI that an organization interacts with as well as protect against reasonably anticipated threats and unauthorized disclosures of ePHI.

In practice, PHI and ePHI include data sets that could be used to tie private healthcare information back to a specific individual. An individual’s name in itself is not PHI, but their name associated with their diagnosis does fall under that umbrella.

Who Must Comply with the HIPAA Security Rule?

Organizations that process, store, and interact with PHI and ePHI must comply with HIPAA. This includes “covered entities” such as:

• Healthcare providers and other health services organizations that transmit PHI to perform transactions like claims, determine benefit eligibility, and field referral authorization requests.
• Health plans, such as insurance providers and other organizations that help individuals and groups pay for healthcare services.
• Healthcare clearinghouses, or organizations that process other entities’ healthcare transactions for tasks like claims processing, billings, and data management.

HIPAA also applies to individuals and organizations outside of these covered entities (“business associates”) who use or disclose individually identifiable health data to perform or provide services.

Some organizations may also choose to maintain compliance with HIPAA even if not required by law in order to align with best practices and build trust with customers and stakeholders. 

How Can Organizations Validate Compliance?

Unlike compliance frameworks such as HITRUST CSF and ISO/IEC 27001, there is no formal certification available or required to prove HIPAA compliance. However, there are other options for organizations that want to provide assurance to customers that they adhere to the strict security standards outlined by HIPAA. This includes:

• Report on HIPAA Compliance: BARR’s attest services team can assess your cybersecurity program against HIPAA requirements and provide a formal report on their conclusions. 
• SOC 2 + HIPAA Security Rule: Many common trust services criteria (TSC) used in SOC 2 reporting align with HIPAA Security Rule requirements. For organizations also interested in pursuing a SOC 2 report, BARR’s attest services team can assess whether controls related to access management, risk management, and asset management are designed to meet HIPAA regulations. 

Before you embark on a journey to assess your organization’s HIPAA compliance, BARR’s consulting team can also perform a readiness assessment to help identify existing gaps in your security program and provide recommendations for remediation.

Ready to get started? Speak with our expert team to determine which option is the best next step for your organization.

About the Authors

Julie Mungai
Senior Manager, Attest Services

As a senior manager in BARR’s attest services practice, Julie brings extensive experience supporting internal audits, SOX audits, various cybersecurity compliance framework audits, and technology risk management in support of organizational programs and initiatives. Outside of work, she volunteers with the ISACA SheLeads Tech and IAPP on task forces to help shape the future of information security and privacy. Julie is a CISA, ISO 27001 Lead Auditor, CCSK, and CIPT.

Zikiya Chabwera
Associate Consultant, Attest Services

Zikiya has more than five years of experience in technical support, audit and risk management, and compliance. As an associate consultant for BARR’s attest services practice, Zikiya supports the planning and execution of cyber risk engagements, including information technology audits and risk assessments for clients in various highly regulated industries.