GDPR Compliance Checklist for Startups: AI Audit in 15 Minutes

I’ve reviewed over 30 startup privacy policies in the last year. Every single one had at least one GDPR violation — and most of them were obvious: vague wording, missing mandatory sections, wrong legal bases for data processing.

A lawyer charges €300–800 for a manual privacy policy audit (2–4 hours of work). An LLM does the initial scan in 15 minutes. It won’t replace a lawyer, but it catches the low-hanging violations before they become a €20M fine.

Here’s what you’ll find below: a complete GDPR checklist for startups, ready-to-use AI audit prompts, and a privacy policy template that covers every Article 13 checkpoint.

GDPR Compliance: What a Startup Actually Needs to Do

GDPR draws a line between two types of entities: the data controller (decides why and how data is processed) and the processor (handles data on the controller’s behalf). If you’re a SaaS startup, you’re almost certainly a controller for your users’ data.

The obligations break into three groups.

Documentation and transparency. Your privacy policy must contain 13 mandatory elements under Article 13. The language must be “clear and plain.” Cookie banners must offer a genuine choice — not pre-ticked boxes.

Technical measures. Encryption in transit and at rest. A working mechanism for deleting data on request. Data export in a machine-readable format (the right to portability). Logged access to personal data. If you’re building with AI APIs, your security audit checklist should cover these alongside GDPR-specific requirements.

Organizational measures. Appointing a DPO (required for public authorities, organizations doing large-scale systematic monitoring, or those processing large amounts of sensitive data — GDPR doesn’t set a specific numerical threshold). A Record of Processing Activities (ROPA). A 72-hour breach notification procedure. A Data Processing Agreement with every processor you use.

Full GDPR Checklist for Startups

The checklist below is organized by priority. Items that can trigger fines on their own are marked critical.

Privacy Policy: Mandatory Elements (Article 13)

• Name and contact details of the controller
• Contact details of the DPO (if appointed)
• Purposes of processing for each data category
• Legal basis for each processing purpose (consent, contract, legitimate interest, legal obligation)
• Categories of personal data processed
• Recipients or categories of recipients (third parties, sub-processors)
• Information on transfers to third countries and the applicable safeguard (SCCs, adequacy decision)
• Retention periods or the criteria used to determine them
• Data subject rights: access, rectification, erasure, restriction, portability, objection
• Right to withdraw consent at any time
• Right to lodge a complaint with a supervisory authority
• Whether providing data is mandatory and the consequences of not doing so
• Existence of automated decision-making, including profiling

Cookie Consent and Tracking

• Cookie banner is shown before any non-essential cookies are set
• “Accept” and “Reject” buttons are visually equivalent
• No pre-ticked checkboxes for non-essential categories
• Cookie list with descriptions of purpose and retention periods
• Option to change the initial choice later
• Analytics (Google Analytics, Mixpanel) do not load before consent
• Marketing pixels (Facebook, LinkedIn) are blocked without consent

Technical Requirements

• HTTPS on all pages and API endpoints
• Encryption of personal data at rest (AES-256 or equivalent)
• API endpoint for user data export (JSON/CSV)
• Mechanism for complete deletion of user data (not soft delete for personal data)
• Logging of access to personal data (who, when, what data)
• Data minimization: only data necessary for the stated purpose is collected
• Access controls: not all employees have access to all data

Organizational Requirements

• Record of Processing Activities (ROPA) is maintained and up to date
• Data Processing Agreement (DPA) signed with each processor (AWS, Stripe, SendGrid, etc.)
• Subject Access Request (SAR) handling procedure is documented
• Breach notification procedure is in place
• Data Protection Impact Assessment (DPIA) conducted for high-risk operations
• Staff have received training on handling personal data

AI Audit of a Privacy Policy: Prompts and Methodology

The audit runs in three stages: completeness check, legal basis analysis, and language/contradiction check. Each stage needs its own prompt — a single “check everything” prompt gives you a superficial scan that’s useful for nothing. If you’re managing multiple audit prompts across projects, a prompt engineering system helps keep them versioned and consistent.

Stage 1: Completeness Check Against Article 13

You are a GDPR compliance auditor. Analyze the privacy policy below
for compliance with the requirements of Article 13 GDPR.

For each of the 13 mandatory elements of Article 13, indicate:
- PRESENT: the element is present and the wording is correct
- PARTIAL: the element is mentioned but the wording is incomplete or imprecise
- MISSING: the element is absent

