The GDPR has 99 articles, and reading all of them is a great way to convince yourself you need a lawyer before you can ship anything. But here's the thing most SaaS teams don't realize: roughly half of those articles are about supervisory authorities, the European Data Protection Board, and legal remedies: the machinery of how the regulation is enforced, not things you have to do.

The obligations that actually land on a company processing personal data are a much smaller, very manageable set, about 40 operative requirements across the regulation's core chapters. Get those right and you're compliant. Here's what they are, in plain terms.

First, which hat are you wearing?

GDPR splits duties between two roles, and you're usually both:

  • Controller: you decide why and how personal data is processed (your users' accounts, your marketing list). Most obligations fall here.
  • Processor: you process data on behalf of another company (you're a SaaS vendor handling your customer's data). This is what triggers those Data Processing Agreements customers send you.

You're a controller for your own users and a processor for your customers' data. Both sets of duties apply.

The obligations that matter

1. Have a lawful basis (Articles 5–9)

Every bit of processing needs a legal reason: consent, contract, legitimate interest, legal obligation, and a few others. Consent, when you rely on it, has to be freely given, specific, and as easy to withdraw as to give (Article 7). Special categories (health, biometrics, and so on) get stricter treatment (Article 9).

2. Be transparent (Articles 12–14)

Tell people what you collect, why, how long you keep it, and who you share it with, in clear language, at the time you collect it. This is your privacy notice, and it needs to be accurate, not aspirational.

3. Honor data-subject rights (Articles 15–22)

People can ask to access, correct, delete ("right to be forgotten"), restrict, port, or object to the processing of their data, and you generally have to respond within a month. In practice this means you need to actually be able to find and export or delete one person's data on request. Build for that early; retrofitting it is painful.

4. Build in privacy by design (Articles 24–25)

Collect only what you need, protect it by default, and be able to demonstrate you're doing so. "Data minimization" isn't a slogan. It's an obligation.

5. Get your processor agreements in place (Articles 28–30)

When you use sub-processors (your cloud host, your email provider, your analytics), you need a contract that binds them to GDPR terms, and you need to keep records of processing activities (Article 30). This is also the flip side of the DPAs your customers ask you to sign.

6. Secure the data (Article 32)

Appropriate technical and organizational measures: encryption, access control, resilience, and regular testing. If that list sounds like SOC 2 or ISO 27001, that's exactly the point. The security work overlaps almost entirely.

7. Be ready to report a breach (Articles 33–34)

Notify your supervisory authority within 72 hours of becoming aware of a personal-data breach, and notify affected individuals if the risk to them is high. Seventy-two hours goes fast. You need a runbook, not a scramble.

8. Assess high-risk processing (Articles 35–36)

For processing likely to be high-risk (large-scale profiling, sensitive data at scale), run a Data Protection Impact Assessment before you start.

9. Appoint a DPO if you need one (Articles 37–39)

Required if your core activities involve large-scale monitoring or special-category data. Many small SaaS companies don't strictly need one, but you should document why if you decide not to.

10. Handle international transfers (Articles 44–49)

Moving EU personal data outside the EEA needs a valid transfer mechanism: an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules.

The good news

Notice how much of this is the same work as your security audit: access control, encryption, breach response, vendor management, records-keeping. If you're already pursuing SOC 2 or ISO 27001, you're most of the way to the operative GDPR obligations. You mainly need to add the privacy-specific pieces: lawful basis, transparency, data-subject rights, and transfers.

That's the case for treating GDPR as a set of controls that share evidence with everything else you're doing, rather than a standalone legal project.

Keel now ships GDPR as a framework covering the 40 operative controller and processor obligations, crosswalked so the security controls you build for SOC 2 or ISO 27001 count toward GDPR too, and you only gather evidence once. Start free at keelgrc.com.

This article is practical guidance, not legal advice. For your specific situation, consult a qualified privacy professional.