# What Is a Business Associate Agreement (and Why Does It Matter)? Source: https://scadable.com/blog/business-associate-agreements-explained Published: 2026-07-12 --- **A Business Associate Agreement, a BAA, is the contract HIPAA requires before a covered entity, a hospital, clinic, or insurer, can legally share protected health information with a vendor. If your company creates, receives, stores, or transmits PHI on a covered entity's behalf, whether or not you think of yourself as a healthcare company, you are typically a Business Associate, and that covered entity cannot legally send you PHI without a signed BAA in place first.** This is not a formality that sits alongside the real work. The BAA is the mechanism that makes a vendor's [HIPAA](/frameworks/hipaa) obligations explicit and enforceable, and it is usually the first concrete signal that those obligations apply to a specific company, at a specific moment, rather than as a general compliance concern to get to eventually. ## What does a BAA actually obligate a vendor to do? Signing a BAA is not just paperwork that unlocks a data feed. It commits the vendor to a specific set of duties: - **Implement the same Security Rule safeguards a covered entity must run.** Administrative, physical, and technical controls: access management, encryption in transit and at rest, audit logging, and a documented incident response process, applied to any system that touches PHI. - **Report breaches on HIPAA-defined timelines.** A vendor that discovers a breach involving PHI has a real, contractual clock to notify the covered entity, not an open-ended "let us know eventually." - **Only use PHI for permitted purposes.** The BAA names what the vendor is allowed to do with the data. Using it outside that scope, even for something that seems benign, like product analytics, is a violation. - **Flow the same obligations down to any subcontractor that also touches the data.** A vendor cannot sign a BAA with a covered entity and then hand PHI to a cloud provider or support tool with no equivalent agreement in place. The obligations travel with the data. That last point is where most of the practical risk sits, and it is worth its own section below. ## Why is a BAA request the clearest signal that HIPAA applies to you? A general "do we handle health data" self-assessment can be genuinely ambiguous, especially for a company that does not think of itself as a healthcare vendor. A device maker whose cloud platform logs patient vitals, or a software vendor whose companion app stores patient records on a hospital's behalf, might reasonably not identify as a healthcare company at all. A BAA request removes that ambiguity. If a hospital, clinic, or insurer is asking your company to sign one, that is not a hypothetical future concern, it is a covered entity telling you directly that it intends to send you protected health information and that HIPAA governs that relationship now. There is no more concrete trigger than that. ## What happens if a vendor cannot sign a BAA? In practice, no BAA typically means no data. A covered entity cannot legally share PHI with a vendor before a BAA is signed, so if a vendor cannot meet the obligations the agreement requires, engineering probably has not built the safeguards yet, or is unwilling to accept the liability, the covered entity simply withholds the data. For the vendor, that usually means the product does not work for that specific customer until the BAA is resolved. This is often the moment a company discovers that a feature it assumed would work out of the box, syncing patient data, storing device telemetry tied to a patient, is actually blocked on a contract it has not thought through. It is a commercial problem before it is a compliance one: a deal that looks closed can stall indefinitely on a BAA nobody scoped early. ## What about a vendor's own subcontractors? This is the part that is easy to lose track of. A BAA does not just cover the direct relationship between the covered entity and the vendor. Any subcontractor of that vendor, a cloud provider, an analytics tool, a support platform, that also touches PHI needs its own BAA with the vendor, flowing the same obligations down the chain. In practice this means mapping every place PHI actually moves through a product, not just the primary data store. Cloud telemetry pipelines built for uptime and observability rather than PHI handling, third-party analytics, and support tooling are common places where patient data ends up without anyone deciding it should be there, and without a BAA covering that specific subprocessor. A security review or an audit is where this chain typically gets discovered, which is a worse time to find it than during product design. This is educational information, not legal advice; whether a specific relationship or subcontractor triggers a BAA obligation depends on the facts, and a company should confirm its own HIPAA posture with qualified counsel. ## Frequently asked questions **What is a Business Associate Agreement?** A Business Associate Agreement, a BAA, is the contract HIPAA requires before a covered entity, a hospital, clinic, or insurer, can legally share protected health information with a vendor. It sets out what the vendor is allowed to do with that data and what safeguards it has to run. **Who actually needs to sign a BAA?** Any vendor that creates, receives, stores, or transmits protected health information on behalf of a covered entity, called a Business Associate under HIPAA. This applies whether or not the vendor thinks of itself as a healthcare company. A cloud platform storing patient vitals or a support tool touching patient records both typically qualify. **What does signing a BAA actually obligate a vendor to do?** Implement the same Security Rule safeguards a covered entity must run, administrative, physical, and technical controls like access management and encryption. Report breaches on HIPAA-defined timelines. Use PHI only for the permitted purposes named in the agreement. Flow the same obligations down to any subcontractor that also touches the data. **What happens if a vendor cannot sign a BAA?** In practice, no BAA means no data. A covered entity cannot legally send protected health information to a vendor without a signed agreement in place first, so the product typically does not work for that customer until the BAA is resolved. **Do a vendor own subprocessors need their own BAAs too?** Yes. Any subprocessor that also touches PHI, a cloud provider, an analytics tool, a support platform, needs its own BAA with the vendor. This chain is easy to lose track of, and it is a common place gaps show up during a security review. **Is a BAA request a reliable signal that HIPAA applies to my company?** It is the clearest one available. A general self-assessment of whether you handle health data can be ambiguous, but a covered entity asking you to sign a BAA means HIPAA applies to your company right now, not hypothetically. Last reviewed: July 12, 2026. ## Where Scadable fits Scadable helps a company map exactly where PHI moves through its product and its subprocessor chain, cloud storage, telemetry, analytics, support tooling, and gets the right BAAs in place with the right parties, rather than leaving that chain to be discovered the hard way during a deal or an audit. Read more on the [HIPAA requirements that apply to connected medical device companies](/blog/hipaa-requirements-medical-device-companies), or [book a call](https://cal.com/rahbaral/quick-chat) to map your own PHI and BAA chain.