Verwerkersovereenkomst — CONCEPT

Dit is een concept. Het is opgesteld op basis van wat het systeem feitelijk doet, niet als juridisch advies, en het moet door een jurist gelezen en vastgesteld zijn voordat een gemeente het krijgt (fase 3, §11, open punt 8). Alles tussen [IN TE VULLEN: …] is een beslissing van partijen en staat er bewust leeg.

Laatst bijgewerkt: [IN TE VULLEN: datum]

Waar deze tekst over gaat. Deze overeenkomst regelt de verwerking van persoonsgegevens door de exploitant van het systeem (de verwerker) in opdracht van de aannemer (de verwerkingsverantwoordelijke). Hij beschrijft de inrichting van fase 3 (plannen A tot en met E). Onderdelen die pas werken zodra de eigenaar er een omgevingsvariabele voor zet — de e-mailmeldingen, de foutrapportage en de nachtelijke back-up — staan er als zodanig bij.

0. Wat er in dit concept nog ingevuld moet worden

Partijen

De verwerkingsverantwoordelijke: [IN TE VULLEN: naam, KvK-nummer, vestigingsadres en vertegenwoordiger van de verwerkingsverantwoordelijke (de aannemer)], hierna: de aannemer.

De verwerker: [IN TE VULLEN: naam, KvK-nummer, vestigingsadres en vertegenwoordiger van de verwerker (de exploitant van het systeem)], hierna: de exploitant.

Deze verwerkersovereenkomst hoort bij [IN TE VULLEN: de hoofdovereenkomst waar deze verwerkersovereenkomst bij hoort, met datum].

Vraag voor de jurist. De aannemer en de exploitant kunnen op dit moment dezelfde rechtspersoon zijn. Is dat zo, dan is er (nog) geen verwerkersovereenkomst nodig tussen die twee en dient dit stuk als het model dat gebruikt wordt zodra er een tweede aannemer op het systeem komt. De gemeente is een eigen verwerkingsverantwoordelijke; de afspraken tussen de gemeente en de aannemer staan in de overeenkomst tussen die twee en niet hier.

Artikel 1 — Onderwerp en duur

1. De exploitant stelt aan de aannemer een systeem beschikbaar waarmee de aannemer het uitvoeren van onkruid- en exotenbestrijding in de openbare ruimte vastlegt: foto's vóór en ná de behandeling, met adres, coördinaat en tijdstip, per project en per ronde, en het delen van dat resultaat met de opdrachtgever van de aannemer.
2. De exploitant verwerkt daarbij persoonsgegevens uitsluitend ten behoeve van die dienst. De aard van de verwerking, de categorieën persoonsgegevens en de categorieën betrokkenen staan in bijlage 1.
3. Deze overeenkomst gaat in op [IN TE VULLEN: ingangsdatum en looptijd] en loopt zolang de hoofdovereenkomst loopt. Verplichtingen die naar hun aard voortduren — geheimhouding, teruggave en verwijdering — blijven daarna gelden.

Artikel 2 — Instructies van de aannemer

1. De exploitant verwerkt de persoonsgegevens uitsluitend in opdracht en op schriftelijke instructie van de aannemer, behalve wanneer een wettelijke verplichting hem tot iets anders dwingt; in dat geval meldt hij dat vooraf, tenzij die wet dat verbiedt.
2. Het gebruik van het systeem door de aannemer en zijn medewerkers geldt als staande instructie. De aannemer bepaalt welke projecten er zijn, welke foto's er in het systeem komen, wie er toegang heeft en met welke opdrachtgever welke gegevens gedeeld worden.
3. De exploitant gebruikt de gegevens niet voor eigen doeleinden. De gegevens worden niet gebruikt om er producten of modellen mee te trainen, niet aan derden verstrekt en niet voor reclame of bezoekersanalyse gebruikt.
4. Meent de exploitant dat een instructie in strijd is met de AVG of andere wetgeving over gegevensbescherming, dan meldt hij dat direct aan de aannemer.
5. Toegang door de exploitant tot de gegevens van de aannemer beperkt zich tot wat nodig is voor het beheer, het oplossen van storingen en het uitvoeren van deze overeenkomst.

Artikel 3 — Geheimhouding

1. De exploitant houdt de persoonsgegevens geheim en legt dezelfde geheimhouding op aan iedereen die namens hem toegang heeft, ook na afloop van hun betrokkenheid.
2. Alleen personen die de gegevens voor hun werk nodig hebben, krijgen toegang. De sleutel waarmee de database benaderd kan worden staat uitsluitend in de omgevingsvariabelen van het hostingplatform en wordt niet in code, in een pagina of in een document opgenomen.

