Verwerkersovereenkomst

Zodra een beveiligingsbedrijf de gegevens van zijn personeel in DutyGrid zet, blijft dat bedrijf de baas over die gegevens. Het bepaalt waarom ze er staan en wie erbij mag. DutyGrid bewaart en verwerkt ze in opdracht. In de woorden van de AVG: de klant is verwerkingsverantwoordelijke, DutyGrid is verwerker, en artikel 28 eist daar een schriftelijke overeenkomst voor, of de klant er nu om vraagt of niet.

De juridische kern hieronder volgt de modelbepalingen die de Europese Commissie heeft vastgesteld (uitvoeringsbesluit 2021/915). Die tekst is gratis te gebruiken en al getoetst; hem overnemen in plaats van zelf formuleren scheelt niet alleen geld maar ook het risico dat een eigen formulering later tekortschiet.

Wat wij zelf invullen zijn de bijlagen, en dat is precies het deel dat over DutyGrid gaat: welke gegevens, welke leveranciers, welke maatregelen, welke termijnen. Die zijn hieronder ingevuld door de code na te lopen, niet door op te schrijven wat we dachten dat er gebeurde.

Verwerkingsverantwoordelijke: de klant, hierna "het beveiligingsbedrijf".

Verwerker: Lovijn Security, handelend onder de naam DutyGrid, ingeschreven bij de Kamer van Koophandel onder nummer 74666347, gevestigd te Rijswijk.

DutyGrid verwerkt persoonsgegevens uitsluitend om de dienst te leveren: personeelsplanning, urenregistratie, verlofadministratie en incidentrapportage voor de beveiligingsbranche.

De overeenkomst loopt zolang het abonnement loopt en eindigt daarmee, met inachtneming van de bewaartermijnen in artikel 8.

DutyGrid verwerkt de gegevens alleen op schriftelijke instructie van het beveiligingsbedrijf. Het gebruik van de software geldt als die instructie.

DutyGrid gebruikt de gegevens niet voor eigen doelen. Concreet: niet voor productontwikkeling met herleidbare gegevens, niet voor marketing, en niet om statistieken te maken die tot een persoon of een bedrijf te herleiden zijn.

Betrokkenen:

• medewerkers van het beveiligingsbedrijf (beveiligers, planners, beheerders);
• contactpersonen bij opdrachtgevers van het beveiligingsbedrijf;
• personen die in een incidentmelding voorkomen. Een melding bevat een vrije omschrijving en kan een foto bevatten. Daarin kunnen bezoekers, klanten, slachtoffers, verdachten of omstanders worden beschreven of afgebeeld: mensen die geen enkele band met het beveiligingsbedrijf hebben en er niets over te zeggen hebben gehad. Dat maakt ze wel betrokkene.

Categorieën gegevens, zoals de software ze werkelijk opslaat:

De regel over notities en redenen stond er eerst ook niet, terwijl de tabel al een vrij opmerkingenveld bij verlof en de vrije omschrijving bij incidenten noemde. De software bewaart meer van dit soort velden: notities bij het plannen van een dienst, de reden bij een ruilverzoek, de reden bij een beschikbaarheidsuitzondering, de notitie bij een goedgekeurde overschrijving en de beheerdersnotitie bij uren. Wat daar wordt getypt bepaalt de invuller, niet de software, dus deze velden horen in een uitputtende opsomming thuis.

De regel over bedrijf en facturatie ontbrak eerst ook: de tabel somde alleen de gegevens van medewerkers op, terwijl de aanmelding de bedrijfsnaam, het KvK-nummer en de bedrijfsgrootte vastlegt en de facturatie daar de Stripe-referenties, de abonnementsstatus en de proefperiodedata bij zet. Het document erkent verderop, bij de bewaring na opzegging, zelf dat die naam en dat nummer bij een eenmanszaak tot een persoon herleidbaar zijn; wie dat erkent en de categorie toch niet in de uitputtende tabel zet, laat de eigenaar tekenen voor een inventaris waar zijn eigen gegevens niet in staan.

