GDPR for SaaS Companies: The Non-Negotiables

The fines get the headlines,hundreds of millions levied against major platforms since GDPR went into force in May 2018.

But for builders, the real story of the last eight years is clarity. Thousands of regulatory decisions have stripped away the ambiguity. We no longer have to guess what the law means in practice.

If you are building software for European users, customers, or employees, figuring out GDPR for SaaS companies is no longer an exercise in interpretation. The baseline is set.

Here are the five foundational requirements that are:

• Not optional
• Not negotiable
• Not subject to a size exception

Consider this your essential SaaS GDPR compliance checklist.

#1: A Lawful Basis for Every Processing Activity

GDPR Article 6 requires a documented lawful basis for every processing activity. You cannot collect data first and justify it later.

Of the six available bases, finding the right GDPR lawful basis for SaaS usually comes down to four:

Consent: the most demanding basis

Consent is the basis most companies reach for first. It is also the hardest to get right.

Valid GDPR consent must be freely given, specific, informed, and unambiguous. So:

• Pre-ticked boxes do not work.
• Bundled consent across multiple purposes does not work.
• Consent that cannot be withdrawn as easily as it was given does not work.

If you are relying on consent for core product functionality, you are building on a fragile foundation.

Contract: the clean choice for core service delivery

Processing necessary to perform a contract with the data subject does not require separate consent.

A user signs up for your SaaS product. Processing their account data to deliver the service? Covered by the contract basis. It is clean, durable, and operational.

Legitimate interests: flexible, but often misused

Legitimate interests require a balancing test: your legitimate interest must not be overridden by the data subject’s rights and interests.

And that test must be documented.

• ”We have a business interest” is not a documented balancing test.
• If you rely on legitimate interests for anything meaningful, your documentation must demonstrate the analysis, not just assert the conclusion.

#2: Records of Processing Activities

Article 30 requires organizations to maintain GDPR records of processing activities (ROPA).

The small-organization exception is narrower than it sounds

GDPR includes an exception for companies with fewer than 250 employees. But that exception falls away if the processing:

• Is likely to result in a risk to data subjects’ rights, or
• Is not occasional, or
• Involves special categories of data or criminal convictions data.

Why most SaaS companies cannot rely on it

For most SaaS companies, even small ones, the exception is an illusion. You are processing personal data regularly to run your application, which means it is not occasional.

Watch this space

The European Commission has proposed loosening this rule: raising the threshold to fewer than 750 employees and applying the exception unless processing is likely to result in a high risk. Until any change is formally adopted, the current rules apply, and keeping a ROPA remains good practice regardless.

What your ROPA must cover

• The name and contact details of the controller, and any representative or DPO
• The purposes of processing
• The categories of data subjects and personal data
• The categories of recipients
• Transfers to third countries, and the safeguards used
• Retention periods
• A general description of technical and organizational security measures

Keep it alive

Treat your ROPA as a living document. Update it when you:

• Add features
• Adopt new vendors
• Change how you process data

An outdated ROPA does not satisfy Article 30. A record that does not reflect reality is just a well-formatted lie.

#3: Data Subject Rights: Machinery, Not Just Policies

GDPR Chapter III gives data subjects eight rights. The ones most likely to be exercised against your business:

• Access (Article 15)
• Rectification (Article 16)
• Erasure (Article 17)
• Portability (Article 20)

Handling GDPR data subject rights in SaaS requires more than good intentions.

A policy is not a capability

Mentioning these rights in a privacy policy is not the same as being able to respond to them.

• Subject Access Request? You generally have one month to respond (extendable for complex or numerous requests).
• Deletion request? You must comply unless an exception applies, and you must be able to demonstrate compliance.

The operational machinery you need

• A defined channel for receiving requests
• A documented response process
• A named owner
• Tooling that can find all data related to a specific person across your systems
• A logging mechanism recording when requests were received and fulfilled

The hardest part to build later

Finding all data related to a specific individual across your systems is the hardest capability to build retroactively.

If your data architecture does not support efficient individual-level retrieval and deletion, that is an engineering project. Not your compliance team’s roadmap. Your engineering roadmap.

#4: Data Processing Agreements for Every Processor

When you share personal data with third-party service providers that process it on your behalf, Article 28 requires a SaaS data processing agreement (GDPR DPA).

That includes your:

• Cloud infrastructure providers
• Analytics platforms
• Customer support software
• Email marketing tools
• Every other vendor that touches personal data on your behalf

What the DPA must include

The basics:

• The subject matter and duration of processing
• The nature and purpose of processing
• The type of personal data and categories of data subjects
• The obligations and rights of the controller

The processor must commit to:

• Implement appropriate technical and organizational measures
• Process data only on your documented instructions
• Ensure confidentiality
• Assist you with data subject rights requests
• Delete or return data at your request
• Provide the information you need for your compliance audits

Have the file ready

Most major SaaS vendors have standard DPAs available.

1. Request them.
2. Review them.
3. File them.

An assessor asking for your vendor DPAs should find a complete, current file, not trigger the start of a procurement sprint.

#5: International Transfers: The Post-Schrems II Reality

Transferring personal data outside the EEA requires a legal mechanism. The cloud feels abstract, until the real world reminds us where the servers actually sit.

🇺🇸 The EU-US Data Privacy Framework

The EU-US Data Privacy Framework, which replaced Privacy Shield after the Schrems II decision, provides a mechanism for transfers to US organizations certified under the Framework.

Verify that your key US vendors are certified. The framework has survived its first court challenge, but an appeal is pending, so having a backup mechanism is wise.

Standard Contractual Clauses

SCCs remain the most widely used mechanism for other transfers.

The 2021 SCCs replaced the older versions. If you are still operating under pre-2021 SCCs that have not been updated, you are using deprecated documentation.

Transfer Impact Assessments

TIAs are increasingly expected alongside SCCs, particularly for transfers to higher-risk jurisdictions.

They are not explicitly named in GDPR’s text. But DPAs have made clear through enforcement that relying on SCCs without assessing the legal environment in the destination country is insufficient diligence.

Ready to Simplify Compliance?

Five non-negotiables. Get these right, and you have built the foundation every other part of your privacy program stands on.

But a foundation only works if it reflects reality. If you want a cleaner way to run this playbook, explore how Regodit can help you operationalize GRC without slowing your roadmap.

Schedule a call or a short demo, and see how the evidence builds itself while your team ships.