Privacyverklaring — 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 de verwerkingsverantwoordelijke en staat er bewust leeg.

Laatst bijgewerkt: [IN TE VULLEN: datum]

Waar deze tekst over gaat. Hij beschrijft de inrichting van het systeem zoals die in fase 3 (plannen A tot en met E) is ontworpen en gebouwd. Een aantal onderdelen werkt pas zodra de eigenaar er een omgevingsvariabele voor zet — de e-mailmeldingen, de foutrapportage en de nachtelijke back-up. Waar dat zo is, staat het er met zoveel woorden bij. De productnaam is Veldapp.

0. Wat er in dit concept nog ingevuld moet worden

1. Wie is verantwoordelijk en wie verwerkt

De aannemer is verwerkingsverantwoordelijke voor de gegevens die in zijn omgeving staan: hij bepaalt welke opdrachten hij uitvoert, welke foto's zijn ploeg maakt en wie er bij zijn kantoor mag. Zijn gegevens: [IN TE VULLEN: naam, KvK-nummer, vestigingsadres en contactadres van de aannemer (verwerkingsverantwoordelijke)].

De exploitant van het systeem is verwerker. Hij bouwt en beheert de software en de omgeving waarin de gegevens staan, en verwerkt ze uitsluitend in opdracht van de aannemer. Zijn gegevens: [IN TE VULLEN: naam, KvK-nummer, vestigingsadres en contactadres van de exploitant van het systeem (verwerker)].

Vraag voor de jurist. Op dit moment kunnen de aannemer en de exploitant dezelfde rechtspersoon zijn. Is dat zo, dan moet vastgelegd worden hoe die twee rollen zich verhouden zodra er een tweede aannemer op hetzelfde systeem werkt.

De gemeente is zelf verwerkingsverantwoordelijke voor de opdracht die zij verstrekt en voor de gegevens die zij in dat kader van de aannemer ontvangt (het portaal en de rapportage). Voor de gegevens van de medewerkers van de aannemer is zij dat niet, en zij krijgt die ook niet te zien (zie §7).

Contact over deze verklaring: [IN TE VULLEN: is er een functionaris gegevensbescherming aangesteld, en zo ja: naam en contactadres].

2. Waarvoor het systeem gebruikt wordt

De aannemer bestrijdt onkruid en invasieve exoten in de openbare ruimte, in opdracht van gemeenten. Het systeem legt vast dát en wannéér een locatie behandeld is:

1. de ploeg maakt op straat een foto vóór en ná de behandeling, met plaats en tijd;
2. het kantoor sorteert die foto's per project, locatie en ronde en houdt de voortgang bij;
3. de gemeente krijgt een deellink naar een portaal en/of een rapport met het resultaat;
4. het kantoor kan de gegevens exporteren als bewijs bij de facturatie of een aanbesteding.

De grondslag: [IN TE VULLEN: de grondslag per verwerking — uitvoering van de overeenkomst met de gemeente, gerechtvaardigd belang, of een wettelijke plicht].

Er wordt in dit systeem niet aan profilering gedaan, er worden geen geautomatiseerde besluiten over personen genomen, en er zit geen advertentie- of bezoekersanalysecode in de pagina's.

3. Welke gegevens er in het systeem staan

Dit is de volledige lijst zoals die op dit moment in het datamodel staat, met per categorie de reden waarom hij er is.

3.1 De inzending van de ploeg (tabel submissions)

Een foto van de openbare ruimte kan onbedoeld personen, kentekens, huisnummers en gevels bevatten. Dat is geen doel van het systeem, maar het is wel wat er kan gebeuren als je op straat fotografeert. De ploeg wordt geïnstrueerd de begroeiing in beeld te brengen en niet de mensen of de auto's eromheen.

3.2 De locaties (tabel locaties)

Adres, genormaliseerd adres, coördinaat, soort, de bron van de locatie, en — bij een import uit een bestand van de gemeente — het identificatienummer uit dat bronbestand en een verwijzing naar de import. Deze rijen komen uit een aanlevering van de gemeente, uit een kartering door de ploeg, of uit een foto.

3.3 De kantooraccounts (tabel gebruikers)

E-mailadres, naam, rol (beheerder, kantoor of kijker), of het account actief is, wanneer de uitnodiging is verstuurd en wanneer de gebruiker voor het laatst is gezien. Daarnaast de interne verwijzing naar het inlogaccount bij de authenticatiedienst. Deze gegevens zijn nodig om iemand toegang te kunnen geven en die weer te kunnen intrekken.

Van de aannemer zelf (tabel tenants) staan de bedrijfsnaam, een korte naam voor in de URL, de status van de omgeving, een e-mailadres voor meldingen en de huisstijl (logo, kleur, introtekst).

3.4 Het auditlog (tabel kantoor_log)

