Do You Need a BAA With Your IT Company?

Short answer: yes, almost always. If the person or company handling your IT can reach the systems where patient data lives, HIPAA requires a signed Business Associate Agreement (BAA) with them. No exceptions for “it's just my nephew who does our computers.”

And this is not paperwork for its own sake. Without a BAA you are out of compliance the moment they touch protected health information, and if they cause a breach, it becomes your breach to report and your liability. Here is who needs one and what happens when it is missing.

What a BAA is

A Business Associate Agreement is a contract, required under 45 CFR 164.308(b) and 164.502(e), between you (the covered entity) and any vendor that creates, receives, maintains, or transmits protected health information (PHI) on your behalf. It legally binds that vendor to safeguard the data and to tell you if something goes wrong.

Is your IT provider a business associate?

If they can access your systems, servers, email, EHR, or backups, where PHI lives, then yes. Almost every IT provider or managed service provider with administrative access to your environment is a business associate, because they can reach the data even if they never intentionally look at it. There is a narrow “conduit exception” for services that only transport data (your ISP, the postal service), but a hands-on IT provider is not a conduit.

Who else needs a BAA

Your IT company is not the only one. You need a signed BAA with essentially every vendor that can touch PHI:

• Your EHR and practice-management system.
• Email and cloud providers (Google Workspace, Microsoft 365) configured for PHI.
• Cloud backup and any offsite storage of patient data.
• Billing companies and clearinghouses.
• Any SaaS tool where patient information is entered, and document shredding or records vendors that handle PHI.

What happens without one

Two things, both bad. First, you are simply out of compliance the moment a vendor accesses PHI without a signed BAA in place, and OCR checks for these. Second, and more painful: if that vendor has a breach, you, as the covered entity, are still responsible for breach notification and the fallout. A missing BAA turns someone else's mistake into your regulatory problem.

What a good BAA covers, and one red flag

A solid BAA spells out the safeguards the vendor will maintain, requires them to notify you of any breach, flows the same obligations down to their subcontractors, limits how they may use the data, and covers return or destruction of PHI when you part ways. The single biggest red flag: a provider who will not sign one, or hedges when you ask. If an IT company balks at a BAA, they should not be anywhere near your patient data.

The flip side is what a good arrangement looks like: an IT partner who signs the BAA directly, and actually carries the safeguards, insurance, and documentation behind it, so the regulatory risk sits with the people operating the security, not just with you.