Am I a HIPAA business associate if my company handles PHI for a covered entity?
A company is a HIPAA business associate when, other than as a member of a covered entity's workforce, it creates, receives, maintains or transmits protected health information for a covered entity in a regulated function, such as claims processing, data analysis, billing, practice management or repricing, or when it provides legal, accounting, consulting, management, administrative or similar services that involve disclosure of PHI to it. The definition sits in 45 CFR 160.103, and the eCFR text of that section is the starting point for any determination. If your company received a business associate agreement to sign, that request is a signal to test the definition against what your systems actually do with the data, not a conclusion that the definition applies.
The answer turns on the specific data flow and the specific function, so the same company can be a business associate for one client and not for another. A billing vendor that receives patient records from a clinic is a business associate for that clinic. The same vendor reviewing de-identified data supplied by a different customer may not be. Start by listing each client relationship, the PHI involved, whether your staff or systems create, receive, maintain or transmit it, and whether the work falls within the regulated functions or listed services. Record the answer for each relationship, because the determination is your organization's own, and it should be confirmed with counsel where the facts are unclear or the contract language is unusual.
Which services put a vendor inside the definition
The definition in 45 CFR 160.103 turns on one question: does the vendor create, receive, maintain or transmit PHI for a covered entity or another business associate. The categories below are the service types where that question most often comes up, and each one can apply to a vendor whatever it calls itself.
Claims, billing and practice management
The regulation names claims processing, data analysis, billing, benefit management, practice management and repricing as regulated functions. A clearinghouse that scrubs claims for a practice holds PHI for that practice, so it is a business associate even if it never talks to patients. Check whether your staff open, edit or store patient claim data on the client's behalf, not just whether the product is labeled billing software.
Legal, accounting and consulting services
Lawyers, auditors, accountants, consultants and administrative contractors become business associates when their engagement involves disclosure of PHI from the covered entity. A law firm reviewing a patient complaint file or an accountant reconciling a patient-level ledger are typical illustrative cases. Ask whether the engagement letter requires PHI access, and whether the work could be done with de-identified data instead.
Health information organizations and e-prescribing gateways
Health information organizations and e-prescribing gateways that need routine access to PHI to move it between parties are named in the definition, even though they may never read clinical content. An exchange that routes orders between a clinic and a pharmacy is an example. The test is routine access to PHI in transit, so confirm whether your platform stores, parses or merely relays messages.
Personal health record vendors
A vendor that offers a personal health record on a covered entity's behalf, such as a patient portal the provider branded and hosts, is a business associate. The HHS app scenarios show the opposite result when a consumer signs up directly and the app acts for the consumer. Confirm who contracted with whom and who controls the data before you assume either status.
Subcontractors of business associates
Any company that handles PHI for a business associate is itself a business associate, even though it never contracts with the covered entity. A hosting firm that stores a billing vendor's database is a typical example. Confirm that your agreement with the upstream business associate exists in writing, because the chain of agreements is what makes each link lawful.
Data transmission and cloud storage services
Data transmission services that need routine access to PHI are business associates, and HHS guidance adds that a cloud provider holding ePHI is one even if it stores only encrypted data without the key. A managed file transfer service carrying lab results is an illustrative case. Ask your provider and yourself whether you can read, route or restore the data, and treat encryption alone as not settling the question.
Is a cloud provider a HIPAA business associate if it cannot read the data?
Yes, in most cases. HHS guidance treats a cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity or business associate as a business associate, even if it stores only encrypted ePHI and does not hold the encryption key. The test is what the provider does with the data on the customer's behalf, not whether it can read the content. A provider that keeps the encrypted files, backs them up, replicates them or moves them across its network is maintaining or transmitting ePHI, and that activity is enough to bring it within the definition in 45 CFR 160.103.
Encryption therefore reduces the provider's exposure to a breach of plaintext data, but it does not remove the business associate relationship. The provider still needs a business associate agreement with the covered entity or with the business associate that is its customer, it remains directly liable for Security Rule compliance under the provisions HHS lists, and its own subcontractors that hold the data become business associates in turn. For an infrastructure team, the practical question is who signs the agreement, which services are covered by it, and whether the provider's own data center, staff and support tooling are included in the scope of its Security Rule safeguards.
A provider with no access to PHI at all may still need to confirm its position with counsel, because the definition turns on the facts of the service rather than on labels. Review the cloud contract, the service description and the data processing terms for how the provider describes its role, whether it accesses customer content for support or troubleshooting, and whether it has any mechanism to recover or inspect data. Ask your provider in writing whether it will sign a business associate agreement for the services you use, and record the answer alongside your own risk analysis.
Covered entity, business associate or neither: which role fits your company
This table compares the four roles a company can hold under HIPAA: covered entity, business associate, subcontractor and neither. Read each column against your own services, then check the trigger and relationship document before deciding which role applies. The main takeaway is that the role depends on what you do with PHI for whom, not on how sensitive your data feels.
| Role | Typical trigger | Relationship document | Common mistake |
|---|---|---|---|
| Covered entity | Health plan, clearinghouse, or covered provider that conducts standard electronic transactions such as claims or eligibility checks | Business associate agreements with each vendor that handles PHI for it | Assuming a provider is covered just because it treats patients, when it is covered only if it sends standard electronic transactions |
| Business associate | Performs a regulated function or service for a covered entity that involves creating, receiving, maintaining or transmitting PHI, such as billing or hosting | Business associate agreement with the covered entity, including Security Rule terms | Believing that storing only encrypted data without holding the key removes business associate status |
| Subcontractor to a business associate | Handles PHI for a business associate, for example a hosting provider used by a billing vendor | Business associate agreement with the business associate that flows down obligations | Treating the upstream contract as enough and never signing a downstream agreement |
| Neither | Does not handle PHI for a covered entity or business associate, or falls under an exclusion such as a provider receiving PHI for treatment | Usually none under HIPAA, though state law or customer contracts may still apply | Assuming that handling health data for consumers means HIPAA applies, when the health app analysis depends on who created the app and on whose behalf |
| Covered entity that is also a business associate | Performs business associate functions for another covered entity, for example a health system running billing for a physician group | Business associate agreement in the business associate role, alongside its own covered entity duties | Treating the two roles as separate and missing the Security Rule duties that apply in the business associate role |
| Vendor's cloud provider | Creates, receives, maintains or transmits ePHI for you, even when it lacks the encryption key | Business associate agreement with the cloud provider covering its HIPAA terms | Relying on a standard cloud terms page without confirming a signed business associate agreement exists |
| Consumer-directed app or tool | Acts only at the consumer's direction, with no contract with a covered entity | Consumer terms and privacy notice, not a business associate agreement | Confirm with the covered entity whether it offers the app to patients, because that can change the answer |
What the definition means for developers, data transmitters and PHR vendors
Whether a health or wellness app is a business associate depends mainly on who asked for it and who controls the data. HHS's app scenarios draw the line at whether the developer creates or offers the app on behalf of a covered entity or its contractor. If a provider contracts with a vendor to deliver an app to patients and the vendor has PHI access to run it, the vendor is generally a business associate. If the consumer downloads and directs the app themselves and the developer is not paid by a covered entity to provide it, the developer usually acts for the consumer and sits outside the definition.
- Covered entity commissions the app: A provider that hires a developer to build a patient-facing app that sends its records or messages is the typical business associate case.
- Consumer chooses the app: A patient who downloads a fitness tracker and sends data to it on their own initiative usually creates a non-HIPAA relationship.
- Developer receives data from a provider: Routine transfer of PHI from a provider to the developer for the app's function can make the developer a business associate even if the consumer later exports the data.
- Interoperability arrangements: Connecting the app to a provider's systems through an agreement can change the analysis, so review the terms, not only the marketing.
- Other rules still apply: Apps outside HIPAA may fall under FTC rules, so the absence of HIPAA is not the absence of obligations.
Before launch, confirm the commercial relationship with each covered entity and document who directs the data flows, using the HHS app scenarios as the starting point.
The regulatory definition names health information organizations, e-prescribing gateways and other providers of data transmission services that need routine access to PHI as business associates. The test is whether the company needs persistent or routine access to PHI to move it, not whether it merely passes encrypted traffic across a network. A service that only carries data and never needs to read or store it stands in a different position from a gateway that routes, translates or holds messages for a covered entity.
- Routine access triggers status: A gateway that routinely reads, indexes or stores PHI to route messages is usually a business associate.
- Conduit-only services: A carrier that only transports data without routine access may fall outside the definition, but confirm this against the actual architecture.
- Message queues and logs: Retained copies of messages, even for troubleshooting, count as maintaining PHI.
- Health information organizations: Entities that aggregate PHI for providers and plans are named in the definition and should assume business associate status.
- Contract signals: Written agreements that describe the service as acting for a covered entity point toward business associate status.
Map every point where your service touches PHI, including logs and backups, and check whether routine access is needed for the function you sell.
Vendors offering personal health records are business associates when they offer the record on a covered entity's behalf. A portal that a hospital or clinic provides to its patients, run by a vendor with access to the patient's PHI, is the common example. The same product sold directly to consumers, with no covered entity arranging or paying for it, may stand outside HIPAA. The distinction rests on the contracting party and the flow of PHI, so the same software can be in scope for one customer and out of scope for another.
- Covered entity arranges the portal: A vendor that runs a provider's branded portal with PHI access is typically a business associate.
- Direct-to-consumer PHR: A record the patient opens and fills on their own account, with no covered entity involvement, usually sits outside the definition.
- Hybrid models: A vendor that serves both channels should separate the data and the agreements so each stream has a clear status.
- Data pulled from providers: Importing a patient's records from a covered entity at the patient's request can still raise questions, so review those flows.
- Sharing back to providers: Sending PHR data into a provider's record system tends to bring the vendor into the covered entity relationship.
For each customer or channel, record who contracted for the service, who pays, and where the data originated.
A subcontractor is a person or entity that performs functions or activities involving PHI for a business associate, and it becomes a business associate itself. The chain can run several levels deep, with each layer inheriting the obligations of the layer above. A company that is not a direct vendor to a covered entity can still be a business associate because it handles PHI for a vendor that is one. This matters for hosting firms, support vendors and offshore processors that sit behind a primary contractor.
- Downstream PHI access: A firm that receives PHI from a business associate to perform a regulated function is a subcontractor business associate.
- Indirect status: The covered entity may never have contracted with you, yet your status still follows the data you handle.
- Covered entities as business associates: A covered entity can be a business associate of another covered entity, so check both roles.
- Direct liability: HHS lists Security Rule compliance and subcontractor agreements among the duties business associates owe directly.
- Deeper chains: Each downstream provider must also be assessed, because a gap at the bottom of the chain is still a gap for the whole arrangement.
Trace your supply chain from the data inward, and ask each upstream party in writing whether your role makes you a business associate.
What business associate status requires from your company
Once your company is a business associate, several HIPAA provisions apply to you directly, not only through your contract with the covered entity. HHS lists the obligations that fall on business associates, including compliance with the Security Rule, breach notification to the covered entity, limits on impermissible uses and disclosures, the minimum necessary standard, cooperation with HHS investigations, and entering business associate agreements with your own subcontractors. Read the status as a set of duties your company owns, and map each one to a named owner, a written procedure and a record that shows it runs.
The Security Rule applies to electronic PHI in your own systems, not only the data you handle on a customer's behalf. Your ticketing platform, file transfer servers, backup repositories, admin laptops and the cloud accounts that hold ePHI are all in scope, along with the people and processes that operate them. Start by inventorying every location where your company creates, receives, maintains or transmits ePHI, then confirm that your risk analysis covers each one. Ask whether any of your own vendors touch that data, because those vendors may themselves be business associates that need written agreements with you.
HIPAA has no certification. No Security Rule standard requires an entity to certify compliance, and HHS does not endorse or recognize private certifications, so a badge or a letter from a vendor does not establish that your company meets its obligations. Your compliance rests on your own controls and the evidence they produce, such as policies, access reviews, audit log samples and tested incident procedures. If a covered entity or OCR asks for independent assurance, an assessor reports on your environment and your evidence, and only that assessor's report carries weight. Confirm with the assessor exactly what the report will and will not cover before you commission it.
How to document whether you are a HIPAA business associate
This sequence turns a vague sense that you "probably handle some PHI" into a documented, approved determination for each client relationship. The output is a register you can show a covered entity, an auditor or OCR, along with the reasoning behind every conclusion.
Inventory every client relationship touching PHI
List each client, partner and engagement where your company creates, receives, maintains or transmits protected health information, including pilots, test environments and support tickets that may contain patient data. Involve engineering, support, finance and sales, because the people who know where data actually flows are often not in legal or compliance. The output is a client-by-client register with the contract name, the type of data, and the system or channel used. The step is complete when someone can point to a row for every relationship in the contract database and every system that stores client data.
Map data flows for each relationship
For each register entry, trace how PHI enters, moves through, is stored in and leaves your systems, including hosting providers, backups, logs and subcontractors. Record whether you only transmit data (for example, as a conduit with routine access), whether you store it in encrypted form, and whether you hold or can access a decryption key. The output is a data flow map per relationship, with each subcontractor named. The step is complete when every flow in the map has an owner and a documented source of truth, such as an architecture diagram or a system configuration export.
Map each relationship to a listed function or exclusion
Compare each mapped relationship against the definition of a business associate in 45 CFR 160.103, which lists regulated functions such as claims processing, billing, data analysis and practice management, and the services that involve PHI disclosure. Then check the four exclusions: treatment disclosures to a provider, plan sponsor disclosures under 164.504(f), certain government eligibility determinations, and covered entities acting for an organized health care arrangement. Note which function or exclusion applies and the specific clause. The output is a mapping table with one row per relationship, the matched function or exclusion, and any open question. The step is complete when every row has a conclusion or a named open question for counsel.
Record the reasoning and approval
Write a determination memo for each relationship that states the facts relied on, the regulatory provision applied, the conclusion (business associate, not a business associate, or undetermined), and any conditions attached to the conclusion. Route the memo to the person accountable for privacy or compliance and to legal counsel, and record their names, roles and dates of approval. Where your company is a covered entity to another covered entity, note that status separately. The output is a signed or approved determination memo stored with the register. The step is complete when each relationship has an approved memo that a reviewer can read without asking the author for context.
Align contracts and business associate agreements to the determination
Check whether the contract with each client matches the conclusion in the memo. If you are a business associate, confirm that a business associate agreement exists and that it covers your Security Rule duties, breach reporting and subcontractor agreements. If you have concluded you are not a business associate, confirm that the contract does not require you to handle PHI in a way that would change that answer. The output is a contract cross-reference added to the register, flagging gaps for remediation. The step is complete when every relationship shows either an executed agreement that fits the determination or a documented decision on how the gap will be closed.
Set triggers for revisiting the determination
Define the events that reopen a determination: a new service line, a new hosting provider, a new integration that moves data, a change in the client's use of your product, a change in key management, or a merger or acquisition. Assign an owner to watch for each trigger, usually the product or account owner who approves changes, and require them to notify the compliance owner before the change goes live. The output is a written change-review procedure and a trigger list attached to the register. The step is complete when each trigger has a named owner and the register records the date of the most recent review.
Review and retain the determination file
Review the full file on a schedule your compliance program sets and after any triggered change, then update the register, memos and contract cross-references together. Keep the file in a location you can produce to a covered entity, an auditor or the HHS Office for Civil Rights on request. The HIPAA documentation standard requires written records of policies and actions to be kept for six years, so retain superseded versions for that period. The output is a dated review log showing what changed and why. The step is complete when the file can answer, for any relationship, what the determination was, who approved it, and when it was last confirmed.
Common questions about business associate status
Does encrypting ePHI before storing it remove business associate status?
No. A cloud service provider that creates, receives, maintains or transmits electronic protected health information for a covered entity or business associate is a business associate, even if it stores only encrypted ePHI and holds no decryption key, according to HHS guidance on cloud computing. The test is whether the provider maintains or transmits ePHI on the customer's behalf, not whether it can read the data. Encryption still matters a great deal for the Security Rule, because it shapes which safeguards apply and how breach exposure is assessed, but it does not change the definition. Review the arrangement with counsel and document why you reached your conclusion, including the key management model and whether the provider can access the data in any form.
Can a covered entity also be a business associate of another covered entity?
Yes. The definition in 45 CFR 160.103 does not exclude covered entities, so a health plan, clearinghouse or provider can act as a business associate when it performs a regulated function for another covered entity, such as billing, claims processing or data analysis. In that role, it takes on direct obligations, including Security Rule compliance and breach notification to the covered entity. The status depends on the specific activity, not on the organization's label. A hospital that bills for a physician group, for example, may be a business associate for that work while remaining a covered entity for its own patients. Map each data flow separately so you know which hat applies to which activity.
Does a vendor need a business associate agreement before it receives PHI?
If the vendor is a business associate, the covered entity must have a written agreement in place before the vendor creates, receives, maintains or transmits PHI for it. The agreement must contain the terms required by the Privacy and Security Rules, including safeguards for ePHI and the obligation to pass those terms to the vendor's own subcontractors. Sharing PHI first and signing later does not cure the gap. Confirm the sequence with your counsel, and ask the vendor during onboarding whether it expects to access PHI at all, including during support, troubleshooting or test environment work. Those activities often trigger the requirement without anyone noticing.
Is a developer of a consumer health app covered by HIPAA?
It depends on who the app is offered on behalf of. HHS scenarios indicate that a developer becomes a business associate when it creates or offers the app on behalf of a covered entity or its contractor, for example when a covered entity gives the developer PHI access to provide a patient portal or personal health record. A developer that offers an app directly to consumers, who control their own data and direct its transfer, usually falls outside the definition. Other laws, including Federal Trade Commission rules, may still apply. Document the relationship, who contracts with whom, who sets the terms of data use and who decides where the data goes, because those facts drive the answer.
Who decides whether my company is a business associate?
Your organization decides, and it should do so with qualified legal counsel who reviews the actual contracts and data flows. HHS publishes the definition and guidance, but it does not issue status determinations for individual companies. Covered entities rely on their vendors' assessments, and vendors are directly liable for the duties that apply to them, so each party should reach and record its own conclusion. The review should cover what PHI is accessed, by whom, for what function, under which contract, and whether any of the four exclusions applies. Revisit the analysis when services, subcontractors or data types change.
Does a certificate or a vendor letter prove business associate status?
No. Neither a certificate nor a letter settles the question. HHS does not endorse or recognize private certifications for HIPAA, and a status statement from a vendor reflects that vendor's view, not a regulatory determination. The status turns on facts: what PHI the vendor touches, for which covered entity, and for what function. Ask for the written analysis behind any statement, the executed business associate agreement where one applies, and a description of data flows and subcontractors. A verifiable paper trail that matches the actual access is what regulators and assessors will look for.
Can a vendor avoid business associate status by saying it never sees PHI?
Not by declaration alone. The definition covers anyone who creates, receives, maintains or transmits PHI for a covered entity, so a vendor that hosts, routes, backs up or supports systems containing ePHI may qualify even if its staff never open a record. Access to encrypted data, log files that contain identifiers and remote support sessions can all count. Review the technical reality of the service, including administrative access, backup copies and disaster recovery sites, before accepting a no-PHI position. If the position is correct, record the reasons and the technical controls that keep PHI out of the vendor's scope.
How DeployOpen helps prepare the evidence behind your HIPAA position
Whether your company is a business associate is a legal conclusion that your counsel and your organization own. DeployOpen helps by preparing the technical scope, systems and records that show where electronic protected health information actually flows, so that the position you document is backed by evidence. DeployOpen does not issue legal opinions or certifications.
How we scope
- Written scope lists each system, data flow and hosting arrangement that creates, receives, maintains or transmits ePHI for a covered entity.
- Scope identifies subcontractors, cloud providers and data transmission services that touch ePHI, so each relationship can be classified.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We map where ePHI is stored, transmitted and processed across self-hosted open-source platforms in your own cloud accounts or data centers.
- We document encryption, access and logging configurations for each system so the data-handling picture is verifiable, not assumed.
- Our security testing team can test in-scope applications, APIs and infrastructure that handle ePHI for the systems in your data map.
How we hand over
- You receive a data-flow inventory, system configuration records and a register of the third parties that touch ePHI.
- Documentation is written so your counsel, compliance lead and auditor can trace each classification back to specific systems and contracts.
- Handover includes a review session where your team confirms the findings and owns the final business associate determination.
How we support
- Ongoing support is available as a retainer for changes to systems, new vendors or new data flows that could alter your status.
- Retainers can cover periodic re-mapping of ePHI flows, configuration reviews and updates to the documented evidence.
- Confirm with your legal counsel and, where relevant, HHS guidance on cloud computing before relying on any classification.
