Is your app’s data handling compliant? The honest answer is a list. How to manage SaaS data compliance comes down to eight things a customer, a regulator or an enterprise buyer can check: a data inventory, export and delete paths, a matching privacy policy, consent, retention, a controls checklist, model-provider flows and a subprocessor list.
How to manage SaaS data compliance in your own app: the eight controls
SaaS data compliance in your own app is eight controls: a personal-data inventory, export and delete paths, a privacy policy that matches the product, consent that optional scripts respect, a retention schedule, a SOC 2-style controls checklist linked to evidence, a record of what reaches model providers, and a subprocessor list.
Privacy and compliance foundations is one of the 13 areas of production hardening and holds 8 of its 123 checks. It is also one of the areas that keep your other answers true over time: the day a new provider or a new tracking script ships, one of these eight goes out of date.
| Control | What it is | The evidence it leaves | Why it matters | Next topic |
|---|---|---|---|---|
| 1. Personal-data inventory | A record of the personal data the app holds | The inventory, dated, checked against one traced user | The team needs a reliable record when a customer or reviewer asks about data use | a GDPR data map for a SaaS |
| 2. Data export and deletion paths | A signed-in user can take their data out or have it removed | An export file, a deletion record and the list of exceptions | Personal-data requests are difficult to fulfill when the application has no reliable mechanism | data subject request handling checklist |
| 3. Privacy and terms alignment | The published policy and terms describe the real app | The policy marked against the inventory, with the owner’s approval | The public description of data use should match what the product actually does | privacy policy for a SaaS |
| 4. Cookie consent controls | Optional tracking waits for the visitor’s choice | A recorded run of accept, refuse, withdraw and reload | Optional tracking needs to follow the user’s recorded consent choices | cookie consent requirements |
| 5. Data retention policy | How long each kind of data stays, and what removes it | The schedule, plus the job or setting behind each line | Keeping data without a defined purpose makes storage and data handling harder to govern | what a data retention policy is |
| 6. SOC 2-style controls checklist | Your security controls listed, each with proof | A checklist where every line points to its evidence | Enterprise buyers need evidence of how the application is protected and operated | MVSP and the SOC 2-style controls checklist |
| 7. Personal data sent to model providers | A list of the user data that goes into AI calls | A field list per model call, and the provider terms on file | For an AI app, the model provider is a second place customer data lives | how to redact personal data before LLM calls |
| 8. Subprocessor list | The vendors that process customer data, made public | A published list that matches the policy and the contracts | Every business customer’s security questionnaire asks for it, and reviewers cross-check it against the privacy policy | what a sub-processor is |
The phrases compliance SaaS and SaaS security compliance also name a product category: platforms such as Vanta, Drata and Sprinto, which in my reading help a company organize evidence for a framework. This page is about the app you built. The eight controls live in its code, its settings and its documents, and a platform can only point at them.
The same goes for an app made with a builder such as Lovable, Bolt or Replit: the best practices for privacy in a low-code app are these eight, because what the app collects, sends and keeps is yours whoever generated the code. Whether the builder itself handles data safely is a separate question; for Lovable, the place to start is is Lovable safe.
My reading of most compliance best practices guides is that they are written for a company governing the SaaS it buys. Zylo’s guide, for one, defines SaaS compliance management as “the practice of ensuring every cloud application in your business aligns with regulatory requirements, industry standards, and internal policies.” That is the buyer’s job. For an app you run, data privacy best practices are the eight rows in the table.
Nothing on this page is legal advice. Where I quote a rule, I name its jurisdiction (UK, EU or California) and keep what a law requires apart from what is good practice.
Who asks, and what they ask to see
Three kinds of people ask about your data handling, and each wants different evidence: a customer wants their data or its deletion and a policy they can read, a regulator wants the record and the breach process, and an enterprise buyer wants a questionnaire answered with proof. The eight controls supply evidence for all three.
| Who asks | What they ask for | The control | The page |
|---|---|---|---|
| A customer or user | A copy of their data, its deletion, and a policy that says what happens to it | Export and deletion paths; privacy and terms alignment | data subject request handling checklist; privacy policy for a SaaS |
| A regulator | The record of what you hold, the lawful basis for holding it, and your breach process | Personal-data inventory | GDPR compliance checklist; breach handling |
| An enterprise buyer | A security questionnaire answered with proof, the controls checklist, a SOC 2 report or ISO 27001 certificate, PCI scope if you take payments, PHI status in health, and a DPA when you process their data | Controls checklist; subprocessor list | security questionnaires; SOC 2; ISO 27001; PCI DSS; PHI under HIPAA; DPAs |
The “what they ask for” cells are my reading of the requests a small SaaS receives, not a list any regulation prints.
The regulator’s breach question has a clock in the UK. Under UK GDPR Article 33, the controller shall notify the breach “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, “unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” The current text names the recipient as “the Commission”, meaning the Information Commission, a word substituted on 30 September 2026 by regulations made under the Data (Use and Access) Act 2025. The EU version of the rule, and what to do in the first hours, belong with handling a personal data breach in a small SaaS. The rest of a regulator’s list under the GDPR (EU and UK), in the order a small team meets it, is a GDPR compliance checklist.
California works by thresholds. According to the CPPA’s FAQ, the CCPA applies to for-profit businesses that collect consumers’ personal information (or have others collect it for them), determine why and how it will be processed, do business in California, and meet any one of three thresholds. The first is “a gross annual revenue of $26.625 million or more (effective January 1, 2025) for the preceding calendar year”. The second is buying, selling or sharing the personal information of 100,000 or more California residents or households, and the third is deriving 50% or more of annual revenue from selling or sharing California residents’ personal information.
The enterprise buyer asks the most, and the questionnaire comes first. Two things make it lighter: knowing how to respond to security questionnaires and having read security questionnaire examples before yours arrives. Behind the questionnaire sit the formal documents a buyer may name: a SOC 2 report (SOC 2 certification, in plain words) or an ISO 27001 certificate, where the first question is what ISO 27001 certification costs a small SaaS. If the app takes card payments, expect a question on PCI DSS requirements, the card industry’s security standard. In US health care, the question is whether the app touches protected health information, which turns on what counts as PHI under HIPAA. And a business customer that makes you its processor will ask for a data processing agreement, so learn what a DPA agreement is before you sign one.
What goes wrong without it
A user asks for their data and nobody knows where it all is
The email is short: send me everything you hold about me, then delete it. You open the users table, then remember the analytics tool, the support inbox, the error tracker and the AI provider. Without a record of where personal data lives and a reliable way to export and remove it, each request turns into a search. The record comes from the GDPR data map topic in the first table, and the process from the data subject request checklist beside it. For a deletion that has to reach every copy, start with GDPR delete requests in a small SaaS.
The privacy policy describes an app that no longer exists
A reviewer asks about a provider your policy never mentions. The policy was accurate on the day it was written; the product kept shipping and nobody went back to it. Take a founder who publishes a privacy policy at launch that names the services the app used then. The app later starts sending users’ text to a model provider, and when a business customer’s reviewer cross-checks the subprocessor list against the privacy policy, the model provider, now a second place customer data lives, is in neither. The lesson I take from it: the privacy policy, the subprocessor list and the data inventory state one fact three times, so they drift unless one is written from the others. My fix is to write the privacy policy from the inventory, never the other way round; the policy topic in the table covers what a SaaS policy holds.
The analytics script loads before anyone consents
Open the site in a private window, click the banner’s refuse button, and the browser’s network tab still shows the analytics script loading. The banner stored the choice, but nothing ties the script tags to it, so tracking runs whatever the visitor picked. The legal rule depends on where your visitors are, so begin with the cookie consent requirements topic in the first table for their countries; the consent control below quotes the UK regulator.
Personal data goes to the model provider inside the prompt
A support feature pastes the customer’s name, email address and full ticket into a prompt so the model can draft a reply. Nobody wrote that flow down, so the provider is missing from the inventory, the policy and the subprocessor list. Strip the fields the model does not need, using the redaction topic in the first table. How long a provider keeps what it receives is set by its terms; for that question, start with zero data retention for your AI features.
A buyer’s questionnaire arrives and honest answers would be no
A large customer sends its security questionnaire, and row after row asks for proof you have never written down: who can reach production data, how access gets reviewed, where logs go and who reads them. The controls may exist, but without a list that ties each one to its evidence, an honest answer to many rows is no. Start with the MVSP and SOC 2-style checklist topic in the first table; the reply itself is the questionnaire work from the section above.
Data is kept forever because nothing deletes it
Years after launch, the database still holds every abandoned signup, every deleted project’s files and the logs from week one, because nothing was ever told to remove them. Data with no purpose and no end date is still data you secure, disclose and search when a request arrives. The retention topic in the first table covers choosing the periods; the retention control below is about enforcing them.
The eight controls, one by one
1. There is a personal-data inventory, and it matches the app
The control is to document what personal data is stored, where it lives, why it is collected, and who can access it. In a small app that list runs past the database: file storage, logs, the analytics tool, the email service, the support inbox and every API the app sends user data to. The verify step is to trace a sample user through storage, logs, and providers and compare it with the inventory. The evidence is the inventory itself, dated, with the trace notes beside it. The GDPR data map topic in the first table has the method for building one.
2. A user can export and delete their data, and only their data
The control is to implement authenticated export and deletion workflows covering related systems and documented retention exceptions. Authenticated means the request proves who is asking, so nobody can pull another user’s data by changing an ID. Related systems means the copies outside your database. Retention exceptions are the records you keep on purpose, written down with the reason. The verify step is to export and delete a seeded user’s data; verify completeness, authorization, and recorded exceptions. The evidence is the export file, the deletion record and the exceptions list. The data subject request checklist in the first table covers the process around it.
3. The privacy policy and terms match the inventory
The control is to verify privacy and terms links and review the stated data practices against the application; document and resolve technical discrepancies with the owner. The owner decides what the policy promises, with their lawyer where needed; the technical job is to find every place the text and the app disagree. The verify step is to compare the policy statements with the data inventory and provider flows and record the owner-approved alignment. The evidence is a copy of the policy marked line by line against the inventory, with the owner’s approval and a date. For what else belongs in the policy, start from the privacy policy row of the first table.
4. Optional scripts wait for consent, and refusal sticks
The control is to implement consent controls for the application’s audience and tracking configuration, including EU visitors where relevant. In the UK, under PECR, the ICO’s cookie guidance states the requirement: “You must also get the user’s consent. Consent must be actively and clearly given. There is an exception for cookies that are essential to provide an online service at someone’s request”. On 3 October 2026, that page said it was based on the previous version of the ICO’s detailed guidance while a revised version was under consultation. Making refusal stick across reloads is good practice in how you meet that rule. The verify step is to test consent, refusal, withdrawal, and persistence; verify optional scripts respect those choices. The evidence is a network capture for each state. The cookie consent topic covers other countries.
5. There is a retention schedule and something enforces it
The control is to document retention periods and handling rules for logs, user history, and abandoned records. A schedule nobody enforces is a wish, so each line should name what applies it: a scheduled job that deletes old rows, a retention setting in the log provider, or a step someone runs on a date. The verify step is to review the schedule against the data inventory and the configured lifecycle controls. The evidence is the schedule, with each period traced to the job or setting that applies it. How long each period should be is a separate question, answered from the data retention row of the first table.
6. A SOC 2-style controls checklist links every control to evidence
The control is a technical controls checklist with supporting evidence organized for enterprise security review. Each line names a control (access to production, backups, logging, change review), who owns it, and where the proof lives: a configuration screen, a test result, a log query. The verify step is to link each documented control to its owner, configuration, or test evidence. This deliverable is not a SOC 2 audit report. It is the evidence a buyer’s reviewer reads, organized so an answer can point to a line. The evidence is the checklist with every link working. The MVSP and SOC 2-style checklist topic covers which controls to list.
7. What reaches model providers is listed and matches the inventory
The control is to inventory the user data that reaches AI providers, redact what is not needed, and record each provider’s data-processing terms. Include the calls you forget: a moderation check, an embedding job, a background summary, a tool call that forwards a whole record. The verify step is to trace each model call, list the fields sent, and match them against the inventory. The evidence is a table of calls and the fields each sends, the redaction code, and each provider’s terms saved with the date you read them. For the stripping itself, use the redaction row of the first table.
8. The subprocessor list matches the providers and the policy
The control is to publish the list of vendors that process customer data, with the agreement in place for each. When a business customer is the controller and you are its processor, your vendors are its sub-processors. In the UK, UK GDPR Article 28 sets the rule in paragraph 2: “The processor shall not engage another processor without prior specific or general written authorisation of the controller.” Under a general authorization, the same paragraph has the processor inform the controller of intended changes so it can object, which is why a new vendor is a change to tell customers about, and why what a sub-processor is matters before your first DPA. The verify step is to confirm the list matches the provider inventory and the privacy policy. The evidence is the published list, the agreement for each vendor and the date of the last comparison.
How to verify the whole area in an afternoon
Verifying this area takes eight tests and, as my working estimate, about an afternoon: trace one seeded user everywhere, export and delete them, read the policy against the inventory, refuse consent and reload, read the retention schedule, follow evidence links, trace each model call, and compare the subprocessor list.
Create one test user first, with a real-looking name, an email address you control and some activity in every feature, because every test below reuses it. Each item points back to its control above, where the full verify step is.
- 01 Control 1: trace the seeded user through storage, logs and providers, and mark anything the inventory misses.
- 02 Control 2: export that user, then delete them, and check what came out, who was allowed to ask, and what stayed on purpose.
- 03 Control 3: read the privacy policy and terms against the inventory and the provider flows, and get the owner to approve the result.
- 04 Control 4: in a private window, accept, refuse, withdraw and reload, watching which optional scripts load each time.
- 05 Control 5: read the retention schedule against the inventory and the jobs or settings that apply it.
- 06 Control 6: open every evidence link in the controls checklist and confirm each control has an owner.
- 07 Control 7: trigger each feature that calls a model and list the fields each call sends.
- 08 Control 8: compare the subprocessor list with the provider inventory and the privacy policy.
For each test, record the date, what you checked, the result, and where the evidence is saved: a file, a screenshot, a link. A failed test goes on the list with its fix, and the record stays even after the fix lands, so the next reviewer sees both.
This area is one section of the full production readiness checklist, which runs the same kind of test across all 13 areas.
Where the sprint stops
The Production Hardening Sprint stops at engineering. Legal advice and certification are separate services; the sprint implements and documents the technical data-handling controls. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. The controls checklist from control 6 is evidence organized for a buyer’s review, and, as its verify step says, it is not a SOC 2 audit report. Which laws apply to your company, and what your policy should promise, stay questions for a lawyer.
Where the sprint does this
In the sprint, area 12 is these eight controls, 8 of the 123 deliverables. Each is checked with the verify step under its control above. The result for every scope item, the work completed and its verification evidence go into the production readiness report, where failures stay visible until resolved. The exact wording of each item is in area 12 of the published scope.
Common questions about SaaS data compliance
Is SOC2 for SaaS?
Yes, in my reading: the AICPA describes SOC as “a suite of service offerings CPAs may provide in connection with system-level controls of a service organization or entity-level controls of other organizations.” A SaaS that holds customer data is that kind of service organization. The definition is on the AICPA’s SOC suite page. Whether a small SaaS needs a report yet depends on who is asking, which is the subject of do I need SOC 2. What the report contains is the subject of SOC 2 certification, in plain words.
What is SaaS security?
SaaS security is the work that keeps a SaaS app’s users and their data safe, and for a SaaS you built it covers: who can sign in (and whether sign-in asks for MFA), what each account can reach (role-based access control), how secrets and keys are stored, how input and output are handled, and how the database is protected. Those are the first four areas of production hardening, and a SaaS security checklist turns them into tests you can run. For SaaS a company buys, the same term means governing third-party apps, their settings and who has access to them, which is a different discipline with its own tools.
What are the 5 key areas of compliance?
No single list of five exists; the answer changes with the source and the framework. For an app that holds personal data, my grouping of five is: knowing what you hold, letting people take it out or remove it, describing it truthfully in public, asking before you track, and deleting it when its purpose ends. Those match controls 1 to 5 above.
What is the best compliance software?
The best compliance software is whichever fits the framework your buyers ask for, in my view, and none of it builds the eight controls for you, because they live in your app’s code, settings and documents. In my reading, a compliance platform organizes and tracks the evidence those controls leave. Choosing between SOC 2 compliance consultants or a compliance platform comes down to what each one automates and what it leaves with you.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase