Attestation Instruments vs a Business Associate Agreement
A certificate describes how a vendor works. A BAA is what makes sending it PHI lawful. Healthcare buyers keep being handed the first when they asked for the second.
The Short Answer
A controls attestation describes practice. A Business Associate Agreement allocates liability.
HIPAA requires the second before a covered entity discloses protected health information to a vendor, at 45 CFR 164.502(e). SOC 2, HITRUST, ISO/IEC 27001, ISO/IEC 42001, a HIPAA Validation Report and a GDPR Data Processing Agreement are all real artifacts produced by real work. None of them is a BAA, and none of them permits a PHI disclosure. Verified against primary sources 2026-08-05.
| Instrument | What it is | Who issues it | What it proves | Permits PHI disclosure to the vendor? |
|---|---|---|---|---|
| Business Associate Agreement | The written contract required by 45 CFR 164.502(e)(2), with required terms at 164.504(e) and 164.308(b) | Nobody issues it. The covered entity and the vendor sign it. | That the vendor is contractually bound to specified uses, safeguards, subcontractor flow-down, breach reporting and termination | Yes. It is the instrument the rule names. |
| SOC 2 Type II report | An attestation examination of security controls over an observation period | A licensed CPA firm | That specified controls were designed and operated over that period | No |
| HITRUST e1 / i1 / r2 certification | Certification against the HITRUST CSF control set, within a scope the organization defines | HITRUST, through an authorized external assessor | That the assessed controls, in the assessed scope, met HITRUST's scoring thresholds | No |
| HITRUST inherited or infrastructure-level claim | Control scores imported from a hosting or cloud provider's own HITRUST assessment | The provider's assessment, reused under HITRUST's Shared Responsibility and Inheritance Program | That the infrastructure underneath was assessed. Not that the application on top of it was. | No |
| ISO/IEC 27001:2022 certificate | Certification that an information security management system meets the standard's requirements | An accredited certification body | That a management system exists, is maintained, and is improved | No |
| ISO/IEC 42001:2023 certificate | Certification of an AI management system | An accredited certification body | That the organization runs a management system for responsible AI development, provision or use | No |
| "HIPAA Validation Report" / HIPAA attestation / readiness report | An examination of controls against HIPAA criteria the organization itself specifies, or a report generated inside a compliance-automation platform | An independent accounting or advisory firm, or the platform. Never HHS. | That specified controls were assessed against specified criteria at a point or over a period | No |
| GDPR Data Processing Agreement | The contract GDPR Article 28(3) requires between a controller and a processor | Nobody issues it. Controller and processor sign it. | That the processor is bound to EU data protection obligations | No. Different regulation, different jurisdiction. |
| "HIPAA compliant" badge on a trust center | A self-description, sometimes backed by one of the rows above | The vendor | That the vendor asserts compliance | No |
This is not legal advice, and your counsel makes the call for your organization.
One column does the work. Every row in it reads No except the first.
What the Rule Actually Requires
The requirement is short enough to read in full, which is unusual for HIPAA and is the reason this argument is settleable rather than arguable.
45 CFR 164.502(e)(1)(i) states that a covered entity may disclose protected health information to a business associate, and may let that business associate create, receive, maintain or transmit PHI on its behalf, "if the covered entity obtains satisfactory assurance that the business associate will appropriately safeguard the information."
Then 164.502(e)(2) says how that assurance has to exist: "The satisfactory assurances required by paragraph (e)(1) of this section must be documented through a written contract or other written agreement or arrangement with the business associate that meets the applicable requirements of § 164.504(e)."
A written contract. Meeting specified requirements. Section 164.504(e)(2) then lists what those requirements are, and they are contractual in a way no audit can substitute for: the contract must establish permitted and required uses, bind the business associate not to use or disclose PHI other than as permitted, require appropriate safeguards, and require it to report breaches. The Security Rule carries the parallel obligation at 164.308(b)(3), which tells a covered entity to "Document the satisfactory assurances required by paragraph (b)(1) or (b)(2) of this section through a written contract or other arrangement."
Two things follow.
First, the obligation is on the covered entity, not the vendor. The rule conditions the disclosure on the written contract. It does not condition it on how well the vendor secures the data afterward. The disclosure is the event.
Second, the rule specifies an instrument type. A written contract meeting 164.504(e). Every artifact in the table above is evidence about how a vendor operates. Only one of them is a written contract that allocates the obligations 164.504(e) enumerates.
If you want the procurement side of this, including how to obtain one by vendor type and how the subcontractor chain works, that lives in the AI vendor BAA guide.
SOC 2, In One Paragraph
SOC 2 is the instrument healthcare buyers confuse with HIPAA most often, and AuthenTech AI has already argued that case at length. The short version: a SOC 2 Type II report is a CPA firm's opinion that specified security controls operated over an observation window, it is voluntary, any software vendor can pursue it, and no volume of SOC 2 controls produces a signed BAA. The full treatment, including what the two report types differ on and what to ask a vendor for, is at SOC 2 and HIPAA for AI platforms. This page covers the instruments that page does not.
HITRUST: What Certification Means
HITRUST is the most credible artifact on the list, which is exactly why it gets over-read.
The HITRUST CSF is a control framework that, in HITRUST's own description, "harmonizes over 70 standards and regulations into a single, integrated approach for defining and assessing security controls," including HIPAA among its mapped sources (hitrustalliance.net, read 2026-08-05). Certification comes in three tiers, described by HITRUST as: e1, "Foundational cybersecurity assurance with 43 core controls," valid one year; i1, "Threat-adaptive assurance with 182 control requirements," valid one year; and r2, "Tailored assurance with the highest level of control requirements," valid two years.
Read the r2 description again. Tailored. An r2 assessment is scoped by the organization being assessed, against its own risk profile, environment and business operations. That is a defensible way to run an assessment program. It also means a HITRUST certificate is a statement about a defined scope, not about a company. Two vendors can both be "HITRUST r2 certified" and have assessed different systems.
On HIPAA specifically, HITRUST's own position is more careful than the way the certificate gets cited. Its "HITRUST and HIPAA Compliance" paper (April 2023) states that "The HITRUST Assurance Program can support assessments that include privacy requirements that map to the HIPAA Privacy Rule but does not provide a privacy-specific certification," and that "The MyCSF Compliance and Reporting Pack for HIPAA does not currently address the HIPAA Privacy Rule."
That matters more than it looks. The business associate contract requirement at 164.502(e) sits in Subpart E, the Privacy Rule. HITRUST is telling you, in its own document, that the part of HIPAA where the BAA obligation lives is the part its certification does not certify.
Note what is not being claimed here. HITRUST does not say a certification authorizes PHI disclosure. It has never said so. The gap is in how a certificate gets read across a procurement table.
The Inherited Certification
Here is the version of the HITRUST claim a compliance officer will actually meet.
HITRUST runs a Shared Responsibility and Inheritance Program. In HITRUST's own words, "Controls can be inherited from vendors, major cloud service providers (CSPs) and your organization's existing HITRUST Validated or Certified Assessments" (hitrustalliance.net, read 2026-08-05). A vendor hosted on a HITRUST-certified cloud can import that provider's control scores into its own assessment. This is a legitimate program, run by HITRUST, and it exists because reassessing a hyperscaler's physical security for every tenant would be absurd.
What it produces is a claim with two possible meanings and one sentence.
When a vendor's page says "HITRUST CSF Certified," a healthcare buyer reads it as: this application was assessed and certified. The other reading is: the infrastructure this application runs on was assessed and certified, and the application inherited those scores. Those are different claims about different systems, and the marketing sentence is often identical.
Some vendors state the distinction plainly. BastionGPT describes HITRUST CSF Certified infrastructure and SOC 2 Type II attested infrastructure and separately notes that its own certification and attestation are in progress. That is the honest form of the claim. Pursuing your own certification takes real time and money, so read it as scope information, not as a knock. Others publish a softer word entirely: Zoom AI Companion's healthcare material describes HITRUST CSF alignment, which is not certification at all and does not claim to be.
The question to ask is one word long. Whose? Then: which assessment, which scope, which tier, and can I see the report. A vendor that inherited its certification can answer that in a sentence. So can a vendor that earned its own.
Either answer is fine. Neither answer is a BAA.
ISO/IEC 27001 and ISO/IEC 42001
ISO 27001 shows up constantly in the directory. Heidi Health lists SOC 2 Type 2, ISO 27001 and US data residency on its Practice tier. Nabla lists SOC 2 Type II and ISO 27001. Both are real certifications. In both entries, the BAA question is answered separately, because it is a separate question.
ISO/IEC 42001:2023 is the newer standard, and it is the one showing up on AI vendor trust pages this year. It and ISO/IEC 27001:2022 are both management-system standards, and that phrase is doing more work than most buyers realize.
ISO describes ISO/IEC 27001:2022 as "the world's best-known standard for information security management systems (ISMS). It defines requirements an ISMS must meet," and says that "Conformity with ISO/IEC 27001 means that an organization or business has put in place a system to manage risks related to the security of data owned or handled by the company, and that this system respects all the best practices and principles enshrined in this International Standard."
ISO describes ISO/IEC 42001:2023 as specifying "the requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI management system within the context of an organization," where an AI management system is "a set of interrelated or interacting elements of an organization intended to establish policies and objectives, as well as processes to achieve those objectives, in relation to the responsible development, provision or use of AI systems."
Read what is being certified in both cases. A system for managing something. Policies, objectives, processes, and the discipline to keep them current. That is genuinely valuable and hard to obtain. It is also, precisely, a statement that the vendor has a management system, not a statement about any particular data you might send it.
What a buyer tends to assume ISO/IEC 27001 certifies: that this product is secure. What it certifies: that the organization runs a system for managing information security risk, within a scope defined on the certificate. What a buyer tends to assume ISO/IEC 42001 certifies: that this AI is safe to use with patient data. What it certifies: that the organization runs a management system covering how it develops, provides or uses AI.
Neither standard mentions HIPAA, because neither is a US healthcare instrument. ISO is a different body writing about a different thing.
The HIPAA Validation Report
This is the newest artifact on the list and the least understood, because it arrived through compliance-automation platforms rather than through a standards body.
Start with the fact that constrains everything else. There is no HIPAA certification. Not a weak one, not an unofficial one. HHS says so directly. Its Office for Civil Rights FAQ, "Are we required to 'certify' our organization's compliance with the standards of the Security Rule?", answers:
"No, there is no standard or implementation specification that requires a covered entity to 'certify' compliance... It is important to note that HHS does not endorse or otherwise recognize private organizations' 'certifications' regarding the Security Rule, and such certifications do not absolve covered entities of their legal obligations under the Security Rule. Moreover, performance of a 'certification' by an external organization does not preclude HHS from subsequently finding a security violation."
HHS marks that page content last reviewed July 26, 2013. It has not moved since.
The compliance-automation vendors say the same thing, in their own materials, without hedging. Drata's HIPAA overview, published 2026-04-20, answers whether official HIPAA certification exists with: "No. HIPAA is a U.S. federal law, not a certifiable standard like ISO 27001." Its companion piece on proving readiness (2026-06-02) states that "There is no official HIPAA certification issued by the U.S. government or any recognized standards body."
So what is the artifact? Drata names it precisely: an AT-C 315 HIPAA report, "produced by an independent accounting or advisory firm," giving "an objective, professionally validated view of your HIPAA controls." AT-C section 315 is the AICPA's Compliance Attestation standard. It governs examinations of an entity's compliance with the requirements of specified laws, regulations, rules, contracts or grants, and the effectiveness of internal control over compliance with those specified requirements.
Specified is the operative word. An AT-C 315 examination reports on the criteria management put in front of the practitioner. It is a real professional engagement with real standards behind it. What it is not is a determination by anyone that a vendor may lawfully receive PHI, because no such determination exists to be made.
Drata states the limit itself: the report "doesn't replace compliance, it proves it to audiences that require independent validation."
Who Issues It, and Why That Is Not a Contract
Three parties get confused in this artifact, so name all three.
The platform (Drata, Vanta and similar) is compliance-automation software. It maps controls, collects evidence continuously, and publishes the result to a customer-facing trust center. Vanta describes its role as helping "Business Associates meet HIPAA Security and Breach Notification Rules requirements with automated evidence, guided controls, and continuous monitoring." Neither platform certifies anyone. They say so.
The assessor is an independent accounting or advisory firm. It performs the examination and issues the report. Its opinion is about controls, against criteria, over a stated period.
HHS is not involved at any point, has not reviewed anything, and by its own FAQ does not recognize the output.
Run the artifact against 164.504(e)(2) and ask which of the required contract terms it contains. Permitted and required uses of PHI: not in it. A binding restriction on further use or disclosure: not in it. Flow-down to subcontractors: not in it. A duty to report breaches to the covered entity: not in it. Termination rights: not in it.
An attestation report has no counterparty. Nobody signs a promise to you. Nobody accepts an obligation that runs to your organization. There is no term to breach, so there is nothing to enforce and nothing to terminate. It is a description of a state of affairs, produced for the vendor, on criteria the vendor's management specified.
A BAA is the opposite object. It is signed by two parties, it allocates liability, and its terms are enumerated by regulation rather than by the vendor.
One is a report about a vendor. The other is a promise from a vendor. HIPAA requires the promise.
A note on the phrase itself. "HIPAA Validation Report" is language that appears on vendor trust pages. The platforms whose tooling produces the underlying artifact use different words for it: Drata names an AT-C 315 HIPAA report and, separately, a HIPAA readiness report. We could not find "HIPAA Validation Report" as a defined product term in Drata's or Vanta's own published materials as of 2026-08-05. Treat the phrase as a description a vendor chose, and ask which of the two things it means: an independent AT-C 315 examination with a firm's name on it, or a readiness report generated inside a platform. Ask to see it. The distinction is visible in about four seconds of reading.
A DPA Is Not a BAA
The Data Processing Agreement is the instrument most likely to be offered in good faith and accepted in error, because unlike the certifications it genuinely is a contract. It is just a contract under a different law.
GDPR Article 28(1) requires that "Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject." Article 28(3) then requires that processing "be governed by a contract or other legal act... that is binding on the processor with regard to the controller."
Structurally that is a close cousin of 164.502(e). Both say: do not hand personal data to a vendor without a written contract binding the vendor. The resemblance is why the substitution happens.
Everything else diverges.
Different regulation. GDPR is EU law. HIPAA is US federal law. Neither has authority over the other's requirement.
Different jurisdiction and trigger. GDPR Article 3(1) reaches processing "in the context of the activities of an establishment of a controller or a processor in the Union." HIPAA's business associate obligation attaches to a covered entity or business associate handling protected health information, wherever that entity operates.
Different data. A DPA governs personal data of EU data subjects. A BAA governs protected health information as HIPAA defines it.
Different obligations. A DPA carries Article 28 terms: processing on documented instructions, confidentiality, security measures, sub-processor authorization, assistance with data subject rights, deletion or return, and audit cooperation. A BAA carries the 164.504(e)(2) terms, including the HIPAA-specific ones a DPA has no reason to contain: breach reporting under the Breach Notification Rule, the minimum necessary standard, individual access and amendment obligations, and availability of records to HHS.
A vendor offering a DPA where you asked for a BAA is usually a vendor built for an EU-first market that added US healthcare customers later. That is a commercial fact, not a character flaw. It is still not the instrument 164.502(e) requires, and no amount of tier upgrade turns one into the other.
The directory has the case in it. Plaud publishes a Data Processing Agreement on its Team plan, and the worked example below reads that list against the table.
One Vendor, Six Instruments, No BAA
The clearest illustration of this entire page is a single vendor's own compliance documentation, because it publishes almost every instrument discussed above and none of the one that matters.
Plaud's compliance documentation, read against primary source on 2026-08-05, enumerates: ISO/IEC 27001:2022, ISO/IEC 27701:2019, GDPR, SOC 2 Type II, HIPAA, and EN 18031, with documents retrievable through a Drata Trust Center. On the HIPAA line it states: "Yes. Plaud has obtained a HIPAA Validation Report." The Team plan adds "Workspace-Level Data Residency and Data Processing Agreement (DPA)."
The word "BAA" does not appear in the article.
Map that against the instrument table above and every row lands somewhere already covered. ISO/IEC 27001 is a management-system certificate. ISO/IEC 27701 extends it to privacy information management, still a management system. SOC 2 Type II is a CPA firm's opinion on controls. EN 18031 is a European radio-equipment cybersecurity standard, relevant to a physical device and irrelevant to PHI disclosure. The HIPAA line resolves to a Validation Report, which the HIPAA Validation Report section has already placed. The DPA is a GDPR Article 28 instrument on one tier.
Six instruments. Two of them contracts. Neither contract is a BAA.
This is not a vendor hiding anything. It published a specific list of specific artifacts and named each one accurately. A reader who checks each name against what that name means arrives at the right answer. A reader who scans for the word "HIPAA," finds it, and stops does not.
That is the failure mode this page exists to interrupt. The second reader concludes a wearable recorder can be worn into a clinical encounter. The full verdict, the tier detail and the auto-redaction finding are in the directory entry for Plaud.
The general rule the case produces: a vendor that holds a BAA says BAA, because it is the single artifact healthcare buyers ask for first. When a list of adjacent instruments has no BAA on it, treat that as information about what exists, not as an oversight in the list.
Three Questions to Send the Vendor
What to keep on file: the countersigned BAA, the certificate or report with its scope page, the date you asked, and the date you were answered. That set is what an auditor wants.
The Governance Turn
Every instrument on this page describes a vendor. None of them describes your organization, and the vendor question is usually the second-most urgent one in the room.
A hospital can run a flawless attestation review, decline the tool, document the decision, and still have staff pasting patient detail into that same tool from a personal account by Thursday. Attestations govern procurement. They do nothing about the tools that never went through procurement, which is most of them. That is shadow AI, and it is the half of this problem a per-vendor verdict does not touch.
The pattern that works is a sanctioned path that is easier than the unsanctioned one. Route staff AI use through a governed layer that holds the contractual paper, screens sensitive data before anything reaches a model provider, and logs every interaction, so the answer to "what did we send" is a query rather than an interview. That is what the AuthenTech AI governed platform (ours) does, and it is why the useful artifact at audit time is a queryable log rather than a folder of vendor certificates.
FAQ
Is a HIPAA Validation Report the same as a BAA?
No. A HIPAA Validation Report is an assessment artifact. Depending on who produced it, it is either an independent examination of controls against HIPAA criteria the organization specified, typically under AICPA standard AT-C 315, or a readiness report generated inside a compliance-automation platform. Either way it is a report about a vendor, not a contract with a vendor. HIPAA requires a written contract before a covered entity discloses PHI, at 45 CFR 164.502(e)(2). An attestation has no counterparty, allocates no liability, and contains none of the terms 164.504(e)(2) requires.
Does HITRUST certification mean a vendor is HIPAA compliant?
No. HITRUST certification means an assessed set of controls, within a scope the organization defined, met HITRUST's thresholds. HITRUST's own "HITRUST and HIPAA Compliance" paper (April 2023) states that its Assurance Program "does not provide a privacy-specific certification." The business associate contract requirement sits in the HIPAA Privacy Rule at 45 CFR 164.502(e). A HITRUST certificate is meaningful evidence about a vendor's security program and it is not the contract HIPAA requires.
What does "HITRUST certified infrastructure" mean?
It means the vendor inherited control scores from its hosting or cloud provider's HITRUST assessment rather than holding its own certification for its application. HITRUST runs this formally through its Shared Responsibility and Inheritance Program, under which "Controls can be inherited from vendors, major cloud service providers (CSPs) and your organization's existing HITRUST Validated or Certified Assessments." The program is legitimate. The claim is just narrower than "we are HITRUST certified" sounds. Ask whose assessment it is.
Does ISO 27001 or ISO 42001 cover HIPAA?
No. Both are management-system standards published by ISO, not US healthcare instruments, and neither addresses HIPAA. ISO/IEC 27001:2022 certifies that an organization has an information security management system meeting the standard's requirements. ISO/IEC 42001:2023 certifies an AI management system covering the responsible development, provision or use of AI systems. Each certifies that a system for managing risk exists and is followed, within the scope stated on the certificate.
Is a DPA enough for HIPAA?
No. A Data Processing Agreement is a contract required by GDPR Article 28(3) between a controller and a processor handling personal data under EU law. HIPAA's requirement is a separate contract under 45 CFR 164.502(e), with terms enumerated at 164.504(e)(2) that a DPA has no reason to include, among them breach reporting under the Breach Notification Rule, the minimum necessary standard, and availability of records to HHS. Different regulation, different jurisdiction, different obligations. A DPA does not make a vendor a business associate.
Is there such a thing as HIPAA certification?
No. HHS states in its Office for Civil Rights FAQ that no standard requires a covered entity to certify compliance, that "HHS does not endorse or otherwise recognize private organizations' 'certifications' regarding the Security Rule," and that such certifications "do not absolve covered entities of their legal obligations under the Security Rule." Compliance-automation vendors say the same. Drata's HIPAA overview answers the question directly: "No. HIPAA is a U.S. federal law, not a certifiable standard like ISO 27001."
What about SOC 2?
SOC 2 Type II is a licensed CPA firm's opinion that specified security controls operated over an observation window. It is voluntary, available to any software vendor, and not a substitute for a BAA. AuthenTech AI covers SOC 2 and HIPAA in full at SOC 2 and HIPAA for AI platforms, including what to ask a vendor to produce.
Then what is a BAA actually for?
It is the written contract that permits the disclosure and allocates what happens afterward. Under 45 CFR 164.504(e)(2) it establishes permitted and required uses of PHI, binds the business associate not to use or disclose it otherwise, requires appropriate safeguards, requires breach reporting, and flows the same obligations down to subcontractors. Certifications tell you how carefully a vendor works. A BAA is what makes handing that vendor PHI lawful. Procurement detail is in the AI vendor BAA guide.
Do these instruments matter at all, then?
Yes. A BAA with a vendor that has no security program is a signature on a liability. Certifications are how you judge whether a vendor can be trusted to do what the BAA obliges it to do. The order is what matters: the BAA determines whether PHI may go to the vendor at all, and the attestations inform whether you want it to.
Is this legal advice?
No. This is not legal advice, and your counsel makes the call for your organization.
Related Resources
The contractual layer, the instruments, and the tools they get attached to
AI Vendor BAA Guide
What a BAA requires, and how to obtain one from each vendor type
Read article →SOC 2 and HIPAA for AI Platforms
The SOC 2 half of the attestation question, in full
Read article →PHI and AI
What counts as PHI, de-identification, and the minimum necessary standard
Read article →AI Tool HIPAA Compliance Directory
Every "is X HIPAA compliant" verdict in one sourced, dated directory
Read article →Is Plaud HIPAA Compliant?
The worked example: six published instruments, no BAA
Read article →Is BastionGPT HIPAA Compliant?
Inherited infrastructure certification, stated plainly
Read article →The Instrument Question Is Easier When the Policy Already Names It
A tool review that starts at the BAA and works outward takes minutes. The reviews that go wrong are the ones with no written standard for what an acceptable answer looks like. Generate a healthcare-ready acceptable use policy that names the instrument, the tier condition, and the evidence to keep on file, then hold every vendor to the same line.