Your managed service provider has domain administrator credentials on every workstation in the building. They can open any chart, restore any backup, and read any mailbox — and most days they do none of that. But the access exists, which means a BAA for an IT vendor is not optional paperwork. It is the contract that makes their access lawful under 45 CFR 164.502(e) and defines what happens when their tooling gets compromised.

This article is for the person who signs that contract: the practice administrator, the privacy officer, the compliance lead. Below is what the agreement must contain, who signs and when, how the breach clock actually runs, and what your file needs to look like when someone asks for it.

Does Your IT Vendor Need a BAA? The Short Answer

Yes, if the vendor creates, receives, maintains, or transmits protected health information on your behalf — including if they merely have persistent access to systems that hold PHI, even when they never intentionally view it. HHS has been explicit that a vendor maintaining PHI counts as a business associate regardless of whether the data is encrypted or whether the vendor actually looks at it.

Vendors that almost always need a BAA:

  • Managed service providers with remote monitoring and management (RMM) agents on your endpoints
  • Break/fix shops that image drives, handle failed workstations, or take equipment offsite
  • Cloud hosting, virtual desktop, and backup providers
  • Email and secure messaging platforms
  • Help desk providers who screen-share into clinical applications
  • Anyone administering your firewall, VPN, identity provider, or endpoint detection tool

Vendors that generally do not, under the narrow conduit exception: your ISP moving encrypted packets, and the postal service. HHS limits that exception to entities that transport information without persistent access — a distinction the HHS cloud computing guidance spells out. A cloud provider that stores your data is a business associate. A router that forwards it is not.

The "We Don't Touch PHI" Objection

You will hear this from IT vendors. It is almost never accurate. If the technician can elevate to local admin on a workstation running your practice management software, they can access PHI. Capability, not intent, is what triggers the requirement. Ask the vendor one question: can any of your staff, using tools you control, reach a system where PHI lives? If the honest answer is yes, you need a BAA for that IT vendor before their agent gets installed.

Nine Clauses Your BAA for an IT Vendor Must Contain

The HHS sample business associate agreement provisions are the baseline. They are a floor, not a ceiling, and they were written generically. Here is what the agreement needs when the counterparty is an IT firm specifically.

  1. Permitted uses and disclosures, scoped tightly. "For the purpose of providing information technology support services" is fine. "For any lawful business purpose" is not. Watch for clauses letting the vendor use de-identified data or aggregate telemetry — decide deliberately, don't inherit it.
  2. Full Security Rule obligations. Business associates are directly liable for the administrative, physical, and technical safeguards under 45 CFR Part 164 Subpart C. Say so in the contract and require they maintain their own risk analysis and written policies.
  3. Breach and security incident notification with a defined clock. Covered below.
  4. Subcontractor flow-down. Your MSP almost certainly uses a third-party RMM platform, an offsite backup provider, and possibly an overseas NOC. Require written BAAs down the chain and the right to request the vendor list.
  5. Individual rights support. If the vendor holds a designated record set — say they host your imaging archive — the BAA must obligate them to support access and amendment requests within your timeline, not theirs.
  6. Access for HHS. Books, records, and practices available to the Secretary. Non-negotiable.
  7. Return or destruction on termination. Required by 164.504(e)(2)(ii)(J). Specify format, deadline, and a written certificate of destruction. IT vendors hold backups, and backups outlive contracts.
  8. Termination for material breach. You need the right to cure-or-terminate. Include it even when the underlying MSA has its own termination language.
  9. Minimum necessary and access controls. Named accounts per technician, no shared credentials, MFA on all remote access, and logging you can request.

Two clauses to negotiate hard: liability caps and indemnification. A cap set at three months of fees is common in MSP contracts and is wildly disproportionate to breach response costs. Push for a carve-out for breaches caused by the vendor's negligence.

If your vendor hands you a two-page BAA that omits half of this, or if you are the one who has to produce the document, you can generate a signature-ready Business Associate Agreement through a six-step wizard and export it as PDF or DOCX. One-time purchase, no subscription — useful when you need a clean baseline to redline against instead of accepting whatever the vendor's template says.

The Breach Clock, in Actual Days

Under the Breach Notification Rule, a business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery. That is the regulatory outer limit. It is a terrible contractual number for you.

Here is why. Your practice must notify affected individuals within 60 days of discovery. If the vendor uses their full 60 days, your notification is already late on the day you learn about it. OCR has treated the covered entity's clock as starting at the business associate's discovery when the associate acts as your agent.

Negotiate the notification window down:

  • Security incidents (unsuccessful attempts, anomalies): reported in a monthly or quarterly summary. Do not require individual notice of every blocked port scan; you will drown.
  • Suspected breach of unsecured PHI: 24 to 72 hours from discovery, in writing.
  • Confirmed breach with identified individuals: 5 business days, including the elements you need for your own notice — the date of the incident, the date of discovery, the categories of PHI involved, and what the vendor is doing about it.
  • Ransomware affecting your data: immediate telephone notice plus written confirmation within 24 hours.

Also write in cooperation obligations: the vendor participates in your risk assessment under 164.402, provides forensic findings, and does not unilaterally decide that an incident is "low probability of compromise." That determination is yours to document.

A Worked Example: Onboarding a New MSP in 14 Days

You have signed a letter of intent with a new IT firm. Here is a sequence that produces both a working relationship and a defensible file.

Days 1–3. Send your BAA template, not theirs. Request their most recent SOC 2 Type II report or equivalent third-party assessment, their HIPAA security policies, evidence of workforce HIPAA training, and their subcontractor list. Assign this to one named person — usually the privacy officer — and log the request date.

Days 4–8. Redline. Expect pushback on notification timelines and liability. Document what you conceded and why; a short memo in the vendor file saying "agreed to 10 business days because vendor's forensic partner requires it, offset by expanded indemnity" is exactly the kind of reasoning OCR wants to see.

Days 9–11. Both parties sign. The BAA must be fully executed before the vendor's RMM agent touches a single endpoint. This is the single most common failure in the entire process — technical onboarding races ahead of contract execution because the practice needs the help now.

Days 12–14. Provision named accounts with MFA. Record the account inventory. Update your risk analysis to reflect the new access path, and add the vendor to your business associate register with the execution date, renewal date, and the name of the person who owns the relationship.

What Goes in the Vendor File

  • Fully executed BAA, signed by authorized representatives of both parties, with dates
  • The underlying service agreement or SOW showing scope of access
  • Security documentation received (assessment report, policy summary, training attestation)
  • Subcontractor list and confirmation of downstream BAAs
  • Account provisioning record: who has access, at what privilege level, since when
  • Annual review note — date reviewed, by whom, changes identified

Where Practices Get Caught

OCR enforcement history is instructive here. North Memorial Health Care settled for $1,550,000 in 2016 after PHI was breached at a contractor operating without an executed business associate agreement. In 2018, Advanced Care Hospitalists paid $500,000 following an incident tied to a billing vendor engaged without a BAA in place. The pattern is consistent: the missing contract is what turns an incident into a finding. You can review resolution agreements and the breach portal at the HHS Office for Civil Rights breach reporting portal.

The three failure modes I see most often in practices:

The inherited vendor. The IT firm has supported the practice since 2014. Nobody remembers signing anything. There may be a BAA in a drawer that references the pre-2013 Omnibus Rule and lacks subcontractor and direct-liability language. Re-paper it.

The one-line acknowledgment. A clause in the MSA reading "Vendor agrees to comply with HIPAA" is not a BAA. It contains none of the required elements at 164.504(e). Auditors read the whole document.

The signed-and-forgotten agreement. The BAA exists. Nobody has looked at it since 2019. Meanwhile the vendor migrated your backups to a new cloud platform and added an offshore help desk. Your subcontractor flow-down clause requires notice; nobody asked, nobody told.

What's Coming, and How to Prepare

HHS published a proposed update to the HIPAA Security Rule in January 2025. Among the proposals: annual written verification from business associates that they have deployed required technical safeguards, and tighter timelines for notifying covered entities when contingency plans activate. The rule is not final as of December 2025 — do not represent it to your vendors as a current requirement. But if you are papering a multi-year MSP contract today, a clause requiring annual security attestation costs you nothing now and saves a renegotiation later.

The other groundwork worth doing: keep your risk analysis current. NIST's SP 800-66 Revision 2 maps Security Rule requirements to practical controls and is the reference most assessors reach for. Vendor access paths belong in that analysis explicitly — each remote access channel, each account, each data flow.

Your Next Step

Pull your vendor list this week. For every entity with technical access to a system holding PHI, confirm three things: an executed BAA exists, it names the current legal entity, and it contains all nine clauses above. Anything that fails, fix before the next incident makes it urgent.

If you need clean agreements to send out, you can build a signature-ready BAA for an IT vendor in about ten minutes and export it in PDF or DOCX for signature. If the gap is broader — missing risk analysis, stale policies, no documented safeguards — automated HIPAA risk analysis and policy generation will close more ground faster than rebuilding the document set by hand.