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

Published July 27, 2026 · Updated August 18, 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 lawfully handle protected health information. A DPA is a European contract that binds a vendor to 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. The two contracts do impose real, preventive obligations: safeguards, purpose limits, subprocessor control, deletion duties. What none of them does is the thing most buyers quietly assume — they cannot un-send your data, and they cannot make a breach, a subpoena or a trained model behave differently. Their protection is exactly as wide as their scope, and their scope is always narrower than the logo suggests. 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 you engage a processor to handle personal data on your behalf (your own staff are not separate processors). 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. The law binds you whether or not you sign anything. A contract binds both signatories — a BAA and a DPA impose duties on you too, which is why signing one without reading it is its own risk. Only the last two are mere evidence about somebody else, and evidence of varying strength at that.

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 offers no opinion under the Confidentiality or Privacy criteria — which is not the same as saying it ignores your data entirely, since the Security criteria do address unauthorized access and disclosure. It simply never examined the commitments those other two categories are about.
• Type I or Type II. A Type I report says the controls were suitably designed and implemented as at a single date — a snapshot, achievable in weeks. A Type II says those controls operated effectively across a period, typically three to twelve months. Type I is a real examination, but of design only: it tells you the machine was built correctly, not that anyone ran it. Treat a proud "SOC 2 (Type I)" announcement accordingly.
• What the system description covers. The system description — conventionally Section 3, though the numbering is an illustrative convention rather than a rule — 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 the tests section — conventionally Section 4, and present in a Type II rather than a Type I — 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 — common, though the inclusive method also exists — 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. Where the vendor's controls only work if you play your part, the report discloses 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, where an outside vendor handles protected health information as a business associate, the covered entity needs a signed Business Associate Agreement first. Not every disclosure creates that relationship — treatment disclosures, disclosures a patient directs to their own app, and genuine conduits sit outside it — but a vendor processing PHI on your behalf is the paradigm case that does. "Covered entity" is narrower than "anyone in healthcare": it means health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with the transactions HIPAA specifies. Plenty of clinicians qualify; not all do, and coaches and wellness apps generally do not.

The critical property, which surprises people every time: the violation is the disclosure itself. Send PHI to a vendor acting as your business associate with no BAA in place and you have breached HIPAA at that moment — no leak, no breach notification, no harm required. HIPAA does recognize situations where no BAA is needed — disclosures for treatment between providers, and the narrow "conduit" exception for services that merely transmit data without accessing it beyond what transmission requires — but an AI vendor that receives, processes and often retains the content is not a conduit, and none of those exceptions rescues a chatbot.

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 now publishes an explicit list of HIPAA-eligible products: ChatGPT for Healthcare, ChatGPT Enterprise with a Regulated Workspace, ChatGPT for Clinicians, the FedRAMP offering, and the API — including an "API with Modified Retention" variant. Note what that means: BAA coverage is no longer synonymous with zero data retention, and the healthcare workspaces are preconfigured ChatGPT Enterprise environments with certain features switched off by default. Feature eligibility still varies — search inside an eligible workspace is treated differently from live external web access on the API — so the covered unit is the workspace-and-feature combination, not "OpenAI".
• Anthropic publishes a BAA matrix, and it is worth reading precisely because it is granular. Claude Enterprise and the first-party API can be covered on a HIPAA-ready organization once the Primary Owner activates it; chat, Projects, Artifacts, voice, Web Search, Research and Skills fall inside, while Web Fetch, the Batch and Files APIs, code execution and computer use fall outside. Consumer and self-serve tiers — Free, Pro, Max, Team — are outside entirely. One counterintuitive detail worth knowing: covered models require 30-day retention and are not available with zero data retention enabled, which is the opposite of what most buyers assume a BAA buys them.
• Google covers Gemini through Vertex AI on Google Cloud under the Google Cloud BAA. Workspace is a separate agreement — the Workspace and Cloud Identity BAA, accepted electronically in the Admin console, covering only a defined subset of services. Do not assume one BAA reaches both. The consumer Gemini app is covered by neither, 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: signing it encrypts nothing and deletes nothing by itself. What it does is legally require the safeguards — limiting uses and disclosures, mandating Security Rule protections, flowing the obligations down to subcontractors, and requiring return or destruction of PHI at the end. That is a real constraint on the vendor's behavior; it is simply not a technical measure, and the file is no safer at the moment of signature than it was the moment before. 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. A vendor training its general models on your customers' data is the paradigm case — the vendor pursuing its own purpose, on data you handed over for another one. The line is drawn by the facts rather than the label: training performed for you, on your documented instructions, can remain processor activity. 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 — when there is a transfer. A Chapter V route is required because data leaves the EEA for a third country, not merely because personal data is being processed; an EU-hosted processor needs a DPA and no transfer mechanism at all. But sending EU personal data to a US provider does require 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 (Case C-703/25 P) 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 closest thing to a 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; too thin for diligence, because it omits the description, tests and exceptions that make a SOC 2 worth reading.
• HITRUST — a prescriptive, certifiable framework mapping HIPAA and others onto testable controls; common in US healthcare procurement.
• FedRAMP — US federal government cloud authorization. Mostly irrelevant unless you sell to government, or supply someone who does.
• GDPR / HIPAA / CCPA-CPRA / EU AI Act — laws, not badges. One careful correction to a line you will hear repeated everywhere, including in earlier versions of this article: GDPR certification does exist. Articles 42–43 create it, and the EDPB maintains a public register of approved schemes and European Data Protection Seals (EuroPriSe among them). What does not exist is a certificate proving an organisation is "GDPR compliant" overall — schemes certify defined processing operations against defined criteria, and Article 42(4) is explicit that certification does not reduce the responsibility of the controller or processor one bit. So treat a GDPR seal as scoped evidence, never as a shield. 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 — stated carefully, because the popular version of it is too cynical. These documents are not empty: an Article 28 DPA obliges a processor to implement Article 32 security measures, restrict processing to your instructions, control its sub-processors and delete or return the data; a BAA compels Security Rule safeguards and flows them down the chain. Those are preventive duties, and they are enforceable. But every one of them operates on the vendor's future conduct, not on the data you already sent. Once your text has been transmitted, it has been transmitted, and the paperwork governs 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 runs out of road at the model. Be precise about which half fails: the legal right does not evaporate — the EDPB's Opinion 28/2024 holds that a model trained on personal data cannot simply be assumed anonymous, so obligations can attach to the model itself, and the appropriate remedy is fact-specific. What fails is the engineering. No deployed technique removes a particular person's data from trained weights; what vendors actually do is suppress it in outputs. A perfect Article 28 chain reaches the stored copies, and stops there. That gap is the subject of GDPR and the right to erasure.
• Retention is only half-covered. The end of it is contractual — a DPA must provide for deletion or return after the service, a BAA for return or destruction of PHI at termination — so do hold vendors to those clauses. What the contracts typically leave to the product are the numbers that matter day to day: the default retention window while you are still a customer, whether humans review your content for abuse or quality, and whether zero-retention is even offered on your endpoints. Those live 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:

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 → as a rule none of these are available at consumer tier, with one real exception worth knowing: OpenAI's ChatGPT for Clinicians is free for verified US clinicians (physicians, NPs, PAs and pharmacists) and lets an individual execute a self-serve BAA under Settings → Agreements, without an enterprise contract. Note its own framing, though — the product is built for work that does not require PHI, and the BAA is an option on eligible accounts rather than the point of it. Outside that, 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.

