HIPAA Business Associate Agreement: What Providers Must Know

A signed HIPAA business associate agreement (BAA) is required before you share protected health information (PHI) with any vendor that creates, receives, maintains, or transmits that PHI on your behalf. No exceptions, no grace periods. HHS defines a business associate as any person or entity outside your workforce that performs functions or services involving access to PHI — and requires satisfactory written assurances before that PHI flows.

Three contract elements must appear in every BAA:

• Permitted uses and disclosures: The agreement must specify exactly what the vendor is authorized to do with your PHI and prohibit any use beyond that scope.
• Safeguards and breach reporting: The vendor must implement appropriate technical, administrative, and physical safeguards and report any breach or security incident to you without unreasonable delay.
• Downstream flow-down and return/destruction: Subcontractors who touch PHI must sign their own BAAs, and all PHI must be returned or destroyed when the relationship ends.

Your immediate action: inventory every vendor your organization uses, flag those that touch PHI in any form, and confirm a current signed BAA is on file before any PHI flows to them. That three-step sequence — inventory, classify, execute — is the foundation of every compliant vendor contracting program.

Table of Contents

• Who counts as a business associate, and when do you need a BAA?
• What clauses does HHS require in a BAA?
• Where to find the HHS model BAA and how to adapt it
• What happens when your vendors subcontract?
• What are the breach reporting obligations under a BAA?
• Common failures that trigger OCR enforcement
• How to draft, negotiate, sign, and manage a BAA
• How an MSP should operationalize BAA obligations
• Key Takeaways
• The case for treating BAA compliance as an operational discipline, not a legal formality
• Securetechie helps healthcare organizations close BAA gaps fast
• Useful sources and model BAA resources

Who counts as a business associate, and when do you need a BAA?

The single test is straightforward: does this vendor create, receive, maintain, or transmit PHI on your behalf? If yes, you need a BAA. HHS guidance draws a clear line between covered entities (health plans, healthcare clearinghouses, and most healthcare providers) and business associates (the outside vendors those entities rely on to do their work).

Vendors that almost always require a BAA

The following categories routinely require BAAs because they access, store, or process PHI as a core part of their service:

• Electronic health record (EHR) platforms and practice management software
• Medical billing and coding companies
• Cloud storage and data hosting providers
• Telehealth platforms and remote patient monitoring vendors
• IT support and managed service providers (MSPs) with access to clinical systems
• Medical transcription services
• Shredding and document destruction companies that handle paper records
• Legal, accounting, or consulting firms that review PHI in the course of their work

The conduit exception and why it is narrower than most people think

A true conduit — a courier delivering sealed envelopes, a postal service, or an internet service provider (ISP) transmitting encrypted packets — does not require a BAA because it has only transient, incidental access to PHI and no ability to retain or use it. HIPAA Journal notes that ISPs and couriers are the clearest examples of genuine conduits, while MSPs and cloud services almost never qualify because they retain persistent access to the data they manage.

Cloud providers and email platforms are the most common misclassification. A cloud storage service that can read, index, or restore your files has persistent access to PHI. That is a business associate relationship, not a conduit. MedComply confirms that cloud providers and email services usually retain this kind of access and therefore require BAAs, not conduit exemptions.

Janitorial staff who clean server rooms without accessing systems, or electricians who work in a data center without touching equipment, generally do not require BAAs because they have no PHI access at all. The distinction is access, not physical proximity.

Pro Tip: When in doubt, treat the vendor as a business associate until you can confirm they truly are a conduit or never encounter PHI. Build a short verification checklist: (1) Does the vendor have any access to systems containing PHI? (2) Could they retrieve, read, or copy PHI in the course of their work? (3) Do they retain any PHI after the service is delivered? A "yes" to any of these means you need a BAA.

One more nuance worth knowing: over-executing BAAs creates its own problems. Asking every minor vendor to sign one generates unnecessary management overhead and can create legal exposure where none existed. Focus BAA requirements on vendors that genuinely create, receive, maintain, or transmit PHI.

