What Should Be in Your BAA and SOW: A Buyer's Checklist

What Is the Difference Between a BAA and an SOW?

A Business Associate Agreement addresses the obligations that govern how a vendor may handle protected health information under HIPAA. A Statement of Work defines the commercial terms of a project -- what will be delivered, by whom, when, how, and for how much. They address fundamentally different questions, and neither is a substitute for the other.

A Business Associate Agreement is a written contract required under HIPAA (45 CFR § 164.504(e)) when a covered entity engages a business associate to perform functions or services involving PHI. It establishes the vendor's permitted and required uses and disclosures of PHI, the safeguards it must implement, its obligations to report incidents and breaches, its responsibilities regarding subcontractors, how it supports the covered entity's compliance duties, and what happens to PHI when the engagement ends. The BAA defines the privacy and security accountability framework for the relationship.

A Statement of Work is a commercial document that defines the specific project: the scope of services, the deliverables, the responsibilities of each party, the milestones, the acceptance process, the fees, the change-control mechanism, and the assumptions underlying the agreed scope. An SOW sits within -- or alongside -- a broader master services agreement or services contract and translates the parties' commercial agreement into a specific, executable project plan.

The two documents should work together. The SOW defines what the vendor will do and what data it will have access to during the project. The BAA defines how the vendor may handle any PHI encountered in doing that work. When one is missing, poorly drafted, or inconsistent with the other, buyers face real exposure -- a project delivered to specification that violated PHI handling requirements, or a BAA that covers data the SOW never anticipated the vendor would touch.

Documents may be structured separately, combined in a single contract, or incorporated by reference into a broader agreement. What matters is that both sets of obligations are addressed clearly and that they are consistent with each other.

When Does a Healthcare Software Buyer Need a BAA?

A BAA is generally required when a HIPAA-covered entity engages a vendor that qualifies as a business associate -- a person or entity that creates, receives, maintains, or transmits PHI on behalf of the covered entity in performing a function or activity for it, subject to applicable HIPAA rules and exceptions. Whether a specific vendor requires a BAA depends on its actual role in the engagement, not on what it calls itself or how its services are marketed.

Under HIPAA, a covered entity is typically a healthcare provider that electronically transmits health information in connection with covered transactions, a health plan, or a healthcare clearinghouse. A business associate is a person or entity that performs certain functions or activities on behalf of, or provides certain services to, a covered entity -- and those functions or activities involve the use or disclosure of PHI (45 CFR § 160.103).

In a healthcare software project, the vendor's actual activities determine whether it qualifies as a business associate. A development team that builds an application but never receives, accesses, or handles real patient data -- working only with synthetic or fully de-identified test data -- may not meet the definition. A development team that is given access to production systems, receives patient records for integration testing, or operates software that processes PHI as part of its contracted services almost certainly does. The relevant question is not whether the vendor is a software company, an integrator, or a cloud provider -- it is whether that vendor, in the course of this specific engagement, creates, receives, maintains, or transmits PHI on behalf of the covered entity.

Subcontractors that handle PHI on behalf of a business associate are themselves subject to HIPAA's business associate provisions under the 2013 Omnibus Rule. This means that if a development vendor engages a subcontractor -- a cloud hosting provider, a data processing firm, a QA partner -- that will handle PHI, those subcontractors also require appropriate BAA arrangements.

Buyers who are uncertain about whether their vendor or a specific engagement requires a BAA should confirm applicability with qualified privacy or legal counsel before the vendor receives any PHI or begins work that would involve it. A conservative approach is to identify the question early -- before the project is scoped and priced -- so that appropriate protections can be built into the engagement from the start rather than retrofitted later.

How Can You Evaluate a Healthcare Software Development Partner Before Signing?

Before signing a contract with a healthcare software development vendor, buyers should evaluate whether the vendor understands the technical, security, operational, and regulatory requirements of building software in a healthcare context -- not only whether it can write code. A vendor with genuine healthcare experience approaches project scoping, data handling, security practices, and documentation differently from one whose experience is primarily in other industries.

