GDPR from day 1 in a startup: minimum documentation before launching a product

Q: What minimum GDPR documentation does a startup need to launch a product?

A startup launching a product, even with two founders and processing only the data of its first beta users, must have available from day one: Record of Processing Activities (RoPA) under art. 30 GDPR with the real processing activities identified (product users, marketing leads, commercial contacts, workforce and candidates), public privacy policy on the website and in the product compliant with arts. 13 and 14 GDPR, art. 28 GDPR contracts with all critical SaaS providers (hosting, database, authentication, transactional email, analytics, CRM), initial assessment of international transfers with verification of the Data Privacy Framework for US providers, breach protocol with template for notifying the AEPD within 72 hours, cookie policy on the website with a banner compliant with LSSICE and the AEPD's current cookie guidance, and a quick assessment of whether the processing triggers the DPIA obligation of art. 35 GDPR.

Q: Do I need a DPIA from the start in a tech startup?

It depends on the nature of the processing, not on the size of the company. Art. 35 GDPR requires a Data Protection Impact Assessment when a processing operation is likely to result in a high risk to the rights and freedoms of natural persons. The AEPD publishes a non-exhaustive list of types that trigger the obligation: large-scale processing of sensitive data, systematic monitoring of behaviour, automated decisions with significant legal effects, source combinations that allow profiling, intensive use of unique identifiers, processing concerning minors or other vulnerable groups. A startup building a conventional B2B SaaS product without any of these elements generally does not need an initial DPIA. A startup training AI models on personal data, offering credit scoring, handling health or working with minors almost certainly does. A DPIA is not bureaucracy: it is the design tool that prevents redesigning the product when there are already ten thousand users.

Q: How are international transfers with US providers managed?

Since July 2023 the EU-US Data Privacy Framework (DPF) has been in force, replacing Privacy Shield after the Schrems II ruling. A US provider adhering to the DPF and listed on the US Department of Commerce's public list allows international transfer without additional Standard Contractual Clauses for flows covered by its self-certification. The startup must: verify on the official list that the specific provider is active (it is not enough for the parent company to be listed if a different subsidiary is contracted), keep documentary evidence of that verification, periodically review whether the listing is maintained and, if not, revert to SCCs with risk analysis of the receiving country. For providers not adhering to the DPF, the Standard Contractual Clauses approved by the European Commission in 2021 are still required and, where applicable, supplementary technical measures.

Q: How often should GDPR documentation be reviewed in a growing startup?

GDPR does not set a specific frequency, but the principle of accountability under art. 5.2 GDPR requires keeping documentation up to date and being able to demonstrate it. In a startup, where the product and data flows change every few weeks, the realistic cycle is: light quarterly review of the RoPA and new providers, full annual review of all documentation, mandatory review every time a new feature affecting personal data is launched, a critical provider is added, a funding round with due diligence is initiated, a new market is entered, a breach occurs or the user base is significantly modified. It is not a formal annual audit; it is a continuous evaluation cycle based on risk and change, which is precisely what the AEPD values as evidence of accountability.

A startup about to launch a product enters the scope of the GDPR at the exact moment it captures the first personal data: the email address of the first waitlist subscriber, the sign-up of the first user in the staging environment or the registration of the first paying customer. Team size, funding stage or revenue are irrelevant to the application of the regulation. What does change with size is the documentary scope: an early-stage startup can comply with a light, proportionate documentary set, but the essential building blocks are the same.

This guide compiles the minimum documentation any B2B or B2C startup should have available before its first real campaign, in line with the GDPR (Regulation (EU) 2016/679), the LOPDGDD (Spain's Organic Law 3/2018) and the LSSICE (Spain's Law 34/2002) where there is a digital presence. The goal is not preventive bureaucracy: it is to have an organised foundation that withstands the first serious enterprise customer, the first external auditor, the first round and the first complaint.

Typical processing activities in an early-stage startup

Almost any startup, B2B or B2C, boils down to five or six processing activities detectable from day one:

