SaaS companies get audited long before a regulator ever contacts them. Every enterprise customer's own GDPR obligation flows down through a data processing agreement into a security review of you — which means your compliance posture is a sales asset or a sales blocker, and rarely anything in between.
Here is what actually gets asked for.
1. Know which hat you are wearing
You are almost certainly both:
- a processor for the personal data your customers put into your product — you act on their instructions, and you do not decide what happens to it
- a controller for your own data — employees, candidates, prospects, billing contacts, website visitors, support requesters
The obligations differ, and conflating them is the most common structural error in SaaS privacy. It shows up immediately in a security review, because a vendor who describes themselves purely as a processor cannot explain why they have a marketing database.
2. A record of processing that reflects reality
Both roles need one, with different contents (Article 30(1) for controllers, 30(2) for processors). Every other item on this list depends on it. Start here or expect to come back to it. More on ROPAs.
3. A DPA with every customer
Article 28 makes it mandatory: a data processing agreement between controller and processor, covering subject matter, duration, nature and purpose, types of data, categories of data subject, and the obligations of both parties.
Have your own DPA ready to send. Vendors who make customers wait for one lose weeks in procurement.
4. A subprocessor list — public, current, and with notice
Every vendor that touches customer data is a subprocessor: your cloud provider, your email service, your support desk, your analytics tool, your error tracker.
You need customer authorisation to use them, an obligation to notify before adding a new one, and a public list. This is the item most frequently found to be out of date — because subprocessors get added by engineering during a sprint, not by legal during a review.
5. A DSAR process that works for both roles
As a controller, you fulfil requests directly. As a processor, you must assist your customer in fulfilling requests they receive — which means having a way for a customer to extract or delete a specific end-user's data, and doing it inside their deadline, not yours.
Enterprise buyers ask about this. "Email support and we'll look into it" is not a satisfying answer to someone with a one-month statutory clock. More on DSAR handling.
6. Retention that is decided, not accidental
For every data type: how long, and why. The default of keeping everything forever because storage is cheap is not defensible, and "our database has no delete function" is an answer that ends a security review.
Pay attention to logs, backups, and the data warehouse. Deletion that does not reach them is not deletion.
7. International transfers with a real mechanism
If personal data leaves the EEA — and if you use a US cloud provider, it does — you need a transfer mechanism: an adequacy decision, standard contractual clauses, or binding corporate rules. Since Schrems II you also need a transfer impact assessment for the destination country.
Note that this cascades to your subprocessors. Their transfers are your problem.
8. Security measures you can evidence
Article 32 requires appropriate technical and organisational measures. In practice, enterprise reviews want: encryption in transit and at rest, access control and least privilege, logging and monitoring, tested backups, vulnerability management, and a documented incident response plan.
The word that matters is evidence. Having the control is half of it; being able to show it was tested is the other half.
9. Breach detection and a 72-hour clock
A personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, where it poses a risk to individuals. As a processor, you must notify the controller without undue delay — and your DPA will specify how fast.
Seventy-two hours is not much time to work out what happened. The plan has to exist before the incident, and it has to name people, not roles.
10. A privacy notice that matches what you do
The most common finding in any privacy audit is not a missing document. It is a document that describes a system nobody built — a notice claiming data is retained for 12 months in a company whose database has never deleted a row.
Regulators treat an inaccurate privacy notice as evidence of a broader accountability failure, and they are right to.
The pattern across all ten: the obligation is not to have policies. It is to be able to demonstrate what you actually do. That is what turns compliance from a document exercise into an operational one — and it is what a continuous compliance scan is for.