What clauses does HHS require in a BAA?

The mandatory provisions come from 45 CFR 164.504(e), and HHS publishes sample language you can use as a starting point. Every BAA must address the following elements, each of which maps to a concrete operational obligation.

Sample clause language you can adapt

Permitted uses: "Business Associate may use or disclose PHI only as reasonably necessary to provide the services described in the Agreement and as otherwise permitted by this BAA or required by law. Business Associate shall not use or disclose PHI for any purpose not authorized herein, including but not limited to marketing, research, or sale of data."

Breach notification: "Business Associate shall report to Covered Entity any Breach of Unsecured PHI without unreasonable delay and in no case later than sixty (60) calendar days after discovery of the Breach, including the identification of each individual whose PHI has been, or is reasonably believed to have been, accessed, acquired, used, or disclosed."

Subcontractor flow-down: "Business Associate shall ensure that any subcontractor that creates, receives, maintains, or transmits PHI on behalf of Business Associate agrees to the same restrictions, conditions, and requirements that apply to Business Associate under this BAA."

The minimum necessary principle deserves explicit language in your BAA. Compliance professionals recommend contract language that prevents vendors from repurposing PHI for secondary uses such as research or marketing without explicit written permission. A clause that limits the vendor to "the minimum necessary PHI to carry out the intended purpose" closes that gap and simplifies audits.

A signed BAA is a contractual assurance, not a compliance certificate. HHS is explicit: if you learn of a material breach by a business associate, you must attempt to cure it or terminate the contract. If termination is not feasible, you must report the problem to OCR. Signing the agreement and filing it away is not enough.

Where to find the HHS model BAA and how to adapt it

HHS publishes a model business associate agreement that covers all required provisions under HIPAA and the HITECH Act. It is the safest starting point for any covered entity drafting a BAA from scratch, because it reflects OCR's current interpretation of the regulatory requirements.

The model BAA covers: definitions (PHI, unsecured PHI, Security Rule, HITECH Act), permitted uses and disclosures, safeguard obligations, breach reporting, patient rights support, subcontractor flow-down, data ownership, term and termination (including the 30-day cure period), and HITECH Act compliance obligations. It also includes a provision confirming that the business associate's data stewardship does not confer data ownership rights over the PHI shared with it.

How to adapt the model for different vendor types

The model is a template, not a finished contract. Customize these fields for each vendor relationship:

• Scope of PHI: Name the specific data elements and systems involved. A billing company needs different access than a cloud backup provider.
• Allowed purposes: List the permitted uses explicitly. For an MSP, that might be system administration, monitoring, and incident response — not analytics or product development.
• Security controls required: Specify encryption standards (AES-256 at rest, TLS 1.2+ in transit), multi-factor authentication, and logging requirements. Generic "appropriate safeguards" language is harder to enforce.
• Incident response SLAs: Define the timeline for initial notification (24–72 hours for a security incident, 60 days maximum for a confirmed breach) and the format of the breach report.
• Audit rights: Include the right to request SOC 2 reports, penetration-test summaries, or configuration attestations at least annually.
• Indemnity and insurance: Specify minimum cyber liability coverage and whether the vendor indemnifies you for breaches caused by their failure to comply.

Pro Tip: When a cloud provider offers a BAA, confirm it covers only the specific paid tier and services you actually use. Free consumer accounts are not covered and must never be used for PHI. Ask the vendor for a written list of in-scope services and verify that your configuration matches what the BAA protects.

For billing companies, the permitted-use clause should explicitly exclude the vendor from using PHI for their own analytics or benchmarking. For MSPs, the safeguards clause should reference specific technical controls: endpoint detection and response (EDR), privileged access management, and documented patch management cycles. The model BAA's generic language is a floor, not a ceiling.

What happens when your vendors subcontract?