Mandatory elements:
1. Controller name and contact details
2. DPO contact details
3. Purposes of processing
4. Legal basis for each purpose
5. Categories of data
6. Recipients of data
7. Cross-border data transfers
8. Retention periods
9. Data subject rights
10. Right to withdraw consent
11. Right to lodge a complaint with a supervisory authority
12. Whether providing data is mandatory
13. Automated decision-making

Response format — a table with columns:
Element | Status | Quote from document | Recommendation

Privacy policy to analyze:
[INSERT TEXT]

Stage 2: Legal Basis Analysis

Analyze the legal bases in the privacy policy below.

For each data processing operation, check:

1. Whether a specific legal basis from Article 6(1) GDPR is stated:
   (a) consent, (b) contract, (c) legal obligation,
   (d) vital interests, (e) public task, (f) legitimate interest

2. For consent: is the mechanism for obtaining and withdrawing consent described?
   Is the consent freely given, specific, informed, and unambiguous?

3. For legitimate interest: has a balancing test been conducted?
   Is a specific legitimate interest identified?

4. For contract: is the processing genuinely necessary for the performance
   of the contract, or merely convenient?

Flag cases where:
- No legal basis is stated
- The legal basis is incorrect (e.g., consent used for processing
  necessary for contract performance)
- One operation references multiple bases without prioritization

Privacy policy:
[INSERT TEXT]

Stage 3: Language and Contradiction Check

Check the privacy policy for language problems and internal contradictions.

Criteria:

LANGUAGE:
- Find formulations that violate the "clear and plain language" requirement
- Flag legal jargon without explanation
- Find vague language: "may", "might", "from time to time",
  "and/or", "including but not limited to", "etc."

CONTRADICTIONS:
- Retention periods in one section contradict another
- Stated purposes don't match actual operations
- Data subject rights are described more broadly in one place than another

GAPS:
- Data is collected (forms, cookies, API) but not described in the policy
- Third-party services are used but not listed as recipients
- Data categories are not specified for all processing purposes

For each finding, indicate:
- Issue type (language / contradiction / gap)
- Quote
- Recommended correction

Privacy policy:
[INSERT TEXT]

Typical AI Audit Findings: What LLMs Find in Most Policies

After running these prompts on dozens of privacy policies, the same five problems show up over and over. Here are real examples (anonymized) with explanations of why they fail.

Problem 1: “Legitimate Interest” as a Catch-All

Wording from a real privacy policy:

“We process your data based on our legitimate interest to improve our services and provide you with a better experience.”

Why it fails: legitimate interest requires a documented balancing test — you weigh your interest against the data subject’s rights, explicitly. “Improving the service” doesn’t pass that bar. The French CNIL fined Criteo €40M in 2023 partly for using legitimate interest without proper balancing tests. Supervisory authorities across the EU have penalized this pattern repeatedly.

Correct wording:

“We process anonymized usage analytics based on our legitimate interest in improving application performance and reliability (Article 6(1)(f) GDPR). We have conducted a balancing test and determined that this processing does not override your rights, as the data is aggregated and cannot identify individual users. For personalized recommendations, we rely on your explicit consent (Article 6(1)(a) GDPR), which you can withdraw at any time in Settings > Privacy.”

Problem 2: Vague Retention Periods

Wording:

“We retain your data for as long as necessary to provide our services or as required by law.”

Why it fails: Article 13(2)(a) requires concrete retention periods or the criteria used to determine them. “As long as necessary” doesn’t qualify as a criterion — no regulator has ever accepted that wording as sufficient.

Correct wording:

“Account data: retained for the duration of your account plus 30 days after deletion request. Transaction records: retained for 7 years (tax compliance obligation under [local law]). Support tickets: retained for 2 years after resolution. Usage analytics: aggregated after 90 days, raw data deleted.”

Problem 3: Missing Information on Cross-Border Transfers

A startup uses AWS (US-East), Stripe (US), SendGrid (US), Mixpanel (US), yet the privacy policy says:

“Your data is stored securely on our servers.”

Why it fails: Article 13(1)(f) requires disclosure of transfers to third countries. Every US-based SaaS in your stack counts as a cross-border transfer. Post-Schrems II, you need to document the safeguards in place — Standard Contractual Clauses (SCCs) being the standard answer since the EU-US Data Privacy Framework (adopted July 2023) only covers companies on the DPF list.

