GDPR for SaaS Founders: DPAs, Sub-Processors, Logs
By CodexierPublished 5 min read
A B2B SaaS product processes personal data on behalf of its customers, which makes the vendor a processor under the GDPR and the customer a controller. That relationship comes with paperwork the customer's legal team will ask for, and with technical obligations their security team will test. Founders who prepare these before the first procurement questionnaire close deals faster; those who do not spend weeks producing documents under deadline. This guide lists what to have ready.
Controller vs processor in SaaS
| Data | Your role | What governs it |
|---|---|---|
| Records your customers store in the product | Processor | The DPA with each customer |
| Your users' logins, names, billing | Controller | Your privacy policy and legal basis |
| Usage analytics on your own product | Controller | Privacy policy, and consent where cookies are involved |
| Support tickets containing customer data | Processor for the data, controller for the ticket | DPA plus internal access rules |
Your data processing agreement
Article 28 of the GDPR sets what a DPA must contain, and enterprise customers will compare yours against that list. Offer your own standard DPA as part of the terms; customers who insist on their own template will negotiate from yours, which is a better position than starting from theirs.
- Subject matter, duration, nature and purpose of processing, and the categories of data and data subjects, described for your actual product.
- That you process only on documented instructions, and what happens if an instruction would break the law.
- Confidentiality obligations for your staff and contractors.
- Technical and organisational measures, in an annex you can update without renegotiating the DPA.
- Sub-processor rules: a list, a notification period for changes and a right to object.
- Assistance with data subject requests and breach notification, with your timelines.
- Deletion or return of data at the end of the contract, with a stated period.
Sub-processor lists
Every vendor that touches customer data on your behalf is a sub-processor: hosting, database, email delivery, error tracking, support desk, analytics that see customer records. Publish the list on a page, with each vendor's purpose and location, and keep a changelog. Customers with EU data residency requirements will scan the location column first, so it pays to choose EU regions where you can.
Keep it current
Add a vendor to the list before it goes live, not after. A customer who finds an unlisted vendor in a log has grounds to escalate.
Notify changes
Offer a mailing list or an in-app notice with the period your DPA promises, usually thirty days, so the right to object is real.
Minimise
Each vendor is a document to maintain and a question in every review. Error tracking that scrubs personal data out of reports removes one from the list.
Location matters
How the data model isolates customers affects this list too; see our note on multi-tenant architecture.
Logging, access and deletion
This is the part the security team tests rather than reads. Three capabilities need to exist in the product: you can show who accessed what and when, you can restrict your own staff's access to customer data, and you can delete a customer completely, including backups, within a stated time.
- Audit log: user, action, object, timestamp, and the same for your own support staff's access. Make it exportable for the customer.
- Role-based access inside your team: support sees what a ticket needs, engineers see production data only through a logged break-glass procedure.
- Encryption in transit everywhere and at rest for the database and backups, with keys managed by the cloud provider at minimum.
- Deletion: a routine that removes a customer's data from the live database, search indexes, file storage and, after the retention window, backups. Test it on a demo account and time it.
- Data export: a customer can take their data out in a usable format without asking you.
Answering security questionnaires
Questionnaires repeat. Build a document that answers the common questions once: hosting and regions, encryption, backups and restore tests, access control, incident response, sub-processors, pen testing, business continuity. Reuse it, and update it when the product changes. Be honest where you have gaps; 'planned for next quarter' is an acceptable answer, an untrue 'yes' is not. If the product's foundations make some answers impossible, that is a scaling problem more than a legal one, and our scaling and upgrade service is where we address it.
When you do not need this yet: a product sold to consumers or to small businesses that never ask for a DPA still needs a privacy policy, secure defaults and a way to delete accounts, but not the enterprise document set. Build the full kit when the first customer with a legal department appears on the pipeline, not before. If that customer is already asking, book a free 15-minute call and we will go through what your product can answer today and what needs building.
Frequently asked questions
Do we need a DPA with every customer?
Yes, whenever a customer stores personal data in your product, which for B2B software is almost always. Make the DPA part of your standard terms so it is accepted at signup rather than negotiated for each deal.
Do we need a data protection officer?
Only if your core activity involves large-scale monitoring or sensitive data. Most small SaaS companies do not, but should name a person responsible for privacy questions and put that contact in the policy.
Can we host in the US and still sell to Swedish companies?
It is possible with the current EU-US framework and the right contractual safeguards, but many Swedish public-sector and regulated customers will refuse. EU hosting removes the question and is usually available from the same providers.
What happens if we have a data breach?
As a processor you notify the affected customers without undue delay so they can meet their seventy-two hour deadline to IMY. Have a written procedure, a template notification and a contact list ready before it happens.
First security questionnaire on your desk?
Send us the questions you cannot answer yet. In fifteen minutes we tell you which need a document and which need a change in the product, and roughly what each would take.
Book a free 15-minute call