Most small and mid-sized healthcare practices believe their HIPAA compliance is handled the moment their IT provider signs a Business Associate Agreement. That belief is the single most expensive misunderstanding in healthcare IT — and it shows up in nearly every OCR investigation that leads to a settlement.
The Office for Civil Rights, which enforces HIPAA, doesn't look at contracts when it investigates a breach. It looks at what the practice actually did. Was a risk analysis performed and documented? Were technical safeguards configured correctly? Were access logs reviewed? Were employees trained, and was that training documented? Was the IT provider operating under defined responsibilities, with audit trails showing what they did and when?
A BAA is a contract between a covered entity and a business associate that allocates HIPAA responsibilities. It is required. It is not a substitute for compliance. Practices that confuse the two consistently end up surprised — and often penalized — when something goes wrong.
The Most Common Misunderstandings
These are the recurring patterns we see when healthcare practices first engage a serious HIPAA-aware managed services review. None of them are unusual. All of them are fixable.
"Our IT provider signed a BAA, so we're HIPAA compliant."
A BAA is a required contract, not a control. Compliance is a function of what you actually do — risk analysis, safeguards, training, audit — and what you can document.
"If we get breached, our IT provider is responsible."
The Omnibus Rule made business associates directly liable for HIPAA violations, but covered entities remain liable for inadequate vendor oversight. OCR penalizes both.
"We've never had an incident, so our setup must be fine."
Most HIPAA penalties don't come from sophisticated attacks. They come from lost laptops, misconfigured email, and unreviewed access — all preventable with controls most practices haven't deployed.
"Our EHR vendor handles HIPAA. We don't need to worry about it."
Your EHR vendor secures its platform. It does not secure your network, endpoints, email, backups, or staff. The covered entity remains responsible for everything outside the EHR itself.
Where Healthcare Practices Get HIPAA Compliance Wrong With Their IT Provider
1. They Skip the Risk Analysis
The HIPAA Security Rule (45 CFR § 164.308) requires an accurate and thorough risk analysis of electronic PHI. It is the most commonly cited finding in OCR enforcement actions — failure to perform or adequately document a risk analysis appears in the majority of HIPAA settlements published in the past several years.
Practices typically don't skip the risk analysis because they don't believe in it. They skip it because they assume their IT provider has done one. Most haven't. The risk analysis is the practice's responsibility — though a competent managed IT provider can perform or facilitate it. Either way, it needs to exist, in writing, dated, and updated annually or after material changes.
2. The BAA Has Vague Responsibility Allocation
A boilerplate BAA generally says the business associate "will implement appropriate safeguards" without defining what those are. When an incident happens, that ambiguity becomes a problem — both sides point at the other, and the practice often discovers that what they assumed the provider was doing was never explicitly agreed to.
A useful BAA enumerates the specific safeguards the provider is responsible for, the access they have to PHI, what data flows through their systems, what audit logs they maintain, what their breach notification timeline is, and what happens to PHI if the engagement ends. Boilerplate language doesn't do any of this.
3. Encryption Is Configured But Not Documented
HIPAA doesn't strictly require encryption — it makes it "addressable," which means you must implement it or document why you didn't. In practice, the lack of encryption is a leading cause of penalties because the documented reason is almost always inadequate. Practices encrypt their email or storage, but can't prove it during an audit because the configuration isn't documented.
4. Access Reviews Don't Happen
Who has access to PHI? Has that list been reviewed in the past 6 months? When staff leaves, are their accounts disabled within a defined window? Most practices can't answer these questions with confidence. The HIPAA Security Rule explicitly requires periodic review of access rights — and OCR auditors check for evidence of these reviews, not just policy claims that they happen.
5. Audit Logs Exist But Aren't Reviewed
Most modern systems generate audit logs by default. Few practices review them. HIPAA requires both: logs must exist AND there must be a process to review them periodically for unusual activity. "The logs are in the system if we needed to look" is not the standard.
6. Employee Training Is One-Time and Undocumented
HIPAA requires recurring workforce training. Most practices complete training at onboarding and never again. The right cadence is annually at minimum, with documented attendance and an explicit acknowledgment of policies that the practice keeps on file.
7. The Incident Response Plan Is a Theoretical Document
Practices have an IR plan because their compliance template told them to. They don't have a tested IR plan with named roles, current contact information, and a defined notification timeline that meets HIPAA's 60-day requirement. When something happens, they discover the plan in mid-crisis — which is the worst time to read it for the first time.
OCR auditors don't evaluate whether you have controls in place — they evaluate whether you can prove it. The practical compliance test isn't "is encryption configured?" It's "can you produce, on demand, the documented configuration, the date it was implemented, the responsible owner, the test of last verification, and the review schedule?" If you can't, treat it as not done.
What a Properly Configured HIPAA-Aware Managed Services Engagement Looks Like
The healthcare-IT relationship that actually holds up under regulatory scrutiny shares a handful of structural features. None of them are exotic. They're the difference between "our IT provider helps with HIPAA" and "our IT provider is operationally responsible for the specific safeguards we've allocated to them."
Specific BAA Provisions
The BAA names the data types accessed, the safeguards deployed, the audit trail kept, and the breach notification timeline. No boilerplate.
Documented Risk Analysis
An accurate, thorough analysis exists in writing, dated and signed off. Updated annually and after material changes. Not optional.
Technical Safeguards With Evidence
Encryption, MFA, EDR, backup, and access controls are not just deployed — their configurations are documented, with evidence the practice can produce on demand.
Audit Log Review Process
Logs are generated AND reviewed on a defined schedule. Unusual activity surfaces for human attention rather than sitting in a system nobody opens.
Tested Incident Response
An IR plan exists, has named owners, has current contact information, and has been walked through at least annually. Notification timelines are mapped to HIPAA's 60-day requirement.
Annual Compliance Review
The practice and the IT provider meet annually to review what changed, re-run the risk analysis, refresh documentation, and check that everything written down still reflects reality.
The OCR Audit Checklist Most Practices Fail
If an investigator showed up at your practice tomorrow with a HIPAA inquiry, this is roughly what they'd ask for. Walk through it honestly — the gaps are the work.
| Request | What They Want to See | Common Gap |
|---|---|---|
| Risk analysis | Current, dated, signed; updated within 12 months | Never performed, or last done 4+ years ago |
| Business Associate Agreements | Signed BAAs with every vendor that touches PHI | Missing for cloud apps, billing services, secondary vendors |
| Workforce training records | Recurring training with attendance evidence | One-time onboarding, no ongoing records |
| Access review logs | Periodic access reviews with documented outcomes | No formal review cadence; access drift unchecked |
| Audit log review | Evidence logs are reviewed, not just generated | Logs exist; no one has opened them |
| Encryption documentation | Configuration documented for email, storage, devices | Configured but undocumented; can't prove during audit |
| Incident response plan | Tested plan with current contacts and named roles | Template document, never tested or updated |
| Sanction policy | Documented disciplinary actions for HIPAA violations | Policy exists but no documented enforcement events |
Frequently Asked Questions
Does signing a BAA with my IT provider make my practice HIPAA compliant?
No. A Business Associate Agreement is a required contract that allocates HIPAA responsibilities between a covered entity and its vendors, but it doesn't perform any technical safeguards on its own. Compliance is a function of the controls actually deployed and documented — encryption, access controls, audit logs, risk analysis, employee training — not the existence of the contract.
Who is liable for a breach — the practice or the IT provider?
Both. Under the HIPAA Omnibus Rule, business associates have direct liability for HIPAA Security Rule violations, but covered entities remain liable for inadequate oversight of their vendors. OCR frequently penalizes both sides. The BAA allocates contractual responsibility but doesn't eliminate regulatory liability for either party.
What is a HIPAA risk analysis and is it really required?
Yes. The HIPAA Security Rule (45 CFR § 164.308(a)(1)(ii)(A)) requires covered entities and business associates to conduct an accurate and thorough analysis of risks to electronic PHI. It's the single most commonly cited finding in OCR enforcement actions — failure to perform or document a risk analysis appears in the majority of HIPAA settlement agreements published since 2018.
Does my IT provider need to be HIPAA certified?
HIPAA itself doesn't issue certifications — there is no government-issued "HIPAA certified" badge, and any vendor claiming one should be questioned. What you want is a provider with documented HIPAA expertise, a signed BAA, evidence of completed risk analyses for similar clients, and ideally HITRUST CSF or SOC 2 Type II attestation, which independently verifies the controls they're operating.
Can a managed IT provider help our practice prepare for an OCR audit?
Yes, and this is one of the highest-value things a managed IT provider does for healthcare clients. Renacy supports healthcare practices with risk analysis documentation, technical safeguard implementation, evidence collection, and audit response preparation — so that if an OCR investigation occurs, the practice has the documentation ready and the controls in place.
Related reading: IT Support for Healthcare →
Renacy is a managed IT support provider serving businesses across New York, New Jersey, Pennsylvania, Connecticut, Massachusetts, Maryland, and Washington DC. Our team specializes in proactive device monitoring, helpdesk support, cloud backup & disaster recovery, and network infrastructure management. Learn more about Renacy →