HIPAA compliance for medical practices.

What HIPAA actually requires

HIPAA is a family of federal regulations codified at 45 CFR Parts 160, 162, and 164. Four rules sit inside that family, and every one of them carries enforcement teeth:

• Privacy Rule - governs how Protected Health Information may be used and disclosed in any form, electronic, paper, or oral. Sets the minimum necessary standard at 164.502(b) and the patient access right at 164.524.
• Security Rule (45 CFR Part 164 Subpart C) - governs the confidentiality, integrity, and availability of electronic PHI through 22 standards and 42 implementation specifications (20 Required, 22 Addressable). Read our Security Rule compliance overview for the full structure.
• Breach Notification Rule - sets a 60-day notification clock once a breach is confirmed under the four-factor analysis at 164.402. No size threshold. No "we did not mean to" exemption.
• Enforcement Rule - defines the four-tier penalty structure, with willful-neglect violations capped at $2,067,813 per category per calendar year as adjusted for inflation. Tier 1 (unknown) starts at $137.

These rules apply to every covered entity (health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically) and every business associate (and subcontractor of a business associate) that creates, receives, maintains, or transmits PHI. The HITECH Act of 2009 made business associates directly liable under the Security Rule, which is why we sign a BAA on day one of every engagement.

A working HIPAA program rests on three legs. One: an inventory of where ePHI lives and moves. Two: administrative, physical, and technical safeguards proportionate to the risk profile of that inventory. Three: documentation that proves both items are happening on a continuous basis. The Office for Civil Rights resolution agreements published since 2013 read, almost without exception, like a documentation autopsy. The cited deficiencies are rarely "you got hacked" - they are "you cannot produce evidence of a current risk analysis."

Required vs Addressable - the spec that catches every practice

Required implementation specifications must be implemented exactly as the rule describes them. There is no flexibility. Addressable specifications must be evaluated, and if reasonable and appropriate, implemented as described. If they are not reasonable and appropriate for the regulated entity, the entity must document why, and implement an equivalent alternative measure that achieves the same objective. The trap at 164.306(d)(3)(ii)(B)(2) is that "Addressable" is widely misread as "optional." It is not. An undocumented Addressable specification is, in practice, a finding waiting to happen.

Where most practices have gaps

After two decades of healthcare engagements - dental, primary care, behavioral health, ambulatory surgery, and specialty practice - the patterns are predictable. We see the same handful of failures over and over:

• Default Microsoft 365 and Google Workspace tiers do not include a BAA out of the box. HIPAA-eligible variants do, but the addendum has to be executed and the tenant has to be hardened. Most practices do neither.
• Termination procedures forget to revoke access on the day someone leaves (covered in detail on our workforce security page). Former employees still receiving EHR notifications six months later is a finding we have personally surfaced inside engagements.
• Six-year documentation retention under 164.316(b)(2)(i) collides with default platform log retention of 30 to 365 days. Audit logs rotate out of existence before they would have been needed in a breach investigation. Our audit controls page covers the fix.
• Annual workforce training videos check the 164.308(a)(5) box but do not change behavior unless they are mapped to the practice's actual risks - our 2026 annual security awareness training course is built specifically to close that gap.
• Vendor BAA cascades go stale when sub-vendors get onboarded without anyone updating the inventory. The billing service signs a BAA. The billing service then signs a BAA with the clearinghouse. The clearinghouse signs a BAA with the cloud host. Three layers down, no one in the covered entity remembers that chain exists - and OCR will follow it on inquiry.
• Sanctions tracking - 164.308(a)(1)(ii)(C) - rarely exists outside HR. If a workforce member commits a Privacy Rule violation and there is no record of corrective action, the deficiency is documented in the breach investigation, not the personnel file.
• Patient access requests under 164.524 are routinely fumbled. The 30-day clock, the format-of-choice requirement, the cost-of-copies cap - all of these are repeated OCR enforcement themes, and all of them are documentation failures, not technology failures.

Our HIPAA security risk assessment exists specifically to surface those gaps before OCR does. Our HIPAA checklist walks the same ground at no cost so you can see where you stand before scoping work.

How a real Petronella engagement runs

Our team is CMMC-RP certified - the credential that overlaps significantly with HIPAA Security Rule discipline because both regimes derive from NIST SP 800-171 / 800-53 control families. The organization is CMMC-AB Registered Practitioner Organization #1449. We sign a BAA the same day we sign a Master Services Agreement. We are a business associate to every healthcare client, and we accept the direct HITECH liability that comes with it.

Phase 1 - Risk Analysis (weeks 1 to 3)

A typical HIPAA program engagement opens with a Risk Analysis under 164.308(a)(1)(ii)(A) using NIST SP 800-66 Revision 2 mapped to the four safeguard categories, with a quantified risk register that becomes the input to the Risk Management plan under 164.308(a)(1)(ii)(B). We catalog every system that touches ePHI - the EHR, the practice management software, the lab interface, the imaging server, the prescription gateway, the patient portal, every smartphone with the EHR app installed, every workstation with browser access, every backup target. Each asset gets a likelihood-and-impact score, and the resulting register orders the remediation roadmap.

Phase 2 - Policy and Workforce Layer (weeks 4 to 8)

