Business Associate Agreements

To meet the Business Associate Agreements requirement, you must execute and keep current BAAs for every third party that creates, receives, maintains, or transmits PHI on your behalf, and you must ensure each BAA clearly defines permitted PHI uses, required safeguards, breach notification duties, and subcontractor (downstream) controls ¹.

Key takeaways:

• Identify all PHI-touching third parties, then block PHI access until a compliant BAA is signed ¹.
• Standardize BAA terms around permitted uses, safeguards, breach notification, and subcontractor flow-downs ¹.
• Operate BAAs as a lifecycle control: inventory, execution, renewals, change triggers, and offboarding evidence.

“Business Associate Agreements requirement” is an operational control, not a paperwork exercise. HICP Practice 10.2 expects you to execute and maintain BAAs with all vendors that create, receive, maintain, or transmit PHI ¹. For a CCO or GRC lead, the fast path is: (1) map PHI data flows to third parties, (2) classify which relationships require a BAA, (3) enforce a contracting gate so PHI cannot be shared without an executed BAA, and (4) retain evidence that BAAs stay current as vendors, services, and subprocessors change.

In practice, most breakdowns happen in the seams: an “IT vendor” is onboarded by Procurement without Security review, a cloud support subcontractor is added without disclosure, or a scope change (new interface, new dataset, new environment) quietly turns a non-PHI vendor into a PHI vendor. This page is written to help you prevent those failures with a concrete workflow, decision points, and the evidence package auditors ask for. It’s requirement-level guidance designed to be implemented quickly, with minimal debate about who owns what.

Regulatory text

Requirement excerpt: “Execute and maintain Business Associate Agreements (BAAs) with all vendors who create, receive, maintain, or transmit PHI.” ¹

Operator meaning: You need (a) complete coverage (every PHI-touching third party has a BAA), and (b) lifecycle management (“maintain” means you track renewals, scope changes, and downstream subcontractors). HICP also highlights what the BAA must cover in plain terms: permitted uses, safeguard requirements, breach notification obligations, and subcontractor management provisions ¹.

Plain-English interpretation

A BAA is your enforceable contract mechanism to control how a third party can handle PHI and what they must do to protect it. The requirement is satisfied only if:

• You know which third parties touch PHI.
• You have a signed BAA in place before PHI is shared.
• The BAA includes the minimum terms called out by HICP: permitted uses, safeguards, breach notification, and subcontractor controls ¹.
• You can prove the BAA is current and still matches actual operations (services used, data exchanged, subcontractors engaged).

Who it applies to

Entity types: Healthcare Organizations and Health IT Vendors ¹.

Operational contexts where this shows up:

• SaaS platforms that store or process PHI (EHR add-ons, scheduling, billing, CRM with PHI fields).
• Managed services (IT support, help desk, hosting, backup, SOC services) where admins can access systems containing PHI.
• Data exchange vendors (interfaces, clearinghouses, analytics) that transmit PHI.
• Professional services that handle PHI datasets (consultants, auditors, legal support in certain workflows).

A useful operational rule: if a third party can access PHI “in the course of performing services,” treat it as BAA-candidate and force a formal classification decision before onboarding.

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

1) Build a PHI-touchpoint inventory (starting point: reality, not contracts)

Create or update a single list that ties together:

• Third party name and service.
• Systems connected (apps, SFTP, APIs, endpoints).
• Whether PHI is created/received/maintained/transmitted.
• Data path description (where PHI flows, where it rests).
• Business owner and technical owner.

Practical tip: Start with your highest-signal sources: EHR integration lists, identity provider application catalog, AP/GL vendor master, and network egress logs for known PHI systems. Your goal is coverage, then refinement.

2) Classify each third party: “BAA required” vs “not required,” with documented rationale

For each third party, record one of three outcomes:

• BAA required (PHI touch confirmed).
• Not required (no PHI touch), with a short rationale.
• Unknown (pending validation), which triggers a due diligence task to confirm data handling.

