Is Supabase AVG-compliant voor Nederlandse bedrijven?

Ja, als je het correct configureert. Kies EU-west (Frankfurt) bij het aanmaken van je project, onderteken Supabase's DPA (beschikbaar in hun Enterprise-plan of op aanvraag), activeer RLS op alle gebruikergerichte tabellen, en configureer retentiebeleid voor logs. Supabase is ISO 27001, SOC 2 Type II en AVG-gecertificeerd.

Moet ik een verwerkersovereenkomst ondertekenen met alle no-code tools die ik gebruik?

Ja, voor alle tools die persoonlijke data van je gebruikers verwerken. Dit omvat minimaal Supabase, Xano, Make/n8n, Stripe/Mollie, en je e-mailprovider (Brevo, SendGrid). De meeste bieden DPA's aan als standaarddocument op hun website of op verzoek. Dit is een AVG-verplichting, geen optie.

Wat is het risico als ik RLS vergeet in een multi-tenant no-code app?

Een ernstig datalek waarbij gebruikers elkaars data kunnen zien of wijzigen. Dit veroorzaakt AVG-meldingsplicht binnen 72 uur, potentieel reputatieschade en mogelijke boetes van de Autoriteit Persoonsgegevens (tot 4% van jaarlijkse omzet of €20M, afhankelijk van wat hoger is). Activeer RLS op dag één, niet als afterthought.

Hoe implementeer ik het recht op vergetelheid (dataverwijdering) in een WeWeb + Supabase-app?

Bouw een accountverwijderingsflow die: 1) alle persoonlijke kolommen in de users-tabel anonimiseert (email, naam, telefoon → vervangen door placeholder-waarden), 2) uploads uit Supabase Storage verwijdert, 3) AI-gebruikslogboeken verwijdert, 4) de Supabase Auth-gebruiker verwijdert via de admin API. Sla een verwijderingstimestamp op voor auditdoeleinden (zonder de persoonlijke data).

No-Code Beveiliging en AVG

Waarom RLS onmisbaar is in multi-tenant apps

Row-Level Security (RLS) is PostgreSQL's mechanisme om toegangscontrole op rijniveau af te dwingen. In een multi-tenant SaaS, waarbij meerdere bedrijven of gebruikers data in dezelfde database opslaan, is RLS geen optionele beveiligingslaag. Het is de fundamentele beveiligingsgarantie.

Zonder RLS: als je applicatielaag een bug heeft (een ontbrekend filter in een query), kunnen gebruikers data zien die niet van hen is. Dit is niet hypothetisch, het is de meest voorkomende oorzaak van datalekken in SaaS-producten.

Met RLS: zelfs als je applicatielaag een bug heeft, weigert de database rijen te retourneren waartoe de gebruiker geen toegang heeft. RLS is een vangnet op het laagste niveau.

Vanuit een AVG-perspectief vereist Artikel 25 (privacy by design) dat toegangscontrole in de architectuur is ingebakken, niet alleen op applicatieniveau wordt geïmplementeerd. RLS voldoet hier perfect aan.

RLS-policies schrijven: de basis

Activeer RLS op een tabel en schrijf je eerste policy:

```sql -- RLS activeren alter table orders enable row level security;

-- Gebruikers kunnen alleen hun eigen orders lezen create policy "users_own_orders" on orders for select using (user_id = auth.uid());

-- Voor multi-tenant: workspace-isolatie create policy "workspace_isolation" on projects for all using ( workspace_id in ( select workspace_id from workspace_members where user_id = auth.uid() ) ); ```

Kernregel: elke gebruikergerichte tabel heeft RLS nodig. Uitzondering: lookup-tabellen (landen, categorieën) die openbare data bevatten, die kunnen zonder RLS.

Test je RLS-policies expliciet: log in als gebruiker A en verifieer dat je alleen rijen met workspace_id = A ziet. Log in als gebruiker B en verifieer hetzelfde. Vertrouw niet op handmatige code-review, run tests.

Veelgemaakte RLS-fouten

**Fout 1: RLS activeren maar vergeten policies te schrijven**. Als RLS is geactiveerd maar er geen policies zijn, is de tabel volledig ontoegankelijk voor alle gebruikers, inclusief degenen die er toegang toe zouden moeten hebben. Altijd policies schrijven na het activeren van RLS.