Artikel 4 — Beveiliging

1. De exploitant treft passende technische en organisatorische maatregelen. Wat er feitelijk staat:

   • De database staat op slot. Row level security staat op elke tabel aan, zonder policies; er is geen enkele weg naar de gegevens vanuit een browser. De enige weg loopt via de serverfuncties van dit ene project, met een sleutel die alleen in de omgevingsvariabelen van Cloudflare staat.
   • De scheiding tussen aannemers wordt in de serverfuncties afgedwongen, niet in de database: elke opvraging en elke wegschrijving draagt de omgeving van de ingelogde gebruiker, en daar bestaat een test op die de broncode leest. Dit heeft een keerzijde die hier uitdrukkelijk genoemd wordt: wie de databasesleutel heeft, kan bij de gegevens van alle aannemers. Wil een opdrachtgever dat niet, dan is een eigen, aparte installatie het antwoord.
   • Inloggen gebeurt met een e-mailadres en een inloglink; er zijn geen wachtwoorden. Elk token wordt gecontroleerd op handtekening, uitgever, publiek en geldigheid, met precies één toegestaan algoritme, en een mislukte controle geeft altijd hetzelfde neutrale antwoord.
   • Rollen en intrekbaarheid. Er zijn drie rollen (beheerder, kantoor, kijker); een kijker kan niets wijzigen. Elke toegangsweg is afzonderlijk in te trekken: een gebruiker deactiveren, een deellink of routelink intrekken, een instuurtoken verwijderen, of de kantoorcode wijzigen.
   • Auditlog. Elke schrijfactie in het kantoor levert een regel op met de actie, het doel, het tijdstip, het interne gebruikersnummer en het e-mailadres — nooit een wachtwoord, een code, een token of een foto, en de details zijn een samenvatting en geen kopie van het verzoek.
   • Verzoekbegrenzing. De publieke ingangen kennen een maximum aantal verzoeken per IP-adres per tijdvak. Het IP-adres staat daarvoor kort in een tijdelijke sleutel: tien minuten voor het insturen van foto's, het opvragen van foto's en logo's, de projectlijst van de ploegpagina, de controle en het tellen van foute kantoorcodes, één uur voor het aanmeldformulier en één minuut voor een geweigerde kantoorcode. Daarna verdwijnt het vanzelf.
   • Foutmeldingen bevatten nooit de inhoud van een verzoek, geen inloggegevens en geen foto's: alleen het pad zonder zoekreeks, de methode, de statuscode en de foutmelding. Een foutmelding draagt standaard géén aanduiding van de aannemer of van de gebruiker; een enkel onderdeel kan die er na het inloggen bewust aan toevoegen. In de kantoor- en veldapplicaties staat het meesturen van persoonsgegevens uitgeschakeld (sendDefaultPii: false).
   • Grens naar de opdrachtgever. Het portaal en het rapport dat aan een opdrachtgever hangt bevatten geen namen van medewerkers, geen kantoornotities, geen auditlog en geen gegevens van een andere opdrachtgever of aannemer. Die filtering gebeurt aan de serverkant en is niet met een instelling te omzeilen.
   • Verkeer loopt over TLS; het systeem is uitsluitend via HTTPS bereikbaar.
   • Back-up. Zodra de back-up-Worker van plan E is uitgerold, wordt er elke nacht een back-up van de database naar de objectopslag gemaakt, in dezelfde bucket als de foto's, onder een eigen map backups/<datum>/.
2. Eén blootstelling wordt hier uitdrukkelijk genoemd, omdat zij bewust is aanvaard: met het 32 tekens lange identificatienummer van een foto kan iedereen zonder code controleren dat die foto bestaat, wanneer hij ontvangen is, waar hij is gemaakt en bij welk project hij hoort. Dat is de prijs van een controleerbaar bewijs; de projectnaam bevat in de praktijk een gemeentenaam. De foto zelf, de naam van de medewerker en de notitie zitten er niet in, en er is geen enkele plek waar die identificatienummers opgesomd worden.
3. De maatregelen zijn geen certificering en er is geen audit door een derde uitgevoerd. Vragen over de beveiliging gaan naar [IN TE VULLEN: contactadres van de verwerker voor beveiligingsvragen].

Artikel 5 — Subverwerkers