Key areas to evaluate before committing to an engagement include: the vendor's experience with HIPAA-compliant software development, its documented security practices and controls, its familiarity with EHR integrations and health data standards, its approach to regulated software documentation, and its track record with similar healthcare products. Experience with healthcare app development specifically -- including its understanding of data flows, access controls, and compliance design -- is more predictive than general technical capability alone.

Vendor evaluation is distinct from contract negotiation, but the two inform each other. The questions a buyer asks during evaluation -- about data access, subcontractor arrangements, security practices, documentation, and project methodology -- should directly shape the specificity and requirements of the BAA and SOW before either document is finalized.

What Should a BAA Include to Protect PHI?

A BAA should, at minimum, satisfy the requirements of 45 CFR § 164.504(e), which establishes what a business associate contract must contain under HIPAA. Beyond statutory requirements, buyers can -- and typically should -- negotiate additional protections that reflect the specific nature of the engagement, the sensitivity of the PHI involved, and the operational realities of the project.

The following checklist identifies the primary elements. Items are labeled to distinguish HIPAA requirements from recommended contractual protections and project-specific considerations.

A. Permitted uses and disclosures

• The agreement specifies the PHI the business associate may access, use, or disclose, and for what purposes. HIPAA requirement
• Uses and disclosures beyond what is necessary for the agreed services are prohibited. HIPAA requirement
• If the vendor may use PHI for data analytics, product improvement, model training, or AI-related processing, those uses are explicitly addressed -- permitted, restricted, or prohibited. Recommended protection
• Secondary uses of PHI -- de-identified data, aggregated outputs, performance benchmarking -- are addressed. Recommended protection

B. Safeguards and security responsibilities

• The business associate must implement appropriate administrative, physical, and technical safeguards to protect PHI. HIPAA requirement
• The agreement identifies which party is responsible for which specific safeguards where responsibilities may overlap. Recommended protection
• Access controls, authentication, encryption standards, audit logging, and monitoring requirements are addressed in sufficient specificity for the engagement. Recommended protection
• The agreement distinguishes between what HIPAA requires and what additional security measures the parties have agreed to beyond the statutory floor. Recommended protection

C. Incident and breach notification

• The business associate must report breaches of unsecured PHI to the covered entity without unreasonable delay and no later than 60 calendar days after discovery. HIPAA requirement
• The business associate must report any security incident of which it becomes aware. HIPAA requirement
• The agreement specifies what information must be included in a breach report, consistent with applicable HIPAA breach notification requirements. HIPAA requirement
• The agreement identifies escalation contacts, reporting channels, and notification timelines for different event types. Recommended protection
• Cooperation and documentation obligations for incident investigation and mitigation are clear. Recommended protection
• Responsibilities for notifying affected individuals and relevant regulators -- and who bears those obligations -- are addressed. Recommended protection

Note: The 60-day outer limit is the statutory maximum under HIPAA. The applicable legal standard for a specific breach depends on the facts, and contracted notification timelines shorter than the statutory maximum may be agreed and are common.

D. Subcontractors and downstream vendors

• The business associate must ensure that subcontractors that create, receive, maintain, or transmit PHI on its behalf agree to the same restrictions and conditions as the business associate. HIPAA requirement
• The agreement identifies whether subcontractors will handle PHI and on what basis. Recommended protection
• Approval, notification, or disclosure expectations for new subcontractors are documented. Recommended protection
• The business associate's responsibility for subcontractor performance and safeguards is addressed. Recommended protection

E. Individual rights and assistance

• The business associate must support the covered entity in responding to individuals exercising applicable HIPAA rights, including access, amendment, and accounting for disclosures. HIPAA requirement
• The agreement specifies how the vendor will handle a request it receives directly from an individual. Recommended protection
• Timelines and processes for fulfilling applicable requests in a way that enables the covered entity to meet its legal obligations are agreed. Recommended protection

F. Data return, destruction, and retention

• At termination, the business associate must, where feasible, return or destroy PHI and retain no copies, or, if not feasible, extend protections to retained PHI. HIPAA requirement
• The agreement addresses how backups, logs, exports, and copies are handled at and after termination. Recommended protection
• If retention is permitted because return or destruction is not feasible, the agreement specifies how long retained data may be kept and what safeguards continue to apply. Recommended protection
• The process and timeline for completing return or destruction -- and confirming it in writing -- are documented. Recommended protection

