Business Associate Contracts and Other Arrangements

This requirement is simple to state and easy to fail in real operations: if a third party meets the definition of a HIPAA business associate and will touch ePHI on your behalf, you must obtain satisfactory assurances that the business associate will safeguard that ePHI before you allow access. (45 CFR Parts 160, 162, 164)

For a Compliance Officer, CCO, or GRC lead, the work is not debating whether you “have BAAs.” The work is building an intake-to-access workflow that forces the right result every time: identify business associate relationships early, route them to the right contract template and approval path, block provisioning until assurances are executed, and retain evidence that proves the gate operated.

This page is written to help you operationalize that gate quickly. It breaks down who the requirement applies to, the minimum process steps to make it real, what artifacts auditors ask for, common failure modes (shadow IT, “free trials,” and affiliates), and a practical execution plan you can run with your legal, procurement, security, and IT teams.

Regulatory text

Requirement (operator view): A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a), that the business associate will appropriately safeguard the information. (45 CFR Parts 160, 162, 164)

What that means in practice:
You must implement a control that prevents any business associate from touching ePHI until you have documented assurances on file. A signed contract is the common mechanism, but the regulatory obligation is broader than “get a signature.” You need a repeatable method to (1) identify business associate relationships, (2) obtain and approve assurances, and (3) enforce the no-access-before-assurances rule consistently. (45 CFR Parts 160, 162, 164)

Plain-English interpretation

If a third party will handle ePHI for you (storage, processing, support, analytics, billing platforms that touch ePHI, managed services, certain consultants), you cannot “turn them on” and hope for the best. You must get written assurances that they will safeguard the ePHI and keep those assurances tied to the relationship.

A regulator or auditor will look for two things:

1. Design: Do you have a defined method to obtain satisfactory assurances for business associates?
2. Operating effectiveness: Can you prove you followed it for real third parties, including the messy ones (urgent onboarding, departmental purchases, trials, acquisitions, and legacy agreements)?

Who it applies to

In-scope entities

• Covered entities under HIPAA. (45 CFR Parts 160, 162, 164)

In-scope operational contexts

This requirement triggers when:

• A third party qualifies as a business associate; and
• The third party will create, receive, maintain, or transmit ePHI on the covered entity’s behalf. (45 CFR Parts 160, 162, 164)

Common examples in real programs:

• Cloud hosting, backup, DR, managed SOC services that ingest logs containing ePHI
• EHR/PM add-ons, integration platforms, transcription, call-center services
• MSPs, desktop support, and consultants with remote access to systems containing ePHI
• Data analytics platforms where ePHI is uploaded or accessible via API

Edge cases that usually cause findings:

• “Incidental” access via support tools or screen sharing
• SFTP drops, shared mailboxes, or ticket attachments that include ePHI
• M&A inherited third parties whose contracts were never reviewed

What you actually need to do (step-by-step)

Treat this as an access gate backed by procurement and IT controls.

1) Build and maintain a business associate inventory (BA register)

Goal: One list that answers: who are the business associates, what systems/data do they touch, and what “assurance” artifact covers them.

Minimum fields to capture:

• Legal name, DBA, and contracting entity
• Service description and business owner
• ePHI touchpoints (create/receive/maintain/transmit) and where ePHI resides
• Access method (VPN, SSO, API, file transfer, support access)
• Assurance artifact reference (executed agreement ID; effective date; renewal date)
• Subcontractor/4th party notes if relevant to the service delivery model

2) Implement an intake triage that identifies business associates early

Goal: Catch BA relationships before contracts are signed or access is provisioned.

Practical triage questions (use in procurement, security review, and IT intake forms):

• Will the third party access or store any data related to patient care, billing, scheduling, clinical notes, or identifiers?
• Will they have admin access to systems that store ePHI?
• Will they receive attachments, exports, or logs that may include ePHI?
• Is the third party performing a function “on behalf of” the covered entity that involves ePHI?

If “yes” or “maybe,” route to the BA contracting path. The control objective is conservative: uncertainty should slow onboarding until clarified.

3) Standardize “satisfactory assurances” as contractable requirements

Goal: Convert “satisfactory assurances” into consistent contract language and approval criteria that you can apply at scale. (45 CFR Parts 160, 162, 164)

Operationalize by creating:

• A Business Associate Agreement (BAA) template (or BAA addendum) owned by Legal with Security/Privacy input
• A fallback playbook for third-party paper: what clauses are required vs. negotiable, and who can accept deviations

Even if Legal owns drafting, Compliance should own the control definition: what must be present for the assurances to be “satisfactory” for your risk posture.

4) Gate access and data sharing on executed assurances

Goal: Make it hard to bypass.

Controls that work in practice:

• Procurement rule: no PO, no contract signature, no renewal without confirming the BAA/assurance is executed and indexed to the BA register.
• IT rule: no account provisioning (SSO app, VPN, API key, shared mailbox access) until the BA register shows “assurances complete.”
• Data-sharing rule: no file transfer credentials, no SFTP folders, no shared drives until approved.

This is where many programs fail: they “have BAAs,” but access is provisioned first and paperwork follows later. The regulatory text prohibits that ordering. (45 CFR Parts 160, 162, 164)

5) Operationalize renewals, changes, and offboarding

Assurances can go stale operationally if the service changes.

Define triggers that require re-review:

• Scope expansion (new product module, new interface, new dataset)
• New access path (API added, privileged access granted, offshore support)
• Material incident or control concerns
• Renewal events where contract terms may have changed

For offboarding:

