HIPAA is not an IT standard. It is a federal law — the Health Insurance Portability and Accountability Act — with criminal penalties for willful neglect and civil penalties that scale with the severity of the violation and the organization's culpability. The Office for Civil Rights at the Department of Health and Human Services enforces it, conducts audits, and investigates breach reports. OCR settled over $135 million in HIPAA cases in a single recent year. The penalties are real, the investigations are invasive, and the reputational damage from a public breach notification is lasting.
Any organization that creates, receives, maintains, or transmits Protected Health Information (PHI) is a Covered Entity or Business Associate subject to HIPAA. That includes hospitals and health systems, physician practices and clinics, health insurers and managed care organizations, pharmacy benefit managers, healthcare clearinghouses, and any vendor or contractor who handles PHI on their behalf — including IT service providers, cloud vendors, EHR hosting companies, and managed security service providers.
If you are the IT provider for a healthcare organization, or if your platform touches patient data in any form, HIPAA applies to you.
The Security Rule — What It Actually Requires
The HIPAA Security Rule governs electronic Protected Health Information (ePHI). It is organized around three categories of safeguards: administrative, physical, and technical. The rule is deliberately technology-neutral — it defines what must be protected and what outcomes must be achieved without mandating specific technical implementations. That flexibility is intentional. It is also what makes HIPAA harder to implement correctly than standards that prescribe specific controls.
Administrative safeguards are the foundation. They require a formal security management process including a documented risk analysis, a risk management plan, workforce training, access management procedures, a contingency plan for system failures, and periodic evaluation of the security program. Most organizations that fail OCR audits fail here first — not because they lack technical controls but because they lack the documentation that proves the controls are managed and reviewed.
Physical safeguards govern facility access and workstation controls. Servers and systems housing ePHI must have controlled physical access. Workstations that access ePHI must have policies governing their use and physical placement. Media containing ePHI must be tracked, and disposal must follow documented procedures.
Technical safeguards are the implementation layer. Access controls must ensure only authorized users can access ePHI, with unique user identification, automatic logoff, and encryption or equivalent measures for data at rest and in transit. Audit controls must log and examine activity on systems containing ePHI. Integrity controls must ensure ePHI is not improperly altered or destroyed. Transmission security must protect ePHI moving across networks.
The Privacy Rule and Breach Notification Rule
The Privacy Rule governs how PHI can be used and disclosed — not just the technical systems that hold it. It defines what counts as PHI (18 categories of identifiers that, combined with health information, create individually identifiable health data), what uses are permitted without patient authorization, what disclosures require authorization, and what patients have the right to access and correct in their own records.
The Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in some cases the media when unsecured PHI is breached. The clock starts at discovery, not at the point the breach occurred. Individual notifications are required within 60 days of discovery. Breaches affecting 500 or more individuals in a single state require media notification. All breaches affecting 500 or more individuals must be reported to HHS immediately and appear on what the industry calls the 'Wall of Shame' — a public HHS database of major breaches.
The breach notification requirements have teeth specifically because unsecured PHI is the trigger. PHI that is encrypted according to NIST standards is not considered 'unsecured' — which means a breach of properly encrypted data does not trigger the notification requirement. Encryption is not just a best practice under HIPAA. It is the difference between a reportable breach and a non-event.
HIPAA and NIST SP 800-171 — The Control Overlap
NIST SP 800-171 was written for Controlled Unclassified Information in non-federal systems — primarily defense contractors. HIPAA was written for healthcare. They are different frameworks with different regulatory bases. But they share a common ancestor: NIST SP 800-53, the comprehensive catalog of security controls for federal information systems that both frameworks drew from.
The overlap is substantial and practically useful. Organizations that have implemented NIST 800-171 controls for CUI compliance have already addressed a significant portion of the HIPAA Security Rule technical requirements. The mapping is not one-to-one, but it is close enough that a 800-171-compliant environment provides a strong foundation for HIPAA compliance — and a HIPAA-compliant environment is well-positioned for 800-171 assessment.
Specific control families where the overlap is direct: Access Control (800-171 family 3.1 maps directly to HIPAA technical safeguard access controls), Audit and Accountability (800-171 family 3.3 covers the same ground as HIPAA audit controls), Configuration Management (800-171 family 3.4 addresses system hardening that HIPAA requires but does not prescribe), Identification and Authentication (800-171 family 3.5 aligns with HIPAA unique user identification and authentication requirements), System and Communications Protection (800-171 family 3.13 covers encryption in transit, which HIPAA requires for transmission security), and Media Protection (800-171 family 3.8 maps to HIPAA physical safeguard media controls).
NIST SP 800-171 Revision 3, finalized in 2024, added requirements around supply chain risk management, software and firmware integrity verification, and more granular controls around privileged access. These additions are relevant to healthcare IT environments because healthcare organizations are increasingly targeted through supply chain attacks — compromised EHR vendors, medical device firmware, and third-party integrations. The 800-171r3 supply chain controls address the same threat vectors that have driven some of the largest healthcare breaches in recent years.
Where HIPAA goes further than 800-171: the Privacy Rule has no analog in 800-171. Patient rights, minimum necessary use, Business Associate Agreement requirements, and breach notification obligations are HIPAA-specific and require policies and procedures that 800-171 compliance does not address.
Where 800-171r3 goes further than HIPAA: the enhanced controls around supply chain risk, software integrity, and the more prescriptive configuration and vulnerability management requirements exceed what the HIPAA Security Rule specifies. Healthcare organizations pursuing 800-171 compliance as part of a defense health contract will need to implement controls that go beyond their HIPAA baseline.
Business Associate Agreements and Why They Matter
A Business Associate Agreement (BAA) is a contract required by HIPAA between a covered entity and any vendor who creates, receives, maintains, or transmits PHI on its behalf. The BAA defines what the business associate is permitted to do with PHI, requires them to implement appropriate safeguards, obligates them to report breaches, and requires them to ensure their own subcontractors are bound by the same obligations.
BAAs matter operationally because they define the boundary of your compliance program. A covered entity that relies on a vendor without a BAA has an uncontrolled PHI exposure — and OCR holds covered entities responsible for their business associates. Choosing a cloud provider, EHR system, messaging platform, or IT managed services provider that refuses to sign a BAA is not a vendor relationship you can have if PHI flows through that system.
Common BAA failures: vendors who sign BAAs without actually implementing the required safeguards, BAAs that do not accurately describe what PHI is being shared or how, subcontractor chains where the BAA obligation was not passed down, and BAAs that were signed years ago and never updated when the scope of the relationship changed.
We review and advise on BAA structures, identify gaps in vendor BAA coverage, and ensure that IT service relationships are structured so that PHI handling is appropriately contracted and controlled at every layer of the stack.
What We Build and What We Document
Implementing HIPAA compliance is a combination of technical implementation and policy documentation. The technical work without the documentation fails an audit. The documentation without the technical implementation fails a breach investigation. Both have to be present and aligned.
On the technical side: encryption of ePHI at rest using AES-256 or equivalent, TLS 1.2 or higher for all ePHI in transit, role-based access controls with documented provisioning and deprovisioning, MFA on all systems with ePHI access, automatic session timeouts on workstations and applications, comprehensive audit logging with retention sufficient for breach investigation, secure backup with tested recovery procedures, network segmentation isolating systems containing ePHI, endpoint protection and patch management, and medical device network security where clinical environments are in scope.
On the documentation side: a formal risk analysis documenting identified threats, vulnerabilities, likelihood, and impact, a risk management plan with documented remediation actions and timelines, information security policies covering each administrative safeguard requirement, workforce training records, an incident response plan with defined roles and tested procedures, a contingency and disaster recovery plan with tested RTOs, media disposal and reuse procedures, and BAA inventory with copies of executed agreements.
We produce documentation that survives OCR scrutiny — not because it is polished, but because it reflects what the environment actually does. An OCR auditor who asks for your risk analysis and receives a document that does not match your actual IT environment is a worse outcome than having gaps. We close the gaps and document what is real.