Your IT Company Is a Business Associate — Whether They Know It or Not
Under HIPAA, any vendor who creates, receives, maintains, or transmits Protected Health Information (PHI) on behalf of a covered entity is a Business Associate. This definition almost certainly includes your IT provider — they access your servers, manage your email, and touch the systems that store patient records.
Business Associates are subject to the HIPAA Security Rule. They are required to implement the same technical safeguards that your practice must have in place — and they must document that they have done so in a signed Business Associate Agreement (BAA).
Most small and mid-size IT providers working with healthcare practices have never signed a BAA with any of their clients. Many have never heard of the requirement. That is not a technicality — it is a compliance gap that OCR has cited in enforcement actions.
The Six Technical Safeguards Your IT Provider Must Implement
HIPAA's Security Rule Technical Safeguards (45 CFR § 164.312) define the specific IT controls required for systems that handle PHI. Here is what each one requires and what your IT partner should be doing to address it:
Access Control
Unique user IDs for every staff member, automatic logoff on idle workstations, and role-based access so each employee can only access the records necessary for their specific role. No shared passwords. No administrator accounts used for daily work.
Audit Controls
Logging enabled on hardware and software systems that process PHI — capturing who accessed what, when, and from where. Logs must be retained and reviewed. Most practices discover their audit logging was never configured.
Integrity Controls
Mechanisms to ensure that PHI is not altered or destroyed in unauthorized ways — including secure transmission protocols and data integrity verification for backups and file transfers.
Transmission Security
PHI transmitted across networks — including email, remote access, and cloud sync — must be encrypted. TLS for email and web, VPN for remote access, and end-to-end encryption for patient communications are all required.
Authentication
Verification that users are who they claim to be — which today means multi-factor authentication for all systems accessing PHI, especially cloud-hosted EHR platforms and email.
Encryption at Rest
PHI stored on workstations, servers, and portable devices must be encrypted so that a lost or stolen device does not result in a reportable breach. This is an addressable standard — but "addressable" does not mean optional.
The Security Risk Analysis: Required Annually, Almost Never Done
HIPAA requires covered entities to conduct and document a Security Risk Analysis — a thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of PHI. This is not a one-time exercise. It must be repeated whenever the environment changes significantly and reviewed annually.
In enforcement actions, OCR consistently cites failure to conduct an adequate Security Risk Analysis as one of the most common and most serious compliance violations. It is also one of the easiest to remediate — but only if your IT provider understands what it requires and is willing to complete the documentation with you.
What "Addressable" Actually Means
HIPAA distinguishes between "required" and "addressable" implementation specifications. "Addressable" does not mean optional — it means you must assess whether the safeguard is reasonable and appropriate for your organization. If you determine it is not appropriate, you must document why and implement an equivalent alternative. In practice, most addressable specifications are expected to be implemented.
The Most Common HIPAA Compliance Gaps in Healthcare Practices
What OCR Finds When They Investigate
- 1No Business Associate Agreement with the IT provider — the most common gap and the most straightforward to remediate.
- 2No Security Risk Analysis has ever been conducted — or the last one was done more than two years ago and never updated.
- 3Audit logging not enabled on EHR and systems accessing PHI — so there is no record of who accessed what when.
- 4Workstation and laptop encryption not enabled — a lost device automatically triggers a reportable breach.
- 5No documented incident response or breach notification procedure — staff don't know what to do when something happens.
- 6Staff HIPAA security training never conducted or more than 12 months out of date — leaving phishing and social engineering as easy vectors.
What To Ask Your IT Provider Right Now
- Have you signed a Business Associate Agreement with us? Can you send it to me?
- When was the last Security Risk Analysis completed for our practice, and can you show me the documentation?
- Is PHI encrypted at rest on our workstations and servers?
- Is audit logging enabled on our EHR and any system that stores patient records?
- What is our multi-factor authentication coverage for systems accessing PHI?
- What is your documented process if we experience a security incident involving patient data?
If your IT provider cannot confidently answer these questions — or if the answers reveal gaps — that is important information. HIPAA compliance is not a burden your IT partner imposes on you. It is a service they should be providing.
MQUAL has been engineering HIPAA-aware technology environments for healthcare practices since 2006. We complete Business Associate Agreements as a standard part of every engagement, and we treat HIPAA Security Rule compliance as an engineering requirement — not an optional add-on.