Elke schrijfactie in het kantoor levert één regel op: welke actie, waarop, wanneer, en door wie — met het interne gebruikersnummer en het e-mailadres. kantoor_log bevat nooit een wachtwoord, een toegangscode of een token, en de bijgeschreven details zijn een samenvatting en geen kopie van het verzoek: tekstvelden worden op 200 tekens afgekapt en lange lijsten op 50 waarden, met alleen het aantal erbij.

Ook een geweigerde toegangspoging levert een regel op, maar alleen in twee gevallen: een onjuiste kantoorcode, of een geldig ondertekend token van iemand die niet (meer) binnen mag. In dat laatste geval staan het interne gebruikersnummer en het e-mailadres uit dat token in de regel, zonder omgeving erbij. Een kapot of verlopen token levert géén regel op.

3.5 De opdrachtgever (tabel opdrachtgevers)

Naam van de gemeente of andere opdrachtgever, een logo, een kleur, een introtekst voor het portaal en een e-mailadres waarop meldingen aankomen als de aannemer die aanzet.

3.6 Tijdelijke technische gegevens

• IP-adres. Voor het begrenzen van het aantal verzoeken bewaart het systeem het IP-adres van de bezoeker 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; er wordt geen geschiedenis van IP-adressen bijgehouden.
• Toegangstokens. De deellink van de gemeente, de routelink van de ploeg, de instuurlink van de ploeg en een eventuele publieke insluitlink zijn elk een willekeurige reeks tekens in een tijdelijke opslag. Ze zijn per stuk in te trekken.
• De ingelogde gebruiker. Na een geslaagde inlog worden de rol en de omgeving van die gebruiker hooguit vijf minuten onthouden, zodat niet elk verzoek de database hoeft te bevragen; een weigering wordt hooguit één minuut onthouden. De publieke sleutels van de inlogdienst worden zes uur bewaard.
• De wachtrij op de telefoon van de medewerker. De veldpagina bewaart een inzending (foto, coördinaat, tijd, naam, notitie) in de browseropslag van het toestel zelf totdat hij verstuurd is. Verstuurde rijen worden zeven dagen na verzending opgeruimd. Die opslag staat op het toestel van de medewerker en niet bij een verwerker.

4. Wie de gegevens verwerken

Er zijn op dit moment geen andere verwerkers. Doorgifte buiten de Europese Economische Ruimte: [IN TE VULLEN: doorgifte buiten de EER — welke verwerkers dat doen en op welke grondslag].

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), en de zoekreeks van een adres wordt weggehaald voordat er iets verstuurd wordt — juist omdat daar de tokens in staan.

5. PDOK: geen verwerker maar een derde

De kaartlagen (achtergrondkaart en luchtfoto) en de adressuggesties komen van PDOK, de open gegevensvoorziening van het Kadaster. PDOK is geen verwerker maar een derde: de browser van de gebruiker haalt die kaarttegels en adressuggesties rechtstreeks bij PDOK op, zonder dat ons systeem ertussen zit. PDOK ziet daarbij het IP-adres van de bezoeker, het opgevraagde gebied en de ingetypte zoekterm. Wij ontvangen daar niets van en sturen er niets naartoe. PDOK verwerkt die gegevens onder zijn eigen voorwaarden (Kadaster, Nederland).

6. Hoe lang de gegevens bewaard blijven

Eerlijk opgeschreven wat er nú geldt, ook waar het antwoord "onbepaald" is:

Het auditlog (kantoor_log) kent geen eigen bewaartermijn en groeit mee met het gebruik. Wie een termijn wil, moet die vaststellen — voor de foto's en de rijen net zo goed: [IN TE VULLEN: hoe lang foto's en rijen na afloop van een opdracht bewaard blijven — het systeem dwingt hier nu geen termijn af].

7. Wie wat te zien krijgt

• Het kantoor van de aannemer ziet alles van zijn eigen omgeving: foto's, locaties, notities, de naam van de medewerker op een inzending, en het auditlog.
• De gemeente ziet via de deellink of het rapport alleen wat bij haar eigen opdracht hoort: adres, coördinaat, soort, status, datum en de foto's. De gemeente ziet géén namen van medewerkers, geen kantoornotities, geen auditlog, en niets van een andere opdrachtgever of een andere aannemer. Die grens wordt aan de serverkant afgedwongen en niet in de browser, en een instelling in een rapportprofiel kan hem niet omzetten voor een rapport dat aan een opdrachtgever hangt.
• De ploeg ziet op de veldpagina de wachtrij op haar eigen toestel: wat zij zelf instuurt. Bij een routelink ziet zij daarnaast de adressen van die route met de status per adres, ook waar een collega die status heeft gezet.
• Een andere aannemer ziet niets van deze omgeving.