Correct wording:

“Your data is transferred to the United States through the following processors: Amazon Web Services (hosting), Stripe (payment processing), SendGrid (email delivery). These transfers are protected by Standard Contractual Clauses (SCCs) approved by the European Commission, supplemented by additional technical measures including encryption in transit and at rest.”

Problem 4: No Distinction Between Mandatory and Optional Data

Wording:

“We collect your name, email, phone number, company name, and job title when you sign up.”

Why it fails: Article 13(2)(e) requires you to state whether providing each piece of data is mandatory. If only an email is required for registration and the rest is optional, say so explicitly. And if every field is marked mandatory without justification, you’ve also violated data minimization under Article 5(1)(c).

Problem 5: Cookie Consent Without Real Choice

The AI audit doesn’t stop at policy text — you can also check cookie banner implementation directly:

Analyze the HTML code of the cookie banner below for compliance
with the GDPR and ePrivacy Directive.

Check:
1. Are analytics/marketing scripts loaded BEFORE the user
   interacts with the banner?
2. Is there a "Reject all" button on the first screen of the banner
   (not in a submenu)?
3. Are the "Accept" and "Reject" buttons visually equivalent
   (size, color, placement)?
4. Are there pre-ticked toggles for non-essential categories?
5. Is the user's choice saved and can it be changed later?

HTML code:
[INSERT BANNER CODE]

Privacy Policy Template for a SaaS Startup

This template covers all 13 elements of Article 13. Sections are annotated with the corresponding requirement number. The text is intentionally specific — wherever you see [FILL IN], that’s where vague language used to live. Think of it as a documentation SOP specifically for privacy compliance.

# Privacy Policy

Last updated: [DATE]

## Who we are

[COMPANY NAME] ("[SHORT NAME]", "we", "us") is the data controller
for personal data processed through [PRODUCT NAME].

Contact: [EMAIL]
Address: [LEGAL ADDRESS]
Data Protection Officer: [DPO NAME, EMAIL] <!-- if applicable -->

<!-- Article 13(1)(a)(b) — controller and DPO -->

## What data we collect and why

### Account data
**Data:** email address, display name
**Purpose:** account creation and authentication
**Legal basis:** contract performance (Article 6(1)(b))
**Mandatory:** email is required; display name is optional
**Retention:** duration of account + 30 days after deletion

### Billing data
**Data:** payment method (processed by Stripe), billing address, invoices
**Purpose:** payment processing and tax compliance
**Legal basis:** contract performance (Article 6(1)(b))
  and legal obligation (Article 6(1)(c)) for invoice retention
**Mandatory:** required for paid plans
**Retention:** invoices retained for [7] years (tax law);
  payment details stored by Stripe per their retention policy

### Usage data
**Data:** pages visited, features used, session duration
**Purpose:** product improvement and reliability monitoring
**Legal basis:** legitimate interest (Article 6(1)(f))
**Balancing test:** data is aggregated within [90] days;
  individual users cannot be identified from aggregated data
**Mandatory:** collected automatically; opt-out available in Settings
**Retention:** raw data [90] days, aggregated data [2] years

### Marketing communications
**Data:** email address, communication preferences
**Purpose:** product updates and educational content
**Legal basis:** consent (Article 6(1)(a))
**Mandatory:** not required
**Retention:** until consent is withdrawn

<!-- Article 13(1)(c)(d), 13(2)(a)(e) — purposes, bases, retention -->

## Who receives your data

| Processor | Purpose | Location | Safeguard |
|-----------|---------|----------|-----------|
| [AWS] | Hosting | [EU/US] | [SCCs / Adequacy] |
| [Stripe] | Payments | US | SCCs |
| [SendGrid] | Email | US | SCCs |
| [Sentry] | Error tracking | US | SCCs |

We do not sell personal data. We do not share data with third parties
for their own marketing purposes.

<!-- Article 13(1)(e)(f) — recipients, cross-border transfers -->

## Your rights

Under GDPR, you have the right to:

- **Access** your personal data (Article 15)
- **Rectify** inaccurate data (Article 16)
- **Erase** your data ("right to be forgotten", Article 17)
- **Restrict** processing (Article 18)
- **Data portability** — receive your data in JSON format (Article 20)
- **Object** to processing based on legitimate interest (Article 21)
- **Withdraw consent** at any time without affecting prior processing

