Business Associate Agreements (BAA): An IT Vendor Guide

Every dental and medical practice relies on outside companies to run its technology: an IT provider, Microsoft 365, a cloud EHR, a backup service, a phone system, an e-fax line. Each of those vendors may see, store or move your patients' information. HIPAA's answer to that reality is the business associate agreement, or BAA — a contract that makes the vendor promise, in writing, to protect patient data the way HIPAA requires.

Most practices have a BAA with their EHR vendor. Far fewer have one with their IT company, their backup provider, their VoIP phone company or their fax service. Those gaps matter: sharing patient data with a vendor that hasn't signed a BAA is a HIPAA violation on its own, before anything goes wrong. And when something does go wrong at a vendor, the first question is whether the agreement was in place.

This guide explains what a BAA is in plain English, which IT vendors need one (and which don't), what the agreement must contain, the red flags to watch for, how the chain of subcontractors works, and exactly how Microsoft's BAA works for Microsoft 365. It's written for practice managers and owners, not lawyers — but it's not legal advice, so have your attorney review contracts that matter.

Does Beefed Up IT sign a BAA? Yes. When we support systems that store or access your patients' information, we sign a business associate agreement with your practice before we start — and the vendors in our own toolset that could touch that data must be covered by a BAA with us too, so the chain of protection doesn't break at our end. Ask us for a copy.

What is a business associate agreement?

A business associate agreement is a written contract, required by HIPAA, between a covered entity and a vendor that creates, receives, maintains or transmits protected health information on the covered entity's behalf. It spells out what the vendor may do with the data, requires the vendor to safeguard it, and obligates the vendor to report incidents and breaches.

The key definitions, from 45 CFR 160.103:

• Covered entity — a health care provider that conducts certain transactions electronically (such as billing insurance), a health plan, or a health care clearinghouse. Your practice.
• Business associate — a person or company that "creates, receives, maintains, or transmits protected health information" for a function or activity regulated by HIPAA on behalf of a covered entity, or that provides certain services (legal, accounting, consulting, data aggregation, management, administrative and others) involving PHI. Your vendors.
• Subcontractor — "a person to whom a business associate delegates a function, activity, or service," other than its own workforce. Your vendor's vendors.
• PHI — individually identifiable health information. ePHI is PHI in electronic form.

Several sections of the HIPAA rules work together here:

• 45 CFR 164.502(e) (Privacy Rule) allows you to disclose PHI to a business associate only if you get "satisfactory assurances" — a BAA.
• 45 CFR 164.308(b) (Security Rule) requires the same for ePHI, as a required implementation specification.
• 45 CFR 164.504(e) lists what the contract must contain.
• 45 CFR 164.314(a) adds Security Rule terms the contract must include.

Since the HITECH Act and the 2013 Omnibus Rule, business associates are also directly liable for certain HIPAA requirements, including complying with the Security Rule. In May 2019, HHS published a fact sheet listing the provisions under which a business associate can be held directly liable — among them failing to comply with the Security Rule, impermissible uses and disclosures, failing to notify the covered entity of a breach, and failing to enter into BAAs with subcontractors. That means a vendor can't escape responsibility by pointing at you, and you can't escape responsibility by pointing at the vendor.

How do you know if a vendor is a business associate?

Ask one question: will this vendor create, receive, maintain or transmit PHI for us, or have routine access to it? If yes, it's a business associate and needs a BAA. If its only contact with PHI is incidental or purely as a pass-through, it probably isn't.

Use this decision guide:

1. Does the vendor store any of our patient data? (Cloud storage, email hosting, backups, voicemail, fax archives, EHR.) → Business associate. Storing counts even if they never look at it.
2. Does the vendor have access to systems where patient data lives? (IT support with admin rights, remote access tools, EHR support staff who remote in.) → Business associate.
3. Does the vendor process or send patient data for us? (Claims, statements, appointment reminders, patient texting, e-prescribing gateways.) → Business associate.
4. Does the vendor only carry data from point A to point B without storing it, with at most transient access? (Internet service provider, postal service, courier.) → Probably a "conduit," not a business associate.
5. Is any contact with PHI only incidental? (Janitorial service, electricians, a building landlord.) → Not a business associate, though you should still limit what they can see.
6. Is it another health care provider receiving PHI for treatment? (Referral to an oral surgeon, a lab you send specimens to for testing.) → Not a business associate for those treatment disclosures.
7. Is it your own employee? → Workforce, not a business associate. Covered by your policies and training instead.

The conduit exception, and why it's narrow

The conduit exception covers only transmission-only services, like the postal service or an internet provider, whose access to PHI is transient. HHS has been explicit that it does not extend to anyone who stores data.

According to HHS guidance, the exception is intended for "mere courier" services and their electronic equivalents, such as internet service providers that only transmit data, including temporary storage incidental to transmission. The difference between a conduit and a business associate is transient versus persistent access. A company that maintains PHI on your behalf is a business associate, even if it never actually looks at the data.

That's why your Comcast or Spectrum internet line doesn't need a BAA, but your cloud phone system that stores voicemails does, and your email provider does.

Encrypted "no-view" cloud services still need a BAA

HHS's 2016 guidance on HIPAA and cloud computing addressed a common vendor argument: "We encrypt your data and don't have the key, so we're not a business associate." HHS rejected it. A cloud service provider that stores encrypted ePHI is still a business associate even without the decryption key. Encryption protects confidentiality but can't, on its own, protect integrity or availability — the provider can still lose, corrupt or fail to deliver your data. So the BAA is required.

Which IT vendors need a BAA?

Most technology vendors that touch a practice's systems are business associates: your managed IT provider, Microsoft or Google, backup, cloud EHR, VoIP, e-fax, secure email, patient messaging and security monitoring services. Your internet provider and domain registrar usually aren't.

One rule of thumb: if a vendor would show up in your security risk assessment as a place ePHI lives, it needs a BAA.

How does Microsoft's BAA work?

Microsoft offers its HIPAA BAA to all customers who are covered entities or business associates, by default, through the Microsoft Online Services Data Protection Addendum (DPA). You don't sign a separate document, and Microsoft won't sign yours. It covers a defined list of in-scope services.

Here's what Microsoft's own HIPAA documentation on Microsoft Learn says, as of this writing (the page was last updated in September 2026):

• It's automatic. The Microsoft HIPAA Business Associate Agreement "is available through the Microsoft Online Services Data Protection Addendum by default to all customers who are covered entities or business associates under HIPAA."
• It's Microsoft's paper, not yours. Microsoft "can't use a customer's Business Associate Agreement" because its multi-tenant services are standardized. Microsoft says its BAA was developed with a consortium of academic medical centers and other healthcare organizations.
• It covers specific services. In-scope services listed include Office 365 commercial services such as Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, Microsoft Entra ID, Microsoft Defender for Office 365, Microsoft Purview, Forms, Planner and Microsoft Copilot and Copilot Chat, plus Microsoft Intune, Windows 365, Azure and Dynamics 365, among others. Check the current list before you put PHI into any service.
• It doesn't make you compliant. Microsoft states plainly that "using Microsoft services doesn't on its own achieve HIPAA compliance" — your organization is responsible for an adequate compliance program and for using the services in a way that meets your obligations.
• There's no HIPAA certification. Microsoft notes there's no HHS-approved certification standard for HIPAA; its in-scope services are audited for ISO/IEC 27001 and HITRUST CSF.

Practical steps for Microsoft 365

1. Download a copy of the BAA from the Microsoft Service Trust Portal and save it, with the date, in your compliance folder. Investigators and insurers may ask to see it.
2. Make sure you're on a business or enterprise plan. The BAA covers Microsoft's commercial online services. Personal and family Microsoft 365 subscriptions and consumer Outlook.com accounts are not appropriate for PHI.
3. Keep PHI inside in-scope services. Exchange, SharePoint, OneDrive and Teams are covered. Before using a newer feature or connected third-party app with patient data, confirm it's in scope. Third-party apps you connect to Microsoft 365 need their own BAA if they access PHI.
4. Configure the security. MFA, Conditional Access, device management, encryption, audit logging and retention are your job. Our HIPAA Security Rule checklist has a 12-step Microsoft 365 hardening sequence, and our article on whether Microsoft 365 is HIPAA compliant goes deeper.
5. Back it up separately — and get a BAA from that backup vendor.

What about Google, Zoom and other big platforms?

Most large platforms that market to healthcare offer a BAA, but the details differ: some include it automatically, others require you to accept it in an admin console, and many limit it to particular plans or services. Never assume. Look for the vendor's HIPAA page, confirm which plan and services are covered, accept or sign the BAA, and keep a copy.

What must a BAA contain?

HIPAA dictates the minimum content of a BAA in 45 CFR 164.504(e) and 164.314(a). A contract missing these terms doesn't meet the requirement, no matter what it's called.

HHS publishes sample business associate agreement provisions that cover these minimums. They're a useful baseline, but HHS notes they aren't a complete contract and don't address business terms.

Your obligations if a vendor violates the BAA

Under 164.504(e)(1)(ii), if you know of a pattern of activity or practice by a business associate that materially breaches the agreement, you must take reasonable steps to cure the breach or end the violation — and, if those steps fail, terminate the contract if feasible. In other words, you can't knowingly look the other way.

What should a good BAA include beyond the legal minimum?

The legal minimum leaves important business questions open — especially how fast the vendor tells you about an incident and who pays for a breach. These are the points worth negotiating, or at least understanding, with your significant vendors.

1. Incident notification timeline. The rules require a business associate to notify you of a breach without unreasonable delay and no later than 60 days after discovery (45 CFR 164.410). But your own 60-day clock to notify patients may start when the vendor discovered the breach, so 60 days is far too slow. Many practices ask for notice within a few business days, with an initial heads-up sooner.
2. Definition of "security incident." The Security Rule's definition includes attempted unauthorized access. Taken literally, that means every blocked login attempt. Good BAAs clarify that routine unsuccessful attempts (pings, port scans, blocked sign-ins) are reported in aggregate or deemed reported, while successful or significant incidents get prompt, specific notice.
3. Cooperation in investigations. Access to logs and forensic findings you'll need for your own breach risk assessment.
4. Who pays. Responsibility for notification costs, credit monitoring, forensic investigation and regulatory penalties caused by the vendor.
5. Cyber insurance. Whether the vendor carries cyber insurance and at what level.
6. Subcontractors. A list of subcontractors that touch PHI, or at least notice when they change.
7. Data location. Whether PHI may be stored or accessed outside the United States.
8. Encryption. A commitment to encrypt ePHI at rest and in transit.
9. Return of data. Format and timeline for returning your data at the end — critical for EHRs and backups so you aren't held hostage when switching vendors.
10. Security documentation. The right to receive evidence of the vendor's safeguards (a SOC 2 report, HITRUST certification, or a security questionnaire) on request.

You won't get custom terms from Microsoft or other hyperscale providers, and small vendors may push back too. That's fine — the goal is to understand the terms you're accepting and to factor weak terms into your risk analysis.

How does the subcontractor chain work?

Each link in the chain needs its own BAA: you sign with your vendor, your vendor signs with its subcontractors, and they sign with theirs. You don't need a BAA directly with your vendor's subcontractors, but you should know who they are.

A typical chain for a small practice's IT looks like this:

1. Your practice (covered entity) → signs a BAA with →
2. Your managed IT provider (business associate) → which signs BAAs with its subcontractors, such as →
3. Its remote monitoring and management (RMM) platform, its backup cloud provider, its security operations center (SOC) or MDR service, its help desk ticketing system if tickets contain PHI → each of which may have its own subcontractors, such as →
4. The cloud data centers those vendors run on.

The rules:

• Under 164.502(e)(1)(ii) and 164.308(b)(2), a business associate may let a subcontractor handle PHI only if it gets satisfactory assurances (a BAA) from that subcontractor. You, the practice, are not required to get a BAA directly with subcontractors.
• Under 164.314(a)(2)(iii), the subcontractor BAA must contain the same Security Rule requirements as yours.
• Since the 2013 Omnibus Rule, subcontractors that handle PHI are business associates themselves, directly liable for Security Rule compliance.

Why you should still care: if your IT provider's remote-access tool or backup vendor is breached, it can become your breach. Ask your provider for a list of subcontractors with access to your data and confirmation that BAAs are in place. A well-run provider can answer that in one email.

Red flags when a vendor talks about BAAs

Watch for vendors who avoid the BAA, water it down, or misunderstand what it means. Any of these should prompt a harder look — or a different vendor.

1. "We're HIPAA certified, so we don't need a BAA." There's no HHS-approved HIPAA certification, and certification of any kind doesn't replace a BAA.
2. "We encrypt everything, so we're not a business associate." HHS has said otherwise for cloud providers that store encrypted data.
3. "We're just a conduit" — from a vendor that stores voicemails, faxes, files or backups.
4. Flat refusal to sign anything. If they won't sign, you can't use them for PHI.
5. A BAA that only covers some services. Fine if you know it — dangerous if staff use an uncovered feature for PHI.
6. A BAA only on a higher plan you aren't on. Common with SaaS tools; confirm your plan is covered.
7. No incident notification commitment, or one that just repeats "60 days."
8. Clauses letting the vendor use your PHI for its own purposes — marketing, product development, AI training — beyond what's needed to serve you. Read data-use clauses closely, especially for AI tools.
9. No answer about subcontractors or data location.
10. An IT provider that uses shared admin accounts, no MFA on its own tools, or can't tell you who has access to your systems. The BAA is only as good as the practices behind it.

How to get your BAAs in order: a step-by-step process

Build a vendor inventory, decide which are business associates, collect or sign BAAs, review the terms, and put it on a yearly calendar. For a small practice this is usually a few hours of work spread over a couple of weeks.

1. List every vendor. Pull a year of credit card and bank statements and accounts-payable records. Every software subscription and service is a candidate. Add anything your IT provider manages on your behalf.
2. Mark which ones touch PHI using the decision guide above.
3. Check for an existing BAA. Look in contracts, online terms, admin consoles (many SaaS vendors have an "accept BAA" toggle), and email.
4. Request what's missing. Most healthcare-focused vendors have a standard BAA ready. If a vendor won't sign, plan to replace it.
5. Read the key terms: incident notice timeline, subcontractors, data return, any data-use rights.
6. Record it. A simple vendor register: vendor, service, PHI involved, BAA date, BAA location, incident contact, renewal date.
7. Restrict use of non-BAA tools. Update your policies to say staff may not put PHI into personal email, consumer cloud storage, consumer texting apps or AI chatbots not covered by a BAA.
8. Review annually and whenever you add a vendor. New vendors shouldn't get PHI until the BAA is signed.
9. Feed it into your risk analysis. High-risk vendors — those holding the most PHI — deserve the closest look.

Scenario: a seven-person dental office

A small dental office typically has eight to fifteen vendors touching PHI, and it's common to find two or three without a BAA the first time you look.

The office: one dentist, two hygienists, two assistants, a front-desk coordinator and an office manager. On-site practice management and imaging server, Microsoft 365 email, a cloud VoIP phone system with voicemail-to-email, an e-fax service, a patient reminder text service, an outsourced IT provider, and a local shredding company.

What the review finds:

• EHR / practice management vendor: BAA in the license agreement. ✓
• Microsoft 365: BAA included by default via the DPA — but no one had downloaded a copy. Saved to the compliance folder. ✓
• IT provider: signed a BAA four years ago; office manager asks which subcontractors (remote management tool, backup cloud) have access to practice data and gets written confirmation of their BAAs. ✓
• VoIP provider: voicemails with patient names and callback requests are stored and emailed. No BAA. The provider offers one on its healthcare plan; the practice switches plans. ✓
• E-fax: the practice is on a basic plan that doesn't include a BAA. Upgrades to a plan with a BAA. ✓
• Patient reminder service: BAA available as a click-through in the admin portal; accepted and saved. ✓
• Imaging software vendor: remotes in to the server for updates and support. Its BAA had never been requested. Requested and signed. ✓
• Shredding company: has a BAA and provides certificates. ✓
• Internet provider: conduit — no BAA needed. Documented why.
• The dentist's personal Gmail, used occasionally to email X-rays to a specialist: no BAA possible. Replaced with Microsoft 365 encrypted email.

Total effort: about four hours of the office manager's time plus a few calls. The practice now has a vendor register it reviews each January. For more on this kind of office, see our dental office IT guide.

Scenario: a 25-person medical practice

A larger medical office tends to have twenty or more vendors with PHI, and the risk is less "missing BAA" than "stale BAA" — agreements signed years ago with vendors whose services have changed.

The practice: four providers, nurses and MAs, billing staff, front desk and a practice administrator. Cloud EHR with a patient portal, telehealth, an outsourced billing company, a clearinghouse, a transcription service that recently added an AI scribe, an answering service, a lab interface vendor, Microsoft 365, a managed IT provider with an MDR security service, and a document management system.

Key findings and actions:

1. The AI scribe was added as a "free feature" of the transcription service. The existing BAA predates it. The administrator asks how audio is processed, where it's stored, how long it's kept, and whether it's used to train models — and gets an updated BAA addressing it.
2. The billing company uses an offshore team for coding. The BAA is silent on data location. The practice adds a clause requiring disclosure and approval of offshore access, and reviews the billing company's security documentation.
3. The MSP's MDR provider sees security logs from practice systems. Confirmed covered by a subcontractor BAA with the MSP.
4. Telehealth runs through the EHR's built-in module, covered by the EHR BAA. A few providers had also used a consumer video app during a busy week; the practice blocks it and retrains.
5. Incident notice timelines vary from "promptly" to "60 days." At renewal, the administrator negotiates shorter notice periods with the largest vendors.
6. Vendor register goes into the annual risk assessment, with the EHR, billing company and MSP flagged as highest-impact vendors.

More on medical-office systems in our medical office IT guide.

What should you do when a vendor reports a breach?

Treat a vendor's breach notice as the start of your own incident response: get the facts, run your own breach risk assessment, and decide who notifies patients. Under HIPAA, notifying affected patients, HHS and (for large breaches) the media is the covered entity's responsibility, although you can contract with the vendor to send the notices for you.

When a business associate tells you something has happened:

1. Log it in your incident log with the date and time you were told and the date the vendor says it discovered the problem. Under 45 CFR 164.404, a breach is treated as discovered on the first day it's known — or would have been known with reasonable diligence — and if the vendor is acting as your agent, its discovery date can be imputed to you. Ask your attorney how that applies; it can shorten your timeline.
2. Ask for specifics in writing: what systems and data were involved, which patients, dates of the incident, whether data was viewed or taken, whether it was encrypted, and what's been done to contain it. The BAA's notice clause should require the vendor to provide the identity of each affected individual to the extent possible (164.410(c)).
3. Run the four-factor breach risk assessment — nature and extent of the PHI, who got it, whether it was actually acquired or viewed, and how far the risk has been mitigated. Our HIPAA breach response plan walks through it.
4. Decide who notifies. Agree in writing whether the vendor will mail letters, staff a call center and pay for credit monitoring, or whether you will.
5. Call your cyber insurer if you have coverage; many policies require prompt notice.
6. Review the relationship. Under 164.504(e)(1)(ii), if the breach reflects a pattern of material violations, you must take reasonable steps to cure it or end the contract.
7. Update your risk analysis to reflect what you learned about the vendor.

BAA, DPA, MSA, NDA: how do the contracts fit together?

A BAA is one piece of a vendor relationship. It sits alongside — and usually overrides, for PHI — the main service contract. Knowing which document says what avoids surprises.

Two things to check: the order of precedence (if the MSA and BAA conflict on PHI, the BAA should win), and liability caps (many MSAs cap the vendor's liability at a few months of fees, which may be tiny compared with the cost of a breach). You may not be able to change a hyperscale provider's terms, but you can negotiate with a local IT provider or a niche software vendor.

What happens to the BAA when you switch vendors?

When a vendor relationship ends, the BAA requires the vendor to return or destroy your PHI — so plan the exit before you sign. This matters most for EHRs, backups and IT providers, where a messy exit can leave you without data or with copies scattered across systems you no longer control.

A clean offboarding of a business associate looks like this:

1. Get your data back first in a usable, documented format — before you cancel. For an EHR, that means a full export you've confirmed you can open or import elsewhere.
2. Revoke access. Remove the vendor's accounts, remote-access tools, API keys and admin roles from your Microsoft 365 tenant, servers and network. Change any passwords they knew.
3. Request written confirmation of destruction of remaining PHI, including backups and subcontractor copies — or, where destruction isn't feasible, written confirmation that BAA protections continue.
4. Keep the BAA and the destruction confirmation in your records. Documentation must be kept six years under 45 CFR 164.316.
5. Update your vendor register and risk analysis.

If you're changing IT providers, the outgoing provider should hand over admin credentials, documentation, backup access and a list of tools to remove. A professional provider will do this cooperatively; it's worth asking about before you hire anyone.

Common BAA mistakes

Most BAA problems come from not knowing which vendors are business associates, not from bad contract language.

1. No BAA with the IT provider — the vendor with the most access to everything.
2. Assuming "HIPAA compliant" on a website means a BAA exists.
3. Forgetting phone, fax and texting vendors.
4. Never downloading Microsoft's BAA, so no one can produce it when asked.
5. Using consumer versions of Microsoft, Google, Dropbox or messaging apps for patient data.
6. Letting staff sign up for free tools — form builders, scheduling apps, AI chatbots — and putting PHI into them.
7. Stale agreements that don't cover new services the vendor added.
8. No plan to get data back when switching EHR or backup vendors.
9. Ignoring vendor incidents — not following up when a vendor reports a breach.
10. Treating the BAA as the end of due diligence. It's a promise, not proof.

Questions to ask any IT vendor about HIPAA

Before a vendor gets access to patient data, ask these questions. The answers tell you as much about their maturity as the BAA does.

1. Will you sign a BAA, and can I see it before we sign the main contract?
2. Which of your services are covered by the BAA, and which aren't?
3. How quickly will you notify us of a security incident or breach, and how?
4. Which subcontractors will have access to our data, and do they all have BAAs with you?
5. Where is our data stored and accessed from — is any of it outside the US?
6. Is our data encrypted at rest and in transit?
7. Do you require MFA for your staff to access our systems or data?
8. How do you control and log which of your employees access our data?
9. What happens to our data if we leave — in what format and how fast do we get it back, and how is it destroyed?
10. Do you have independent security documentation (SOC 2 report, HITRUST, ISO 27001)?
11. Do you carry cyber liability insurance?
12. Will you use our data for anything other than providing the service to us, including AI training?

For your IT provider specifically, our guide to choosing a managed IT provider has more questions.

What's changing for business associates?

The proposed HIPAA Security Rule update published January 6, 2025 would require more active vendor oversight, but as of October 2026 it has not been finalized. Among other changes, the proposal would require covered entities to obtain written verification from business associates, at least every 12 months, that they've deployed required technical safeguards — with an analysis by a qualified subject-matter expert — and would require business associates to notify covered entities within 24 hours of activating their contingency plans. We cover the status and details in HIPAA Security Rule proposed changes.

Whether or not that rule is finalized as proposed, the direction is clear: "they signed a BAA" is becoming the starting point of vendor oversight, not the end of it.

The bottom line

A business associate agreement is required for every vendor that creates, receives, maintains or transmits patient information for your practice. In IT terms, that almost always includes your managed IT provider, Microsoft 365 (whose BAA is built into its Data Protection Addendum), your backup service, your cloud EHR, your phone system if it stores voicemails or recordings, your e-fax and secure email vendors, and any patient messaging tools. Your internet provider usually doesn't need one; anyone who stores data does — encrypted or not.

Make a vendor list, collect the BAAs, read the incident-reporting and data-return terms, ask about subcontractors, and review it every year. Then remember the BAA is only the paperwork — the real protection comes from the safeguards on both sides. Our free HIPAA Security Self-Assessment can show you where else to look.

If you'd like help sorting out which of your vendors need agreements, or reviewing how your IT is set up for HIPAA, see how we work with healthcare practices — or book a free 20-minute call.