What should a HIPAA business associate agreement checklist include when an IT vendor handles PHI?
A practical HIPAA business associate agreement checklist should define what protected health information (PHI) the vendor can access, what safeguards it must maintain, how incidents are reported, how subcontractors are managed, how data is returned or destroyed at termination, and what evidence the covered entity can request to verify performance.12 HHS guidance makes this especially important when an IT vendor creates, receives, maintains, or transmits PHI for a covered entity, because the agreement is the written assurance that the vendor will safeguard that information.1 The checklist should help a healthcare organization compare IT vendors and MSPs before signing a contract, not just after a compliance problem shows up.
That matters because many BAAs are treated like procurement paperwork instead of risk-control documents. The agreement gets signed, filed away, and rarely revisited until there is a security incident, audit question, vendor transition, or disagreement about who was supposed to secure what. In practice, that is where the real trouble starts. If the agreement is vague about logging, backups, privileged access, breach notice timing, or subcontractor oversight, the healthcare organization may discover too late that the vendor relationship was never governed clearly enough.
At Datapath, we think a BAA should support the operating model, not just the legal file. If an IT vendor, cloud partner, security firm, backup provider, helpdesk operator, or MSP can create, receive, maintain, or transmit PHI on behalf of a healthcare organization, the agreement should make responsibilities clear enough that compliance, IT, and leadership all understand what is expected.13
Review HIPAA IT vendor risk before signing
Datapath helps healthcare teams evaluate IT provider scope, BAA expectations, admin access, logging, backup evidence, subcontractors, incident notice, and offboarding requirements.
When is a business associate agreement required for an IT vendor that handles PHI?
HHS guidance says a business associate relationship exists when a person or organization creates, receives, maintains, or transmits protected health information for a covered entity, or for another business associate, while performing a covered function or service.1 For IT service providers, that often means a BAA is required even when the vendor is not a clinical application vendor.
Use this routing table before procurement treats the HIPAA agreement as just another form.
| Vendor situation | Why the BAA question matters | Datapath review path |
|---|---|---|
| Vendor handles PHI directly | The vendor may store, transmit, support, restore, or investigate systems containing regulated data | HIPAA IT services |
| MSP or IT provider has admin access | Privileged access can expose email, files, endpoints, backups, identity, and logs even when support is indirect | Managed IT services |
| Backup, cloud, or disaster recovery vendor stores PHI | Return, destruction, restore testing, incident notice, encryption, and subcontractor obligations need to be explicit | Healthcare disaster recovery planning |
| Security or monitoring provider reviews PHI-adjacent logs | Alert data, screenshots, device telemetry, mailbox evidence, or forensic exports may contain PHI | Healthcare cybersecurity services |
| HIPAA agreement form for IT service providers | A generic form needs operational detail for admin access, remote tools, audit logs, backups, subcontractors, and offboarding | HIPAA IT services |
Can you use a HIPAA agreement form for IT service providers?
A HIPAA agreement form can be a useful starting point, but it should not be treated as the finished vendor control for an IT service provider. The form still needs to reflect the real service model: whether the vendor has standing admin access, which systems may contain PHI, which remote-support tools are used, how Microsoft 365 or EHR-adjacent logs are reviewed, how backups are protected, and how access is removed at termination.
For an MSP, the biggest risk is a form that sounds compliant but never answers operational questions. Before signing, the covered entity should confirm that the agreement and supporting evidence explain how the vendor will safeguard PHI, report security incidents, manage subcontractors, and prove that critical controls are working.
Why does the BAA matter so much for healthcare IT vendors?
Because the BAA is one of the main documents that turns HIPAA expectations into enforceable vendor obligations. HHS makes clear that a covered entity must obtain satisfactory assurances that a business associate will appropriately safeguard PHI, and the BAA is the mechanism used to document those assurances.12
That becomes especially important in IT relationships because healthcare vendors often touch more of the operating environment than leadership realizes. A managed service provider may have admin access to Microsoft 365, endpoints, servers, backup systems, network devices, ticketing tools, and remote-support platforms all at once. A cloud backup provider may store sensitive files. A helpdesk or monitoring platform may collect screenshots, logs, or emails containing PHI. A security vendor may analyze incident data pulled from production systems. Even if the vendor is not the clinical system owner, it may still be handling regulated information indirectly.
That is why we recommend evaluating BAAs alongside the broader healthcare IT operating model. If your team is reviewing support fit, accountability, or security posture more broadly, our healthcare solutions page, HIPAA IT compliance checklist, and HIPAA risk assessment checklist are good companion resources.
When does an IT vendor or MSP usually count as a business associate?
An IT vendor or MSP usually counts as a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate.12 The key issue is not whether the vendor thinks of itself as a healthcare company. The key issue is whether its services involve regulated information in a way HIPAA cares about.
Typical examples include:
- managed IT providers with administrative access to systems containing PHI
- cloud backup or disaster recovery providers storing regulated data
- security monitoring vendors reviewing logs, alerts, or device telemetry tied to PHI environments
- helpdesk and remote-support teams that can access user sessions, inboxes, files, or line-of-business systems
- hosted email, storage, or collaboration platforms where PHI may be created or maintained
- consultants supporting migrations, assessments, integrations, or incident response in healthcare environments
This is also where organizations get tripped up by assumptions. A vendor may say it is “not handling PHI directly,” but if its tools or staff can access environments where PHI lives, that distinction often collapses under scrutiny. The checklist should force both sides to define the real exposure clearly.
What should the checklist confirm before the agreement is signed?
Before signing a BAA, a healthcare organization should verify that the vendor relationship, data scope, and security responsibilities are described precisely enough to govern daily operations instead of just satisfying a legal minimum.
1. Is the scope of PHI access clearly defined?
The checklist should confirm:
- what categories of PHI the vendor may access
- whether access is routine, occasional, incidental, or emergency-only
- which systems, applications, data stores, backups, and devices are in scope
- whether the vendor stores PHI, transmits it, or only supports systems that contain it
- whether any offshore access, shared support queues, or third-party tooling are involved
A vague scope statement is one of the fastest ways to create hidden risk. If leadership cannot tell which systems and workflows are covered, then access reviews, logging, retention, and breach-response expectations will usually stay vague too.
2. Are security safeguards described in operational terms?
The BAA should not stop at generic language like “reasonable safeguards.” It should tie that expectation to the actual environment.24 The checklist should ask whether the vendor can explain and, when appropriate, evidence controls such as:
- multifactor authentication for privileged and remote access
- endpoint protection and patching practices
- encryption for data in transit and at rest where relevant
- backup protection and restore validation
- logging and monitoring for administrative actions
- role-based access and least-privilege administration
- workforce security awareness and access termination procedures
The point is not to force every BAA to read like a 40-page security standard. The point is to avoid a contract that says the vendor will protect PHI without defining what that means in the real operating environment.
3. Are subcontractor obligations explicit?
HIPAA requires business associates to ensure that subcontractors who create, receive, maintain, or transmit PHI on their behalf also agree to the same restrictions and conditions.12 The checklist should verify:
- whether the vendor uses subcontractors at all
- what kinds of subcontractors may touch systems or PHI
- whether downstream BAAs or equivalent agreements are required
- how subcontractor onboarding, review, and offboarding are handled
- whether the healthcare organization must be informed about material subcontractor changes
This matters because many vendors now rely on layered service delivery: cloud infrastructure, SOC tooling, outsourced helpdesk, contractors, and specialized engineering support. If subcontractor obligations are fuzzy, the risk expands faster than the covered entity can see.
4. Is breach and incident reporting specific enough?
A good checklist should require specificity around incident notification. HHS expects the business associate to report breaches of unsecured PHI and other security incidents as required by the agreement and applicable rules.13 The BAA should clarify:
- what counts as a reportable security incident
- how quickly the vendor must notify the covered entity
- which contact channels must be used
- what initial facts are required in the first notice
- how ongoing investigation updates will be handled
- whether forensic support, log access, and evidence preservation expectations are documented
We strongly prefer concrete notice timing over vague language like “without unreasonable delay” when the operational relationship is high trust and high access. For many IT vendor relationships, a 24-hour or even same-day notification expectation is more useful than language that sounds compliant but leaves too much room for interpretation.
5. Does the agreement define termination handling?
One of the most overlooked checklist items is what happens when the vendor relationship ends. The agreement should state how PHI will be returned or destroyed, when access will be removed, how retained copies are handled, and what exceptions apply if destruction is not feasible.12
The checklist should also ask:
- who owns the offboarding process
- how admin credentials, agents, backups, exports, and documentation are transferred
- whether retained logs or archives still contain PHI
- whether the vendor must certify destruction or return completion
- how long any post-termination obligations continue
This is especially important when replacing an MSP or cloud vendor. We have seen transitions get messy fast when the BAA says PHI will be returned or destroyed but the operational handoff plan was never built.
What should healthcare organizations ask the vendor to prove?
A BAA is still a contract, not a full audit. But the checklist should push the organization to gather enough evidence that the vendor’s obligations are credible. Depending on the relationship, that may include:
- security policy summaries or control overviews
- cyber liability or errors-and-omissions insurance details
- proof of MFA and privileged access practices
- backup and restore testing summaries
- incident-response plan excerpts or escalation process documentation
- independent assessment reports or attestations where available
- documentation of workforce training and access management practices
The right level of evidence depends on the risk of the relationship. A vendor with persistent administrative access to identity systems, endpoints, backups, and hosted data should be reviewed more deeply than a limited-scope consultant with temporary supervised access.
How should the checklist handle shared responsibility?
This is the part many teams skip. The BAA should not create the illusion that compliance can be outsourced completely. HIPAA responsibilities are often shared across the covered entity and the vendor, especially in IT environments.24
A practical checklist should identify who owns:
| Control area | Covered entity | Vendor / MSP |
|---|---|---|
| User authorization and business approval | Usually primary owner | Supports implementation |
| Technical administration and secure configuration | Shared | Often primary executor |
| Endpoint monitoring and patching | Shared | Often primary executor if managed |
| Backup oversight and restore testing | Shared | Shared |
| Incident escalation to leadership and legal | Primary owner | Supports and reports |
| Patient, regulator, or partner communications | Primary owner | Provides facts and evidence |
| Subcontractor oversight in vendor chain | Review responsibility | Primary owner |
This kind of responsibility mapping prevents the common failure mode where both sides assume the other one is handling the control.
What are the biggest red flags in a weak BAA?
The most common warning signs are not subtle. We would treat these as red flags:
- the agreement does not clearly define PHI exposure or in-scope systems
- breach reporting language is vague or slow
- subcontractor handling is missing or glossed over
- security obligations are purely generic and unsupported by evidence
- termination and data-return language is incomplete
- the vendor resists clarifying admin access, logging, or backup responsibilities
- the covered entity is expected to accept broad liability limitations without meaningful operational commitments
A weak BAA usually reflects a weak governance model. Even if the vendor is technically capable, unclear obligations make disputes and delays much more likely during an incident.
What is the real goal of the checklist?
The goal is not just to sign a HIPAA document. The goal is to create a vendor relationship that is governable under pressure. A strong HIPAA business associate agreement checklist helps healthcare organizations compare vendors more carefully, define security and compliance expectations earlier, and reduce the chance that a contract gap becomes an operational problem later.
For healthcare leaders, that means the checklist should support better decisions around access, evidence, accountability, and offboarding. If a vendor is going to touch regulated systems, you want more than a signature. You want enough clarity that both sides know how the relationship is supposed to work when everything is normal and when something goes wrong.
If your organization is evaluating healthcare IT support partners more broadly, start with our healthcare IT solutions page, explore our HIPAA technical safeguards checklist for medical practices, and review our HIPAA disaster recovery requirements guide for the controls that often sit adjacent to BAA risk.
Frequently Asked Questions
When does HHS require a HIPAA business associate agreement for an IT vendor handling PHI?
HHS guidance says a business associate relationship exists when a vendor creates, receives, maintains, or transmits PHI for a covered entity, or for another business associate. In that situation, the relationship usually needs a BAA that defines permitted uses, safeguards, reporting, subcontractor handling, and return or destruction obligations.12
What should a HIPAA agreement for IT service providers include?
A HIPAA agreement for IT service providers should define PHI scope, systems in scope, permitted uses, MFA and access controls, logging, backup and restore responsibilities, breach or security-incident notice, subcontractor obligations, termination handling, evidence expectations, and who owns remediation when gaps appear.
Is a HIPAA agreement form for IT service providers enough for an MSP?
A generic HIPAA agreement form is rarely enough by itself for an MSP. The form should be adapted to the actual support model, admin access, Microsoft 365 responsibilities, backup scope, remote-support tools, subcontractors, logging, incident response, and offboarding requirements.
Should a covered entity review IT vendor evidence before signing a BAA?
Yes. The covered entity should ask for enough evidence to understand whether the vendor can actually meet the agreement. That may include MFA practices, access-control workflows, incident-response procedures, backup and restore summaries, subcontractor controls, insurance details, and reporting samples.
Sources
- HHS: Business Associates
- 45 CFR § 164.504(e) — Business associate contracts
- HHS: Summary of the HIPAA Security Rule
- HHS: Guidance on Risk Analysis Requirements under the HIPAA Security Rule