To exercise any right: email [PRIVACY EMAIL] or use Settings > Privacy
in the application. We respond within 30 days.

<!-- Article 13(2)(b)(c)(d) — data subject rights -->

## Automated decision-making

[OPTION A: if not used]
We do not use automated decision-making or profiling
that produces legal or similarly significant effects.

[OPTION B: if used]
We use automated processing for [DESCRIBE]. You have the right
to obtain human review of this decision by contacting [EMAIL].

<!-- Article 13(2)(f) -->

## Complaints

You have the right to lodge a complaint with a supervisory authority.
For [COUNTRY], this is [AUTHORITY NAME] ([WEBSITE]).

<!-- Article 13(2)(d) -->

## Cookies

See our [Cookie Policy](/cookies) for details on cookies used,
their purposes, and how to manage preferences.

## Changes to this policy

We notify users of material changes via email [and/or in-app notification]
at least [30] days before changes take effect.

Automation: Recurring AI Audits

A one-time audit finds current issues. A recurring audit catches drift — every new SaaS tool in your stack means the privacy policy needs updating, every new data collection form means the checklist runs again.

Here’s a three-step automation setup.

Step 1: export the current privacy policy. A script pulls the policy text from the site and writes it to a file. curl plus HTML parsing works for most sites; use Playwright for SPAs.

Step 2: run the audit via API. Send the prompts from the section above to an LLM API. Save the output as a JSON report.

import openai

def audit_privacy_policy(policy_text: str) -> dict:
    prompts = {
        "completeness": COMPLETENESS_PROMPT,
        "legal_bases": LEGAL_BASES_PROMPT,
        "language": LANGUAGE_PROMPT,
    }
    results = {}
    for audit_type, prompt in prompts.items():
        response = openai.chat.completions.create(
            model="gpt-5.4",
            messages=[
                {"role": "system", "content": prompt},
                {"role": "user", "content": policy_text}
            ],
            temperature=0.1  # minimal creativity for an audit
        )
        results[audit_type] = response.choices[0].message.content
    return results

Step 3: wire it into CI/CD or your monthly SOP. Run the audit as part of a recurring process. Push the report to Slack or save it to Notion. If any of the 13 elements comes back MISSING, auto-create a task in the issue tracker. For monitoring AI pipeline health alongside compliance, LLM observability tools can track audit prompt performance over time.

Frequency: monthly for products in active development, quarterly for anything stable.

Limitations of AI Audits: What LLMs Can’t Check

An AI audit covers text and document structure. There’s a hard boundary to what it can catch — and I think it’s important to be honest about this.

Practice vs. documentation. An LLM can confirm that your policy says “data is deleted after 30 days.” It can’t confirm the code actually does it. That’s code review and integration tests.

Jurisdiction-specific law. GDPR is a floor, not a ceiling. Germany’s BDSG, France’s Loi Informatique et Libertés, and Austria’s DSG all add requirements on top. An LLM knows the general rules but doesn’t track recent rulings from national supervisory authorities — and those rulings matter. The model’s training data has a cutoff date; a ruling from last month won’t be in there.

Risk assessment. A DPIA requires analyzing your specific business context: what data, what risks, what mitigations. An LLM can hand you a template, but only someone who actually knows your operations can fill it in correctly.

Hallucination risk. LLMs occasionally invent Article numbers, cite non-existent CJEU rulings, or misstate fine amounts. Always verify specific legal references against the source text. The audit prompts above are designed to minimize this by asking for structured output rather than free-form legal advice.

The practical play: run the AI audit first. Send the result to a lawyer labeled “AI pre-screened, needs legal review.” The lawyer skips the mechanical checklist and focuses on the hard questions. In my experience, legal review drops from €300–800 to roughly €100–200 because they’re working from a structured report, not raw policy text.

Steps to Take

1. Work through the checklist above and mark your current status for each item
2. Run the privacy policy through all three prompts (completeness, legal bases, language)
3. Fix MISSING and PARTIAL items using the template as a reference
4. Check the cookie banner with the separate prompt
5. List all sub-processors and confirm a signed DPA exists for each one
6. Set up a monthly automated audit
7. Send the result to a lawyer for final sign-off

The first three steps take 15–20 minutes with an LLM. The rest is team work — but you’re going into it with a concrete action list, not a vague instruction to “become GDPR-compliant.”

Need help with AI-powered compliance automation? I help startups build AI products and automate processes — belov.works.