Six years after GDPR took effect, "compliance" still means very different things to different companies. Some treat it as a one-time legal exercise (set up a cookie banner, write a privacy policy, done). Others treat it as a continuous operational practice. The difference shows up the first time a Data Protection Authority asks you a question, or when a major customer's procurement team sends you a 47-question DPA addendum.
This post is the practical version: what a SaaS company actually needs to do, and the order to do it in.
Step 1: Map your data, properly
GDPR Article 30 requires you to maintain a Record of Processing Activities (RoPA). In practice, this means a document — typically a spreadsheet — that lists every category of personal data you process, why you process it, where it goes, and how long you keep it. It's the foundation that everything else builds on.
The mistake most teams make is treating this as a compliance artifact rather than an operational one. A good RoPA tells you, at a glance, that your customer support tool is processing personal data and is hosted by a US company — flagging the cross-border transfer issue. A bad RoPA gets written once, lives in SharePoint, and goes out of date within 90 days.
Update the RoPA as part of every new vendor or product launch. Make it part of your procurement process. If a new SaaS tool would mean processing personal data with a new vendor, that decision should require RoPA update before the contract is signed.
Step 2: Document your legal bases
For every category of processing, you need a legal basis (GDPR Article 6). The six options: consent, contract, legal obligation, vital interests, public interest, or legitimate interest. Most SaaS processing falls under contract (your terms of service) or legitimate interest (security, fraud prevention, product analytics).
"Consent" is overused in compliance theater. If you actually need to perform a contract — hosting a customer's account, processing their payment — you don't need consent for that processing. Consent specifically applies to optional processing where the user must have a real choice (marketing communications, optional analytics, third-party advertising). Asking consent for things you'd do anyway dilutes the value of real consent and creates withdrawal headaches.
For legitimate interest, you also need a Legitimate Interests Assessment (LIA) — a documented analysis showing that your interest is real, the processing is necessary, and the user's rights aren't overridden. This sounds like paperwork, but it forces the right conversations: do we really need this data? Could we achieve the same outcome with less?
Step 3: Subject rights, operationalized
GDPR gives users rights: access, rectification, erasure, portability, restriction, objection. The legal text is well-known; the operational implementation is where most companies stumble.
The test is: can a non-engineer at your company fulfill a Subject Access Request within 30 days, end-to-end? That includes pulling all the user's data from your systems (and your subprocessors), formatting it readably, and delivering it securely. If your answer is "we'd build a script for that when we get one," you're not ready.
Build the operational tooling now. A simple admin dashboard where support can search for a user, click "export," and get a complete data dump removes 95% of the friction. The same dashboard should support deletion (with proper handling of data you must keep for legal/financial reasons), portability exports, and processing restriction.
Step 4: Subprocessor management
Every SaaS tool you use that processes customer data is a subprocessor (your hosting provider, email service, support desk, analytics tool, payment processor). GDPR requires that you have appropriate contracts with each, that you maintain an updated subprocessor list, and that you notify customers when you add or change subprocessors.
Practical setup: maintain a public subprocessor page on your website. Notify customers via email 30 days before adding any new subprocessor. Have a Data Processing Agreement (DPA) signed with each — most major SaaS providers have a standard DPA you can sign electronically.
Pay particular attention to cross-border transfers. Any subprocessor outside the EU/EEA needs an additional legal mechanism: Adequacy Decision (Switzerland, UK, etc.), Standard Contractual Clauses, or — for US transfers under the current Data Privacy Framework — DPF participation. Document your reliance on whichever mechanism applies.
Step 5: Breach response
GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a breach affecting personal data. That's a tight timeline, especially when you're also trying to investigate, contain, and fix the breach.
Have a written incident response plan. Test it at least annually with a tabletop exercise. The plan should specify: who is the incident commander, who notifies the DPA, who notifies customers, who handles communications, who handles forensics. Without practiced roles, your 72-hour clock will start running before you've even figured out what happened.
Step 6: Vendor and customer DPA discipline
You need DPAs going both directions. From your side as a controller (processing employee data, marketing leads, etc.) you sign DPAs with your subprocessors. From your side as a processor (handling your customers' data on their behalf) your customers will want a DPA from you.
Publish a standard DPA template. Make it electronically signable. Resist customer requests to sign their custom DPA template unless absolutely necessary — you can't realistically maintain 200 different DPA terms across your customer base. Most enterprise customers will accept a well-written standard DPA after their legal team reviews it.
Step 7: Data minimization, in the product
The biggest privacy improvements often come from product decisions, not legal ones. Do you really need to collect that field? Do you need to retain logs for 5 years, or could 90 days work? Can you store hashes instead of values? Is there a feature that processes data you don't need?
Run a quarterly review of your schemas. For each personal data field, ask: do we use this? If we stopped collecting it tomorrow, what would break? Many of those fields are vestigial — added in 2019 for a feature that never shipped, or because someone thought it might be useful, or because the form template had it.
Each field you eliminate is one less surface for breach risk, one less line in your DPA, and one less data point you need to handle in subject requests.
Step 8: Hosting choices
Where your data is hosted affects compliance directly. EU-hosted is the cleanest path: no cross-border transfer mechanisms required, GDPR applies to the host directly, and the host is subject to the same regulatory regime as you.
Hosting on EU regions of US-headquartered providers complicates things. The provider's corporate parent is subject to the Cloud Act, which means data could be compelled out of the EU region by US legal process. Whether that's a meaningful risk for your specific data depends on what you process — but it's a documentable concern that may show up in customer DPAs.
For French and EU-focused SaaS companies, French sovereign hosting (like FranceVPS) eliminates the Cloud Act exposure entirely. It's not a compliance silver bullet, but it removes one of the more difficult conversation topics from your customer audits.
What "compliant" looks like in 2026
The companies that handle GDPR well in 2026 share traits: they treat compliance as an operational practice, they invested in tooling early, their RoPA is current within the past 90 days, their subject request flow is automated and tested, and their hosting choices align with their customers' regulatory expectations.
It's not exotic. It's just sustained effort, applied across the right surface area.