The GDPR has no discount for startups - a three-person company with an MVP is bound by exactly the same rules as a corporation. The good news: while you are still building the product, compliance is cheap. After launch, with a live user base and signed contracts with vendors, every fix costs many times more. Here are 12 points to tick off before you go live.
- The GDPR applies to startups exactly as it does to corporations - a three-person company with an MVP is bound by the same rules.
- The records-of-processing exemption (Article 30) for organisations under 250 employees almost never applies to digital products.
- From the moment you become aware of a breach, you generally have 72 hours to notify the President of UODO.
- Electronic marketing requires a separate consent to the communication, on top of accepting the terms of service (the Electronic Communications Law, since November 2024).
- Under time pressure, the emergency priority is: legal bases and the privacy policy, DPAs, cookies, and the breach procedure.
Legal foundations
1. A legal basis for every processing purpose
Map out what data you collect and why - and assign each purpose one of the legal bases in Article 6 GDPR: contract, legal obligation, consent, legitimate interest (with a written balancing test). The classic mistake: “we’ll just get consent for everything”. Consent can be withdrawn and is the weakest basis operationally - use it where it genuinely fits (marketing, optional data), not as a skeleton key.
2. Information obligations (Articles 13-14)
Your privacy policy is not a footer decoration - it has to be specific: who the controller is, what data, for what purposes, on what legal bases, who it is shared with, how long it is kept and what rights people have. Write in plain language; a layered approach (a short notice plus the full policy) works best. And remember the points where you collect data outside the sign-up form: the newsletter, recruitment, leads from LinkedIn.
3. Records of processing activities (Article 30)
Yes, there is an exemption for organisations with fewer than 250 employees - and almost no startup will benefit from it, because the exceptions to it (processing that is not occasional, sensitive data, risk to individuals’ rights) cover practically every digital product. A simple spreadsheet listing processing activities, purposes, categories of data, recipients and retention periods is enough to start with. Bonus: the record is the best map for every other point on this list.
4. Data processing agreements (Article 28)
Hosting, analytics, CRM, mailing, technical support - every vendor processing data on your behalf needs a data processing agreement (DPA). With the big SaaS providers you usually accept their standard DPA - but you need to know that you have done so, and keep a list of your processors. “I don’t know whether we have a DPA with our hosting provider” is one of the first things to surface in a regulatory inspection or an investor’s due diligence.
Product and data
5. Privacy by design and by default (Article 25)
Data protection has to be built into the product, not bolted on afterwards. In practice: collect only the data a feature needs to work, make the most privacy-friendly settings the default, anonymise test data and restrict developers’ access to production. The check question for every new feature: “does this have to collect this data in order to work?”
6. Retention - expiry dates for data
“We keep everything because it might come in handy” flatly contradicts the storage limitation principle. Set retention periods for each category: deleted accounts, logs, backups, marketing data, recruitment candidates. And - the harder part - design a mechanism that actually deletes or anonymises the data once the period is up.
7. Marketing consents
Sending electronic marketing is a separate regime (in Poland, since November 2024: the Prawo komunikacji elektronicznej, i.e. the Electronic Communications Law) - you need consent to the communication, separate from acceptance of your terms of service. The checkbox must not be pre-ticked, the consent must be recorded (who, when, for what) and easy to withdraw. Buying databases “with lawful consents” almost never works the way the seller promises.
8. Cookies and tracking
Cookie banners are the most visible part of compliance - and the part most often broken. The rules: non-essential scripts (analytics, marketing) fire only after consent; “reject all” is as easy to reach as “accept”; if you use programmatic advertising, you need a consent management platform (CMP) compliant with the current TCF framework. Before launch, test what actually fires in the background before anyone clicks consent - your browser’s developer tools are enough.
Risks and procedures
9. Transfers outside the EEA
A US SaaS tool in your stack = most likely a transfer of data to a third country. For each vendor, check the transfer mechanism: an adequacy decision (for the US - certification under the Data Privacy Framework; check its current legal status), standard contractual clauses (SCCs) and, where needed, a transfer impact assessment. Record this in your records of processing activities and your privacy policy.
10. Breach procedure - 72 hours
From the moment you become aware of a personal data breach, you generally have 72 hours to notify the President of UODO (the Polish data protection authority) - unless the breach is unlikely to result in a risk to individuals - and where the risk is high, you must also inform the affected individuals themselves. 72 hours is very little time when there is no procedure: who assesses, who decides, who drafts the notification. Prepare a one-page procedure and an internal breach register (mandatory for all breaches, including those not notified) before you need them.
11. Do you need a DPIA?
If your product profiles users, evaluates people, processes sensitive data on a large scale or uses innovative technologies (AI!), you may fall under a mandatory data protection impact assessment. At the very least, carry out a documented threshold assessment. You will find full instructions in the article DPIA step by step.
12. Do you need a DPO?
The obligation to designate a data protection officer applies, among others, to companies whose core activities consist of regular and systematic monitoring of individuals on a large scale, or of large-scale processing of sensitive data. An adtech, healthtech or HR-tech startup can fall into this sooner than it thinks. For the “employee or outsourcing” analysis, see the piece on external and in-house DPOs.
Where should you start GDPR work when time is short?
If launch is two weeks away, the emergency order is: legal bases and the privacy policy (points 1-2), DPAs with key vendors (point 4), cookies (point 8), the breach procedure (point 10). The rest - in the first month after go-live. Ultimately, though, the list cannot be split: every point is a separate risk.
This article is for information purposes only and does not constitute legal advice.