De technische regel stond er eerst evenmin. De tabel is bedoeld als uitputtende opsomming, en dan hoort er ook in te staan wat er ontstaat zonder dat iemand het intypt: artikel 7 en de subverwerkersbijlage erkennen zelf dat elke medewerker bij het inloggen zijn IP-adres en browsergegevens aan Google doorgeeft, dat de planner hetzelfde aan PDOK doorgeeft bij het instellen van een werklocatie, en dat het hostingplatform requestlogs bijhoudt. Wie dat wel in de bijlage zet en niet in de categorieën, noemt de partij maar niet het gegeven.

Vier categorieën verdienen aparte aandacht, omdat ze zwaarder wegen dan de rest:

Kopieën van identiteitsbewijzen. Een kopie paspoort bevat een BSN en een pasfoto. De wet staat een werkgever toe die voor zijn loonadministratie te bewaren, maar het is aan het beveiligingsbedrijf om te bepalen of het die kopie in DutyGrid wil zetten en of het BSN daarop is afgeschermd. DutyGrid dwingt dat niet af.

Locatiegegevens. Bij in- en uitklokken worden coördinaten vastgelegd. Dat is volgen van personeel op het werk, en het beveiligingsbedrijf hoort zijn mensen daarover te informeren. De gegevens worden alleen op die twee momenten vastgelegd en niet tussendoor.

Gezondheidsgegevens. Bij elke verlofaanvraag hoort een vrij opmerkingenveld, en de verlofadministratie kent de soort "ziek". Dat is een bijzondere categorie in de zin van artikel 9 AVG. De software kan niet zien wat iemand in dat veld typt.

Waar die soort vandaan komt, verdient een precisering die er in de eerste versie niet stond. Het verloftype is in de database vrije tekst; de twee aanvraagformulieren bieden vandaag vakantie, bijzonder verlof, onbetaald verlof en overig, en dus geen ziekmelding. De beoordeel- en beschikbaarheidsschermen herkennen "ziek" wel en tonen het als ziekmelding, dus die registraties bestaan: van eerder, of doordat een planner ze via de API aanmaakt. Gezondheidsgegevens komen daarmee vooral binnen via het opmerkingenveld bij een gewone verlofaanvraag, en dat veld hoort bij elk van de vier soorten.

Twee dingen horen hierover expliciet in deze overeenkomst te staan. Ten eerste: een werkgever mag registreren dat iemand ziek is en hoe lang, maar niet wat iemand mankeert; dat is voorbehouden aan de bedrijfsarts. Het is aan het beveiligingsbedrijf om zijn planners daarop te wijzen, en DutyGrid dwingt het niet af. Ten tweede: deze gegevens zijn zichtbaar voor planners en beheerders van het bedrijf, niet alleen voor een verzuimfunctionaris. Wie dat te ruim vindt, gebruikt het opmerkingenveld niet.

Het voorbeeld in het invulveld vroeg letterlijk om een diagnose ("Bijv: Griep") en is aangepast; er staat nu bij elke verlofsoort bij dat de medewerker niet hoeft te vermelden wat hij mankeert.

Incidentgegevens over derden. De omschrijving bij een incident is vrije tekst en kan gaan over mensen die niets met het beveiligingsbedrijf te maken hebben. Komt daar informatie in te staan over bijvoorbeeld gezondheid, etniciteit of een strafbaar feit, dan is ook dat een bijzondere categorie. Het beveiligingsbedrijf bepaalt hoe zijn beveiligers een melding schrijven; DutyGrid slaat op wat er wordt ingevoerd. Foto's bij een melding staan bij Vercel Blob op een adres dat niet te raden is maar wel opvraagbaar voor wie het kent; zie de bijlage met subverwerkers.

De maatregelen zoals ze in de software zijn getroffen:

• Wachtwoorden worden gehasht opgeslagen met Argon2. Bewust "gehasht" en niet "versleuteld": er bestaat geen sleutel waarmee ze terug te lezen zijn, ook niet voor DutyGrid zelf. In een opsomming van maatregelen zijn dat twee verschillende dingen, en een auditor leest ze ook zo.
• Sessies lopen via een willekeurig sessietoken zonder ingebakken inhoud, dat in een HttpOnly-cookie staat en bij elk verzoek in de database wordt opgezocht, met een beperkte geldigheidsduur en verwijdering bij uitloggen. Bij een wachtwoordwijziging vervallen alle overige sessies van het account; de sessie waarmee de wijziging wordt doorgevoerd blijft geldig. Bewust niet "alle sessies vervallen": dat zou meer beloven dan de code doet, en het verschil is niet academisch, want een gestolen kopie van precies dat actuele token overleeft de wachtwoordwijziging tot het verloopt of tot er wordt uitgelogd. Wat de toegang draagt is het opzoekbare token, en een maatregelenlijst hoort te beschrijven wat de toegang draagt.
• Toegang is gebonden aan een rol: een beveiliger ziet zijn eigen rooster, een planner het bedrijf, en alleen de eigenaar kan het abonnement beheren. Bewust "beheren" en niet "erbij komen": een tweede beheerder kan de abonnementsgegevens wél inzien; alleen afsluiten, wijzigen en het betaalportaal zijn aan de eigenaar voorbehouden. Een ruimere formulering zou iets beloven wat de software niet doet.
• Gegevens van verschillende bedrijven zijn gescheiden op bedrijfsniveau; elke vraag aan de database is gebonden aan het bedrijf van de ingelogde gebruiker.
• Kopieën van identiteitsbewijzen zijn alleen op te vragen via het profiel van die ene medewerker. Het overzicht van medewerkers stuurt de verwijzingen naar die documenten niet mee, ook niet verborgen in het antwoord van de server.
• Meekijken met een bedrijf vanuit het beheer, het overnemen van een account en het automatisch genereren van planningen worden vastgelegd in een logboek, met wie en wanneer.
• Al het verkeer verloopt over TLS.
• Toegang tot de productieomgeving is beperkt tot de beheerder van DutyGrid.

Iedereen die namens DutyGrid toegang heeft tot de gegevens is tot geheimhouding verplicht.

DutyGrid schakelt de partijen in die staan in de bijlage met subverwerkers onderaan deze pagina. Het beveiligingsbedrijf geeft daar bij het aangaan van de overeenkomst toestemming voor.

Voor een nieuwe subverwerker informeert DutyGrid het beveiligingsbedrijf vooraf, zodat het bezwaar kan maken.

De lijst wordt bewaakt door een geautomatiseerde controle op de broncode, die faalt zodra er een externe partij bij komt die er niet in staat.

De database staat in Frankfurt en de applicatie draait in dezelfde regio. Twee partijen in de bijlage geven gegevens door aan de Verenigde Staten, beide op basis van het EU-VS-datakader:

• Stripe, voor de abonnementsgegevens van de eigenaar van het bedrijf;
• Google, dat het IP-adres en de browsergegevens ontvangt van iedere bezoeker van de marketing- en accountpagina's, doordat die pagina's daar hun lettertypen ophalen. Dat raakt ook elke medewerker die inlogt.

De reisafstandberekening via Google staat klaar maar is niet actief. Zodra die wordt aangezet gaan woonadressen van medewerkers naar een verwerker buiten de EU; dat vergt een aanpassing van deze overeenkomst voordat het zover is.

Zolang het abonnement loopt bewaart DutyGrid de gegevens die het beveiligingsbedrijf invoert.

Na opzegging worden de gegevens binnen negentig dagen verwijderd. Een proefperiode die verloopt zonder abonnement wordt binnen dertig dagen opgeruimd. Beide termijnen worden uitgevoerd door een dagelijkse taak.

De vijf dingen die daarvoor in de code moeten zitten, zitten erin: de taak wordt dagelijks aangeroepen door een geplande taak, de selectie kent naast verlopen proefperiodes ook de opgezegde bedrijven in beide spellingen, er is een opzegmoment om de negentig dagen vanaf te tellen, de taak veegt de foto's en documenten bij de opslagdienst, en hij verwijdert het Stripe-klantprofiel. Een geautomatiseerde controle houdt dit artikel aan die vijf eisen vast: valt er één weg uit de code, dan eist de controle hier het voorbehoud terug.