Processing	Typical data	Legal basis
Product users	Identifiers, contact, usage data, logs.	Performance of contract (6.1.b)
Leads and marketing	Subscribers, prospects, newsletter readers.	Consent or legitimate interest (6.1.a/6.1.f) + art. 21 LSSICE
Invoicing and tax obligations	Billing data, IBAN, withholdings.	Legal obligation (6.1.c)
Workforce and candidates	Employment data, received CVs, evaluations.	Employment contract + legal obligation (6.1.b + 6.1.c)
Customer support	Tickets, conversations, incident records.	Performance of contract (6.1.b)
Analytics and product improvement	Telemetry, events, usage metrics.	Legitimate interest (6.1.f) or consent depending on the case

Proportional minimum documentation

An early-stage startup reasonably covers its obligations with the following blocks, without over-engineering:

Record of Processing Activities (RoPA): one page, five or six entries, with the information of art. 30.1 GDPR (controller, purposes, categories of data subjects and data, recipients, transfers, retention periods, technical and organisational measures).
Public privacy policy: a complete version on the website and a product version delivered at user sign-up, complying with arts. 13 and 14 GDPR.
Cookie policy and banner: consent configuration in line with LSSICE and the current AEPD cookie guidance, with no non-essential cookies before acceptance.
Art. 28 GDPR contracts (DPAs) signed and archived with all SaaS providers that process personal data on behalf of the startup: hosting, database, authentication, transactional email, support, CRM, analytics, storage, observability.
Contractual clauses with B2B customers: when the startup acts as a processor on behalf of a customer who is the controller (typical case of B2B SaaS), the commercial contract must include the content of art. 28.3 GDPR or an annexed DPA.
International transfer map: list of providers outside the EEA with verification of the Data Privacy Framework or Standard Contractual Clauses and, where applicable, supplementary measures.
Operational security policy: one or two pages with the real measures (access management, multi-factor authentication, encryption in transit and at rest, backups, onboarding/offboarding of staff with system access, action logging).
Breach protocol: two paragraphs on who assesses the incident, when to notify the AEPD within 72 hours and a communication template for affected individuals where applicable.
Clauses for employees and candidates: art. 13 GDPR information delivered at onboarding and on CV receipt.
Initial DPIA assessment: prior analysis of whether any processing triggers the obligation under art. 35 GDPR; if it does not, document the conclusion to support the accountability principle.

The privacy policy: what it should really contain

A startup's privacy policy is not a decorative page. It is the document through which the duty of transparency under arts. 13 and 14 GDPR is met towards the user and, in practice, one of the first pieces any serious B2B customer, investor or auditor reviews. Minimum content:

Identity of the controller (full company name, tax ID, postal address) and contact details of the Data Protection Officer if appointed.
Specific purposes, distinguishing those essential to the service from optional ones (analytics, product improvement, marketing).
Legal bases per purpose: performance of contract, legal obligation, consent or legitimate interest with its corresponding test.
Recipients and categories of processors (hosting, support, transactional email, analytics) without the need to list each specific tool if an accessible sub-processor list is maintained.
International transfers with identification of the safeguard mechanism (Data Privacy Framework, Standard Contractual Clauses).
Differentiated retention periods by block (service use, invoicing, marketing, security logs).
Data subject rights (access, rectification, erasure, objection, restriction, portability) and the concrete way to exercise them: dedicated email, form, user panel.
Mention of the right to lodge a complaint with the AEPD.
Version and update date.

SaaS providers and art. 28 GDPR contracts

A conventional startup accumulates between fifteen and thirty SaaS providers before even having a hundred real users: cloud hosting, managed database, authentication, transactional email, support, CRM, observability, storage, AI, payments. Each provider processing personal data on behalf of the startup is a processor and needs an art. 28 GDPR contract.

Critical aspects when contracting:

Signed DPA version archived as available evidence (most B2B SaaS provide a standard DPA at sign-up or in the legal section of the dashboard).
Verification of international transfers: check adherence to the Data Privacy Framework for US providers; if not applicable, Standard Contractual Clauses and, where relevant, supplementary measures.
Accessible sub-processor list and procedure for change notification.
Time frames and mechanisms for returning or exporting data at the end of the service, before destruction.
Commitment to notify breaches to the controller without undue delay.
Geographic location of servers and the possibility of choosing a European region when available.