The downstream obligation is one of the most frequently overlooked requirements in HIPAA compliance. Under HITECH and HIPAA rules, a subcontractor that creates, receives, maintains, or transmits PHI on behalf of a business associate becomes a business associate itself and must sign a BAA. Your vendor's vendor is your problem too.

This matters practically because modern IT and healthcare services rely heavily on subcontractor chains. A billing company may use an offshore coding team. A cloud storage provider may use third-party data centers. An MSP may rely on a remote monitoring platform hosted by a separate vendor. Each link in that chain that touches PHI requires its own BAA.

What to verify in a vendor's subcontractor management program

During vendor onboarding, request and review the following:

• Subprocessor list: A current, written list of all subcontractors that access or process PHI, including their location and the nature of their access.
• Evidence of downstream BAAs: Confirmation (not just a verbal assurance) that the vendor has executed BAAs with each PHI-touching subcontractor.
• Change-notice procedures: A contractual commitment to notify you before adding or replacing a subcontractor that will access PHI, with a defined notice period (typically 30 days).
• SOC 2 Type II report or equivalent: Third-party attestation that the vendor's controls (and ideally its subcontractors' controls) meet security and availability standards.
• Training records: Evidence that the vendor's staff and relevant subcontractor personnel have completed HIPAA training.
• Incident logs: A summary of security incidents in the prior 12 months, including any that involved PHI.

Request these documents before PHI flows, not after. A vendor that cannot produce a subprocessor list or evidence of downstream BAAs during procurement is a material compliance risk regardless of how well-written their own BAA is.

Sample wording to include in your BAA: "Business Associate shall maintain a current list of all subcontractors that create, receive, maintain, or transmit PHI on Business Associate's behalf and shall provide that list to Covered Entity upon request. Business Associate shall provide Covered Entity with at least thirty (30) days' prior written notice before engaging any new subcontractor that will have access to PHI."

What are the breach reporting obligations under a BAA?

Business associates must report breaches of unsecured PHI to the covered entity without unreasonable delay and no later than 60 days after the breach is discovered. That 60-day window is a ceiling, not a target. Most well-drafted BAAs and good-faith compliance programs aim for initial notification within 24–72 hours of discovery, with a full written report to follow.

The steps a covered entity and business associate should follow after a breach are:

1. Preserve evidence. The BA must secure logs, system snapshots, and access records immediately. Deleting or overwriting evidence, even unintentionally, complicates OCR investigations.
2. Isolate affected systems. Contain the incident to prevent further unauthorized access or disclosure. This may mean taking systems offline or revoking credentials.
3. Assess the scope. Identify which individuals' PHI was accessed, acquired, used, or disclosed, and what data elements were involved.
4. Notify the covered entity. The BA provides written notice including: the date of the breach, the date of discovery, a description of what happened, the PHI involved, and the individuals affected.
5. Covered entity notifies affected individuals. The covered entity (not the BA) is responsible for notifying affected patients and, for breaches involving 500 or more individuals in a state, notifying prominent media outlets.
6. Submit the OCR breach report. Breaches affecting 500 or more individuals must be reported to OCR within 60 days of discovery. Smaller breaches may be reported annually.

The covered entity's cooperative obligations during an OCR investigation include making records available to HHS, supporting audits, and providing documentation of corrective actions taken. If the BA caused the breach, the covered entity must take reasonable steps to cure the breach or terminate the contract. If termination is not feasible, OCR must be notified.

A practical incident response plan should be in place before a breach occurs, not drafted in response to one. The plan should assign roles, define escalation paths, and include pre-drafted notification templates that can be customized quickly.

Note on the 60-day rule: The 60-day period runs from the date the breach was discovered, not the date it occurred. A BA that discovers a breach on day one and waits 59 days to notify the covered entity has technically complied with the letter of the rule but has likely violated the "without unreasonable delay" standard. OCR has cited delayed notification as an aggravating factor in enforcement actions.