Wat de opruiming bewust laat staan, hoort hier ook te staan, want anders belooft dit artikel meer dan het waarmaakt. De inlogaccounts van een opgeruimd bedrijf worden geanonimiseerd en niet verwijderd: naam en wachtwoord krijgen een vaste markering, en de bedrijfsnaam op het account, de profielfoto, het KvK-nummer, de 2FA-geheimen en de Stripe-verwijzingen worden gewist, maar het e-mailadres blijft staan, en dat geldt voor de eigenaar én voor de planners en medewerkers met een account. De reden is dat de registratieroute daarop controleert om te voorkomen dat hetzelfde bedrijf zichzelf een nieuwe proefperiode geeft. Er staat vandaag geen einddatum op die bewaring: na de cooldown van negentig dagen vanaf het moment van opruimen maakt de registratieroute het adres pas weer vrij op het moment dat iemand het opnieuw gebruikt, en wie niet terugkomt blijft er met zijn adres in staan. Die keuze hoort besproken en begrensd te zijn; de lijst onderaan noemt hem.

Van de bedrijfsregistratie zelf blijft een romp bestaan: het interne nummer, de status, het opzegmoment en de tijdstempels van de opruiming. De bedrijfsnaam krijgt dezelfde vaste markering als de accounts, en het KvK-nummer, de verwijzing naar de eigenaar en de bedrijfsgrootte worden gewist. De Stripe-referenties blijven op die romp staan totdat de verwijdering van het klantprofiel bij Stripe aantoonbaar is gelukt en gaan dan in dezelfde stap mee weg; eerder wissen zou een tijdelijk mislukte Stripe-verwijdering permanent maken. Oudere inlogregistraties uit de begintijd van de software gaan met de tenant mee weg, met één smalle uitzondering voor de platformtoegang van de beheerder van DutyGrid, die in een logboekregel wordt vastgelegd.

Het beveiligingsbedrijf kan tijdens de looptijd een export van zijn gegevens opvragen.

Facturatiegegevens bewaart DutyGrid zeven jaar, omdat de fiscale bewaarplicht dat voorschrijft. Dat is een eigen wettelijke verplichting en geen verwerking in opdracht.

Vraagt een medewerker om inzage, correctie of verwijdering, dan is het beveiligingsbedrijf degene die daarop antwoordt. DutyGrid helpt daarbij binnen vijf werkdagen met de gegevens die het onder zich heeft.

Bij een inbreuk op de beveiliging waarschuwt DutyGrid het beveiligingsbedrijf zonder onnodige vertraging en uiterlijk binnen achtenveertig uur nadat de inbreuk bekend is geworden, met wat er bekend is over de aard, de betrokken gegevens en de genomen maatregelen.

De melding aan de Autoriteit Persoonsgegevens en aan de betrokkenen doet het beveiligingsbedrijf; dat is zijn verantwoordelijkheid als verwerkingsverantwoordelijke.

Het beveiligingsbedrijf mag eens per jaar controleren of DutyGrid zich aan deze afspraken houdt, op eigen kosten en na aankondiging van dertig dagen.

Het beveiligingsbedrijf verklaart dat het een geldige grondslag heeft voor de gegevens die het aanlevert, en dat het zijn medewerkers heeft geïnformeerd over de verwerking.

Dat is de verplichting van het beveiligingsbedrijf als verwerkingsverantwoordelijke en niet van DutyGrid. Deze zin staat er zodat het schriftelijk vastligt, zonder dat er een gesprek over gevoerd hoeft te worden.

Nederlands recht. Op aansprakelijkheid is de regeling uit de algemene voorwaarden van toepassing.

Deze lijst is opgesteld door de code na te lopen op externe aanroepen, niet door op te schrijven welke diensten we denken te gebruiken. Hij wordt bewaakt door een geautomatiseerde controle op de broncode die faalt zodra er een externe partij bij komt die hier niet staat. Laatst nagelopen: 16 augustus 2026.

In gebruik:

