The thing most checklists skip
Generic GDPR advice treats you as one thing. A software business is two, simultaneously, and the obligations differ depending on which hat you are wearing at the time.
Your signup list, your marketing contacts, your staff records, your billing data. You decided why you hold it and how it gets used.
Everything your customers put into your product. They decided why it exists; you handle it on their instructions.
Article 4(7) a controller "determines the purposes and means of the processing" · Article 4(8) a processor "processes personal data on behalf of the controller"
Both cards are green on purpose. This is not a choose-one. If you sell software that stores anything about your customers' people, you are a processor for that, and a controller for your own business records, at the same time. Advice written for one role will quietly mislead you about the other.
If you have not yet established whether GDPR reaches you at all, that is the prior question — does GDPR apply to my US company works through the territorial test.
The contract your customers will ask for
Once you are a processor, your customers need a written contract with you covering specific ground. It is usually called a Data Processing Agreement, and Article 28(3) sets out what it has to contain.
This is not optional paperwork between friends. Your customer is legally required to have it before entrusting you with personal data, which is why it turns up in procurement — and why not having one ready costs you deals rather than fines.
You process the customer's data on their documented instructions and not for your own purposes. Using customer data to improve your product is exactly the kind of thing this catches — it needs to be instructed, not assumed.
Article 28(3)(a) "processes the personal data only on documented instructions from the controller"
Anyone on your side who can see customer data is bound to keep it confidential. In a small company this usually means employment terms and contractor agreements, not a separate ceremony.
Appropriate technical and organisational measures under Article 32. The practical translation: encryption, access control, backups, and the ability to describe all three in writing when a buyer asks.
When one of your customer's users asks for their data, or asks for it deleted, your customer has one month to answer — and the data is inside your product. Being able to export or delete a single person's records is a product feature, not a policy.
On termination, you delete or return the data at the customer's choice. Worth deciding what your product actually does here before a contract commits you to something it does not do.
You make available the information needed to demonstrate compliance, and allow audits. For most small vendors this is answered with documentation rather than site visits — but the documentation has to exist.
Article 28(3)(h) "make available to the controller all information necessary to demonstrate compliance"
Sub-processors: the part that surprises people
Every vendor in your stack that touches customer data — your hosting, your database, your email sender, your error tracker, your support desk — is a sub-processor. And two rules apply that most founders discover late.
- You cannot bring in a new sub-processor without the customer's written authorisation
- Most contracts use general authorisation — you keep a published list, announce changes in advance, and the customer may object
- Which means the list has to exist, be public, and actually be kept current
- Sub-processors must be bound by the same obligations you signed up to
- If one of them fails, you remain fully liable to your customer
- "We use a big cloud provider" is not a defence — it is a description of who you will be explaining on behalf of
Article 28(2) "shall not engage another processor without prior specific or general written authorisation" · Article 28(4) "the initial processor shall remain fully liable to the controller"
Three things SaaS founders get wrong
1"Our customers' data is our data — we can learn from it"
As a processor you may only use customer data on their documented instructions. Your own product improvement is not automatically one of them.
Aggregate analytics, model training, benchmarking across accounts — these are purposes, and purposes need to be instructed by the controller, which in practice means written into the agreement rather than assumed from the fact that you host it.
What this means for you: if you plan to learn anything from customer data, decide it early and put it in the contract. Retrofitting permission across an existing customer base is far harder than asking on day one.
2"We'll write a DPA when a customer asks for one"
By then it is already costing you the deal. The DPA is a procurement gate, not a closing formality.
Your customer cannot lawfully hand you personal data without it, so an enterprise buyer asks for it early — often in the same breath as a security questionnaire. A vendor who responds "we're working on it" has just told a procurement team they are early-stage in the one area procurement is paid to be careful about.
What this means for you: the DPA is sales collateral as much as legal paperwork. Having one ready shortens deals; not having one silently loses them, and you rarely find out that was the reason.
3"Deleting an account deletes the data"
Only if your product actually does that — including in backups, logs and analytics.
Article 28(3) commits you to deleting or returning data at the end of the relationship, and Article 17 gives individuals deletion rights your customer will pass through to you. Both assume deletion is a thing your system can genuinely do, for one person or one account, on request.
What this means for you: this is the obligation most likely to be a build problem rather than a paperwork one. Find out what your product does today before you sign a contract describing what it should do.
What this looks like when a deal is on the line
The compliance work above rarely announces itself as compliance work. It arrives as a security questionnaire, a procurement checklist, or a one-line email asking for your DPA and your sub-processor list.
For a small vendor selling into larger organisations, that moment is where GDPR actually bites. Not a fine — a stalled deal, a delayed renewal, or a buyer who quietly picks the competitor who answered faster.
Why this matters to you: almost none of this is expensive if you do it before you need it, and almost all of it is expensive under deal pressure. A DPA drafted calmly costs a few hundred to a few thousand. The same document drafted in a week because a customer is waiting costs the same money plus whatever the delay does to the deal — and you negotiate it from the weaker side.
Where to start
The honest sequence is: work out whether GDPR reaches you, then work out which role you are in for which data, then build the paperwork the second one implies.
Our free scope checker handles the first step — about seven plain-language questions, covering GDPR, NIS2 and the EU AI Act. It runs entirely in your browser, needs no account, and tells you when a regulation does not apply to you.
The free readiness check goes further: a score out of 100 against the controls that matter, your top three gaps, and the single thing to fix first — which for most software companies turns out to be one of the things on this page.
Sources cited on this page
- GDPR Article 4(2), 4(7) and 4(8) — definitions of processing, controller and processor
- GDPR Article 28(1)–(4) — processor obligations, sub-processor authorisation and liability
- GDPR Article 28(3)(a)–(h) — what the processing contract must contain
- GDPR Article 32 — security of processing
- GDPR Article 17 — right to erasure