Business Associate Agreement (BAA): What It Is, What HIPAA Requires, and Why a Contract Alone Cannot Protect PHI

Every healthcare organization relies on business associate agreements to govern how third-party vendors use and protect patient data.

A BAA defines what a vendor is permitted to do with protected health information (PHI), what safeguards it must maintain, what happens when something goes wrong, and what happens to the data when the relationship ends.

But a BAA has an inherent limitation:

Once plaintext PHI leaves a healthcare organization and enters a vendor environment, the organization is largely relying on that vendor's systems, credentials, employees, subcontractors, and security controls to honor the agreement.

Seald Healthcare changes that model by turning contractual restrictions into cryptographically enforceable access policies at the individual-record level.

What Is a Business Associate Agreement?

A business associate agreement, or BAA, is a written contract required under HIPAA between a covered entity and a business associate that creates, receives, maintains, or transmits PHI on its behalf.

Business associates can include revenue cycle companies, clearinghouses, cloud providers, analytics platforms, billing companies, health technology vendors, and AI providers.

Under HIPAA, the agreement establishes how the business associate may use or disclose PHI and requires appropriate safeguards for protecting that information.

The BAA is therefore an essential part of healthcare data governance.

But governance and enforcement are not the same thing.

What Does HIPAA Require a BAA to Include?

Under 45 CFR § 164.504(e), a business associate agreement generally must establish permitted uses and disclosures of PHI, require appropriate safeguards, require reporting of unauthorized uses or disclosures, extend applicable restrictions to subcontractors, address the return or destruction of PHI at termination, and allow termination when a material provision of the agreement is violated.

Those requirements matter. They define the vendor's legal and contractual obligations.

The problem begins after the agreement is signed.

A contract may say that only certain employees may access PHI. It may prohibit access outside an approved purpose. It may require access to end when the contract terminates.

But unless those requirements are connected to the data itself, the organization still depends on the vendor to implement and continuously maintain the controls necessary to make those promises true.

A BAA Is a Promise. It Is Not a Security Control.

Consider a typical healthcare vendor relationship.

A health system executes a BAA with a revenue cycle management company. The agreement limits the vendor's use of PHI to billing activities and requires it to safeguard the information.

The health system then sends patient data to the vendor.

Traditionally, that data may be encrypted while traveling between the two organizations. But once it reaches the vendor environment, it must often be decrypted so the vendor's systems, employees, applications, or downstream services can use it.

At that point, the security of the patient data depends heavily on the vendor environment.

If credentials are compromised, infrastructure is breached, an authorized account is abused, or the data is copied into another downstream system, the BAA cannot make the exposed plaintext unreadable.

The agreement can establish responsibility after an incident.

It cannot cryptographically prevent an unauthorized party from reading the data.

Third-Party Risk Has Become Healthcare Risk

Healthcare organizations increasingly depend on interconnected ecosystems of business associates, subcontractors, cloud platforms, data processors, and software vendors.

That dependency has dramatically expanded the number of environments in which PHI can be exposed.

The Change Healthcare attack demonstrated the scale of that problem. A compromise affecting one critical healthcare intermediary created consequences across providers, payers, pharmacies, and patients throughout the country.

The lesson is not that healthcare organizations should stop using vendors.

Modern healthcare cannot operate without them.

That is one of the problems Seald Healthcare was built to solve.

From a BAA on Paper to Cryptographic Enforcement

Seald Healthcare encrypts PHI at the record level before it reaches third-party environments and keeps encryption and access policies attached to the data wherever it moves or is stored.

The data does not become readable simply because someone possesses the database, file, cloud credential, or storage location.

Plaintext is produced only at an authorized read time for an authorized user, device, service, or workflow.

That changes what a BAA can become.

Instead of merely documenting what a vendor is permitted to do, the organization can translate those restrictions into access policies that are evaluated whenever protected data is requested.

If a vendor is authorized to access specific records only for a specific workflow, the policy can reflect that.

If access is permitted only from approved devices or locations, those conditions can become part of the authorization decision.

If access must stop when the agreement terminates, the organization can revoke decryption authority without depending on the vendor to locate and delete every readable copy first.

The BAA remains the legal agreement.

Seald Healthcare provides the cryptographic enforcement layer underneath it.

Policy Studio: Turn Contract Language Into Enforceable Policy

Policy Studio is where the legal and technical layers come together.

Policy Studio is powered by Marlow, Seald Healthcare's proprietary AI, which analyzes BAAs, vendor contracts, and internal security requirements and translates them into proposed access policies.

Marlow does not independently decide who gets access to patient data.

It analyzes the agreement, drafts the corresponding rules, identifies relevant restrictions, and stages them for review and approval.

