BAA Refusal and Required Contract Terms: What to Do When a Vendor Will Not Sign
Vendor relationships are where HIPAA compliance most often gets messy, not because the rules are mysterious, but because modern clinic operations depend on outside companies for billing, scheduling, EHR hosting, patient communications, analytics, IT support, document management, and niche clinical tools. Many of those vendors touch protected health information (PHI) in ways that make them business associates under HIPAA. When a vendor refuses to sign a Business Associate Agreement (BAA), the clinic’s options are not “accept the risk” or “sign anyway and hope for the best.” The options are operational, and sometimes uncomfortable: change the workflow so the vendor does not receive PHI, change vendors, or stop the activity that requires the vendor.
This article explains how to determine whether a vendor actually requires a BAA, what contract terms HIPAA requires in a compliant BAA, why some “standard vendor BAAs” still fail the requirements, and how to respond when a vendor will not sign. The goal is to give clinics a repeatable decision process that produces defensible outcomes and a clean documentation trail.
Informational note: This report is for informational purposes only and does not constitute legal advice.
Start with classification: does this vendor meet the definition of a business associate
A BAA is not a generic “HIPAA form.” It is a specific contract used when a vendor is a business associate. HIPAA’s definition is functional, not marketing-based. A business associate is generally a person or entity that, on behalf of a covered entity, creates, receives, maintains, or transmits PHI for a regulated function or activity, or that provides certain services to a covered entity where the service involves disclosure of PHI. Subcontractors that handle PHI on behalf of a business associate also fall into the business associate chain.
This definition matters because many vendors try to decide the issue by labeling themselves “HIPAA compliant” or “not a business associate.” HIPAA does not let a vendor opt out by declaration. If the vendor’s role and data flows meet the definition, the vendor is a business associate as a matter of law, and the clinic must treat the relationship accordingly. OCR’s “Covered Entities and Business Associates” guidance is explicit that entities that meet the definition must comply with the HIPAA Rules, and it reinforces that business associates are directly liable for compliance with certain HIPAA provisions.
The practical test for clinics is to ignore the vendor’s branding and instead map the workflow. Ask one narrow, engineering-style question: will this vendor create, receive, maintain, or transmit PHI on the clinic’s behalf as part of the service being purchased? If the answer is yes, assume business associate status unless a narrow exception applies. If the answer is no because the vendor never touches PHI, a BAA may not be required, but that conclusion should be supported with specific facts, not assumptions.
The hard rule: you generally may not let a business associate touch PHI without a compliant BAA
HIPAA’s Privacy Rule requires covered entities to obtain “satisfactory assurances” from business associates in the form of a written contract or other written arrangement that meets the business associate contract requirements. The contract must establish permitted and required uses and disclosures of PHI by the business associate and must contain specific safeguards, reporting duties, and downstream restrictions.
The Security Rule reinforces this from the electronic PHI angle. It states that a covered entity may permit a business associate to create, receive, maintain, or transmit electronic PHI on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with the organizational requirements rule, that the business associate will appropriately safeguard the information.
Taken together, the message is blunt: if the vendor is a business associate and PHI will flow, you need a BAA that meets the regulatory requirements. A “security addendum,” a generic NDA, a vendor’s privacy policy, or a verbal promise does not satisfy the requirement because HIPAA requires specific contractual content. OCR’s “Business Associates” guidance points back to the regulation and frames the contract elements as mandatory.
This is why BAA refusal is a stop sign. It is not a negotiable compliance preference. If you cannot get a compliant BAA, the safe path is to design the workflow so the vendor never receives PHI, or to choose a vendor that will sign.
What HIPAA requires in a BAA: the contract terms you cannot waive
Most contract fights happen because clinics and vendors treat BAAs as optional paperwork. HIPAA treats BAAs as an enforcement mechanism. The required elements are specified in the Privacy Rule’s business associate contract section, and OCR provides sample provisions and a model BAA that reflect those requirements.
Rather than list the required terms as a checklist, it is more useful to understand them as a set of control objectives that the contract must accomplish.
The contract must define allowed uses and disclosures and prohibit everything else
A compliant BAA must establish the permitted and required uses and disclosures of PHI by the business associate. The contract may not authorize the business associate to use or further disclose PHI in a manner that would violate the Privacy Rule if done by the covered entity, except for limited allowances that HIPAA specifically permits for business associates, such as certain management and administration uses under defined conditions.
In practice, this term is where many vendor templates go wrong. If the vendor’s contract says it may “use customer data to improve services” without limiting that phrase to permitted HIPAA purposes, you have a mismatch. The permitted uses must stay inside HIPAA boundaries, and the BAA must be written so that there is no ambiguity about whether PHI can be used for the vendor’s independent product development, marketing, analytics resale, or other secondary purposes that are not permitted.
The contract must require safeguards and HIPAA-aligned security controls
The Privacy Rule contract requirements require the business associate to use appropriate safeguards and comply with the Security Rule with respect to electronic PHI. The Security Rule’s organizational requirements similarly contemplate written assurances that the business associate will safeguard electronic PHI.
This matters because some vendors try to sign a BAA but refuse to accept security obligations that mirror HIPAA’s requirements, usually by limiting their responsibility to “commercially reasonable” measures or by carving out subcontractors and cloud providers. HIPAA’s structure expects the business associate to be accountable for safeguarding PHI within the scope of its services and to ensure appropriate protections in its own downstream chain. A BAA that dodges safeguards is not a real BAA; it is a contract designed to fail gracefully for the vendor.
The contract must require reporting of improper uses, disclosures, and breaches
BAAs must require the business associate to report to the covered entity any use or disclosure of PHI not provided for by the contract, including breaches as required by the Breach Notification Rule. The Breach Notification Rule separately requires business associates to notify covered entities following discovery of a breach of unsecured PHI.
Clinics should pay close attention to how vendor templates define “breach” and “security incident” and what timelines apply. HIPAA’s breach rule uses a defined framework and includes timing expectations for business associate notice to the covered entity. Vendor language that gives itself unlimited time, allows discretionary reporting, or narrows the scope of reportable events below HIPAA’s standards is a contract term that should be corrected before PHI flows.
The contract must bind subcontractors and prevent PHI from leaking down the chain
HIPAA does not stop at the first vendor. Business associates must ensure that any subcontractors that create, receive, maintain, or transmit PHI on their behalf agree to the same restrictions and conditions that apply to the business associate with respect to such information. The Security Rule’s organizational requirements explicitly apply to business associate contracts with subcontractors as well.
This is an area where clinics should resist hand-waving. It is common for a vendor to say “our cloud provider is compliant” or “we use reputable sub-processors” without offering contractual assurance that those sub-processors are under appropriate restrictions. If your vendor refuses to commit to downstream safeguards, you are effectively accepting a blind spot for where your patients’ data travels.
The contract must support individual rights that the covered entity remains responsible for
Business associates often hold the operational keys to PHI, especially in hosted systems. HIPAA anticipates this and requires BAAs to include terms requiring the business associate to make PHI available to the covered entity as needed for individual access, amendment requests, and accounting of disclosures, to the extent applicable. OCR’s model agreement includes provisions to support these workflows and makes clear that the covered entity remains responsible for responding to individuals, but the business associate must cooperate.
This becomes important when vendors refuse BAAs because they do not want obligations tied to access workflows or they want the right to withhold data during billing disputes. OCR has explicitly stated that business associates may not block or terminate access to PHI they maintain on behalf of a covered entity in a manner that would violate the Privacy Rule’s requirements. If a vendor’s contract tries to reserve leverage over access to PHI, you should assume you are looking at future operational pain.
The contract must address return or destruction of PHI at termination when feasible
HIPAA requires BAAs to include a term that, at termination, the business associate will return or destroy all PHI received from, or created or received on behalf of, the covered entity, if feasible. If return or destruction is not feasible, the contract must extend the protections of the BAA to the PHI and limit further uses and disclosures.
This is a common friction point with cloud vendors, because “deletion” is complex in distributed storage systems. HIPAA’s standard is not perfection; it is feasibility plus continued protections when destruction cannot be fully achieved. Vendors that refuse the clause entirely are telling you, in advance, that data lifecycle control will not be part of the relationship.
The contract must give the covered entity a mechanism when the business associate violates the agreement
HIPAA’s business associate framework includes an expectation that covered entities will respond when they learn of a pattern of activity or practice by the business associate that constitutes a material breach or violation. OCR’s guidance states that the covered entity must take reasonable steps to cure the breach or end the violation and, if unsuccessful, terminate the contract if feasible. If termination is not feasible, the covered entity must report the problem to OCR.
This matters in the refusal scenario because it reveals the enforcement posture: HIPAA expects covered entities to treat business associate misconduct as something they must address, not tolerate. A vendor that refuses a BAA is asking you to tolerate a baseline noncompliant posture before any services begin. That is a bad starting point.
Why “we encrypt everything” is not an escape hatch
A common vendor argument is that it does not need to sign a BAA because it only handles encrypted data, does not have the decryption key, or has “no view” access. OCR addressed this directly in its guidance on HIPAA and cloud computing. OCR explains that cloud service providers (CSPs) that create, receive, maintain, or transmit electronic PHI on behalf of a covered entity or business associate are business associates, even if the CSP cannot view the ePHI because it is encrypted and the CSP does not have the key.
The compliance implication is simple: encryption is a safeguard, not a classification test. A vendor can be a business associate even when its personnel cannot read the data, because the vendor is still maintaining or transmitting PHI on the clinic’s behalf. Vendors that refuse BAAs on the basis of “no view” often misunderstand HIPAA or are hoping the clinic does.
The conduit exception exists, but it is narrow and easy to misapply
Some vendors claim they are “mere conduits,” like the postal service, and therefore not business associates. OCR guidance treats the conduit concept as narrow. In the cloud computing guidance, OCR explains that the conduit exception applies where the only services provided are transmission of ePHI that do not involve storage of the information other than temporary storage incident to transmission. If the vendor provides transmission services plus maintains ePHI for processing or storage, it is still a business associate.
Clinics should treat “conduit” claims as something to verify with architecture facts. If a service queues messages, stores attachments, archives content, provides searchable logs, or retains data for more than transient transmission, it is usually outside the narrow conduit concept as OCR describes it.
When a vendor refuses to sign: the decision framework that avoids self-inflicted violations
When a vendor refuses a BAA, the clinic’s path depends on what, exactly, would flow to the vendor and why. The correct response is not primarily legal theory; it is system design.
First response: stop PHI from flowing until classification and contract posture are resolved
If the vendor relationship is already in motion, the immediate control is to stop sending PHI through the vendor while you assess. HIPAA’s structure is built on the idea that you obtain satisfactory assurances before permitting the business associate to handle PHI. Continuing to transmit PHI while the vendor refuses the required contract is the fastest way to turn a procurement issue into a reportable compliance issue.
Operationally, this may mean disabling an integration, pausing an interface feed, turning off automated exports, or restricting staff from using the tool with patient identifiers. This is inconvenient, but it preserves your posture while you decide between redesign, replacement, or termination.
Second response: decide whether the vendor can be used without PHI by changing the workflow
Often the best outcome is to keep the vendor but change the data exposure so the vendor never receives PHI in the first place. This is not “getting around HIPAA.” It is applying the definition correctly by designing the workflow so the vendor is not performing a service that involves PHI.
There are several common patterns that can work if implemented honestly. One is de-identification. If the clinic can provide data that is de-identified consistent with HIPAA’s de-identification standard, the dataset is no longer PHI, and a BAA is not required for that dataset. OCR’s model BAA and sample provisions treat de-identification as an optional permitted activity and, by implication, acknowledge that de-identified data is handled differently from PHI.
Another pattern is local processing with non-PHI outputs. For example, a tool might run inside the clinic environment and only send aggregated metrics or operational signals to the vendor. If the vendor never receives PHI, the vendor is not functioning as a business associate for that activity. This approach requires real technical controls, because “we promise we only send non-PHI” is not a control unless the system enforces it.
A third pattern is patient-directed disclosures that are outside the vendor’s role “on behalf of the clinic.” When an individual directs a covered entity to transmit their own information to a third party, the third party is not automatically a business associate simply because it receives data. The relationship depends on whether the third party is performing services for the covered entity or instead receiving information as a separate recipient at the individual’s direction. OCR’s patient access guidance emphasizes that covered entities must provide access in the requested form and format if readily producible and includes discussion of electronic copies and transmission. Clinics should treat this route carefully and document the individual’s direction, because it is not a solution for routine vendor processing. It is a solution for specific patient-directed transfers where the vendor is not part of clinic operations.
Third response: if the vendor needs PHI to perform the service, replacement is usually the correct answer
If the vendor cannot perform the service without receiving PHI, and the vendor refuses a compliant BAA, the practical conclusion is that the vendor is unusable for that purpose. HIPAA’s framework does not provide a “risk acceptance” option for disclosing PHI to a business associate without the required written assurances.
Clinics sometimes attempt to compromise by sending “minimal data.” Minimum necessary is a Privacy Rule principle, but it does not eliminate the business associate contract requirement. If the vendor is still creating, receiving, maintaining, or transmitting PHI on your behalf, you are still in business associate territory, regardless of how small the dataset is.
Replacement can feel like overkill when the vendor is otherwise attractive, but replacement is often less costly than trying to retrofit a noncompliant vendor into a compliant posture. The key is to treat BAA willingness as a gating requirement in procurement rather than as a late-stage negotiation detail.
Fourth response: document the decision and preserve evidence of your due diligence
Whatever path you choose, document the classification analysis and the vendor’s refusal. This is not performative paperwork. It becomes your proof that the clinic acted deliberately and corrected a noncompliant posture when identified.
A solid file typically includes the workflow map showing whether PHI would flow, a brief classification memo referencing the business associate definition and why it does or does not apply, the vendor’s written refusal or nonresponsive posture, and the remediation decision such as redesign or vendor replacement. The goal is that, if you are later asked why a tool was used or not used, you can answer with facts.
Negotiating a BAA when the vendor is hesitant: reduce friction without surrendering required terms
Sometimes refusal is real, and sometimes it is a default posture from a sales team that has not dealt with health care clients. In those cases, negotiation can work if it is targeted.
A strong starting move is to provide OCR’s sample business associate agreement provisions or the HHS model BAA and ask the vendor to propose edits rather than forcing the clinic to reverse engineer the vendor’s template. OCR explicitly provides these sample materials to help regulated entities comply. This also frames the discussion correctly: the clinic is not inventing obligations; it is implementing published requirements.
The second move is to isolate the non-negotiables. Many vendors refuse because they fear unlimited liability or open-ended audit rights, not because they reject HIPAA’s core requirements. It is often possible to negotiate business terms such as insurance limits, indemnity scope, venue, or pricing without altering HIPAA’s required contract elements. The line to hold is that you cannot agree to remove required Privacy Rule clauses, Security Rule assurances, breach notice duties, or subcontractor restrictions.
The third move is to reduce the vendor’s PHI exposure when possible. Vendors that refuse BAAs sometimes do so because they do not want to be in the PHI handling business. If you can configure the service so it does not receive PHI, the vendor may become comfortable proceeding. OCR’s cloud guidance is relevant here because it clarifies that even “no view” hosting can still trigger business associate status, so the redesign must be real, not cosmetic.
Finally, if the vendor insists it is not a business associate, demand the architecture explanation in writing, including whether it stores any PHI beyond transient transmission, whether it logs identifiers, whether it retains message content, and what exact data fields it receives. The conduit exception is narrow, and a vendor that truly fits it should be able to articulate why under OCR’s own description.
Enforcement reality: missing BAAs are not theoretical risk
It is easy to treat BAAs as administrative paperwork until you look at how OCR describes enforcement outcomes and published resolution agreements. OCR’s resolution agreement pages include cases where failure to have required business associate agreements was part of the compliance failures addressed. One example is MedEvolve, where OCR’s resolution materials state that MedEvolve failed to enter into a business associate agreement with a subcontractor, alongside other cited failures.
That example is useful for clinics because it illustrates how BAA gaps surface. The trigger is often an incident, breach, or investigation, and then the absence of BAAs becomes part of the compliance story. Even when an OCR matter resolves through corrective action rather than penalties, the operational burden of responding and remediating is substantial, and it usually arrives when the clinic is already dealing with the underlying incident.
Separately, OCR emphasizes that business associates are directly liable for certain HIPAA obligations. That means a vendor that truly is a business associate does not get a free pass simply because it refused to sign a BAA. The clinic still cannot permit PHI flow without satisfactory assurances, and the vendor still risks enforcement if it is acting as a business associate. Refusal is therefore a signal that the vendor is not prepared to operate in a regulated role.
Building a clinic-grade process: make BAA decisions predictable
The most reliable way to handle BAA refusals is to remove improvisation from the process. Clinics that do this well tend to implement a small set of controls.
One control is a vendor inventory that classifies each vendor as business associate, non-business associate, or pending, based on a documented workflow analysis. The classification should reference the business associate definition and note the specific PHI data flows.
A second control is a procurement gate that blocks go-live until the BAA is executed when business associate status applies. This is the simplest way to prevent staff from adopting tools informally and creating PHI exposure before legal and security review occurs. This gate aligns directly with the “satisfactory assurances” requirement that applies before permitting ePHI handling.
A third control is template discipline. Using OCR’s model BAA and sample provisions as a baseline reduces variation and helps ensure the required clauses are present. When you accept a vendor’s BAA template, map it back to the regulatory requirements rather than assuming “it says HIPAA so it is fine.”
A fourth control is downstream verification for subcontractors in high-risk vendor categories such as hosted platforms, billing vendors, managed IT, and communication tools. The contract must require subcontractors to agree to the same restrictions, but you should also understand who the sub-processors are and how the vendor governs them, because that is where data travels.
The bottom line
When a vendor will not sign a BAA, treat it as a design constraint, not as a compliance debate. If the vendor is a business associate and will receive PHI on your behalf, HIPAA’s structure expects a compliant written agreement as a condition of that relationship. If the vendor refuses, your defensible choices are to redesign the workflow so the vendor does not receive PHI, choose a different vendor, or stop using the service for PHI-related functions. In the modern clinic environment, the most expensive path is usually the one that tries to pretend refusal is a minor administrative snag.
Sources
HHS OCR, “Business Associates” (guidance on BAAs, required elements, and required response to material breaches, including termination and reporting to OCR if termination is not feasible).
45 C.F.R. § 164.504(e), business associate contract requirements (required contract elements, safeguards, reporting, subcontractors, return or destruction).
45 C.F.R. § 164.502(e), disclosures to business associates and the requirement for satisfactory assurances via contract or other written arrangement.
45 C.F.R. § 164.308(b)(1), Security Rule requirement for satisfactory assurances before permitting a business associate to handle electronic PHI.
45 C.F.R. § 164.314(a), Security Rule organizational requirements for business associate contracts and subcontractor arrangements.
HHS OCR, “Sample Business Associate Agreement Provisions” (official sample clauses intended to support compliance).
HHS OCR, “Model Business Associate Agreement” (model agreement text illustrating compliant provisions).
HHS OCR, “Guidance on HIPAA and Cloud Computing” (cloud providers as business associates, encryption and “no view” does not remove BA status, conduit exception described as narrow).
45 C.F.R. § 164.410, Breach Notification Rule requirement for business associates to notify covered entities following discovery of a breach of unsecured PHI.
HHS OCR, “Breach Notification Rule” overview (scope of 45 C.F.R. §§ 164.400–414 and applicability to covered entities and business associates).
HHS OCR, “Covered Entities and Business Associates” (direct liability of business associates and coverage of entities meeting the definition).
HHS OCR, “Resolution Agreements” overview and MedEvolve Resolution Agreement page (example of enforcement context referencing failure to enter into a BAA with a subcontractor).
HHS, CMS Guidance Letter GL-2022-03 on covered entities’ responsibility regarding business associate compliance (reinforces obligations in regulated relationships).