G. Termination and enforcement

• The covered entity must be able to terminate the agreement if it knows of a pattern or practice by the business associate that constitutes a material breach, where cure is not possible or not accomplished. HIPAA requirement
• Escalation and cure processes for material violations are defined. Recommended protection
• Continuing obligations -- particularly for PHI handling -- that survive termination are identified. HIPAA requirement
• How the BAA interacts with the master services agreement and SOW on termination is clear. Recommended protection

H. Cooperation, documentation, and audit-related provisions

• The business associate must make its internal practices, books, and records available to the Secretary of HHS for compliance determinations. HIPAA requirement
• What evidence of controls the buyer can request -- and through what process -- is addressed. Recommended protection
• Compliance-related cooperation rights, assessment frequency, notice requirements, and confidentiality protections for audit results are scoped and agreed. Recommended protection

What Should an SOW Include for a Healthcare Software Project?

An SOW for a healthcare software project should be specific enough that both parties can determine, at any point, what has been delivered, what remains to be delivered, and how quality and acceptance will be measured. Vague or template-driven SOWs are among the most reliable predictors of scope disputes, budget overruns, and failed deliveries in technology projects. Healthcare adds additional dimensions -- security, interoperability, regulatory documentation -- that generic SOW templates rarely address adequately.

A. Project scope and exclusions

• The business problem or clinical objective the software addresses is stated. Project-specific
• The specific services to be delivered are defined at a level that distinguishes them from what is not included. Project-specific
• Included features, integrations, environments, and workflows are listed explicitly. Project-specific
• Explicit exclusions -- features, integrations, environments, or use cases not covered -- are documented. Recommended protection
• Assumptions on which the scope and estimate are based are identified. Recommended protection
• Dependencies on the buyer, third parties, or existing systems are clear. Project-specific

B. Deliverables and acceptance criteria

• Concrete deliverables are named, not described in general terms. Recommended protection
• Functional and nonfunctional requirements are addressed, including security, privacy, interoperability, performance, and accessibility where relevant. Recommended protection
• How deliverables will be tested and accepted is defined -- who tests, what criteria must be met, what constitutes a defect, and how defects are prioritized. Recommended protection
• Who approves acceptance and who has authority to approve on the buyer's side is named. Project-specific
• How unresolved acceptance disputes are escalated is documented. Recommended protection

C. Milestones, schedule, and dependencies

• Milestones and expected outputs are defined. Project-specific
• Buyer responsibilities -- approvals, data access, decisions -- that affect the schedule are documented with their own deadlines. Recommended protection
• External dependencies, third-party integrations, and access requirements that could affect delivery are identified. Project-specific
• How delays, changed priorities, and material dependency failures will be communicated and documented is agreed. Recommended protection

D. Fees, billing, and change control

• Pricing structure, payment milestones, and billing schedule are documented. Project-specific
• What is included and excluded from the agreed fee is explicit. Recommended protection
• How change requests are submitted, estimated, approved, and documented is defined. Recommended protection
• How scope changes affect fees, timelines, and deliverables is agreed in advance. Recommended protection
• Unexpected integration or compliance requirements that could affect cost are addressed -- what happens if they arise, and who decides how to proceed. Recommended protection

E. Responsibilities and decision rights

• Named roles for product, engineering, security, privacy, and project management are documented for both parties. Project-specific
• Approval authority, escalation paths, and who can authorize scope or budget changes are clear. Recommended protection
• Who has authority to accept deliverables, sign off on testing, and authorize release is identified. Project-specific

F. Testing, documentation, and handover

• Test plans, test evidence, defect classification, and release criteria are agreed. Recommended protection
• Documentation and training deliverables are defined. Project-specific
• Deployment, support, and maintenance responsibilities after delivery are clear. Project-specific
• Source code, repositories, infrastructure configurations, credentials, and access to be transferred are identified and scheduled. Recommended protection
• Operational support expectations and any agreed service levels are documented. Project-specific

G. Intellectual property and third-party components

