Revvolt
Aan de slag

Veiligheid & privacy

Je vertrouwt ons met je laadgegevens en straks met je uitbetaling. Op deze pagina staat in gewone taal wat we van je bewaren, waar het staat en wie erbij kan. Geen techniek nodig om het te snappen.

Laatst bijgewerkt: juli 2026

Liever de techniek? Spring naar de technische toelichting →

In het kort

Alleen jij ziet jouw gegevens

Elk account kan uitsluitend bij zijn eigen gegevens. Dat zit niet in een filter in de app, maar als slot in de database zelf.

Versleuteld opgeslagen

De sleutel waarmee we je laadsessies ophalen bewaren we versleuteld. Wat je nodig hebt om die te openen ligt ergens anders, dus met een kopie van de database alleen kun je niets.

Wij kennen je wachtwoord niet

Je wachtwoord gaat rechtstreeks naar onze inlogdienst en komt nooit langs onze eigen servers. Log je in met Google, dan heb je bij ons zelfs helemaal geen wachtwoord.

Alles is herleidbaar

Koppelingen, registraties en controles komen in een logboek waar alleen aan toegevoegd kan worden. Niets kan stil worden aangepast of gewist.

Welke gegevens we van je hebben

We vragen wat we nodig hebben om je ERE's te kunnen registreren en uitbetalen. Niet meer.

Wat we opslaan

  • Je naam en e-mailadres, voor je account en onze berichten.
  • Je adres en de EAN-code van je netaansluiting — die zijn verplicht voor de registratie bij de NEa.
  • Merk en model van je laadpaal, en welke laadpaal op welk adres staat.
  • Je laadsessies: begin- en eindtijd en het aantal kWh.
  • Later, zodra we uitbetalen: je bankrekeningnummer. Dat krijgt dezelfde versleutelde behandeling als je laadpaalkoppeling.

Wat we níet doen

  • We volgen je auto niet: geen ritten, geen locaties, geen kentekens.
  • We zien niets van het overige stroomverbruik in je huis — alleen wat er door je laadpaal gaat.
  • We bedienen je laadpaal niet. We lezen alleen sessies uit — starten, stoppen of instellingen wijzigen doen we niet.
  • We verkopen je gegevens niet, verhandelen ze niet en bouwen er geen advertentieprofielen mee.

Waar je gegevens staan

Je account- en laadgegevens staan bij verwerkers in de Europese Unie, versleuteld onderweg en versleuteld op schijf. Onze leveranciers werken onder een verwerkersovereenkomst en krijgen alleen wat ze nodig hebben om hun werk te doen.

Voor het meten van websitebezoek gebruiken we cookies — die staan los van je account. Wat we meten en hoe je het uitzet lees je in onze Privacyverklaring.

Hoe de koppeling met je laadpaal beveiligd is

Elk laadpaalmerk doet het anders. We kiezen per merk altijd de weg waarbij wij zo weinig mogelijk van je hoeven te weten.

01

Toestemming bij de fabrikant

Bij de meeste merken klik je in de omgeving van de fabrikant zelf op 'toestaan'. Je inloggegevens komen dan nooit langs ons: wij krijgen alleen een sleutel, en die kun je aan beide kanten weer intrekken.

02

Eén keer inloggen of een sleutel plakken

Bij sommige merken log je één keer in, of maak je in je eigen account een sleutel aan die je bij ons plakt. Daarna bewaren we alleen die sleutel, versleuteld — je wachtwoord slaan we niet op.

03

De uitzonderingen, en dat zeggen we erbij

Een enkel merk biedt (nog) geen andere weg dan je inloggegevens. Dan bewaren we ze versleuteld, staat dat in gewone taal op de koppelpagina vóórdat je iets invult, en verdwijnen ze zodra je de koppeling verbreekt. Zulke uitzonderingen willen we kwijt: we vragen bij die fabrikanten om een nette koppeling.

Wie er bij je gegevens kan

Waarom we zo veel vastleggen

Een ERE-certificaat is pas iets waard als iemand kan nagaan dat die kWh echt geladen is. Daarom bewaren we het antwoord van je laadpaal onveranderd zoals we het binnenkregen, en leggen we elke controle en elke wijziging vast. Lastig voor wie zou willen sjoemelen — en prettig voor jou, want het is jouw bewijs als er ooit vragen over komen.

Jij houdt de regie

Samen veilig

Voor de techneuten

Wil je meer dan "we versleutelen alles"? Hieronder de mechanismen zelf. Wel op het niveau waarop je ze kunt beoordelen, niet op het niveau waarop ze een handleiding worden.

Klik een onderwerp open.

Toegangscontrole in de database
  • Row-level security staat aan op elke tabel met klantgegevens. De policies binden aan het gebruikers-id uit het geverifieerde sessietoken, niet aan iets wat de client meestuurt. Een API-sleutel loopt door exact dezelfde policies.
  • Kolommen met sleutelmateriaal hebben daarbovenop hun rechten ingetrokken voor de klant-rol. Een fout in één policy levert dus nog steeds geen sleutels op — twee sloten, niet één.
  • De rol die RLS mag omzeilen bestaat alleen server-side, achter onze eigen API, en komt nooit in browser-code terecht. Geen rechtstreekse databaseverbinding vanuit de client.
