HIPAA Business Associate Agreements: What Healthcare Data Teams Need to Know

Most healthcare organizations know they need a Business Associate Agreement before sharing protected health information with a vendor. What is less clear is what that agreement should actually include, how to evaluate whether it protects your organization, and what to do when a vendor’s standard terms fall short.

If your team collects patient data through online forms, intake workflows, or any web-based tool that touches PHI, reviewing the BAA is not optional. It is part of building a compliant, reliable data collection process.

What a Business Associate Agreement Is

Under HIPAA, a Business Associate is any person or entity that performs functions or services for a covered entity that involve creating, receiving, maintaining, or transmitting PHI. That definition is intentionally broad and includes software vendors, cloud storage providers, form platforms, analytics tools, and any other third party that handles patient data on your behalf.

A Business Associate Agreement is the contract that establishes the terms under which a BA can use or disclose PHI. Without a BAA in place, sharing PHI with a vendor creates a HIPAA violation, regardless of how the vendor actually handles the data.

The HHS Office for Civil Rights enforces HIPAA’s BAA requirements and has issued significant fines for organizations that failed to have agreements in place or had agreements that didn’t meet regulatory standards.

What a BAA Must Contain

The HIPAA Privacy Rule specifies the required elements of a valid BAA. An agreement that omits these provisions doesn’t satisfy the requirement even if both parties have signed it.

Permitted uses and disclosures. The BAA must describe the purposes for which the BA is permitted to use or disclose PHI. Uses beyond those described require separate authorization.

Prohibition on unauthorized use. The agreement must state that the BA will not use or disclose PHI except as permitted by the agreement or required by law.

Appropriate safeguards. The BA must agree to implement appropriate safeguards to prevent unauthorized use or disclosure, including the technical, physical, and administrative safeguards required by the HIPAA Security Rule.

Reporting obligations. The BA must agree to report any unauthorized use or disclosure and any security incidents, including breaches, to the covered entity.

Subcontractor requirements. If the BA uses subcontractors who also handle PHI, the agreement must require that those subcontractors enter into equivalent BAAs.

Access and amendment rights. The BA must agree to make PHI available for access and amendment as required by the Privacy Rule, and to support the covered entity’s obligations to individuals who exercise these rights.

Return or destruction of PHI. Upon termination, the BA must return or destroy all PHI received from the covered entity, or document why that isn’t feasible.

What to Verify Before Signing a Vendor’s BAA

Most established software vendors offering services to healthcare organizations will have a standard BAA. That doesn’t mean it’s adequate. Healthcare compliance and IT teams should evaluate a vendor BAA against several practical criteria before accepting it.

Scope clarity. Does the BAA clearly describe which services involve PHI and which don’t? Vague scope language can create ambiguity about what protections apply.

Security Rule alignment. Does the vendor commit to specific technical safeguards, or does the BAA just reference ‘appropriate safeguards’ without specifics? Strong agreements include commitments to encryption at rest and in transit, access controls, and audit logging.

Breach notification timeline. HIPAA requires breach notification to covered entities without unreasonable delay and within 60 days. Vendors should specify their internal notification timeline in the BAA.

Subprocessor coverage. If the vendor uses cloud infrastructure, data centers, or other subcontractors, the BAA should confirm that PHI handled by those subcontractors is covered by equivalent agreements.

Termination provisions. What happens to PHI when the contract ends? The BAA should specify how and when data is returned or destroyed, and what documentation the vendor will provide.

When a BAA Is Required for Data Collection

For healthcare organizations using online forms for patient intake, scheduling, clinical research enrollment, or any workflow where respondents may submit health information, the form platform is a Business Associate. A BAA is required before that platform can be used in production with real patient data.

This applies whether the platform is a dedicated healthcare tool or a general-purpose form builder. The determining factor is whether PHI is being created, received, maintained, or transmitted, not the vendor’s primary market focus.

FormAssembly offers BAAs for healthcare customers and is designed to support HIPAA-compliant data collection workflows. Data is encrypted at rest and in transit, access is controlled through role-based permissions, and audit logging captures collection events in a format that supports compliance documentation.

Common BAA Mistakes Healthcare Organizations Make

Getting a BAA signed is necessary but not sufficient for HIPAA compliance. A few common mistakes create ongoing risk even when agreements are in place.

Using a vendor for PHI workflows before the BAA is executed is the most obvious gap, but it happens frequently when teams move quickly or when a tool gets adopted without formal IT approval.

Accepting a BAA that doesn’t reflect the actual data flows is another common issue. If a vendor’s form platform will process PHI but the BAA only covers data storage, the agreement doesn’t cover the actual risk.

Not reviewing BAAs when vendor services change is a slower-developing problem. If a vendor adds new subcontractors, changes their data storage infrastructure, or updates their security practices, the BAA should be reviewed and updated to reflect those changes.

For healthcare IT and compliance teams, BAA management is an ongoing operational responsibility, not a one-time procurement checklist item. Building a vendor review process that includes BAA status as a regular check is a more reliable approach than relying on initial agreements to hold indefinitely.