Data Compliance for SaaS: What Vendors Receive
Every software company holds data that belongs to someone else. Every vendor it adds carries that data further. Where your users live decides which rules apply, and what your vendors receive decides how much of the work lands on you.
The kinds of rules people call compliance
Privacy laws. They cover personal data, anything that points to a person. They say why you may hold it, what you must tell people, and what rights people keep over their own records. Almost every country now has one of its own. Europe has the GDPR, the General Data Protection Regulation. California has the CCPA, the California Consumer Privacy Act. Brazil has the LGPD, its general data protection law, and China the PIPL, the Personal Information Protection Law.
Industry laws. They sit on top and cover one trade and one kind of data. They ask for more than the privacy law does, and they follow the data to your vendors. HIPAA, the Health Insurance Portability and Accountability Act, covers US health plans, billing clearinghouses, and providers who bill electronically. GLBA, the Gramm-Leach-Bliley Act, covers US financial companies. FERPA covers school records where the school takes federal money, and COPPA services aimed at children under 13.
Audits and certificates. They are not laws. An outside auditor checks that a company's controls existed and worked for a period, then writes a report. That is proof about the company, not proof that it follows a law, so a SOC 2 report does not make a company GDPR compliant. SOC 2 is a US report on how a service company handles security, access, and monitoring. ISO 27001 is the international standard for running security, and an accredited body issues the certificate. PCI DSS is the card industry's own rule set for anyone who touches card numbers.
Product and supply chain rules. They target how a company is run and what it sells, not the personal data inside. NIS2, the second Network and Information Security Directive, puts security duties on essential and important organizations across 18 EU sectors, and DORA, the Digital Operational Resilience Act, does the same for finance and its tech providers. Both reach a small vendor through its bigger customers' contracts. The EU Data Act works the other way. It applies to anyone selling a cloud service in the EU, at any size, and the contract must let a customer leave with their data inside 30 days.
Who answers for the data
Controller. The controller decides why data is collected and what happens to it next. A company that signs people up and asks them for a phone number is the controller of those numbers, because it chose to ask. It answers to the people in the data and to the regulator, and it picks every vendor that touches the data after that.
Processor. The processor handles the data for the controller and follows written instructions. It has no purpose of its own. A hosting company, a mail sender, and an import tool are processors as long as they only do the job they were given. A processor that starts using the data for something it wants becomes a controller for that part.
Your customer is the controller of their users' data, which makes you the processor. Your hosting provider and error tracker sit under you as subprocessors, and you answer to the customer for what they do. Every link needs a written contract, and the law sets what it covers, from security and confidentiality to deletion and audit rights.
The role follows the data, not the label. A contract can call a vendor a processor while its privacy policy claims the right to use your content for its own analytics. There, it is a controller. Your own responsibility stays where it is either way, and someone harmed can claim against both of you.
What a product does with your data
Any product that receives your data does a small number of things with it. It can keep a copy and decide who opens that copy, hand parts of it to its own vendors, move it across borders, hold it for years, and feed it to a model.
Data can be stored. It sits in a database, and copies of it sit in backups, often in another country. A product's privacy page should name both places.
Data can be opened by people. Support staff and engineers reach live records to do their work. What matters is how they get that access, how they lose it when they leave, and whether anything records who looked.
Data can end up in logs. An error report carries the values that caused the error, so one broken row travels to whoever runs the error tracker. Data leaves this way with nobody deciding to send it.
Data can cross a border. Once it leaves your region it needs legal cover, either a country the EU has ruled safe or the standard clauses inside the vendor contract. The vendor's pages should say where its servers sit and which route it relies on.
Data can outlive its use. Each kind of record has a number of days attached to it, and deletion counts only when it clears the backups and the vendors too.
Data can be encrypted. On the way and at rest, and someone holds the keys. Know who that is.
Data can train a model. Prompts and files sent to an AI feature may be stored, and they may feed a model shared with other customers. The terms should say whether that happens and whether you can turn it off.
The kinds of vendors you can add
Infrastructure you build on. You rent servers, a database, file storage, and an error tracker, and your whole product stands on them. All of your users' data reaches these companies, because there is nowhere else for it to live. Auditing a company that size is out of reach, and you do not have to. Sign the data processing agreement they already publish, name them on your subprocessor page so your customers can see who holds their data, and check which region that data sits in.
A library you install. You run an install command, and someone else's code ships inside your own bundle. It runs with the same rights as the code you wrote, so it can read anything on the page, including your users' data and whatever the browser has saved. A library can also send data to its own server, so watch the requests it makes. Watch who can publish the package too, because stolen publishing rights put new code inside your product on your next install. A library that stays in the browser can do less, because all the work happens on the user's machine, and it also never receives your users' data.
A script loaded from the vendor's server. You paste a snippet into your page for analytics, a chat window, or a session recorder. The browser downloads that code from the vendor every time someone opens the page. These products collect data as their job. A session recorder can save your users' data as they move through the page. You can usually control what goes to these services, through their own settings or through cookie consent.
An API you call from your backend. Your server sends data to theirs for payments, email, a model, or a check on a document. Their code stays on their side, so pay attention to which data you share with them. Everything in the request is data they now hold. Their terms say how long they keep that request, who can read it, and whether it trains a model.
A SaaS product. You sign up, and from that day your users' data lives on someone else's servers. It sits in their database and in their backups, their support staff can open it, and their own subprocessors hold pieces of it. Pay attention to who those subprocessors are and which countries they sit in, because you answer to your customer for all of them. The contract says what the vendor may do with the data, and it also sets how you get the data back and how their copies are deleted the day you leave.
You can answer most of this yourself. In the browser, open developer tools, go to the Network tab, then reload the page and use the feature you are checking. Every request the page makes shows up as a line with the domain it went to, and clicking a line shows what was sent inside it. A vendor that promises your data stays in the browser is confirmed or caught right there.
On your own server the requests are yours to read. Log one call to the vendor's API and look at the body of it. Those fields are what the vendor receives, and that list is the one worth shortening.
Where Updog sits
Updog is a CSV and spreadsheet importer you install as a library. When someone uploads a file, it lives only in their browser. They match the columns to your fields, fix what the checks flag, and press submit, and your own API receives the finished rows. File data is never sent to Updog servers, so we hold no copy of it.
One request goes to us, and it checks the license. It carries the API key and the domain, with no file contents, rows, or headers. The SDK also keeps one key in the browser storage, a signed grant that lets the editor work while our API is down, and it holds no personal data. You can turn that off if you would rather nothing was stored. Every field in that request and in that key is listed on our data and privacy page.
For the file itself, your subprocessor list stays as it was, because the file never reaches us.
Your own duties stay where they are. Once the rows reach your API, they sit under the same rules as the rest of your data. Account data for our Console is ours, and it sits in the European Union. Support email is a real path for data to reach us, so pay attention when you are about to send us something sensitive.
As of August 2026, we hold no SOC 2 report and no ISO 27001 certificate, and we sign no business associate agreements. How to report a security problem is on our security page.
Every vendor you add puts another copy of your users' data somewhere you do not control. We built Updog so that importing a file adds none. The file stays in the browser where it was opened, and the only thing left to answer for is what your own API does with the rows.