Versleuteling
  • Onderweg: TLS met moderne cipher suites, HSTS op onze domeinen, geen gemengde content.
  • In rust: schijfversleuteling bij de hostingpartij, plus versleutelde backups die de EU niet verlaten.
  • Daarbovenop versleutelen we sleutelmateriaal van laadpaalkoppelingen op applicatieniveau met AES-256-GCM (authenticated encryption, eigen nonce per waarde). De ciphertext draagt een versieprefix, zodat we van sleutel of algoritme kunnen wisselen zonder downtime en zonder big-bang-migratie.
  • De encryptiesleutel leeft in de runtime-omgeving — niet in de database, niet in de repository, niet in een backup. Een databasedump zonder die sleutel levert geen bruikbaar token op. Keerzijde die we eerlijk noemen: raakt die sleutel kwijt, dan moet iedereen opnieuw koppelen. Dat is de bedoelde faalrichting.
Authenticatie & sessies
  • Inloggen en registreren gaan vanuit de browser rechtstreeks naar onze managed auth-provider. Je wachtwoord passeert onze eigen API-routes, servercode en tabellen dus niet. Opslag is een bcrypt-hash met per-gebruiker salt, in een schema waar onze applicatierol niet bij kan.
  • Sessies zijn kortlevende JWT's in httpOnly, secure cookies; het verversen gebeurt in middleware. Autorisatie hangt altijd aan het gebruikers-id uit het token.
  • Google-login gaat via OIDC. Die gebruikers hebben bij ons helemaal geen wachtwoord — niets om te lekken.
  • De auth-endpoints zijn rate-limited bij de provider; herhaalde mislukte pogingen lopen dus niet ongelimiteerd door.
Laadpaalkoppelingen
  • Waar de fabrikant het ondersteunt: OAuth 2.0 authorization code flow, met een CSRF-`state` in een kortlevende httpOnly cookie, vaste redirect-URI's en tokenuitwisseling server-side.
  • We vragen de smalste scope die de laadsessies oplevert. Geen rechten om te starten, te stoppen of instellingen te wijzigen — die kunnen we dus ook niet misbruiken als er iets bij ons misgaat.
  • Tokens verversen we buiten je flow om. Lukt dat niet meer, dan markeren we de koppeling als verlopen en vragen we je opnieuw te koppelen, in plaats van door te blijven hameren op de API van de fabrikant. Dat is ook wat hun fair-use-beleid van ons vraagt.
  • Merken zonder OAuth: een sleutel of personal access token die je zelf aanmaakt, of — als er echt geen andere weg is — inloggegevens. Altijd applicatie-versleuteld, altijd met disclosure op de koppelpagina vóór het invulveld, altijd weg bij verbreken. Welke maatregel bij welk merk hoort, staat op die koppelpagina zelf.
Ingestie & bewijsvoering
  • Het antwoord van de fabrikant gaat onveranderd in append-only opslag. De genormaliseerde sessie is een afgeleide daarvan, dus elke berekening is opnieuw uit te voeren vanaf de bron.
  • Sessies worden geüpsert op de sessie-identificatie van de fabrikant. Een herhaalde, overlappende of achterstallige sync kan daardoor geen dubbele kWh opleveren.
  • Levert de fabrikant ondertekende meterdata (OCMF), dan bewaren we die ondertekende blob zoals hij is — de signature is namelijk waardeloos zodra je hem herschrijft.
  • Toewijzing is datumgebonden: een sessie hoort bij de eigenaar die op de starttijd van die sessie aan de laadpaal hing. Een latere koppeling kan geen eerdere sessies claimen, en bij een overdracht verhuizen alleen de sessies vanaf de afgesproken datum.
  • Elke verificatiestap en statuswijziging is een append-only auditregel. Op die tabellen bestaan geen UPDATE- of DELETE-rechten, ook niet voor ons.
De ERE-berekening
  • ERE = kWh × hernieuwbare fractie × fossiele referentie × 3,6 / 1000. Geen geheime saus: het is de rekenregel uit de regelgeving, en hij is unit-tested.
  • De parameters staan per kalenderjaar in configuratie in de database, niet in de code. Dezelfde bron voedt de calculator op deze site, je portaal en de registratie — één waarheid, dus geen verschil tussen wat we voorrekenen en wat we boeken.
Wat er nog niet is
  • MFA met TOTP. De opslagkant staat klaar bij onze auth-provider; de schermen erbij zijn een korte klus die we willen afronden vóór er uitbetaalgegevens in accounts staan.
  • Een check tegen bekende gelekte wachtwoorden bij registratie en wachtwoordwijziging.
  • De uitbetaalkant bestaat nog niet. Bankgegevens krijgen dezelfde applicatie-versleuteling als sleutelmateriaal, met strakkere toegang — dat bouwen we samen met de uitbetaling, niet erna.
  • Een gepubliceerde subprocessor-lijst en verwerkersovereenkomst voor wie ze wil inzien. Nu op aanvraag.

Wat we bewust niet publiceren

Geen infrastructuurdiagrammen, versienummers, namen van tabellen, endpoints of sleutels, en geen uitputtende lijst van welke maatregel bij welke leverancier zit. Voor jou verandert dat niets aan de garantie; voor een aanvaller is het het verschil tussen zoeken en weten.

Iets gevonden?

Als je een zwakke plek denkt te zien, horen we dat graag vóórdat iemand anders hem vindt. Mail ons met wat je zag en hoe we het kunnen nabootsen. We gaan er serieus mee om, ondernemen niets tegen wie netjes en zonder schade meldt, en noemen je met plezier als bedankje. Vraag: probeer niets waarmee je bij gegevens van andere klanten kunt komen, en geef ons de kans het te repareren voordat je het publiceert.

support@revvolt.nl

Onze contactgegevens voor meldingen staan ook machineleesbaar in /.well-known/security.txt.

Vragen over deze pagina of over je eigen gegevens? Mail ons op support@revvolt.nl

PrivacyverklaringVoorwaardenHelpcentrum