3 GDPR mistakes in your Privacy Policy (and how Estonian e-Residents usually fix them)

Most one-person SaaS founders write their Privacy Policy once, early on, usually by copying a template they found online, and never look at it again. That is a reasonable way to get started — but it also means the same handful of gaps show up again and again once a founder actually sits down to review the policy against the GDPR text.

This is especially common for solo founders running an Estonian e-resident OÜ: the company formation is quick and the tooling is excellent, but there is no in-house legal team checking the Privacy Policy before it goes live. Below are the three gaps that come up most often, what GDPR actually asks for, and how founders usually fix them.

Mistake 1: no clear legal basis listed for each purpose

The problem. A Privacy Policy says what data is collected ("we collect your name, email and usage data") but never says *why it is legally allowed to collect it*. GDPR does not treat "we need it to run the product" as self-explanatory — every processing purpose needs one of six specific legal bases (consent, contract, legal obligation, vital interests, public task, or legitimate interest).

What GDPR requires. Article 6 requires a lawful basis for every purpose of processing, and Article 13 requires that basis to be disclosed to the person whose data it is — not just that processing happens, but *why it is lawful*.

How it is usually fixed. Founders rebuild the policy as a simple table: one row per purpose (account creation, billing, analytics, marketing emails), with the data collected for it and the specific legal basis next to it. Account and billing data is almost always "performance of a contract." Analytics and product-improvement data is usually "legitimate interest," which should be a real, documented balancing judgment, not just a label. Marketing emails to people who are not yet customers almost always need "consent" — a contract basis does not cover sending unsolicited marketing.

Mistake 2: third-party tools used without a DPA or a mention in the policy

The problem. The founder uses an analytics tool, an email-sending service and a payment processor — completely normal for a SaaS — but the Privacy Policy never mentions them, and there is no signed data processing agreement with any of them. Legally, each of those tools is processing personal data on the founder's behalf, which makes the founder the controller and the tool a processor, with specific obligations attached.

What GDPR requires. Article 28 requires a written contract (a DPA) with every processor, covering what they may do with the data, their security obligations, and sub-processor rules. Article 13 separately requires the Privacy Policy to tell users which categories of recipients their data is shared with.

How it is usually fixed. Most mainstream SaaS tools already publish a standard DPA that customers can accept online — the fix is often just finding that page and accepting it, then listing each tool and its purpose in the Privacy Policy's "who we share data with" section. For smaller or less common tools, founders send the processor a standard DPA and ask them to countersign it.

Mistake 3: no clear process or deadline for deletion/export requests

The problem. The Privacy Policy says "you have the right to access or delete your data" and stops there — no email address to send the request to, no mention of how long it takes, no internal process for what actually happens when a request arrives. In practice this means requests get missed, answered inconsistently, or answered late.

What GDPR requires. Article 12(3) sets a concrete deadline: the controller must respond within one month of a verified request (extendable by two more months for complex cases, with notice to the requester explaining why). The right of access (Art. 15), erasure (Art. 17) and portability (Art. 20) all need to actually be exercisable, not just named.

How it is usually fixed. Founders add one short section naming exactly where to send a request (a specific email address), what happens next (confirmation, identity check if needed, a result within one month), and — for a one-person operation — a simple personal checklist or calendar reminder so a request sent to a solo inbox does not get buried under support tickets.

These three are not an exhaustive audit

A policy can pass all three checks above and still have other issues specific to a particular product — special categories of data, children's data, unusual international transfers. For a standard single-product SaaS, though, fixing these three usually closes most of the gap between "a Privacy Policy exists" and "a Privacy Policy reflects what GDPR actually asks for."

If you would rather start from a template that already has all three built in — a data/purpose/legal-basis table, a dedicated section for listing third-party processors, and a named contact with a one-month deadline for data requests — the GDPR Starter Pack for Estonian e-Residents includes an editable Privacy Policy, Terms of Service and a standard Article 28 DPA, built around exactly these gaps. It is a self-service template, not individual legal advice — for anything unusual about your specific business, show the filled-in version to a lawyer before publishing.