• Confirm access revocation
• Confirm data return/destruction terms were executed as agreed
• Update BA register status and retain closure evidence

6) Align with your Security Rule administrative safeguards program

This requirement lives in the Security Rule’s administrative safeguards area, so it should connect to:

• Third-party risk management intake
• Security review checkpoints for systems with ePHI
• Incident response expectations for third parties that touch ePHI
• Documentation and retention practices that show governance (45 CFR Parts 160, 162, 164)

Where Daydream fits (practical, not theoretical)

If you are tracking BAAs in email threads and spreadsheets, the gate will eventually fail. Daydream can act as the system of record for your BA register, store executed assurance artifacts, and drive an intake workflow that blocks onboarding tasks until the “satisfactory assurances” checkpoint is complete.

Required evidence and artifacts to retain

Keep artifacts that prove both coverage (you identified the BA) and control operation (you obtained assurances before access).

Recommended evidence set:

• Current BA register (exportable)
• Executed BAA/assurance documents (signed versions) mapped to each BA
• Intake records showing triage decisions (BA vs. not BA) and approver
• Access provisioning records showing timing (assurances completed before access)
• Contract exception log (if you allow deviations) with risk acceptance approvals
• Renewal/change management records (scope changes, re-reviews)
• Offboarding checklist completion (access removed; data disposition confirmed)

Common exam/audit questions and hangups

Expect questions like:

• “Show me your list of business associates and the executed assurances for each.”
• “How do you ensure no business associate gets access to ePHI before the agreement is executed?”
• “How do you handle ‘urgent’ onboarding requests?”
• “How do you identify business associates purchased outside procurement (department card spend, trials)?”
• “What happens when the service changes and starts ingesting ePHI?”

Hangups that stall teams:

• Disagreement on whether a third party is a BA
• Legal negotiation timelines conflicting with operational urgency
• Lack of a single system of record for BA relationships and contract status

Frequent implementation mistakes and how to avoid them

Mistake: Treating “BAA on file somewhere” as compliance

Fix: Tie every BA to a specific executed assurance artifact in the BA register, and make that field required before access.

Mistake: Allowing access while “contracting is in progress”

Fix: Implement a hard gate in provisioning and procurement workflows. Escalate exceptions to a formal risk acceptance that is time-bound and documented.

Mistake: Missing BAs created through shadow IT

Fix: Add BA triage to AP/vendor onboarding, expense review for software subscriptions, and identity governance (new SSO apps require a BA check if they handle sensitive data).

Mistake: Not revisiting assurances after scope changes

Fix: Define explicit re-review triggers and enforce them in your change management and renewal processes.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this page, so this guidance stays anchored to the regulatory text and operational exam expectations. (45 CFR Parts 160, 162, 164)

Risk implications to communicate internally:

• Without satisfactory assurances, you have an ungoverned ePHI pathway. That increases breach likelihood, complicates incident response, and creates defensibility problems during audits and investigations.
• If you cannot prove the ordering (assurances first, access second), the program looks performative even if the third party has strong security.

Practical 30/60/90-day execution plan

First phase (Immediate)

• Stand up a BA register with required fields and owners.
• Freeze new BA onboarding that involves ePHI until an assurance artifact is executed and indexed.
• Publish a one-page intake decision tree for “Is this third party a business associate?”

Second phase (Near-term)

• Implement procurement and IT gating checkpoints tied to the BA register status.
• Standardize templates: BAA/addendum language and an exception playbook.
• Backfill: identify existing third parties with potential ePHI access, prioritize by access type (privileged access, hosted storage, integrations).

Third phase (Ongoing)

• Build renewal and change triggers into contract management and service owner processes.
• Run periodic BA register reconciliations against SSO app catalog, AP vendor lists, and system access logs for ePHI systems.
• Test control operation: sample a set of BAs and verify evidence shows assurances before access.

Frequently Asked Questions

Do we need a BAA for every third party we work with?

You need satisfactory assurances for third parties that are business associates and will create, receive, maintain, or transmit ePHI on your behalf. (45 CFR Parts 160, 162, 164) Not every third party relationship meets that standard, so your intake triage must make and document the call.

What counts as “satisfactory assurances” under this requirement?

The Security Rule requires satisfactory assurances in accordance with the HIPAA business associate contract requirements referenced in the regulatory text. (45 CFR Parts 160, 162, 164) Operationally, treat it as executed contractual obligations that you can produce on request and that you consistently require before access.

Can we provision access while Legal negotiates the BAA if the project is urgent?

The requirement prohibits permitting the business associate to handle ePHI until assurances are obtained. (45 CFR Parts 160, 162, 164) If the business insists, route it through a documented exception path that blocks ePHI exposure (for example, de-identified data only) until execution.

How do we handle “free trials” or click-through SaaS tools that might touch ePHI?

Put trials through the same intake triage and block ePHI use until assurances are executed. The easiest operational rule is: no ePHI in tools that are not in your approved catalog with a recorded assurance artifact.

What evidence will an auditor accept to prove we didn’t allow access before assurances?

Keep the executed agreement and a record of the access provisioning date that shows provisioning occurred after execution. Pair that with your BA register entry and the intake approval record to show the control operated end-to-end.

We inherited vendors after an acquisition. Are we immediately noncompliant?

The requirement still applies to covered entities and business associates handling ePHI. (45 CFR Parts 160, 162, 164) Treat post-acquisition as a remediation project: inventory inherited third parties, identify which are business associates, then obtain and index assurances while controlling access paths.