Does a SOC 2 report mean a vendor is GDPR or HIPAA compliant?

No. SOC 2 is an auditor's opinion on a vendor's internal controls against the AICPA's Trust Services Criteria — most often Security alone. GDPR compliance depends on lawful basis, data-subject rights and an Article 28 contract; HIPAA depends on a signed BAA and the Privacy and Security Rules. A vendor can hold a clean SOC 2 Type II and still be unusable for patient data or EU personal data.

Is "SOC 2 certified" a real thing?

No. SOC 2 is an attestation, not a certification — a CPA firm issues a report, not a certificate. Type I covers the design of controls on one date; Type II covers their operating effectiveness over a period, usually three to twelve months. Ask which type, which criteria were in scope, what period it covers, and whether the opinion contained exceptions.

Does a BAA make an AI tool HIPAA compliant?

It makes the vendor legally accountable for the PHI it handles, on the specific products the agreement names — usually enterprise or API tiers, never consumer subscriptions. Compliance remains a property of your practice: your safeguards, training, minimum-necessary discipline and risk analysis. And the BAA must be executed before any PHI is sent; the disclosure itself is the violation otherwise.

Do I need a DPA if I use an AI chatbot at work?

If personal data of customers, patients or colleagues goes into it and you are the controller, yes — GDPR Article 28 requires a contract with the processor, plus a valid transfer mechanism such as the EU–US Data Privacy Framework or Standard Contractual Clauses. Note that consumer accounts typically cannot sign a DPA at all, so a personal subscription used for work leaves you with no processor contract in place.

Does Secret Chat AI sign a BAA or act as an enterprise processor?

No. Secret Chat AI is a privacy-focused gateway for individuals, not a HIPAA or enterprise compliance solution; it does not sign BAAs and should not be relied on as a compliance control. What it does is reduce exposure: no server-side chat archive, local-only history, and anonymized access so your queries are never associated with you. Redacting sensitive details before sending remains your responsibility.

If a vendor has all three — SOC 2, BAA and DPA — is my data safe?

It is well governed, which is not the same thing. All three allocate accountability after the fact; none of them prevents a breach, overrides a court order, or removes data already absorbed into a trained model. The only control that does not depend on someone else's audit is what you choose not to send.

SOC 2, BAAs and DPAs for AI Tools Explained

Published July 27, 2026

This article is general information, not legal advice. Data protection and healthcare privacy law differ by country and are evolving quickly around AI. For your own situation, consult a qualified lawyer or your compliance officer. Your use of Secret Chat is governed by our Terms of Service and Disclaimers.

Three acronyms decide whether an AI tool is usable with sensitive data, and they are constantly confused for one another. A SOC 2 is an auditor's report about how a vendor runs its own security program. A BAA is a US contract that lets a vendor legally touch health data. A DPA is a European contract that lets a vendor process personal data on your behalf. They come from different worlds — an accounting body, a health statute, and the GDPR — they answer different questions, and none of them is a substitute for the other two. More importantly, none of them does what most buyers assume: they do not keep your data out of anyone's hands. They decide who is answerable when something goes wrong. This guide explains each one precisely, shows exactly where the AI industry's version of each is narrower than it looks, and gives you the questions to ask before your data leaves the building.

The One-Minute Version

SOC 2 — an attestation report written by a CPA firm about a vendor's internal controls. Answers: "does this company operate a security program that works?" Says nothing about whether it trains on your data.
BAA (Business Associate Agreement) — a contract required by the US HIPAA rules before a vendor may handle protected health information. Answers: "may I legally send patient data here?" Covers specific products, not whole companies.
DPA (Data Processing Agreement/Addendum) — a contract required by GDPR Article 28 whenever someone processes personal data on your instructions. Answers: "is this vendor bound to act as my processor, and on what terms?" Usually unavailable on consumer accounts.

Three more distinctions are worth fixing in your head before anything else, because almost every vendor page blurs them: a law (GDPR, HIPAA) is what you must obey; a contract (BAA, DPA) is what a vendor promises you; a certification (ISO 27001, ISO 42001) is a third party's formal declaration of conformity; and an attestation (SOC 2) is an auditor's opinion on the vendor's own description of itself. Only the first is binding on you. The rest are evidence — of varying strength — about somebody else.

SOC 2: What the Badge Actually Certifies (Nothing)

SOC 2 comes from the American Institute of CPAs. A licensed accounting firm examines a service organization's controls against the Trust Services Criteria and issues a report. The first thing to internalize: there is no such thing as a SOC 2 certificate. Nobody is "SOC 2 certified" — a vendor has a SOC 2 report, and the report is normally shared under NDA. A public logo on a marketing page is not the report, and it tells you none of the five things that matter:

Which criteria were in scope. There are five categories — Security, Availability, Processing Integrity, Confidentiality, Privacy. Only Security (the "common criteria") is mandatory; the other four are optional, and most vendors include none of them. A SOC 2 with only Security in scope has, by construction, no opinion on confidentiality of your data or on privacy practices.
Type I or Type II. A Type I report says the controls were suitably designed on a single date — a snapshot, achievable in weeks. A Type II says the controls operated effectively across a period, typically three to twelve months. Type I is a plan; Type II is evidence. Treat a proud "SOC 2 (Type I)" announcement accordingly.
What the system description covers. Section 3 of the report defines the boundary — which products, which environments, which infrastructure. A company with a five-year-old SOC 2 for its core platform may have shipped an AI feature last quarter that sits entirely outside that boundary. The badge does not move when the product does.
Whether the opinion was clean. Reports can be unqualified, qualified, adverse, or a disclaimer, and Section 4 lists the auditor's tests and any exceptions found. Real reports frequently contain exceptions. Almost nobody reads that far.
What period it covers, and what happened since. A Type II covers a closed window that ended months ago. The gap between the period end and today is addressed — if at all — by a bridge letter (a management statement that nothing material changed). A bridge letter is not audited.

Two more mechanics separate people who have read a SOC 2 from people who have received one:

Carve-outs. Under the carve-out method — the norm — the vendor's own suppliers (cloud host, and often the AI model provider itself) are excluded from the audit. The report lists complementary subservice organization controls it assumes they perform, but the auditor tested none of them. The chain of trust quietly ends at the vendor's front door.
CUECs. Every report contains complementary user entity controls — the controls the vendor assumes you implement for the whole thing to hold (access reviews, MFA, correct configuration, not pasting secrets into prompts). CUECs are the section that hands part of the compliance back to the customer, and they are the single most useful page in the document.

What SOC 2 genuinely gives you is real: a company with a clean Type II covering Security has provable change management, access control, monitoring, and incident response. That is worth a great deal. It is simply not an answer to "is my prompt used for training?", "how long is it retained?", "who else sees it?", or "what happens if a court asks?" Those live in the product documentation and in your contract — nowhere near the auditor's opinion.

BAA: The One That Is Product-Specific, Not Company-Specific

Under HIPAA, a covered entity (a clinician, health plan, or clearinghouse) may let an outside vendor handle protected health information only under a signed Business Associate Agreement. The critical property, which surprises people every time: the violation is the disclosure itself. Send PHI to a vendor with no BAA in place and you have breached HIPAA at that moment — no leak, no breach notification, no harm required.

HHS publishes sample provisions, and a real BAA has to do a specific set of things: limit permitted uses and disclosures, require Security Rule safeguards, oblige the vendor to report breaches and security incidents to you, flow the same obligations down to its subcontractors, make records available to HHS, and return or destroy PHI at termination. Since the 2013 Omnibus Rule, business associates are also directly liable for parts of HIPAA — the agreement is not a polite formality.

Now the part that trips up every AI buyer. BAA coverage in AI attaches to products and endpoints, not to brands. The same company will sign for one of its offerings and refuse for another sitting on the same models:

OpenAI offers BAAs to eligible enterprise customers — its healthcare-oriented ChatGPT offering and supported API endpoints — typically paired with zero data retention, which must be applied for and enabled by an account team rather than switched on in settings. Some capabilities (live web search, for one) are explicitly not HIPAA-eligible even inside an otherwise covered account.
Anthropic will sign a BAA covering its HIPAA-ready services, such as the first-party API and Enterprise plans; the consumer and self-serve tiers — Free, Pro, Max, Team, the Workbench and Console — are outside it.
Google covers Gemini through Vertex AI on Google Cloud and through eligible Workspace tiers under its Cloud BAA. The consumer Gemini app is not covered, regardless of how carefully it is used.

So "Does OpenAI sign BAAs?" is the wrong question. The right one is: "Is the exact plan, endpoint and feature set I will use listed as covered, in writing, and is the agreement executed before the first record moves?" Consumer subscriptions — the ones a solo practitioner actually buys — are outside all of it. That is the whole subject of our guide on whether ChatGPT is HIPAA compliant for therapists and coaches.

Two closing nuances. First, a BAA is a contract, not a control: it encrypts nothing and deletes nothing. It allocates liability and creates notification duties. Second, being outside HIPAA — as coaches, most consultants, and most SaaS companies are — removes the statute but not the duty. State laws increasingly reach consumer health data regardless of covered-entity status (Washington's My Health My Data Act is the sharpest example), and professional ethics never asked whether HIPAA applied.

DPA: The European Contract That Decides Who Is Answerable

Under the GDPR you are the controller when you decide why and how personal data is processed; a vendor acting on your instructions is a processor. Article 28 says you may only use processors offering sufficient guarantees, and that the relationship must be governed by a contract containing a defined list of terms. A DPA is that contract. Its mandatory content is worth knowing because it doubles as a review checklist — the processor must:

process personal data only on your documented instructions, including for transfers;
ensure everyone handling the data is under a duty of confidentiality;
implement the Article 32 security measures;
engage sub-processors only with your authorization and under the same obligations;
assist you with data-subject rights requests, and with security, breach notification and impact assessments (Articles 32–36);
delete or return the data at the end of the service;
make available the information needed to demonstrate compliance and allow audits.

Then comes the clause that matters most for AI, and that almost no vendor page mentions. Article 28(10): a processor that determines the purposes and means of processing becomes a controller for that processing. Training a model on your customers' data is exactly that — the vendor pursuing its own purpose. This is why "we do not train on business/API data" language in a DPA is not marketing garnish; it is the sentence that keeps the vendor a processor instead of an independent controller you never authorized.

Three structural traps follow:

The consumer tier usually cannot execute a DPA at all. OpenAI's DPA, for instance, requires a business account — personal accounts cannot sign it. An employee using a personal chatbot subscription for work data therefore has no Article 28 chain whatsoever. That is the real shape of "shadow AI" risk: not a leak, but a processing relationship that legally does not exist.
A DPA does not create a lawful basis. You remain the controller: the legal basis, the transparency notice, the DPIA where required, and the decision to send in the first place are yours. A signed DPA does not make an unlawful disclosure lawful; it only regulates what the recipient may do with it.
Transfers need their own mechanism. Sending EU personal data to a US provider requires an Article 45–46 route: the vendor's self-certification under the EU–US Data Privacy Framework, or the Commission's Standard Contractual Clauses (2021/914) plus a transfer impact assessment; the UK adds its own Addendum/IDTA. The DPF survived its first court test — the EU General Court dismissed the Latombe challenge in September 2025 — but an appeal is pending before the Court of Justice, the same court that struck down Safe Harbor and Privacy Shield. Anyone relying solely on the DPF should keep SCCs ready as a fallback.

One underrated part of a DPA package: the sub-processor list. It is the only public map of who really touches your data — which clouds, which model providers, in which countries — and it comes with notification and objection rights you should actually read. If an AI vendor is a thin layer over someone else's models, the list is where that becomes visible.

The Rest of the Alphabet, Briefly

ISO/IEC 27001 — a genuine certification of an information security management system by an accredited body. Ask for the certificate and its scope statement; the scope is where the surprises hide.
ISO/IEC 42001 — the 2023 standard for an AI management system: governance of AI-specific risks, not just security. Several frontier labs, Anthropic among them, now hold it. It is currently the closest thing to an AI-specific management credential.
SOC 3 — a short, public, general-use version of a SOC 2. Fine for a website badge, useless for diligence.
HITRUST — a prescriptive, certifiable framework mapping HIPAA and others onto testable controls; common in US healthcare procurement.
FedRAMP — US federal government cloud authorization. Irrelevant to you unless you sell to the government.
GDPR / HIPAA / CCPA-CPRA / EU AI Act — laws, not badges. Nobody is "GDPR certified". The AI Act adds obligations on AI systems specifically, with transparency duties arriving through 2026 — we cover what it does and does not give you in our plain-English AI Act guide.

What None of These Documents Do

Here is the uncomfortable core of the topic. Every document above is a promise about consequences, not a reduction in exposure. Once your text has been transmitted, it has been transmitted. What the paperwork changes is who is accountable, who must tell you, and who pays. That distinction has practical consequences:

Compliant vendors still get breached. A SOC 2 Type II and a signed DPA do not stop an intrusion; they define the notification clock afterwards — see what actually happens to your chats when a provider is breached.
Compliant vendors still answer to courts. No contract overrides valid legal process. Retained data can be preserved and produced regardless of what your DPA says, as covered in Your AI Chats Can Be Subpoenaed.
Deletion rights stop at the model. Even a perfect Article 28 chain cannot remove data absorbed into trained weights — only stored copies. That gap is the subject of GDPR and the right to erasure.
Retention lives outside all three. Default retention windows, human review for abuse monitoring, and whether zero-retention is available on your endpoints are product facts, documented in product docs. Our 13-provider retention audit exists because no badge answers this.
Training defaults live outside all three too. Whether your conversations feed the next model is a settings-and-terms question, not an audit question — the per-platform steps are in our 2026 opt-out guide and the concept in training opt-out.

Which leads to the one rule that outranks the entire alphabet: data you never send needs no paperwork. Minimization is the only control that does not depend on somebody else's auditor, somebody else's uptime, or somebody else's lawyer.

The Diligence Checklist That Actually Works

Ten questions, in the order that saves the most time. Any vendor selling to regulated buyers can answer all of them in writing.

1. Which exact plan, endpoint and features are covered by the BAA / DPA / SOC 2 — named, in writing?
2. May I see the full SOC 2 Type II report (not the badge), including Section 4 exceptions and the CUECs, plus a bridge letter for the gap since period end?
3. Is the AI feature itself inside the audited system description, or was it shipped after the period?
4. What is the default retention, and can zero-retention be enabled on the endpoints I use?
5. Is my data used for model training or improvement by default — and where is that stated contractually, not on a marketing page?
6. Who are the sub-processors, in which countries, and what notice do I get before the list changes?
7. What is the breach notification commitment, in hours, to whom, with what detail?
8. Is there human review for safety, abuse or quality — and can it be disabled on my tier?
9. What is the transfer mechanism for EU/UK data: DPF self-certification, SCCs, or both?
10. On termination, what is deleted, from where, and by when — including backups?

If you want a fast first pass over a vendor's public documents, this prompt gets a usable triage in one shot — paste the vendor's compliance page, DPA or SOC 2 scope section after it:

You are reviewing an AI vendor's compliance documentation as a cautious data protection reviewer. From the text below, extract exactly: (1) which products, plans or endpoints each commitment applies to; (2) whether a SOC 2 is Type I or Type II, which trust services criteria are in scope, and what period it covers; (3) the default data retention period and whether zero retention is available; (4) whether customer data is used for training by default; (5) the named sub-processors and the countries involved; (6) the transfer mechanism for EU personal data; (7) the breach notification timeline. For anything not stated in the text, write "NOT STATED" instead of inferring it, and list those gaps at the end as the questions I should send the vendor. Here is the documentation:

Which Document Do You Actually Need?

You handle US patient data as a covered entity or business associate → a BAA covering your exact product, executed first. Nothing else substitutes. And keep identifiers out of prompts anyway.
You process other people's personal data in the EU/UK → a DPA plus a valid transfer mechanism, plus your own lawful basis and (often) a DPIA.
You are buying a vendor for a team and want evidence they are competently run → a SOC 2 Type II covering Security, read properly, ideally alongside ISO 27001 and — for AI-specific governance — ISO 42001.
You are an individual using AI for your own work → none of these are available to you at consumer tier, and that is the honest answer. Your controls are what you type, what the tool retains, and whether your identity is attached to it.

How Secret Chat AI Fits — and Its Honest Limits

That last line is where Secret Chat AI sits, so here is the straight version of what it does and does not change about this article.

What it is not. Secret Chat AI is a privacy-focused gateway for individuals, not a compliance solution. It does not sign BAAs and it is not sold as an enterprise processor arrangement. If you are a covered entity handling PHI, or a controller who needs an Article 28 contract with a named processor, you need a BAA-covered or DPA-covered path — and Secret Chat is not it. We would rather say that plainly than let a privacy claim be mistaken for a compliance claim.

What it does. It attacks the exposure side rather than the paperwork side. There is no server-side archive of your conversations — chats and files live only in your own browser's local storage, so on our side there is no history to breach, subpoena or forget. And Secret Chat is an anonymizer: it builds no profile of you, no chat is ever associated with you, your queries reach the top LLMs anonymously, and they are never used for training. Your email is used only for account access and payment — never linked to your prompts. So even where a model provider retains API data under its own terms, that record is not tied to your name, account or IP; you use the model as a stranger.

What it does not do. Secret Chat AI removes you from your queries — it does not remove the data from your messages. Whatever you type still reaches the model provider verbatim (anonymously, but verbatim), and that provider processes it under its own terms. Anonymity is not a legal exemption: if you paste a client's, patient's or employee's personal data into a prompt, the responsibility for that disclosure is yours, and redacting identifying details before sending remains your job here exactly as with any other tool. For teams whose answer to that is "then we will run it ourselves", we compared the trade-offs in secure gateway vs self-hosting; the professional angles are in our guides for lawyers and business owners.

Frequently Asked Questions

Does a SOC 2 report mean a vendor is GDPR or HIPAA compliant?
No. SOC 2 is an auditor's opinion on a vendor's internal controls against the AICPA's Trust Services Criteria — most often Security alone. GDPR compliance depends on lawful basis, data-subject rights and an Article 28 contract; HIPAA depends on a signed BAA and the Privacy and Security Rules. A vendor can hold a clean SOC 2 Type II and still be unusable for patient data or EU personal data.
Is "SOC 2 certified" a real thing?
No. SOC 2 is an attestation, not a certification — a CPA firm issues a report, not a certificate. Type I covers the design of controls on one date; Type II covers their operating effectiveness over a period, usually three to twelve months. Ask which type, which criteria were in scope, what period it covers, and whether the opinion contained exceptions.
Does a BAA make an AI tool HIPAA compliant?
It makes the vendor legally accountable for the PHI it handles, on the specific products the agreement names — usually enterprise or API tiers, never consumer subscriptions. Compliance remains a property of your practice: your safeguards, training, minimum-necessary discipline and risk analysis. And the BAA must be executed before any PHI is sent; the disclosure itself is the violation otherwise.
Do I need a DPA if I use an AI chatbot at work?
If personal data of customers, patients or colleagues goes into it and you are the controller, yes — GDPR Article 28 requires a contract with the processor, plus a valid transfer mechanism such as the EU–US Data Privacy Framework or Standard Contractual Clauses. Note that consumer accounts typically cannot sign a DPA at all, so a personal subscription used for work leaves you with no processor contract in place.
Does Secret Chat AI sign a BAA or act as an enterprise processor?
No. Secret Chat AI is a privacy-focused gateway for individuals, not a HIPAA or enterprise compliance solution; it does not sign BAAs and should not be relied on as a compliance control. What it does is reduce exposure: no server-side chat archive, local-only history, and anonymized access so your queries are never associated with you. Redacting sensitive details before sending remains your responsibility.
If a vendor has all three — SOC 2, BAA and DPA — is my data safe?
It is well governed, which is not the same thing. All three allocate accountability after the fact; none of them prevents a breach, overrides a court order, or removes data already absorbed into a trained model. The only control that does not depend on someone else's audit is what you choose not to send.

Conclusion

The compliance alphabet is worth learning precisely, because each letter answers a narrow question well and every other question badly. SOC 2 tells you a company is competently run; it says nothing about training or retention. A BAA tells you a specific product may legally hold health data; it protects nothing technically and covers no consumer plan. A DPA tells you a vendor is bound as your processor on European terms; it neither creates your legal basis nor reaches into model weights. Ask which exact product each document covers, read past the badge to the scope, and treat every promise as a statement about liability rather than about exposure. Then apply the rule that survives all of them: send less, attach your identity to even less, and prefer tools that keep no archive of your words and no link between your words and your name.

SOC 2, BAAs, and DPAs
The Compliance Alphabet for AI Tools, Explained Simply