If you handle protected health information (PHI) in any form—as a hospital, insurer, clearinghouse, or one of their business associates—HIPAA compliance requirements aren't optional guidance, they're federal law enforced by the HHS Office for Civil Rights (OCR) under 45 CFR Parts 160 and 164. In 2023 alone, OCR received over 30,000 complaints and closed more than 20 resolution agreements totaling millions in settlements. Compliance automation vendors like Vanta have made it easier to track policies, collect employee attestations, and generate audit-ready evidence packages. But HIPAA's Security Rule also demands technical safeguards over the systems that store, process, and transmit ePHI—including the third-party software, open-source components, and CI/CD pipelines those systems depend on. That's a gap most GRC platforms don't close. This post breaks down what covered entities are actually required to do, where policy-tracking tools stop short, and how Safeguard fills the software supply chain security requirement HIPAA increasingly demands.
Who Counts as a Covered Entity Under HIPAA?
A covered entity is any health plan, health care clearinghouse, or health care provider that transmits health information electronically in connection with a standard transaction defined by HHS. That covers roughly 700,000 entities nationwide, from solo practitioners billing Medicare to national insurers like UnitedHealth Group. The definition extends indirectly to business associates—vendors, cloud hosts, billing companies, and software providers that create, receive, maintain, or transmit PHI on a covered entity's behalf. Since the 2013 Omnibus Rule, business associates are directly liable for HIPAA Security Rule compliance, not just contractually obligated through a Business Associate Agreement (BAA). If your SaaS product touches PHI for a hospital client, you're in scope even if you never see a patient. This distinction matters for software vendors selling into healthcare: a BAA on file doesn't substitute for actual technical safeguards, and OCR has pursued business associates directly, including a $2.3 million settlement against a billing vendor in 2023 for failing to conduct a risk analysis.
What Are the Core HIPAA Compliance Requirements?
The core requirements break into three rules: Privacy, Security, and Breach Notification. The Privacy Rule (45 CFR 164.500-534) governs how PHI can be used and disclosed, requiring minimum-necessary access and patient rights to access their own records within 30 days of request. The Security Rule (45 CFR 164.302-318) mandates administrative, physical, and technical safeguards specifically for electronic PHI (ePHI)—things like access controls, audit logs, encryption, and a documented risk analysis under 164.308(a)(1)(ii)(A). The Breach Notification Rule (45 CFR 164.400-414) requires notifying affected individuals within 60 days of discovering a breach affecting 500 or more people, and notifying HHS immediately for breaches of that scale, or annually for smaller ones. Unlike the Privacy Rule's addressable specifications, several Security Rule provisions—like encryption of data at rest and in transit—shifted toward being effectively mandatory following HHS's January 2025 proposed rule update, which would remove "addressable" status altogether and require encryption with limited exceptions.
How Does HIPAA Security Rule Compliance Differ from What Vanta Tracks?
Vanta and similar GRC platforms are built to automate evidence collection for control frameworks—confirming that a firewall policy exists, an employee completed security training, or an access review happened on schedule. That maps well to Security Rule administrative safeguards like workforce training (164.308(a)(5)) and sanction policies, but it does not extend into the technical composition of the software running your ePHI systems. HIPAA's technical safeguards under 164.312 require organizations to protect ePHI integrity and confidentiality, which in practice means knowing what's inside the applications processing patient data: which open-source libraries are embedded, whether they carry known CVEs, and whether build pipelines are tamper-resistant. A 2024 HHS breach report showed that hacking incidents, many originating from exploited software vulnerabilities in third-party applications, accounted for over 79% of the 167 million individuals affected by reported breaches that year. A GRC tool can confirm you have a vulnerability management policy on paper; it can't tell you that a vendor dependency in your patient portal has an unpatched critical CVE. That's a software supply chain problem, not a policy-tracking problem.
What Happens When a Covered Entity Fails to Comply?
Noncompliance triggers a tiered penalty structure under the HITECH Act, ranging from $137 to $2,067,813 per violation category per year as of the 2024 inflation adjustment, with the lowest tier reserved for violations the entity didn't know about and the highest for willful neglect that goes uncorrected. Real enforcement actions illustrate the range: Anthem paid $16 million in 2018—still the largest HIPAA settlement ever—after a breach exposed 79 million records tied to inadequate risk analysis and unpatched vulnerabilities in its network. In February 2024, OCR settled with a Massachusetts health system for $950,000 after ransomware exploited an unpatched vulnerability that had been publicly known for over a year. These aren't isolated incidents: OCR's 2023 enforcement summary noted that failure to conduct an accurate and thorough risk analysis remains the most commonly cited violation in resolution agreements, appearing in the majority of settled cases going back over a decade. The pattern is consistent—breaches trace back to software and infrastructure gaps that a documented policy alone never would have caught.
How Often Must Risk Assessments and Security Reviews Be Updated?
HHS does not specify a fixed interval in the regulatory text, but NIST SP 800-66 Rev. 2 (the HHS-endorsed implementation guide, published in February 2024) recommends conducting a risk analysis at least annually and whenever there's a material change to systems, applications, or infrastructure handling ePHI. In practice, OCR audits treat "set it and forget it" risk assessments as a violation in themselves—the 2016-2017 Phase 2 Audit Program found that 94% of audited entities had insufficient risk management processes, largely because assessments were stale or didn't cover newly deployed systems. For organizations shipping software continuously, an annual snapshot is already outdated by the time it's filed if new dependencies, containers, or third-party integrations are introduced weekly. HHS's proposed 2025 Security Rule update would formalize this by requiring a technology asset inventory and network map to be reviewed at least annually and updated whenever the environment changes, effectively codifying continuous visibility as a compliance requirement rather than an audit-season exercise.
How Safeguard Helps
Safeguard is built to cover the part of HIPAA compliance that policy-and-attestation platforms weren't designed for: the actual software supply chain producing and running the systems that touch ePHI. Where Vanta and comparable GRC tools confirm your policies and training records exist, Safeguard gives covered entities and their business associates continuous, evidence-backed visibility into the technical safeguards under 45 CFR 164.312—generating and maintaining SBOMs for applications handling PHI, continuously scanning dependencies for known CVEs, and verifying build pipeline integrity so a compromised upstream package doesn't become the next unpatched-vulnerability breach. That directly supports the risk analysis requirement under 164.308(a)(1)(ii)(A) with real-time data instead of a point-in-time questionnaire, and it produces the kind of technology asset inventory HHS's 2025 proposed rule is expected to require. For teams already running a GRC platform for administrative and physical safeguard evidence, Safeguard slots in alongside it to close the technical safeguard gap—so when OCR asks how you know your ePHI systems are free of known exploitable vulnerabilities, the answer is a continuously updated record, not a policy document promising it gets checked "regularly."