The HIPAA Security Rule is the primary federal standard governing electronic protected health information (ePHI) in the United States. But it doesn’t stand alone. Several other frameworks, international standards, and technical specifications work alongside it to define how organizations must protect health data stored or transmitted electronically. Here’s what each one covers and how they fit together.
The HIPAA Security Rule
The HIPAA Security Rule is the cornerstone. It applies to any ePHI that a covered entity or business associate creates, receives, maintains, or transmits. The rule requires protection against reasonably anticipated threats, hazards, and impermissible disclosures, and it organizes its requirements into three categories of safeguards: administrative, physical, and technical.
Administrative safeguards make up the largest portion. These are the policies and procedures an organization puts in place to manage ePHI security. They include conducting a formal risk analysis (required, not optional), developing a risk management plan, creating sanction policies for employees who violate rules, and reviewing information system activity logs. Organizations must also designate a specific person responsible for security, establish workforce clearance procedures, manage who gets access to what information, and maintain a contingency plan that covers data backup, disaster recovery, and emergency operations. Security awareness training for staff falls here too, along with procedures for responding to security incidents and written contracts with any business associates who handle ePHI.
Physical safeguards cover the tangible protections around systems and buildings. Facility access controls, workstation use policies, workstation security, and device and media controls all fall into this category. When a laptop is disposed of or a hard drive is reused, there are required procedures for wiping or destroying the data.
Technical safeguards address the technology itself. Every user must have a unique login identifier. There must be an emergency access procedure, audit controls to track who accessed what, and integrity controls to confirm ePHI hasn’t been altered. Encryption is classified as “addressable,” meaning organizations must implement it or document why an equivalent alternative is appropriate.
The Security Rule distinguishes between “required” and “addressable” specifications. Required means exactly what it sounds like. Addressable doesn’t mean optional. It means an organization must assess whether the specification is reasonable and appropriate, implement it if so, or document why not and adopt an equivalent measure.
The HITECH Act and Breach Notification
The HITECH Act strengthened HIPAA’s enforcement and added breach notification requirements specifically relevant to ePHI. When a breach of unsecured ePHI occurs, covered entities must promptly notify every affected individual. If the breach affects more than 500 people, the organization must also notify the HHS Secretary and the media. Breaches affecting fewer than 500 individuals are reported to HHS on an annual basis. HITECH also extended HIPAA’s security requirements directly to business associates, not just covered entities, closing a significant gap in the original law.
Business Associate Agreements
Any third party that handles ePHI on behalf of a covered entity, whether a cloud hosting provider, billing company, or IT contractor, must sign a business associate agreement. These contracts are required under HIPAA and must spell out exactly how the business associate is permitted to use the information, prohibit any use or disclosure beyond what the contract allows or the law requires, and obligate the business associate to use appropriate safeguards. This requirement effectively extends ePHI protection standards across the entire chain of organizations that touch the data.
NIST SP 800-66
The National Institute of Standards and Technology published SP 800-66 (now in its second revision) as a practical cybersecurity resource guide for implementing the HIPAA Security Rule. It walks organizations through each administrative, physical, and technical safeguard with key activities, descriptions, and sample questions to help assess compliance. NIST also maps the HIPAA Security Rule’s standards to its own Cybersecurity Framework and to the broader SP 800-53 security control catalog, giving organizations a structured way to align their HIPAA efforts with widely recognized cybersecurity practices. This guide is particularly useful for smaller healthcare organizations that need concrete steps rather than abstract regulatory language.
HHS Cybersecurity Performance Goals
In 2024, HHS released voluntary Cybersecurity Performance Goals specifically for the healthcare sector, divided into two tiers. The “Essential” goals set a baseline: patching known vulnerabilities, securing email, requiring multifactor authentication, providing basic cybersecurity training, using strong encryption, revoking credentials when workforce members leave, planning for incidents, enforcing unique credentials, and separating regular user accounts from privileged ones. Vendor and supplier cybersecurity requirements also fall into this essential tier.
The “Enhanced” goals push organizations further. These include maintaining a full asset inventory, establishing third-party vulnerability disclosure and incident reporting processes, conducting regular cybersecurity testing, implementing network segmentation, centralizing log collection, and building out configuration management. While voluntary, these goals signal the direction HHS expects the industry to move and may influence future rulemaking.
HITRUST CSF
The HITRUST Common Security Framework takes a different approach by consolidating over 60 frameworks and standards into a single, comprehensive control library. Rather than replacing HIPAA, it harmonizes HIPAA’s requirements with other frameworks like NIST, ISO, and PCI DSS into one unified set of controls. Many healthcare organizations pursue HITRUST certification as a way to demonstrate compliance across multiple standards simultaneously, which is especially valuable for business associates that serve clients with varying compliance requirements.
ISO 27799
Outside the U.S. regulatory landscape, ISO 27799 is the primary international standard for health information security. It builds on ISO/IEC 27002 (a general information security controls standard) and tailors it specifically for healthcare. The standard applies to health information in all forms, not just electronic, covering everything from printed records to video and medical images. It sets a minimum level of security appropriate to an organization’s circumstances, focused on maintaining the confidentiality, integrity, and availability of personal health information. ISO 27799 is intentionally technology-neutral, defining what security is required without dictating specific tools or systems. Healthcare organizations operating internationally or those seeking alignment with global best practices often use this alongside HIPAA compliance.
FHIR Security Standards for Data Exchange
When ePHI moves between systems, the HL7 FHIR (Fast Healthcare Interoperability Resources) standard includes its own security layer. All production data exchange should be secured using TLS, the same encryption protocol that protects banking websites. Users and client applications must be authenticated, with OAuth recommended as the authorization method. The HL7 SMART App Launch guide provides a specific framework for how third-party apps securely connect to health data systems.
FHIR also defines a security label infrastructure for access control and supports both role-based access control (where permissions are tied to a person’s job title or role) and attribute-based access control (where permissions depend on specific characteristics of the user, the data, or the context). Additional protections like DNS security extensions help verify that data is being sent to legitimate endpoints. These standards matter because interoperability, the ability to share health records between different providers and systems, is increasingly required by federal regulation.
SOC 2 Audits
SOC 2 isn’t a healthcare-specific standard, but it plays an important role in the ePHI ecosystem. Developed by the AICPA, SOC 2 audits evaluate an organization’s controls across five trust services criteria: security, availability, processing integrity, confidentiality, and privacy. The AICPA publishes formal mappings between these criteria and HIPAA requirements, allowing cloud providers and technology vendors to demonstrate that their security controls align with what HIPAA demands. For healthcare organizations evaluating vendors, a SOC 2 report provides independent verification that a company’s systems meet recognized security standards relevant to ePHI protection.
How These Standards Work Together
The HIPAA Security Rule sets the legal floor. NIST SP 800-66 tells you how to implement it. The HHS Cybersecurity Performance Goals point toward where the bar is moving. HITRUST rolls everything into one certifiable framework. ISO 27799 covers international operations. FHIR secures data in transit between systems. SOC 2 helps you vet your vendors. And the HITECH Act makes sure breaches have real consequences.
No single standard covers every aspect of ePHI protection on its own. Organizations that handle electronic health data typically layer several of these frameworks together, using HIPAA as the legal baseline and drawing on the others to fill in implementation details, address specific technologies, or satisfy the expectations of partners and clients who require demonstrated compliance beyond the regulatory minimum.