**Fout 2: Vergeten om INSERT en UPDATE-policies te schrijven naast SELECT**. Veel developers schrijven alleen een SELECT-policy. Maar je hebt aparte policies nodig voor `INSERT`, `UPDATE` en `DELETE`. Een ontbrekende `INSERT`-policy kan ertoe leiden dat gebruikers rijen invoegen met een workspace_id die niet de hunne is.

**Fout 3: Performante policies niet optimaliseren**. RLS-policies worden uitgevoerd bij elke query. Een policy die een subquery uitvoert (zoals het controleren van workspace-lidmaatschap) kan traag zijn als de workspace_members-tabel groot is. Voeg indexen toe op de kolommen in je RLS-policy WHERE-clausules.

**Fout 4: Service role gebruiken vanuit de frontend**. De Supabase service role bypast RLS volledig. Gebruik nooit de service role sleutel in je WeWeb- of FlutterFlow-app. Gebruik altijd de `anon` of `authenticated` sleutel.

AVG-dataresidentievereisten

De AVG vereist niet expliciet dat data in de EU moet worden opgeslagen, maar het vergemakkelijkt compliance voor internationale datatransfers aanzienlijk. Voor Nederlandse B2B-SaaS is EU-dataresidentie steeds vaker een contractuele vereiste van enterprise-klanten.

Keuzes voor EU-dataresidentie:

**Supabase**: Kies `eu-west-1` (Frankfurt) bij het aanmaken van het project. Let op: je kunt de regio niet wijzigen na aanmaken. Al je data, inclusief database, storage en Edge Function logs, blijft in de EU.

**Xano**: Biedt EU-regio's aan op betaalde plannen. Kies Europa bij het instellen van je workspace.

**Make/n8n**: Make's servers zijn gebaseerd in de VS maar data die erdoor gaat kan tijdelijk buiten de EU worden verwerkt. Voor scenario's met gevoelige persoonlijke data gebruik je n8n self-hosted in de EU of Supabase Edge Functions als alternatief.

AVG-verplichtingen voor no-code SaaS

De acht verplichtingen die Nederlandse no-code SaaS-bedrijven het vaakst negeren:

1. **Verwerkingsregister**: Documenteer welke data je verwerkt, waarvoor en hoe lang je het bewaart 2. **Verwerkersovereenkomsten (DPA's)**: Onderteken DPA's met Supabase, Xano, Make, Stripe, en elke andere tool die persoonlijke data verwerkt 3. **Cookiebanner**: Voor analytics en marketing cookies op je marketingsite 4. **Privacybeleid**: Specifiek, niet generiek, beschrijf exact welke data je verzamelt en waarom 5. **Recht op inzage**: Procedure voor gebruikers om hun data op te vragen 6. **Recht op vergetelheid**: Bouw accountverwijdering in die alle persoonlijke data verwijdert 7. **Databreuk-procedure**: Weet hoe je een databreuk binnen 72 uur meldt bij de Autoriteit Persoonsgegevens 8. **Privacy by design**: RLS, minimale dataverzameling, versleutelde opslag voor gevoelige velden

Beveiligingsaudit checklist voor no-code apps

Voordat je een no-code SaaS lanceert voor betalende Nederlandse klanten:

**Database**: - [ ] RLS geactiveerd op alle gebruikergerichte tabellen - [ ] RLS-policies getest door in te loggen als verschillende gebruikers - [ ] Service role sleutel nooit in frontendcode - [ ] Supabase project in EU-west regio

**Frontend (WeWeb/FlutterFlow)**: - [ ] API-sleutels (OpenAI, Stripe, etc.) nergens in de frontend - [ ] HTTPS afgedwongen - [ ] Geen gevoelige data in URL-parameters of localStorage

**Backend (Xano/Edge Functions)**: - [ ] JWT-validatie op elk beveiligd endpoint - [ ] Invoervalidatie op alle parameters - [ ] Rate limiting op AI- en dure endpoints - [ ] Geen stack traces in productie-foutresponses

**Compliance**: - [ ] Privacybeleid gepubliceerd en correct - [ ] DPA's ondertekend met alle verwerkers - [ ] Accountverwijderingsflow gebouwd en getest - [ ] Cookiebanner geïmplementeerd

No-Code Beveiliging en AVG: Supabase RLS correct gebruiken