This classification record becomes a key audit artifact because it shows you are not guessing.

3) Standardize BAA content to the HICP minimums

Your template or negotiated BAA should explicitly address the elements HICP calls out ¹:

• Permitted uses and disclosures of PHI: Define what the third party is allowed to do with PHI, and prohibit unrelated use.
• Safeguard requirements: Require administrative, technical, and physical safeguards appropriate to the service. Tie safeguards to your risk process (for example, “consistent with your security requirements for PHI systems”).
• Breach notification obligations: Define notification triggers, escalation path, and cooperation duties.
• Subcontractor management (flow-down): Require the business associate to impose equivalent PHI protections on subcontractors that touch your PHI and to remain responsible for them.

Negotiation stance that works: Put non-negotiables into a short “BAA minimum requirements” exhibit. Let legal negotiate commercial points elsewhere, but keep these minimums fixed.

4) Put a contracting gate in front of PHI access

Write and enforce a simple rule: no BAA, no PHI. Operationalize it by integrating Security/Privacy review into:

• Procurement intake.
• Vendor onboarding in ITSM.
• Identity provisioning (no production access without compliance approval).
• Integration approvals (no PHI interface without BAA status = “executed”).

If your process allows “retroactive BAAs,” you will eventually miss one. Auditors know this pattern.

5) Maintain BAAs through change management

“Maintain” is where most programs fail. Add explicit triggers that force review of BAA scope and downstream exposure:

• New data elements added (a dataset becomes PHI-bearing).
• New integration method (API added, new file transfer path).
• Vendor adds a subprocessor that touches your PHI.
• Service moves environments (new hosting region, new cloud service, new support model).
• Renewal, termination, or acquisition (either party).

Tie these triggers to existing governance: change advisory board for systems, renewal workflow in Procurement, and vendor risk reassessments.

6) Offboard cleanly

When a PHI-touching relationship ends, you need evidence the third party no longer retains or can access your PHI, consistent with your agreement and operational requirements. At minimum, document:

• Account disablement and access revocation.
• Data return or destruction confirmation (as contractually required).
• Confirmation of subprocessors handling PHI during the term, if that was part of the service.

Required evidence and artifacts to retain

Auditors usually want “coverage, content, currency, and control.” Build a folder (or GRC record) per third party with:

1. Executed BAA (final signed copy) and any amendments/addenda.
2. BAA coverage register showing all PHI-touching third parties and BAA status.
3. PHI data flow record (system-to-vendor mapping, interface description).
4. BAA minimum requirements checklist showing the agreement includes: permitted uses, safeguards, breach notification, subcontractor provisions ¹.
5. Change/renewal evidence: renewal tickets, scope change approvals, subprocessor disclosures and your review decision.
6. Offboarding evidence: access termination confirmation and data disposition record.

If you use Daydream to manage third-party risk, treat the BAA as a first-class artifact linked to the vendor record, with lifecycle tasks for renewals, scope changes, and subprocessor reviews so “maintain” is provable without heroic spreadsheet work.

Common exam/audit questions and hangups

Expect questions that test completeness and operational discipline:

• “Show me your list of business associates and how you determined they handle PHI.”
• “Pick a random PHI vendor. Prove the BAA was signed before go-live.”
• “Where does this vendor store/transmit PHI? Who can access it?”
• “What contract language requires safeguards and breach notification?” ¹
• “How do you know subcontractors are covered?” ¹
• “What happens when a vendor’s service changes? Who re-evaluates BAA scope?”

Common hangup: teams can produce BAAs, but cannot prove coverage (that all PHI relationships are captured) or maintenance (that BAAs remain aligned to the current service).

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating “BAA signed” as the finish line

Avoidance: Put BAAs into a lifecycle workflow with owners, change triggers, and renewal/offboarding tasks.

Mistake 2: Missing “incidental” PHI access pathways