Common failures that trigger OCR enforcement

Most HIPAA enforcement actions involving BAAs trace back to a small set of recurring mistakes. Knowing them in advance is far cheaper than learning them through an OCR investigation.

• Misclassifying vendors as conduits. Treating an MSP, cloud provider, or email platform as a conduit because it "just passes data through" is the most common and most dangerous error. Persistent access to PHI means business associate status, period. Mitigation: apply the three-question verification checklist from the who-needs-a-BAA section to every vendor before classification.

• Assuming a compliance badge equals a signed BAA. A vendor's HIPAA compliance certification, SOC 2 badge, or website privacy statement is not a BAA. You need the actual signed agreement scoped to the services you use. Mitigation: maintain a centralized contract repository with signed BAAs, effective dates, and renewal reminders.

• Retroactive BAAs. Executing a BAA after PHI has already been shared is a standalone violation. OCR has penalized organizations for missing BAAs even when no breach occurred. Mitigation: make BAA execution a hard gate in vendor onboarding — no PHI access until the agreement is signed.

• Incomplete BAA clauses. A BAA that omits required provisions (subcontractor flow-down, HHS records availability, return/destruction) is non-compliant even if it is signed. Mitigation: use the HHS model BAA as a baseline and run a clause-by-clause checklist before execution.

• Missing subcontractor BAAs. Your vendor signed a BAA with you, but their offshore coding team or cloud subprocessor did not sign one with them. That gap is your exposure. Mitigation: require subprocessor lists and downstream BAA evidence during onboarding and annually thereafter.

• Failing to enforce breach obligations. A vendor reports a security incident informally via email but never submits the required written breach report. The covered entity files it away without following up. Mitigation: define breach reporting SLAs in the BAA and assign a compliance officer to track and escalate open incidents.

• Weak technical safeguards despite a signed BAA. A BAA that requires "appropriate safeguards" but does not specify encryption standards, access controls, or logging requirements is difficult to enforce. Mitigation: include specific technical requirements in the safeguards clause and verify them during vendor assessments.

Pro Tip: Build a short remediation playbook for audit readiness: (1) document evidence of each control (screenshots, logs, training rosters), (2) prepare a corrective action plan for any identified gaps, and (3) update your contracting controls to prevent recurrence. OCR looks favorably on organizations that identify gaps proactively and document their remediation efforts.

A useful reference for building your HIPAA compliance checklist is to map each BAA clause to a specific control or artifact. That mapping becomes your audit evidence package.

How to draft, negotiate, sign, and manage a BAA

The process from vendor identification to a fully operationalized BAA typically takes multiple weeks, depending on vendor responsiveness and the complexity of the relationship. Here is a practical roadmap.

1. Vendor inventory (1–2 weeks). List every vendor your organization uses. For each one, determine whether they create, receive, maintain, or transmit PHI. Use the three-question checklist from the classification section. Output: a vendor register with a PHI-access column and a BAA-required flag.

2. Risk classification (concurrent with inventory). Rank PHI-touching vendors by risk: volume of PHI accessed, sensitivity of data, vendor security maturity, and criticality to operations. High-risk vendors (EHRs, billing companies, MSPs) get priority.

3. Template selection and customization (3–5 days). Start with the HHS model BAA. Customize scope of PHI, permitted uses, security control requirements, incident response SLAs, audit rights, and indemnity terms for each vendor tier.

4. Negotiation (1–4 weeks). Send the draft BAA to the vendor. Most enterprise vendors have their own BAA templates; review theirs against the HHS required provisions and your customized requirements. Key negotiation points:

   • Insist on audit rights (right to request SOC 2 reports or equivalent annually).

• Require specific incident response SLAs (initial notification within 72 hours).
• Limit secondary uses of PHI explicitly (no analytics, no product training, no benchmarking).
• Require 30-day advance notice before adding new subprocessors.
  • Confirm indemnity scope and minimum cyber liability insurance requirements.

5. Execution (1–2 days). Both parties sign. File the executed BAA in a centralized contract repository with the effective date, renewal date, and a reminder 90 days before expiration.

6. Operationalization (ongoing). Confirm the vendor has implemented the required controls before PHI flows. This means verifying encryption configuration, access controls, and logging — not just accepting the vendor's word.

7. Ongoing audit schedule (annually or after incidents). Review each BAA annually. Request updated SOC 2 reports, subprocessor lists, and training attestations. Trigger an out-of-cycle review after any security incident involving PHI.

Typical cost items to budget

• Legal review of vendor-proposed BAA language: varies by firm and complexity.
• Vendor security assessments or questionnaires: internal staff time or third-party assessment fees.
• SOC 2 Type II reports from vendors: typically provided at no cost by enterprise vendors; may require a paid tier.
• Remediation work (encryption gaps, access control upgrades): depends on current state.
• Implementation of technical controls (EDR, logging, backup): ongoing managed service costs.

How an MSP should operationalize BAA obligations

When an MSP signs a BAA with a healthcare client, the agreement creates specific, auditable obligations. A signed contract is only as good as the controls behind it. Here is what operational compliance looks like in practice.

Controls an MSP must maintain under a BAA

• Least-privilege access: Every technician accesses only the systems and data required for their specific task. Privileged access is logged, time-limited, and reviewed quarterly.
• Encryption in transit and at rest: All PHI transmitted over networks uses TLS 1.2 or higher. Data at rest uses AES-256 encryption. Both are verified through configuration screenshots, not verbal assurances.
• Logging and monitoring: All access to PHI-containing systems is logged. Alerts are configured for anomalous access patterns, failed login attempts, and after-hours activity.
• Patch management: Critical patches are applied within 30 days of release; emergency patches within 72 hours. Patch logs are maintained and available for audit.
• Endpoint detection and response (EDR): All endpoints with access to PHI run EDR software with active monitoring and automated threat containment.
• Backup and disaster recovery: PHI is backed up daily with encrypted offsite copies. Recovery time objectives (RTOs) and recovery point objectives (RPOs) are documented and tested quarterly. Securetechie's backup and disaster recovery services are designed to meet these obligations directly.
• Documented runbooks: Incident response, access provisioning, and offboarding procedures are written, version-controlled, and reviewed annually.

Deliverables MSPs should provide to healthcare clients

• Onboarding checklist confirming controls are in place before PHI access begins
• Current subprocessor list with each vendor's role and PHI access scope
• SOC 2 Type II report or equivalent attestation summary (annually)
• Incident response report template pre-populated with the MSP's contact information and escalation paths
• Monthly security report covering patch status, alert summaries, access reviews, and backup verification

How to demonstrate evidence during audits

Screenshots of access logs and configuration settings, change-control records showing patch application dates, staff training rosters with completion dates, and penetration-test summaries are the artifacts OCR and internal auditors look for. A well-organized SOC 2 compliance program produces most of these artifacts as a byproduct of normal operations.

Pro Tip: When evaluating an MSP during procurement, ask for three specific things: (1) a screenshot of their privileged access management configuration showing time-limited sessions, (2) a sample monthly security report from a current client (redacted), and (3) the date of their most recent penetration test and a summary of findings. An MSP that cannot produce these quickly is not ready to sign a BAA.

Key Takeaways

A BAA must be in place before PHI flows to any vendor that creates, receives, maintains, or transmits it on your behalf — missing that agreement is a standalone HIPAA violation regardless of whether a breach occurs.

The case for treating BAA compliance as an operational discipline, not a legal formality

Most organizations treat a BAA as a contract problem. Draft it, sign it, file it. The compliance team checks a box, and the vendor relationship proceeds. That framing is where most enforcement exposure originates.

The regulatory framework is clear: a signed BAA is the beginning of an ongoing obligation, not the end of one. HHS expects covered entities to monitor vendor performance, respond to known breaches, and terminate relationships when vendors fail to comply. An organization that signs a BAA with an MSP and never verifies whether that MSP actually encrypts data, maintains access logs, or tests its incident response plan has met the letter of the requirement and missed the point entirely.

The vendors most likely to cause a breach are also the ones most likely to present a polished BAA. Enterprise software companies have legal teams that produce well-formatted agreements. What they do not always produce is evidence that the controls behind those agreements are actually implemented and tested. Asking for a SOC 2 Type II report, a subprocessor list, and a recent penetration-test summary is not excessive due diligence. It is the minimum a covered entity should do before trusting a vendor with patient data.

There is also a practical asymmetry worth understanding. When a business associate causes a breach, the covered entity still bears the notification burden and the reputational cost. Patients do not distinguish between "your vendor was breached" and "you were breached." That asymmetry is the strongest argument for treating vendor oversight as an ongoing operational discipline rather than a one-time contracting exercise.

Securetechie helps healthcare organizations close BAA gaps fast

Healthcare organizations in Southern California face a specific challenge: most of their vendors are enterprise platforms with standardized BAA templates that may not reflect the organization's actual risk profile or the specific controls their compliance program requires. Securetechie's HIPAA compliance and managed IT services are built to close that gap.

Securetechie provides HIPAA compliance audits that map your current vendor relationships against BAA requirements, identify missing agreements, and produce a prioritized remediation plan. For organizations that need an MSP ready to sign a BAA and back it with auditable controls, Securetechie delivers 24/7 monitoring, endpoint detection and response, encrypted backup and disaster recovery, and documented incident response procedures. Every engagement includes a subprocessor list, onboarding checklist, and monthly security reporting so your compliance team always has the evidence it needs.

For healthcare providers ready to get their vendor contracting program in order, the next step is a compliance gap assessment. Contact Securetechie to schedule yours, or visit the cybersecurity services page to see how the technical controls map to your BAA obligations.

Useful sources and model BAA resources

The following authoritative references are the primary documents to download and consult when drafting or reviewing a BAA.

• HHS Model Business Associate Agreement (PDF): The official HHS model BAA covering all required provisions under HIPAA and the HITECH Act. Download this first. It is the safest baseline for any covered entity drafting a BAA from scratch and reflects OCR's current regulatory interpretation.

• HHS Sample Business Associate Agreement Provisions: HHS's annotated sample provisions page, which explains each required clause under 45 CFR 164.504(e) and provides editable language. Use this alongside the model BAA to understand the regulatory intent behind each clause.

• HHS Business Associates Guidance: The primary HHS guidance page on who qualifies as a business associate, what written assurances are required, and what covered entities must do when a BA breaches the agreement. The authoritative source for the legal definition and covered entity obligations.

• HIPAA Journal: HIPAA Business Associate Agreement (2026 Update): A detailed explainer covering the conduit exception, common misclassifications, and subcontractor obligations. Useful for compliance teams that need plain-language explanations alongside the regulatory text.

• BAA Generator: When Do You Need a HIPAA BAA?: A decision-tree resource for classifying vendors and determining when a BAA is required. Practical for vendor onboarding workflows.

• MedComply: Do I Need a BAA With My Vendor?: A plain-English guide covering cloud provider BAA scope limitations, configuration requirements, and the risks of relying on compliance badges instead of signed agreements.

• AccountableHQ: BAA Contract Requirements and Key Clauses: Covers minimum necessary obligations, permitted-use language, and template guidance for compliance professionals building or reviewing BAA programs.

Recommended

• HIPAA Compliance Checklist for Healthcare (2026) | Secure Techies
• CCPA & CPRA Compliance Guide for California Business | Secure Techies
• PCI DSS Compliance Guide for Business | Secure Techies
• Law Firm IT Services LA | Secure, Confidential, Always-On | Secure Techies