• Ownership and licensing of deliverables -- work product, code, configurations, documentation -- are specified. Recommended protection
• Pre-existing tools, libraries, frameworks, and third-party components included in the deliverables are identified. Recommended protection
• Open-source obligations where relevant to the deliverables are addressed. Recommended protection
• Restrictions or dependencies that may affect the buyer's ability to modify, maintain, or transfer the software to another vendor are identified. Recommended protection

Note: Intellectual property provisions may sit in the master services agreement rather than the SOW itself. Where this is the case, the SOW should be consistent with those provisions and reference them clearly, so there is no ambiguity about ownership of project-specific deliverables.

H. Security and privacy responsibilities

• What data the vendor can access in each environment -- development, test, staging, production -- is documented. Recommended protection
• Whether test, staging, or development environments may contain PHI is addressed explicitly, with controls specified. Recommended protection
• Approved data-transfer and storage methods are identified. Recommended protection
• Access management, credential handling, and offboarding procedures are agreed. Recommended protection
• Security testing, vulnerability identification, remediation timelines, and incident escalation are addressed. Recommended protection
• The SOW is consistent with -- and does not contradict -- the BAA and other applicable security or privacy obligations. Recommended protection

How Should the BAA and SOW Work Together?

The BAA and the SOW must be consistent with each other. Inconsistencies between them are not merely a drafting inconvenience -- they create real ambiguity about which obligations govern and which party bears responsibility when a situation arises that both documents touch. Buyers who review each document in isolation, without checking alignment between them, routinely discover conflicts only after a problem has occurred.

Areas where alignment matters most:

• Definitions of PHI and sensitive data: If the SOW uses a different definition of "health data" or "personal information" than the BAA uses for PHI, the vendor may comply with the SOW while acting outside the BAA's permissions -- or the buyer may think it has PHI protections where none apply.
• Permitted processing and project activities: The SOW describes what the vendor will do. The BAA describes what uses of PHI are permitted. If the SOW calls for an activity -- data migration, analytics, AI model training, load testing with production data -- that is not addressed or authorized in the BAA, neither document resolves the question of whether that activity is permitted.
• Subcontractors and third-party services: If the SOW identifies third-party hosting, analytics, or testing services, the BAA should address whether those vendors require their own BAA arrangements.
• Incident reporting and escalation: The BAA sets minimum reporting obligations. If the SOW contains separate escalation or incident-communication obligations, check whether they are consistent or whether they create conflicting timelines and contacts.
• Testing and acceptance: If the SOW calls for acceptance testing using real patient data, the BAA must clearly authorize that use and the associated data access. If the BAA does not, the parties need to resolve the inconsistency before testing begins.
• Data return and destruction: The BAA governs what happens to PHI at termination. The SOW should be consistent with those provisions and should not leave open a scenario where the vendor retains data that the BAA requires to be returned or destroyed.
• Order of precedence: Many agreements include an order-of-precedence clause that specifies which document controls in the event of a conflict. Buyers should read this language carefully and understand which document wins in specific scenarios. It is common for parties to agree that the BAA governs for all PHI-related matters -- but this must be stated, not assumed.

Which Questions Should Buyers Ask a Vendor Before Signing?

Buyers should use pre-contract discussions to turn a vendor's general assurances into specific written commitments -- before either document is executed. The questions below help identify gaps in a vendor's understanding, uncover operational facts that affect the contract, and build the specificity that makes a BAA and SOW enforceable rather than aspirational.

Where a vendor's answers are vague, conditional, or rely on "standard practices" without specifics, ask for those specifics in writing before signing. The contract is only as strong as what it actually says.

Which BAA and SOW Mistakes Should Healthcare Buyers Avoid?

The most common contract mistakes in healthcare software engagements are not exotic -- they are foreseeable gaps that buyers discover too late. Most can be avoided through deliberate review before execution.