Once approved, Seald Healthcare's cryptographic layer enforces those policies at the record level on every decryption request.

For example, a BAA or vendor agreement might establish that a billing vendor may access PHI only for an approved revenue cycle workflow, from managed systems, during the term of the agreement.

Policy Studio can translate those requirements into the corresponding access conditions.

If a request does not satisfy the active policy, the record does not decrypt.

The vendor receives ciphertext instead.

That is fundamentally different from asking whether a vendor has promised to comply with the rule.

The rule is enforced on the data itself.

Zero-Knowledge Record-Level Encryption

The architecture behind that enforcement matters.

Seald Healthcare manages key infrastructure separately from the patient data through a zero-knowledge architecture.

Each record is protected with its own data encryption key, and each data key is itself encrypted under key material controlled by the customer's organization. Seald Healthcare cannot independently unwrap those data keys or decrypt the underlying PHI.

The result is separation between:

That distinction matters during a breach.

Compromising a database, cloud environment, vendor system, or storage credential does not by itself provide the authority required to turn encrypted patient records into plaintext.

Authorization is evaluated when decryption is requested.

This is why Seald Healthcare is not simply another form of encryption at rest.

It is policy-governed, record-level encryption designed to remain effective across organizational boundaries. It is security that travels with your patient data.

What Vendor Onboarding Looks Like With Seald Healthcare

Seald Healthcare is designed to fit into existing healthcare data exchanges rather than replace them.

When onboarding a vendor, the healthcare organization identifies the existing workflow and the PHI being shared. Seald Healthcare integrates at the point where that data leaves the originating environment through its API, SDK, or supported workflow.

The organization then establishes who or what at the vendor is authorized to decrypt the protected records.

Policy Studio can use the applicable BAA, vendor agreement, and internal requirements to draft the access conditions governing that relationship.

Those policies are reviewed and approved by the organization.

Once deployed, PHI is encrypted at the record level before it reaches the vendor. The vendor continues receiving data through the existing operational workflow, but access to plaintext is governed by the approved policy.

Every decryption request is evaluated against that policy.

Authorized requests can decrypt the appropriate records at authorized read time.

Unauthorized requests remain ciphertext.

And when the relationship changes, access can change with it.

There is no need to renegotiate the security architecture every time a permission changes. Policies can be updated or revoked in real time.

When the Vendor Relationship Ends

BAAs typically address what must happen to PHI when a vendor relationship terminates.

Traditionally, enforcing that requirement can be difficult.

Patient data may exist across production systems, databases, backups, downstream processors, or other vendor-controlled environments. The covered entity often has to rely on contractual representations that the information has been returned or destroyed.

Record-level encryption changes the control model.

With Seald Healthcare, the organization can revoke the vendor's authority to decrypt protected records.

The ciphertext may still physically exist somewhere, but possession of ciphertext is not the same as possession of readable patient data.

The organization retains cryptographic control after the data has been shared.

Every Access Decision Becomes Verifiable Evidence

Enforcement alone is not enough. Healthcare organizations also need to know what happened.

Seald Healthcare records decryption activity, denied requests, policy changes, revocations, key activity, and relevant access context in a tamper-evident audit trail.

Organizations can see who or what accessed a record, when access occurred, and the device, location, or policy context associated with the request.

That creates a verifiable history across vendor relationships rather than relying solely on logs maintained independently by each business associate.

The same evidence can support security reviews, incident response, audits, regulatory inquiries, and cyber insurance underwriting.

The BAA Should Be the Beginning of Vendor Security, Not the End

Healthcare organizations still need BAAs.

Seald Healthcare does not replace them.

It makes them more meaningful.

The BAA establishes the rules governing the relationship. Policy Studio, powered by Marlow, translates those requirements into technical policies. Seald Healthcare's cryptographic layer then enforces the approved policies on the patient data itself.

That creates a fundamentally different vendor-security model:

A vendor no longer receives unrestricted plaintext simply because a contract has been signed.

The vendor receives encrypted patient data and only the records it is authorized to decrypt, under the conditions the healthcare organization controls.

If those conditions change, access changes.

If access is revoked, the records stop decrypting.

If the vendor is breached, possession of encrypted data alone does not make the PHI readable.

The Bottom Line on Business Associate Agreements

A business associate agreement answers an important question:

Healthcare organizations should also be able to answer a second question:

That is the gap between contractual governance and cryptographic enforcement.

Seald Healthcare closes that gap with zero-knowledge, record-level encryption, policy-governed decryption, real-time revocation, and tamper-evident evidence across the healthcare data lifecycle.

Your BAA defines the rules. Seald Healthcare enforces them on the data itself.

Book a demo to see how Seald Healthcare can protect your next vendor connection.