Eén ding is openbaar zonder code, en dat is een bewuste keuze: met het 32 tekens lange identificatienummer van een foto kan iedereen controleren dat die foto bestaat, wanneer hij ontvangen is, waar hij gemaakt is en bij welk project hij hoort. Dat is de prijs van een controleerbaar bewijs, en de projectnaam bevat in de praktijk een gemeentenaam. De foto zelf, de naam van de medewerker, de notitie en de nauwkeurigheid zitten er niet in, er is geen enkele plek waar die identificatienummers opgesomd worden, en de verzoekbegrenzing maakt het aftasten ervan onbruikbaar.

8. Hoe de gegevens beveiligd zijn

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, die daarvoor een sleutel gebruiken die alleen in de omgevingsvariabelen van Cloudflare staat en nooit in een pagina terechtkomt.
• Dat betekent ook, met zoveel woorden: wie die sleutel heeft, kan bij de gegevens van alle aannemers. De scheiding tussen aannemers wordt afgedwongen in de serverfuncties — elke opvraging draagt de omgeving van de ingelogde gebruiker — en niet door de database zelf. Voor een opdrachtgever die dat niet acceptabel vindt, is een eigen, aparte installatie het antwoord.
• Inloggen gaat met een e-mailadres en een inloglink; wachtwoorden bestaan niet in dit systeem. Een token wordt bij elk verzoek gecontroleerd op handtekening, uitgever, publiek en geldigheid, met precies één toegestaan algoritme. Een mislukte controle geeft altijd hetzelfde neutrale antwoord.
• Toegang intrekken kan per weg: een gebruiker deactiveren, een deellink of routelink intrekken, een omgevingstoken verwijderen, of de kantoorcode wijzigen.
• Rollen. Een kijker kan niets wijzigen, en het beheerscherm voor het hele platform vereist een echt account: met de kantoorcode alleen is het niet te bereiken.
• Verzoekbegrenzing. De publieke ingangen (insturen, de controle van een foto en de acties in het portaal) kennen een maximum aantal verzoeken per IP-adres per venster (tien minuten; één uur voor het aanmeldformulier; één minuut voor een geweigerde kantoorcode). Ook foute kantoorcodes worden per IP-adres geteld: na tien foute pogingen binnen tien minuten krijgt elke volgende foute poging een wachttijd.
• In een foutmelding en in het auditlog komt nooit een token, een code, een wachtwoord of een foto. Zie §4 voor wat er wél in een foutmelding staat.
• Back-up. Zodra de back-up-Worker van plan E is uitgerold, wordt er elke nacht een back-up van de database in de objectopslag gemaakt, in dezelfde bucket als de foto's, onder een eigen map.

9. De rechten van betrokkenen

Wie in dit systeem voorkomt — een medewerker van de aannemer, een kantoorgebruiker, en in uitzonderingsgevallen iemand die op een foto staat — heeft het recht om zijn gegevens in te zien, te laten corrigeren, te laten verwijderen, de verwerking te laten beperken, daartegen bezwaar te maken en de gegevens in een gangbaar bestandsformaat te ontvangen.

Een verzoek gaat naar de aannemer, want die is verwerkingsverantwoordelijke: [IN TE VULLEN: het adres waarop een betrokkene zijn rechten uitoefent]. Komt het verzoek toch eerst bij de exploitant binnen, dan verwijst die door naar de aannemer en voert hij alleen uit wat de aannemer opdraagt.

Praktisch: een foto is met het identificatienummer, of via het adres, de datum en het project, terug te vinden, en het kantoor kan hem verwijderen — waarbij zowel de rij als de bytes in de objectopslag weggaan. Staat er iemand herkenbaar op een foto en wil die persoon dat niet, dan is het verwijderen van die ene foto de gebruikelijke afhandeling. Let op: een foto die al in een verstuurd rapport of in een back-up zit, moet daar apart uit gehaald worden.

Er kan altijd een klacht ingediend worden bij de Autoriteit Persoonsgegevens.

10. Datalek

Vermoedt iemand dat er gegevens op straat liggen — een gelekte deellink, een gestolen telefoon met de veldpagina erop, een verkeerd verstuurd rapport — dan hoort dat direct gemeld te worden bij [IN TE VULLEN: het adres waarop een vermoeden van een datalek gemeld wordt]. De aannemer beoordeelt als verwerkingsverantwoordelijke of het gemeld moet worden bij de Autoriteit Persoonsgegevens (binnen 72 uur) en of de betrokkenen geïnformeerd moeten worden. De exploitant meldt een lek dat hij zelf constateert aan de aannemer, binnen de termijn die in de verwerkersovereenkomst staat, en helpt bij het vaststellen van de omvang.

11. Wijzigingen

Verandert er iets aan het systeem waardoor deze verklaring niet meer klopt — een nieuwe verwerker, een nieuwe categorie gegevens — dan wordt deze tekst bijgewerkt en krijgt hij bovenaan een nieuwe datum. Zolang er CONCEPT boven staat, is de tekst niet door een jurist vastgesteld en mag hij niet als de definitieve privacyverklaring aan een gemeente gegeven worden.