"The startup that organises GDPR from day one does not do it out of fear of the AEPD. It does it because the first enterprise customer asks for a vendor questionnaire, the first investor asks for due diligence, the first external auditor asks for the RoPA and the first serious customer asks for a signed DPA. Showing up with that folder closed is product, not overhead."

Mario P. Talamillo · Managing Partner, Certix®

Data Protection Impact Assessment: when it kicks in

Art. 35 GDPR requires a Data Protection Impact Assessment (DPIA) when a processing operation is likely to result in a high risk to the rights and freedoms of natural persons. The AEPD has published a non-exhaustive list of types of processing that trigger the obligation, including:

Large-scale processing of special category data (health, ideology, sexual orientation).
Systematic monitoring of activity and behaviour.
Automated decisions with significant legal effects on individuals.
Combinations of sources and data sets enabling advanced profiling.
Use of innovative technologies where risk assessment is not yet consolidated.
Large-scale processing of minors or other vulnerable groups.

A conventional B2B SaaS startup not falling within any of these scenarios does not need an initial DPIA, but must document the analysis leading to that conclusion. A startup training AI models on personal data, offering scoring, handling health, integrating minors' data or building identification tools almost certainly does. A well-executed DPIA is the design tool that prevents redesigning the product once there are ten thousand users and a signed contract with a bank.

Continuous review cycle

A startup's product changes every few weeks. GDPR documentation that is not kept up to date ceases to be valid evidence within a few months. A realistic cycle:

Quarterly: light review of the RoPA (are there new processing activities due to launched features?), inventory of added providers and verification of pending DPAs.
Annual: full review of all documentation, contrast of published versions against the actual state of the product, refresh of the privacy policy if there are material changes.
Event-driven: mandatory review when launching a feature affecting personal data, onboarding a critical provider, initiating a round with due diligence, entering a new market, suffering a breach or significantly modifying the user base.

It is not a formal annual audit: it is a continuous evaluation cycle based on risk and change. It is exactly what the AEPD values as evidence of accountability under art. 5.2 GDPR.

Minimum launch-phase checklist for the startup

RoPA with real processing activities identified.
Privacy policy published on web and product, with version and date.
Cookie policy with banner compliant with LSSICE and AEPD guidance.
DPAs signed with all critical SaaS providers.
International transfer map with verification of Data Privacy Framework or Standard Contractual Clauses.
Operational security policy adapted to size.
Breach protocol and AEPD notification template.
Information clause for employees and candidates.
Initial DPIA assessment with documented conclusion.
Quarterly, annual and event-driven review schedule.

Frequently asked questions

What minimum GDPR documentation does a startup need to launch a product?

RoPA under art. 30 GDPR, public privacy policy compliant with arts. 13 and 14, signed DPAs with critical SaaS providers, international transfer map with Data Privacy Framework or SCCs, cookie policy, breach protocol, clauses for employees and initial DPIA assessment.

Do I need a DPIA from the start in a tech startup?

It depends on the processing, not on size. Art. 35 GDPR triggers it where there is high risk: large-scale sensitive data, systematic monitoring, automated decisions, advanced profiling, AI on personal data, minors. A conventional B2B SaaS without those elements usually does not need it, but the conclusion should be documented.

How are international transfers with US providers managed?

By verifying adherence to the Data Privacy Framework on the official US Department of Commerce list and keeping evidence. If the provider is not adhered, the 2021 Standard Contractual Clauses are needed and, if applicable, supplementary technical measures. The verification must be reviewed periodically.

How often should GDPR documentation be reviewed in a growing startup?

Light quarterly review of the RoPA and providers, full annual review and mandatory event-driven review (new feature, critical provider, round, breach, market entry). Art. 5.2 GDPR requires being able to demonstrate that documentation is kept alive.

This content is informational and educational in nature and does not constitute specialised legal advice. Applying the regulation to a specific case requires individual analysis. Spanish regional and sector-specific rules may extend or modify timeframes and requirements.

Want to organise your startup's GDPR before the next launch or round?

At Certix we assign you an expert in tech-sector compliance. No commercial intermediaries, no generic templates.

Talk to an expert