Your IT provider has concrete obligations under the HIPAA Security Rule when they touch systems that hold patient data. Plenty of small and mid-size shops never finish that work. Practice owners often learn about the gap only after a breach, a complaint, or an audit letter.

Your IT company is a Business Associate — whether they say so or not

Under HIPAA, a vendor who creates, receives, maintains, or transmits Protected Health Information (PHI) for a covered entity is a Business Associate. That definition usually covers your IT provider. They reach your servers, manage email, run backups, and work inside the systems that store charts and billing data tied to patients.

Business Associates fall under the Security Rule. They are expected to put technical safeguards in place for the PHI they handle, and to document that relationship in a signed Business Associate Agreement (BAA).

Many small and mid-size IT firms that serve clinics have never signed a BAA with those clients. Some have never been asked. OCR has cited that gap in enforcement actions. It is not a paperwork nicety; it is a compliance hole that sits open until someone closes it.

Figures that show up often in HIPAA discussions (and already on this page) are useful context, not a personalized risk score for your practice: settlements tied to weak technical safeguards have averaged in the multi-million-dollar range in published examples (including a commonly cited $10.9M figure for inadequate technical safeguards); breach notification to patients generally must start within 60 days of discovery; and willful neglect can carry civil penalties up to $50K per violation under the published penalty tiers. The practical point is simpler: waiting until OCR is involved is an expensive way to discover missing BAAs, encryption, or logging.

The six technical safeguards your IT partner should be running

HIPAA’s Security Rule technical safeguards (45 CFR § 164.312) spell out IT controls for systems that handle PHI. Here is what each one asks for in practice, and what a competent healthcare IT partner should be doing about it.

Access control

Every staff member gets a unique user ID. Workstations log off automatically when idle. Access is role-based so people only reach the records their job requires. Shared passwords and daily use of administrator accounts are off the table.

Audit controls

Logging is turned on for hardware and software that process PHI — who accessed what, when, and from where. Logs are retained and actually reviewed. Many practices find out during an incident that audit logging was never configured.

Integrity controls

Controls exist so PHI is not altered or destroyed without authorization. That includes secure transmission methods and integrity checks on backups and file transfers, not only a hope that nothing changed.

Transmission security

PHI that crosses a network — email, remote access, cloud sync — needs encryption appropriate to the path. In practice, that usually means TLS for email and web traffic, VPN for remote access, and end-to-end encryption where patient messaging requires it.

Authentication

Users prove they are who they say they are. Today that means multi-factor authentication on systems that reach PHI, especially cloud EHR platforms and email.

Encryption at rest

PHI on workstations, servers, and portable devices should be encrypted so a lost or stolen device does not automatically become a reportable breach. Encryption at rest is an “addressable” standard under HIPAA — and “addressable” does not mean optional.

The Security Risk Analysis: required on a cadence, often skipped

Covered entities must conduct and document a Security Risk Analysis — a real look at risks and vulnerabilities to the confidentiality, integrity, and availability of PHI. It is not a one-time binder exercise. It needs review when the environment changes in a meaningful way, and at least annually in most well-run programs.

OCR enforcement actions keep citing missing or stale Security Risk Analyses as common, serious findings. The remediation path is clear when your IT partner knows what the analysis requires and will complete the documentation with you instead of treating it as someone else’s homework.

What “addressable” actually means

HIPAA splits implementation specifications into “required” and “addressable.” Addressable does not mean you can ignore the safeguard. It means you assess whether it is reasonable and appropriate for your organization. If you decide it is not, you document why and put an equivalent alternative in place. In practice, most addressable specs are expected to be implemented for a typical clinic.

What OCR often finds when they dig in

  • No Business Associate Agreement with the IT provider — still the most common gap, and usually the fastest to fix once someone asks for the PDF.
  • No Security Risk Analysis on file, or one older than two years that was never updated when systems changed.
  • Audit logging is off on the EHR and other systems that touch PHI, so there is no usable record of access.
  • Workstation and laptop encryption not enabled — a lost device then tends to trigger breach analysis and notification work.
  • No written incident response or breach-notification procedure, so staff improvise under stress.
  • Staff HIPAA security training never done, or more than 12 months out of date, which leaves phishing and social engineering as easy paths in.

Questions worth asking your IT provider this week

  • Have you signed a Business Associate Agreement with us? Can you send the current copy?
  • When was the last Security Risk Analysis completed for this practice, and can you show the documentation?
  • Is PHI encrypted at rest on our workstations and servers?
  • Is audit logging enabled on our EHR and any other system that stores patient records?
  • Which systems that access PHI have multi-factor authentication, and which still do not?
  • What is your documented process if we have a security incident that involves patient data?

If the answers are vague, delayed, or reveal gaps, treat that as data about the support model — not as a reason to feel embarrassed. HIPAA compliance is not a burden a good IT partner dumps on the practice. It is part of the engineering work they should already be doing.

MQUAL has been building HIPAA-aware technology environments for healthcare practices since 2006, including practices in Tampa Bay and across the country. A signed BAA is standard on engagements that touch PHI, and Security Rule work is treated as an engineering requirement rather than an optional add-on after something goes wrong.