• Treating a signed BAA as proof of HIPAA compliance. A BAA documents the parties' obligations; it does not establish that a vendor's actual practices comply with those obligations. Buyers should separately verify that vendors have the controls in place to honor what the BAA requires. Prevention: Ask for evidence of security controls, not just a signed document.
• Assuming every vendor needs a BAA -- or that a software-only engagement never does. The requirement depends on the vendor's actual role in the engagement. Software development teams that access production PHI need a BAA; those that work only with de-identified or synthetic data generally do not. Prevention: Analyze the specific engagement, not the vendor's category.
• Using generic deliverable descriptions. "Develop a patient portal" describes an outcome, not a deliverable. Without specifics, acceptance disputes are almost guaranteed. Prevention: Define deliverables at the feature and integration level.
• Leaving acceptance criteria undefined. If the SOW does not say what "done" means, the vendor's definition controls. Prevention: Specify functional, security, performance, and interoperability criteria with measurable standards.
• Failing to identify subcontractors and third-party dependencies. A primary vendor's BAA does not automatically extend to its subcontractors. Prevention: Require the vendor to disclose all subcontractors that will handle PHI and confirm BAA coverage before project start.
• Allowing unclear breach notification terms. Notification timelines, required content, and escalation contacts left to inference create chaos when an incident occurs. Prevention: Specify notification timelines, contacts, and minimum required information in the BAA.
• Overlooking PHI in development, testing, analytics, support, or backups. PHI does not exist only in production systems. Development environments, QA environments, backup systems, support tickets, and analytics pipelines all require assessment. Prevention: Map all environments where vendor personnel may access data and address each in the BAA and SOW.
• Leaving data return, destruction, and transition vague. "Return or destroy PHI at the end of the engagement" is not a plan. Prevention: Define timelines, confirmation requirements, and what happens to backups, logs, and copies.
• Failing to reconcile the BAA, SOW, and master services agreement. Conflicting order-of-precedence clauses, overlapping indemnification provisions, and inconsistent data definitions between documents create ambiguity that is resolved under pressure rather than by design. Prevention: Review all three documents together before signature.
• Relying on verbal promises. "We'll use synthetic data for testing" means nothing if it is not in the contract. Prevention: Document commitments in writing before execution.
• Assuming a security certification settles vendor risk. A SOC 2 report or ISO 27001 certificate describes a vendor's own controls at a point in time -- it is not an assessment of the vendor's fitness for your specific engagement or a guarantee that all applicable requirements are met. Prevention: Review what the certification covers, its scope, and its limitations in the context of your project.

What Should You Check Before Signing Your BAA and SOW?

Before either document is executed, buyers should work through a consolidated pre-signature review to confirm that both the BAA and the SOW address their respective obligations adequately -- and that the two documents are consistent with each other and with the master services agreement.

BAA readiness

• The vendor's role has been assessed and BAA applicability confirmed with appropriate review.
• Permitted PHI uses and disclosures are clearly defined and appropriate for the project.
• Safeguards and security responsibilities are documented and assigned to named parties.
• Breach notification timelines, contacts, required content, and cooperation obligations have been reviewed.
• Subcontractors that may handle PHI are identified and downstream BAA obligations are addressed.
• Data return, destruction, retention terms, and post-termination obligations have been reviewed.
• Termination rights and continuing obligations are clearly stated.

SOW readiness

• Project scope, exclusions, and assumptions are explicit and agreed.
• Deliverables are named specifically, not described generically.
• Acceptance criteria are measurable and tied to specific deliverables.
• Milestones, dependencies, and buyer responsibilities are clear and include their own deadlines.
• Fees, included and excluded items, and change-control procedures are documented.
• Testing, documentation, handover, intellectual property, and post-delivery support expectations are defined.
• Security and privacy responsibilities -- including data access per environment -- are addressed.

Cross-document readiness

• The BAA, SOW, and master services agreement have been reviewed together for inconsistencies.
• Definitions of PHI and sensitive data are consistent across documents.
• Permitted data access and uses match the actual project activities described in the SOW.
• Contractual responsibilities have named owners on both sides.
• Order-of-precedence language is understood, and PHI-related matters are governed by the BAA.
• Unresolved legal, privacy, security, or commercial questions have been escalated before signing -- not deferred to post-signature.

Buyers with questions about how applicable HIPAA requirements interact with their specific engagement -- including whether a BAA is required, what it must contain, and how it should align with their broader contract structure -- should consult qualified legal counsel, a privacy attorney, or an experienced compliance professional before execution. The costs of careful pre-signature review are consistently lower than the costs of resolving contract disputes or compliance gaps after work has begun.