Support tools, log aggregation, remote administration, and ticket attachments can all become PHI vectors.
Avoidance: Ask, “Can the third party’s staff access systems containing PHI, even for support?” If yes, route through the BAA decision.

Mistake 3: No subprocessor visibility

A primary vendor may pass PHI to subcontractors.
Avoidance: Require and track subprocessor disclosures and flow-down obligations ¹.

Mistake 4: Inconsistent BAA terms across business units

Multiple templates create gaps in safeguards or breach notification.
Avoidance: Use one enterprise BAA standard plus controlled exceptions approved by Privacy and Security.

Mistake 5: Retroactive contracting after integration work begins

Avoidance: Enforce gating in procurement and identity/integration approvals so PHI cannot move until BAA execution is confirmed.

Enforcement context and risk implications

HICP frames BAAs inside third-party risk management because the operational risk is straightforward: a third party mishandling PHI can create breach response obligations, patient harm, and regulatory exposure. Even without citing specific public cases here, you should assume regulators and auditors will test two things: (1) whether you contracted for the minimum protections HICP describes, and (2) whether you run a process that prevents PHI sharing without those protections in place ¹.

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign a single accountable owner for BAA coverage (usually Privacy/Compliance) and a single workflow owner (often Vendor Management or GRC).
• Pull a candidate list of PHI-touching third parties from procurement, IT app catalogs, EHR integration lists, and managed service providers.
• Establish the “no BAA, no PHI” gating rule in procurement intake and integration approvals.
• Publish a one-page BAA minimum requirements checklist aligned to HICP: permitted uses, safeguards, breach notification, subcontractor provisions ¹.

Days 31–60 (Coverage and remediation)

• Complete classification for each third party: BAA required / not required / unknown.
• Triage gaps: prioritize active PHI flows without executed BAAs for contracting remediation or service suspension.
• Centralize executed BAAs and amendments in a controlled repository tied to vendor records.
• Implement an exception process for edge cases, with documented compensating controls and an expiration.

Days 61–90 (Maintenance and audit readiness)

• Add change triggers to vendor renewal, IT change management, and vendor risk reassessment workflows.
• Formalize subprocessor review tracking for PHI vendors and store disclosures with the vendor record ¹.
• Run an internal audit drill: sample a set of PHI vendors and prove coverage, execution-before-access, and current scope alignment.
• Operationalize dashboards: “PHI vendors without executed BAA,” “BAAs pending renewal,” and “vendors with unknown PHI status.”

Frequently Asked Questions

Do we need a BAA for a SaaS tool if we “don’t intend” to store PHI there?

If the tool creates, receives, maintains, or transmits PHI in practice, intent does not reduce the requirement. Classify based on actual data flow and access paths, then gate PHI sharing until the BAA is executed ¹.

What if a third party claims they never access PHI, but they provide admin support to a PHI system?

Administrative access creates a PHI exposure path even if they rarely view records. Treat it as PHI-touching unless you can prove technical controls prevent PHI access, and document the decision either way.

Can we accept a vendor’s “standard BAA”?

You can, but verify it covers the HICP minimums: permitted uses, safeguards, breach notification, and subcontractor controls ¹. Document your review and any negotiated amendments.

How do we handle subcontractors (downstream vendors) we don’t contract with directly?

Your BAA should require the business associate to bind subcontractors to equivalent PHI protections and remain accountable for them ¹. Operationally, require subprocessor disclosure and track approvals tied to scope changes.

What evidence is most persuasive in an audit?

Auditors respond well to a complete BA register tied to PHI data flows, executed BAAs stored centrally, and workflow evidence showing you block PHI access until execution. Add samples that show maintenance actions after service changes.

Our contracts renew automatically. How do we show we “maintain” BAAs?

Treat renewal and scope review as separate from commercial auto-renewal. Keep a recorded review outcome when services, integrations, or subprocessors change, and retain the current executed BAA version tied to the vendor record.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices