Building on OpenAI or Anthropic? A Data Governance Checklist for SaaS Founders
A data governance-first checklist for SaaS founders building on OpenAI, Anthropic, or any LLM provider. Data flows, DPAs, retention, personal data, and audit evidence.
SECURITY
TL;DR
Building on a third-party LLM provider like OpenAI or Anthropic means your product now has a critical vendor sitting inside your data flow. This changes what you owe to your users, your enterprise customers, and your future auditors.
The right question is not "is OpenAI secure" or "is Anthropic secure." The right question is what data leaves your infrastructure, what the provider does with it, and how you would evidence the answer under scrutiny.
Under GDPR, UAE PDPL, and India's DPDP, you are the data controller and the LLM provider is a processor. That distinction shapes your obligations regardless of which provider you pick.
A signed Data Processing Agreement with the provider, an accurate position on retention, and Zero Data Retention where eligible are the three contractual baselines to lock in early.
The eight checkpoints below are what a founder should be able to answer for their own setup before shipping an LLM feature to customers, and before an enterprise buyer or an auditor asks.
Somewhere in the last twelve months, most SaaS products have started routing user data through a third-party language model. A summarisation feature here, a chatbot there, a document analysis flow that quietly sends contract text to an API endpoint your customers have never heard of. The engineering decision to do this is usually simple. The governance decision behind it is usually skipped.
This post is a checklist you can work through in an afternoon. It applies whether you are building on OpenAI, Anthropic, Google Gemini, Amazon Bedrock, Azure OpenAI, or an open-source model you host yourself. The provider changes; the questions do not.
Controller and processor: the one mental model you need
Every data protection law your product touches (GDPR in the EU and UK, UAE PDPL, India's DPDP, and most of the other privacy regimes worth naming) works from the same underlying model. Two roles, defined by who decides what.
The controller is the party that decides why the data is being processed and how. In your case, that is your company. You decided to build the AI feature, you decided what data feeds into it, and you decided what your product does with the result.
The processor is the party that processes the data on the controller's instructions. When you send a prompt to OpenAI or Anthropic, the provider is a processor acting on your instructions. They are not the controller of that data. You are.
This one distinction shapes the entire checklist below. Almost every obligation under GDPR, PDPL, and DPDP attaches to the controller, not the processor. The provider's compliance certifications and enterprise privacy pages tell you what kind of processor they are. They do not discharge your obligations as the controller. Understanding this cleanly is the difference between a founder who governs the vendor relationship and a founder who assumes the vendor has governed it for them.
Checkpoint 1: What data is actually leaving your infrastructure
Start here because most founders discover their answer is different from what they assumed.
Map every LLM call your product makes and document what is included in the prompt sent to the provider. This means the literal string. If the prompt includes a customer's document, name that. If it includes user chat history, name that. If it includes a system prompt with internal instructions, name that too because the provider sees it regardless of your intent.
The question to answer: for each LLM feature in your product, what fields, records, or content types appear in the prompt or in any attached context?
Reasoning: you cannot govern what you have not mapped. Every subsequent checkpoint depends on this one being honest. Founders often assume they are only sending "the user's question" when in fact they are enriching prompts with account data, previous interactions, or system context that materially changes what leaves the building.
Checkpoint 2: How you would evidence AI vendor governance in an audit
This checkpoint used to sit at the end of the list. It has moved to the front because it frames what the other seven checkpoints are for. Everything else in this post is what an auditor or an enterprise security reviewer will effectively walk you through.
Under SOC 2, an LLM provider is typically treated as a subservice organisation for the purposes of the Common Criteria on vendor and risk management. You will be expected to demonstrate that you have evaluated the provider's controls, have appropriate contractual protections in place, and monitor the relationship over time.
Under ISO 27001, the same relationship is captured under the supplier relationships controls (Annex A 5.19 through 5.23 in the 2022 version of the standard). The auditor will look for a supplier evaluation, a contract, and evidence of ongoing management.
Under ISO 42001, which focuses specifically on AI governance, third-party AI supplier controls sit as a first-class concern. If you are pursuing ISO 42001 alongside your other frameworks, this checkpoint gets pulled to the front of the conversation. Our ISO 42001 post covers the wider standard, and our SOC 2 vs ISO 27001 post covers how those two frameworks compare.
The question to answer: for each LLM provider your product depends on, do you have documented vendor evaluation, contractual protection, transparency to users, and ongoing monitoring, all in a form you could hand to an auditor tomorrow?
Reasoning: audit-ready evidence is what turns the remaining six checkpoints from good practice into a defensible position. Founders who leave this checkpoint for later usually redo the previous work under audit pressure, which costs more time than doing it now.
Checkpoint 3: Whether the data leaving includes personal data, and if so, what your lawful basis is
If the data leaving your infrastructure includes anything that identifies or relates to an identifiable person, your product is processing personal data through a third-party processor. This triggers obligations under whichever data protection law applies to your users.
Under GDPR, you need a lawful basis for the processing (typically legitimate interest or contract necessity for a product feature), a data processing agreement in place, and appropriate transparency to your users.
Under India's DPDP, the roles are named differently (data fiduciary and data processor) but the practical mechanics rhyme. You need consent for the processing where the law requires it, a written contract with the processor, and the ability to honour data principal rights requests even for data that has passed through the LLM provider.
Under UAE PDPL, the underlying obligations sit with the data controller. The Executive Regulations that fill in the operational detail have been evolving, so specific requirements for AI-processor arrangements are still crystallising. The safe default is to apply the same controller-processor discipline you would under GDPR and adjust as the regulations settle.
The question to answer: for each LLM feature, does the data leaving your infrastructure include personal data, and if so, what is your lawful basis, how have you disclosed the processing to users, and what is your position on data subject rights?
Reasoning: personal data is the single most common trigger for regulatory exposure in AI features, and it is the checkpoint most likely to be under-thought before an enterprise customer asks. We covered the wider GCC and India data privacy landscape in the GCC data privacy laws post.
Checkpoint 4: Which provider tier you are on, and what its retention default is
The principle first: verify the current defaults of whichever provider tier you are on, document your position, and revisit at least twice a year. Both major providers have updated their retention terms multiple times in the last eighteen months, and any specific number in this post should be reverified at the provider's documentation before you rely on it.
The principle matters more than the numbers because the numbers move. That said, as of the current published policies:
OpenAI's API default retains inputs and outputs for up to 30 days for abuse monitoring and does not use them for model training. Zero Data Retention is available for eligible customers on supported endpoints.
Anthropic's API default retains inputs and outputs for 7 days and does not use them for model training. Enterprise customers who need longer retention for their own auditing purposes can opt into a 30-day window through their DPA. Zero Data Retention is available for eligible customers, and a newer Enterprise Frontier Safeguards arrangement lets misuse-monitoring activity data live in the customer's own cloud storage rather than Anthropic's, aimed at highly regulated buyers.
The consumer products of both providers run under different defaults. Founders who have a company ChatGPT or Claude.ai account but are building on the API are looking at two different data regimes running in parallel.
The question to answer: which provider tier is each of your LLM features running on, what is that tier's retention default, and does that retention window match what you have told your customers and your auditors?
Checkpoint 5: Whether you have a Data Processing Agreement in place with the provider
If you are processing personal data belonging to your users through OpenAI, Anthropic, or any other LLM provider, you need a signed Data Processing Agreement (DPA) with them. This is not optional under GDPR, and equivalent contractual arrangements are expected under DPDP and PDPL.
Both major providers make DPAs available to eligible commercial and enterprise customers. Signing up for the API on a personal credit card and shipping the feature to enterprise customers is a documentation gap that any competent security reviewer will catch.
The question to answer: for each LLM provider your product uses, is there a signed DPA in place under the entity that operates your product, and is it recent enough to reflect the current terms?
Reasoning: the DPA is the contractual mechanism that makes the processing lawful under most privacy regimes and it is the single document your enterprise buyer's legal team will ask for. Getting this right is inexpensive if you do it early and expensive if you do it after a customer has already flagged the gap.
Checkpoint 6: Where the provider processes and stores your data geographically
Both OpenAI and Anthropic have expanded regional processing options over the last eighteen months, but the defaults do not always match what a European or Middle Eastern buyer expects.
For enterprise customers with EU users, data residency in the EU may be a contractual requirement or a strong buyer preference. For customers with users in the UAE or Saudi Arabia, data localisation expectations are still forming but are increasingly appearing in enterprise procurement conversations, particularly for financial services and government-adjacent buyers.
The question to answer: where does your LLM provider process and store your API traffic by default, are regional processing options available for your workload, and does the answer meet what your enterprise contracts commit to?
Reasoning: cross-border data transfer is where AI features most commonly trip a compliance obligation that was invisible before. Founders who committed to EU data residency in their enterprise contracts before adding an LLM feature sometimes discover the feature has quietly broken the commitment.
Checkpoint 7: How you handle prompt and output logging in your own systems
This one gets skipped because it does not feel like a governance question. It is.
Every LLM feature typically involves your own logging: for debugging, for evaluations, for cost tracking, for quality monitoring. Whatever the provider retains is only one side of the ledger. What your own product logs is the other.
The question to answer: for each LLM feature, what does your product log about the prompt and the response, where is that log stored, how long is it retained, who can access it, and how does that access align with the sensitivity of the underlying data?
Reasoning: a founder who has negotiated ZDR with the provider but is logging full prompts and responses to a shared observability platform has moved the problem, not solved it. Your own logging is inside your SOC 2 or ISO 27001 scope and is treated as your systems, not the provider's.
Checkpoint 8: What your users are told about AI processing in your product
Transparency to users is a governance requirement under GDPR (through the fair processing and privacy notice obligations), under DPDP (through notice and consent), and increasingly under emerging AI-specific rules including the EU AI Act.
The question to answer: does your product's privacy notice, terms of service, or in-product disclosure tell users that their data may be processed by a third-party AI provider, and is that disclosure accurate to what actually happens?
Reasoning: your enterprise buyer's data protection officer will read your privacy notice. If the notice does not mention AI processing and your product ships an AI feature, the mismatch will surface in review. This is one of the cheapest checkpoints to close and one of the most commonly ignored.
What this post does not cover
This post is deliberately scoped to data governance. It does not cover prompt injection defence, output safety filtering, model red-teaming, or the choice between providers on model performance grounds. Those are separate conversations.
We also want to name a positioning boundary. Adversarial testing of AI systems and LLM penetration testing are a distinct discipline from data governance and from traditional application testing. If your product ships an LLM feature and you are working through this checklist, your first VAPT should still be a conventional application and API test, as we covered in the VAPT post. AI-specific adversarial testing is a separate scope that most SaaS founders do not need in their first year of shipping AI features.
Frequently asked questions
We are a small SaaS and we only use the OpenAI API for one feature. Do we really need all this?
If the feature touches any customer data at all, the mechanics of this checklist apply proportionally. You do not need enterprise-scale documentation, but you do need a signed DPA, an accurate privacy notice, a documented retention position, and a reasonable answer for a security questionnaire. This is a two-week exercise, not a two-quarter one, if done early.
Can we use ChatGPT or Claude.ai for internal work with customer data?
Not with regulated or confidential customer data on consumer accounts. Consumer tiers of both products have different data handling defaults from the API and enterprise tiers, and using them with customer data creates a Shadow AI risk that is difficult to defend to an auditor. The safe pattern is API access, or the paid enterprise product with a DPA in place.
What about using Cursor, Windsurf, or other AI coding tools with our codebase?
The same controller-processor logic applies. Your codebase is your data, and an AI coding tool that sends your code to a third-party model is a processor in your data flow. Check the tool's data handling defaults (some route through OpenAI or Anthropic under the tool vendor's account, some let you bring your own API key), get a DPA with the counterparty that actually holds the data, and document the arrangement inside your SOC 2 or ISO 27001 vendor management scope. This is one of the most common Shadow AI gaps in early-stage SaaS today.
How often should we review our AI vendor governance?
At least twice a year, and any time the provider changes its terms. Both major providers have updated their retention and enterprise terms multiple times in the last eighteen months, and the pace shows no sign of slowing.
Where to start
If your product ships an LLM feature and you have not worked through these nine checkpoints, the first hour of the exercise is usually the highest-value hour of the quarter. It surfaces the gaps that would have surfaced anyway, on your timeline instead of your enterprise buyer's.
If you would like a second set of eyes on your specific setup, our 30-minute discovery call exists for exactly this.
Secure your business with expert help
Company
Services
© 2026 Auro Security. All rights reserved.
Connect
insights