1. De aannemer geeft de exploitant toestemming om de volgende subverwerkers in te schakelen:

   subverwerker	wat hij verwerkt	waar
   Cloudflare	Pages (de site en de serverfuncties), Workers (de back-up), KV (deel-, route- en omgevingstokens, en de sleutels voor de verzoekbegrenzing mét IP-adres), R2 (de foto's en de databaseback-up)	wereldwijd netwerk; [IN TE VULLEN: dataregio van Cloudflare]
   Supabase	de PostgreSQL-database met alle rijen uit bijlage 1, plus de inlogaccounts van het kantoor	[IN TE VULLEN: regio van het Supabase-project]
   de e-mailprovider	alleen wanneer EMAIL_API_KEY en EMAIL_FROM gezet zijn: het ontvangeradres, het onderwerp en de tekst van een melding	[IN TE VULLEN: naam en regio van de e-mailprovider]
   de foutendienst (Sentry-compatibel)	alleen wanneer er een DSN gezet is: het pad zonder zoekreeks, de methode, de statuscode en de foutmelding — nooit een verzoekbody, een token of een foto	[IN TE VULLEN: naam en regio van de foutendienst achter de DSN]

2. De exploitant legt elke subverwerker schriftelijk dezelfde verplichtingen op als die welke hier voor hemzelf gelden, en blijft jegens de aannemer aansprakelijk voor wat de subverwerker doet.
3. Wil de exploitant een subverwerker toevoegen of vervangen, dan meldt hij dat vooraf aan de aannemer: [IN TE VULLEN: termijn waarbinnen een nieuwe subverwerker vooraf gemeld wordt en waarbinnen bezwaar gemaakt kan worden]. Maakt de aannemer binnen die termijn gemotiveerd bezwaar, dan zoeken partijen een oplossing; komt die er niet, dan mag de aannemer de hoofdovereenkomst voor het betrokken deel beëindigen.
4. PDOK is geen subverwerker maar een derde. De kaartlagen en de adressuggesties worden rechtstreeks door de browser van de gebruiker bij PDOK (Kadaster, Nederland) opgehaald; PDOK ziet daarbij het IP-adres van die bezoeker, het opgevraagde gebied en de ingetypte zoekterm. De exploitant stuurt PDOK geen gegevens en ontvangt er ook niets van. PDOK verwerkt onder zijn eigen voorwaarden.

Artikel 6 — Doorgifte buiten de EER

1. De exploitant geeft persoonsgegevens niet buiten de Europese Economische Ruimte door, tenzij dat uit de inrichting van een subverwerker volgt en daarvoor een geldige grondslag bestaat.
2. Van belang is dat het netwerk van Cloudflare een wereldwijd netwerk is en dat de opslagregio's per dienst ingesteld moeten worden. Wat er feitelijk geldt: [IN TE VULLEN: doorgifte buiten de EER — welke subverwerkers dat doen, op welke grondslag en met welke aanvullende maatregelen].

Artikel 7 — Bijstand bij de rechten van betrokkenen

1. Krijgt de exploitant een verzoek van een betrokkene, dan beantwoordt hij dat niet zelf: hij stuurt het onverwijld door naar de aannemer.
2. De exploitant helpt de aannemer, voor zover dat redelijkerwijs mogelijk is, bij het beantwoorden van verzoeken om inzage, correctie, verwijdering, beperking, bezwaar en overdraagbaarheid. Praktisch is dat goed te doen: een foto is met haar identificatienummer of via adres, datum en project terug te vinden, en het verwijderen ervan haalt zowel de rij als de bytes uit de objectopslag weg.
3. De exploitant helpt de aannemer ook bij een gegevensbeschermingseffectbeoordeling en bij het beoordelen van een beveiligingsincident, met de informatie die hij redelijkerwijs kan geven.
4. Wat niet automatisch meegaat: een foto die al in een verstuurd rapport of in een back-up zit, moet daar apart uit worden gehaald.

Artikel 8 — Datalekken

1. Ontdekt de exploitant een inbreuk in verband met persoonsgegevens, dan meldt hij dat aan de aannemer: [IN TE VULLEN: termijn voor het melden van een datalek aan de verwerkingsverantwoordelijke; gebruikelijk is onverwijld en uiterlijk 24 uur].
2. De melding bevat in ieder geval wat er is gebeurd, wanneer, welke categorieën gegevens en welke (ongeveer) hoeveel betrokkenen het raakt, wat de vermoedelijke gevolgen zijn en welke maatregelen genomen of voorgesteld worden.
3. De aannemer beoordeelt als verwerkingsverantwoordelijke of er gemeld moet worden bij de Autoriteit Persoonsgegevens en of de betrokkenen geïnformeerd moeten worden. De exploitant doet die meldingen niet zelf.
4. Meldadres: [IN TE VULLEN: het meldadres voor een (vermoedelijk) datalek, aan beide kanten].

Artikel 9 — Audit

1. De aannemer mag laten controleren of de exploitant deze overeenkomst nakomt.
2. Voorwaarden: [IN TE VULLEN: hoe vaak er geauditeerd mag worden, wie de auditor mag zijn, welke aankondigingstermijn geldt en voor wiens rekening de kosten komen].
3. De exploitant werkt aan zo'n controle mee en levert de informatie die nodig is om aan te tonen dat de verplichtingen uit deze overeenkomst worden nagekomen. Een controle mag nooit inhouden dat de auditor toegang krijgt tot de gegevens van een andere aannemer.

Artikel 10 — Bewaren, teruggave en verwijdering

1. Bewaartermijnen. Het systeem dwingt op dit moment maar op een paar plaatsen een termijn af. Wat er feitelijk geldt:

   wat	bewaartermijn
   de rijen in de database en de foto's in de objectopslag	tot de aannemer ze verwijdert; het systeem ruimt niets uit zichzelf op
   het auditlog (kantoor_log)	geen eigen termijn; groeit mee met het gebruik
   de sleutels van de verzoekbegrenzing, met het IP-adres	tien minuten voor het insturen van foto's, het opvragen van foto's en logo's, de projectlijst van de ploegpagina, de controle en het tellen van foute kantoorcodes; één uur voor het aanmeldformulier; één minuut voor een geweigerde kantoorcode
   de onthouden rol van een ingelogde gebruiker	vijf minuten (een weigering: één minuut)
   de databaseback-ups onder backups/<datum>/, zodra de back-up-Worker van plan E is uitgerold	[IN TE VULLEN: hoeveel dagen de databaseback-ups bewaard blijven — er is nu geen opruimregel]
   de verstuurde inzendingen in de wachtrij op de telefoon van een medewerker	zeven dagen na verzending

2. Na afloop van de overeenkomst geeft de exploitant de persoonsgegevens op verzoek van de aannemer terug in een gangbaar bestandsformaat, en verwijdert hij daarna alle kopieën binnen [IN TE VULLEN: de termijn waarbinnen de gegevens na afloop teruggegeven en verwijderd worden], tenzij een wettelijke bewaarplicht zich daartegen verzet.

3. Twee plekken worden hierbij uitdrukkelijk genoemd, omdat ze anders blijven staan:

   • de databaseback-ups onder backups/<datum>/ in de objectopslag, zodra de back-up-Worker van plan E is uitgerold — die verdwijnen niet doordat rijen in de database verwijderd worden, en er is nu geen opruimregel;
   • de wachtrij in de browseropslag op de telefoon van een medewerker — die staat op het toestel zelf; verstuurde inzendingen worden na zeven dagen opgeruimd en de rest verdwijnt pas als de medewerker de gegevens van de website wist.
4. De exploitant bevestigt de verwijdering schriftelijk aan de aannemer.

Artikel 11 — Aansprakelijkheid

[IN TE VULLEN: de aansprakelijkheidsregeling, inclusief een eventueel maximum en de verhouding tot de hoofdovereenkomst].

Artikel 12 — Slotbepalingen

1. Bij strijd tussen deze verwerkersovereenkomst en de hoofdovereenkomst gaat deze verwerkersovereenkomst voor, voor zover het de verwerking van persoonsgegevens betreft.
2. Wijzigingen zijn alleen geldig als beide partijen ze schriftelijk zijn overeengekomen.
3. Toepasselijk recht en bevoegde rechter: [IN TE VULLEN: toepasselijk recht en bevoegde rechter].

Bijlage 1 — Aard van de verwerking, gegevens en betrokkenen

Onderwerp en aard: het vastleggen, opslaan, ordenen, tonen, exporteren en verwijderen van foto's en gegevens over behandelde locaties in de openbare ruimte, ten behoeve van de uitvoering en verantwoording van een bestrijdingsopdracht.

Categorieën betrokkenen:

• medewerkers van de aannemer die met de veldpagina insturen (hun naam staat op de inzending);
• kantoormedewerkers van de aannemer met een account;
• contactpersonen bij de opdrachtgever (een e-mailadres voor meldingen);
• personen die onbedoeld op een foto van de openbare ruimte staan.

Categorieën persoonsgegevens:

Er worden geen bijzondere categorieën persoonsgegevens gevraagd of bewust vastgelegd. Wat er op een foto van de openbare ruimte terechtkomt, is niet volledig te sturen.

Bijlage 2 — Subverwerkers

De tabel in artikel 5, met de aanvulling dat PDOK daar geen deel van uitmaakt en waarom (artikel 5 lid 4).

Bijlage 3 — Beveiligingsmaatregelen

De maatregelen in artikel 4. Deze bijlage wordt bijgewerkt zodra er iets aan de inrichting verandert; de datum bovenaan dit document geeft aan wanneer dat voor het laatst gebeurd is.