Klaargezet maar nog niet actief: Google (Distance Matrix, los van Google Fonts hierboven) via maps.googleapis.com, voor de reisafstand tussen woonadres en werklocatie. Dit is de zwaarste van de hele lijst: zodra de bijbehorende sleutel wordt gezet, gaan bij het inplannen van elke dienst het woonadres van de medewerker en het objectadres naar Google. Die sleutel staat bewust niet in de productieomgeving, en deze doorgifte moet in de overeenkomst staan voordat hij wordt aangezet, niet erna; artikel 7 zegt hetzelfde.

De volledige toelichting per partij, en de lijst van partijen die eerder zijn weggehaald en waarom, is op te vragen via info@dutygrid.nl.

Wat hier goed aan is. De bijlagen kloppen met de software. Ze zijn opgesteld door de code na te lopen, en de subverwerkerslijst wordt door een geautomatiseerde controle bewaakt. Dat is het deel waar de meeste standaardovereenkomsten juist rammelen, want daar staat vaak wat iemand dacht dat er gebeurde.

Wat er nog moet. De partijgegevens zijn hierboven ingevuld. Wat rest is de modelbepalingen van uitvoeringsbesluit 2021/915 als basistekst overnemen waar dit document ze samenvat.

Wanneer u er wél een jurist bij haalt. Zodra een klant met zijn eigen versie komt, met eigen bepalingen over aansprakelijkheid, boetes of auditrechten. Dat gebeurt vanzelf bij een grotere opdrachtgever. Voor een eerste klant met deze basis is dat niet nodig.

Eén punt is afgerond: de dagelijkse opruimtaak. Artikel 8 belooft twee termijnen, en daar stond tot 19 augustus 2026 een voorbehoud bij: vijf dingen moesten daarvoor in de code staan. Alle vijf zitten erin (de geplande dagelijkse aanroep, de opgezegde bedrijven in beide spellingen in de selectie, het opzegmoment, de veeg bij de opslagdienst en de verwijdering van het Stripe-klantprofiel), en de geautomatiseerde controle die het voorbehoud aan de code vasthoudt volgt sindsdien het echte aanroeppad, in beide richtingen: mist de code een eis, dan eist de controle het voorbehoud; heeft de code alles, dan eist hij dat het voorbehoud weggaat.

Drie dingen die pas mogen als ze kloppen. Een overeenkomst mag niets beloven wat de software niet doet. Deze drie punten staan er daarom bewust nog niet in als toegezegde maatregel:

1. De e-mailadressen van een opgeruimd bedrijf. De opruiming anonimiseert de accounts en bewaart het e-mailadres, van iedereen met een account en zonder einddatum, om een tweede proefperiode te blokkeren. De registratieroute maakt zo'n adres na de cooldown pas weer vrij op het moment dat iemand het opnieuw gebruikt; wie niet terugkomt, blijft er met zijn adres in staan. Dat is te verdedigen, maar niet zonder termijn en niet zonder het op te schrijven. Artikel 8 noemt het nu; wat er nog moet gebeuren is kiezen: een einddatum eraan hangen, of het adres vervangen door een onomkeerbare afdruk waarmee de blokkade net zo goed werkt. Zolang die keuze niet is gemaakt en gebouwd, staat de uitzondering in het artikel en niet in de kleine lettertjes.
2. Het auditspoor op gewone mutaties. Een eerdere versie van artikel 4 beloofde dat wijzigingen aan personeels-, klant- en opdrachtgegevens in een logboek terechtkomen. Dat was niet waar: die routes schreven niets naar het logboek. Vandaag wordt alleen vastgelegd wat hierboven in artikel 4 staat: meekijken, accountovername, automatisch plannen en beheeracties. De bredere logging wordt in een aparte wijziging gebouwd; pas als die op productie draait, mag deze belofte terug in artikel 4.
3. De lettertypen van Google. De aanmeldpagina haalt lettertypen bij Google op, waardoor Google het IP-adres krijgt van iedere medewerker die inlogt. Dat staat nu eerlijk in de bijlage, en daarmee klopt het document. Het blijft wel een doorgifte naar de Verenigde Staten voor iets wat net zo goed vanaf de eigen server geleverd kan worden. Doe dat liever vóór ondertekening; dan valt deze partij helemaal van de lijst.

Vragen over deze overeenkomst? Mail info@dutygrid.nl.