From the risk analysis we author or refresh the policy and procedure set covering all 42 implementation specifications. The Privacy Rule body of policies - notice of privacy practices, minimum-necessary determinations, patient access, accounting of disclosures, amendments - is updated for current Omnibus Rule and 2024 reproductive-health rulemaking. The Security Rule policies are tied directly to the risk register: every Required spec gets a policy, every Addressable spec gets either a policy or a documented alternative. We design the workforce HIPAA training program, build the BAA inventory, and stand up incident response with documented annual tabletops.

Phase 3 - Technical Safeguards (weeks 6 to 12, overlapping)

For practices that want the technical layer handled too, we run HIPAA managed IT services covering tenant hardening, MFA enforcement on every account that touches ePHI under 164.312(d), FIPS-validated encryption at rest and in transit, audit logging that actually correlates and meets the six-year retention rule, automated patch and vulnerability cadence, endpoint detection and response on every clinical workstation, network segmentation between clinical and guest Wi-Fi, and quarterly internal vulnerability scans against the in-scope estate. The technical layer plugs into the same documentation engine as the policy layer.

Phase 4 - Continuous Evaluation (ongoing)

For organizations that need their hosting environment inside the BAA boundary, our HIPAA compliant hosting in Raleigh bundles managed infrastructure with the compliance program under one BAA. The documentation engine is delivered through our HIPAA compliance platform so policies, evidence, and training records live in one auditable place. Quarterly safeguard reviews, annual penetration testing (in-house team, no third-party markup), annual tabletop exercises, BAA re-attestation, and a continuously-current OCR evidence binder are the deliverables you can point a regulator or a contracted auditor at on any business day.

HIPAA, breach notification, and AI workloads

The Breach Notification Rule presumes a breach has occurred upon any acquisition, access, use, or disclosure of unsecured PHI in a manner not permitted under the Privacy Rule, unless a four-factor risk analysis at 45 CFR 164.402 demonstrates a low probability that the PHI was compromised. The four factors are: (1) the nature and extent of the PHI involved, including the types of identifiers and likelihood of re-identification; (2) the unauthorized person who used the PHI or to whom the disclosure was made; (3) whether the PHI was actually acquired or viewed; (4) the extent to which the risk to the PHI has been mitigated.

Affected individuals must be notified within 60 days of discovery. Breaches affecting 500 or more individuals must be reported to HHS and prominent media inside the same 60 days and posted to the public OCR breach portal. Late or incomplete reporting compounds into a separate violation. Breaches affecting fewer than 500 individuals are logged and reported to HHS annually within 60 days after calendar year-end.

Our breach response playbook is part of every HIPAA engagement, and our data breach forensics team handles confirmed incidents end to end - containment, evidence preservation, chain-of-custody documentation, root-cause analysis, and the Notification Rule clock. Craig holds DFE certification #604180 and CCNA, CWNE, and CMMC-RP credentials, which means the forensics work product can hold up to scrutiny in litigation and regulatory proceedings.

The AI inference problem - why your staff cannot paste PHI into ChatGPT

For clinical AI workloads, the same risk framework now extends to model inference pipelines. Any path where ePHI lands in a third-party LLM without an executed BAA is an impermissible disclosure under 164.502. Free-tier ChatGPT, free-tier Claude.ai, free-tier Gemini - none of these are HIPAA-eligible. The paid enterprise tiers from several major LLM vendors do offer BAAs, but the tenant has to be configured for it and the data-processing terms have to be reviewed. If your practice is evaluating ambient scribing, claims automation, prior authorization, or any AI workload that touches PHI, talk to us before deployment, not after.

For the deeper architecture analysis on what HIPAA-compliant LLM stacks actually look like, including private inference inside the BAA boundary, see our analysis of HIPAA-compliant private LLMs across five architecture patterns.

HIPAA program scope - what's in, what's not

The Privacy Rule scope is all PHI in any form. The Security Rule scope is electronic PHI only. A printed appointment list left on a counter is a Privacy Rule concern; a USB stick with an unencrypted patient export is both a Privacy Rule and a Security Rule concern. Both rules apply to the same covered entity simultaneously, so program design has to cover both. Our engagements always bracket both rules unless the client explicitly requests a Security-Rule-only assessment.

What is out of scope: research data that has been de-identified under the Safe Harbor method at 164.514(b)(2) or the Expert Determination method at 164.514(b)(1) is no longer PHI and is outside HIPAA. Education records covered by FERPA are excluded. Employment records held by a covered entity in its role as employer are excluded. Workers' compensation records have a narrow disclosure carve-out at 164.512(l). We help scope all of these on a per-engagement basis.

How Petronella connects HIPAA, CMMC, and broader cybersecurity

For healthcare contractors that also touch the Department of Defense supply chain - medical device manufacturers, federal medical research recipients, VA contractors - HIPAA sits alongside CMMC and NIST SP 800-171. We consult across all three CMMC levels: Level 1 (17 controls for Federal Contract Information), Level 2 (110 NIST SP 800-171 practices for Controlled Unclassified Information), and Level 3 (24 enhanced NIST SP 800-172 practices for the highest CUI sensitivity). The control overlap with HIPAA is significant: HIPAA's audit-controls standard at 164.312(b) maps to NIST AU controls; HIPAA access-control at 164.312(a) maps to NIST AC controls. Practices in this dual-regime situation should not run two independent programs - they should run one unified control set with HIPAA-specific and CMMC-specific evidence overlays. We do this routinely. See our CMMC compliance pillar and the broader cybersecurity program overview for how the regimes intersect, and our vCISO services for the executive-layer governance that makes a unified program possible.