And the honest corollary, since this article has spent its length insisting that scope beats branding: GDPR roles follow what a service actually does, not what it calls itself. Saying we are not sold as an enterprise processor arrangement is a statement about what we offer — an Article 28 contract is not on the menu — not a legal spell that would prevent a regulator from characterizing the processing otherwise if you routed someone else's personal data through us. That is precisely the reason not to route it through a tool that offers you no such contract.

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 whatever a model provider holds under its own terms and configuration — we select providers offering zero-retention or immediate-deletion handling, and each answer carries a Session Privacy Report stating which applied, as our privacy policy describes — the record on that side carries our gateway's credentials and server address, not your name, your account or your IP. You use the model as a stranger. Two honest footnotes: "anonymously" describes the link and not the words, so anything identifying that you type into the prompt is still in the prompt; and we do keep ordinary infrastructure telemetry — IP addresses, request timestamps and error codes, for at most 30 days — which is not a record of what you asked.

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

1. 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.

2. 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.

3. 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, and rarely 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.

4. 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, where the vendor sits outside the EEA, 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.

5. 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.

6. 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. The two contracts do impose preventive duties — safeguards, purpose limits, sub-processor control, deletion at the end — and a SOC 2 gives scoped assurance that controls were designed and operating. What none of them can do is prevent every breach, override a court order, or remove data already absorbed into a trained model. Their protection is only as wide as the products, criteria and period they name. 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 lawfully hold PHI and legally requires the vendor to safeguard it; it implements nothing itself and covers no consumer plan. A DPA binds a vendor as your processor on European terms, with real duties attached; 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 remember that what you are buying is a bounded set of enforceable promises — not a guarantee about where your words end up. 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.

Sources

• AICPA & CIMA — SOC 2 examinations and the Trust Services Criteria
• US HHS — Sample Business Associate Agreement provisions
• GDPR — Article 28 (Processor)
• European Commission — Standard Contractual Clauses for international transfers
• IAPP — General Court dismisses the Latombe challenge to the EU–US Data Privacy Framework
• OpenAI — Data Processing Addendum
• OpenAI — Business data privacy, security and compliance
• Anthropic — What certifications has Anthropic obtained?
• Google Cloud — HIPAA compliance and covered products
• Google Workspace — HIPAA compliance and the separate Workspace/Cloud Identity BAA
• OpenAI — HIPAA-eligible products and functionality
• Anthropic — Business Associate Agreements for commercial customers (feature coverage matrix)
• EDPB — Register of GDPR certification mechanisms, seals and marks (Articles 42–43)
• EDPB — Opinion 28/2024 on data protection aspects of AI models