Een praktische checklist om apphosting te toetsen aan de AVG: jurisdictie, subverwerkers, bewaartermijnen, back-ups en een uitweg.
Bijgewerkt op 24 september 2026
"AVG-conform" is geen vinkje dat een hostingplatform je kan geven; het is een reeks specifieke, controleerbare feiten over wie jouw data verwerkt, waar, onder wiens recht, en wat er gebeurt als er iets misgaat. Dat geldt voor elk onderdeel van een app, ook voor een statische front-end in een CDN-cache: een gecachete HTML-pagina kan nog steeds persoonsgegevens bevatten (de naam van een ingelogde gebruiker in een vooraf gerenderde pagina, bijvoorbeeld), dus "het zijn maar statische bestanden" is geen automatische vrijstelling. Dit is de checklist om tegen elk platform aan te houden, geen pagina die betoogt dat het antwoord altijd dezelfde leverancier is.
Vraag naar de statutaire vestigingsplaats en het toepasselijke recht van het bedrijf, niet alleen de regionaam in een dropdown. Een Amerikaans bedrijf dat data verwerkt in een EU-datacenter valt nog steeds onder Amerikaans recht dat zijn moederbedrijf raakt, inclusief de CLOUD Act; een in de EU opgericht bedrijf zonder buitenlandse moeder neemt dat pad helemaal weg. Sarpius publiceert zijn KVK-nummer en vestigingsplaats (KVK 73239038, Apeldoorn, Nederland) op zijn dataresidentiepagina, plus het feit dat het de hardware waarop het draait zelf bezit in plaats van capaciteit te huren binnen de regio van een hyperscaler.
Controleer of "EU-regio" de hele stack dekt of maar één dienst: staat de database in dezelfde regio als de app? De objectopslag? De edge-/CDN-laag die een statische front-end cachet? Een platform dat statische assets via een CDN van een derde serveert (standaard Cloudflare, bij Sarpius) brengt die CDN-beheerder als subverwerker in beeld, zelfs voor content die nooit een database raakt, precies waarom de lijst met subverwerkers ertoe doet. Is er een vastgelegd beleid over waar toekomstige regio's worden toegevoegd? Een platform dat daar vaag over is op zijn eigen documentatiepagina, is er een die je steeds opnieuw moet controleren.
Een korte, met naam genoemde lijst wint het van een vage regel als "we gebruiken providers volgens de industriestandaard". Vraag wat elke subverwerker doet, waar hij gevestigd is, en of hij te vervangen is. Let vooral op analytics- en foutopsporingstools: veel platforms sturen dit stilletjes naar een Amerikaanse leverancier. Je eigen observability-stack self-hosten haalt hem helemaal van de lijst, een kleiner aanvalsoppervlak voor een FG om te beoordelen, niet alleen een kleiner document. Sarpius noemt er precies twee, Cloudflare Inc. (DNS/CDN/DDoS, wereldwijd netwerk) en Mollie B.V. (betalingen, Nederland), en stelt dat zijn foutopsporing (Sentry) en analytics (Matomo) self-hosted zijn in plaats van naar een derde te worden gestuurd. Is Cloudflare als subverwerker voor een bepaald domein een harde blokkade, dan is dat een reëel pad om naar te vragen, geen vinkje: Sarpius heeft een betaalde, per domein instelbare "Privacy route" die Cloudflare voor dat specifieke domein uit het verzoekpad haalt, tegen een meerprijs van EUR 4,99/maand bovenop de EUR 1,99/maand vergoeding voor een eigen domein. Inschakelen betekent dat de DNS van het domein rechtstreeks naar de eigen edge van Sarpius wijst in plaats van naar Cloudflare, en dat de CDN-, WAF- en DDoS-bescherming van Cloudflare het verkeer van dat domein niet meer dekt; het is een echte ruil van Cloudflare's bescherming tegen Cloudflare's afwezigheid op het datapad.
De moeite waard om letterlijk te lezen. Sommige verwerkersovereenkomsten stellen dat ze alleen gelden "voor klanten op Enterprise- en Pro-plannen", die van Vercel is daar een voorbeeld van. Een gratis-planproject dat persoonsgegevens verwerkt zonder DPA-dekking heeft geen contractuele AVG-onderbouwing. Vraag: geldt de DPA voor elk plan, vanaf gratis?
Zoek naar echte cijfers: hoe lang wordt data bewaard na accountsluiting, en hoe lang worden beveiligings-/toegangslogs bewaard? Vage antwoorden ("zo lang als nodig") zijn een geel vlaggetje; een genoemde termijn met met naam genoemde uitzonderingen (wettelijke of fiscale bewaarplicht) is hoe een echt beleid eruitziet. Sarpius: actieve accounts bewaard zolang nodig, gesloten accounts minstens 6 maanden en daarna verwijderbaar behalve voor wettelijke/fiscale bewaarplicht, beveiligingslogs tot 12 maanden.
Vraag expliciet of het platform advertentiecookies van derden gebruikt, data verkoopt of verhuurt, of profilerings-/databrokerdiensten als subverwerker inzet: een platform zou dit in één zin moeten kunnen beantwoorden, niet in een alinea vol voorbehouden. Sarpius stelt dat het geen persoonsgegevens verkoopt, verhuurt of verhandelt, geen analytics of advertentiecookies van derden gebruikt, en alleen first-party cookies plaatst voor authenticatie, beveiliging en taal.
Dit is het punt waar de meeste platforms omheen draaien. "We maken back-ups" betekent meestal interne, door de operator uitgevoerde back-ups voor het eigen disaster recovery van het platform, geen hersteldpunt waar een klant zelf over gaat. Vraag: kun je zelf een herstel starten? Bestaat er point-in-time recovery? Wat is er gedekt, per resourcetype? Een platform dat eerlijk is over een gat hier is bruikbaarder dan een platform dat dekking suggereert die het niet heeft gebouwd. Sarpius stelt ronduit dat zelfbediend herstel en point-in-time recovery nog niet bestaan, dat een herstel vandaag via support loopt, en dat dit is waar het platform nu aan bouwt, niet ergens voor "ooit".
De praktische toets: staat de broncode in je eigen git-repository, onder je eigen account, op een host die jij koos? Zijn databases een standaard-engine (Postgres, MySQL/MariaDB) bereikbaar met elke standaardclient, zodat een pg_dump gewoon werkt? Is objectopslag S3-compatibel, bereikbaar met een bestaande S3-client en je eigen sleutels, geen eigen exporttool nodig, inclusief de gebouwde assets van een statische front-end, die in diezelfde objectopslag staan? Als alle drie ja zijn, kan data weg zonder medewerking van de leverancier.
Los van losse tooltoegang: geeft het platform je een geautomatiseerd, compleet archief van alles wat het bewaart? Bij Sarpius kan de eigenaar een complete Project-migratiebundel downloaden, rechtstreeks vanuit de Project-werkruimte achter een consolelogin plus je tweefactorcode als 2FA aanstaat. De bundel bevat, per component, de gebouwde front-end/statische output en de actuele containerbestanden (inclusief geüploade media en applicatiestatus); een SQL-dump per database; bucketobjecten en bucketmanifesten; een manifest.json-bestand met de git-repository-URL en exacte commit-SHA per component, een sha256-checksum per bestand, en een expliciete lijst van wat niet is opgenomen en waarom (zoals een onbereikbare container of een te grote bucket); en ontsleutelde omgevingsvariabelen die alleen op het moment van downloaden als secrets.env worden toegevoegd, nooit bewaard in het rustende bundelbestand in opslag. Downloadautorisatie loopt via een kortlevend, eenmalig token dat 5 minuten geldig is, beperkt tot een consolesessie achter 2FA. Bundels blijven 24 uur downloadbaar, en kunnen één keer per 24 uur worden aangevraagd.
Nee. Naleving hangt af van de verwerkersovereenkomst, subverwerkers, bewaartermijnen en je eigen gebruik van de data, niet alleen van de locatie van de server. Een Amerikaans bedrijf kan hosten in een EU-regio en toch bereikbaar zijn onder Amerikaans recht voor de data die het beheert.
Een derde partij die een platform inzet om te helpen bij dataverwerking, bijvoorbeeld een CDN of betalingsverwerker. Een korte, met naam genoemde lijst is sterker bewijs dan een algemene nalevingsverklaring.
Hangt af van de leverancier. Controleer de eigen reikwijdtebepaling van de DPA; sommige sluiten gratis/Hobby-tiers expliciet uit.
Of een herstel door de klant zelf kan worden gestart, of point-in-time recovery bestaat, en wat er per resourcetype is gedekt. Een leverancier die een gat gewoon benoemt, is veiliger dan een die meer suggereert dan hij heeft gebouwd.
Ja: het haalt die tools van de lijst met subverwerkers en van de vraag naar doorgifte naar een derde land, in plaats van te beargumenteren waarom die data naar een Amerikaanse leverancier sturen onder de EU-doorgifteregels acceptabel is.
Sarpius biedt twee lagen om weg te kunnen. Ten eerste directe toegang: je git-repository blijft op je eigen githost staan, databases zijn standaard PostgreSQL, Redis en MariaDB bereikbaar met standaardclients, en objectopslag is S3-compatibel met je eigen inloggegevens. Ten tweede een geautomatiseerde Project-migratiebundel, gedownload vanuit de Project-werkruimte achter een consolelogin plus je tweefactorcode als 2FA aanstaat. Die bevat containerbestanden, statische buildoutput, SQL-dumps van databases, bucketobjecten, en een manifest met git-commit-SHA's en sha256-checksums per bestand. Ontsleutelde omgevingsvariabelen worden op het moment van downloaden als secrets.env meegeleverd via een eenmalig token dat 5 minuten geldig is, en nooit in het opgeslagen archief bewaard. Bundels blijven 24 uur bewaard, één keer per 24 uur op te vragen.
Sarpius publiceert zijn statutaire vestigingsplaats, zijn twee met naam genoemde subverwerkers, zijn bewaartermijnen en zijn DPA op één pagina, en is expliciet dat het vandaag vanuit één Nederlandse locatie draait, met zelfbediend databaseherstel nog niet beschikbaar. Houd de checklist hierboven tegen elke leverancier aan, inclusief deze, in plaats van een badge zomaar te vertrouwen.